As a follow-up to yesterday's problems with exhausted identity ranges, I have come to a realization which I am now adopting as a best practice and I highly recommend for others:

The reasoning behind this advice is that when @identityrangemanagementoption = 'auto' (the default in Management Studio), identity ranges will be allocated for all subscribers, even though they will never use these ranges because the table article is read-only. Yet, if the table has a small datatype for a primary key (such as tinyint or smallint) it is quite likely that the identity range will be exhausted (with the default identity range being 1000, this doesn't take many subscribers) and when this happens synchronization will cease.

If there is a reason for allocating these ranges to read-only table articles or for leaving automatic identity range mangement enabled, please post it in the comments.

This morning I encountered a fun new error message during SQL Server synchronization. The error message (from the Replication Monitor) was:

First, some background: I am using a (very) simple replication topology with a single publisher running SQL Server 2005 and ~10 subscribers running SQL Server 2005 Express (all with the latest service packs and patches, of course). No re-publishing servers, multiple publications, etc. The error occurred not long after I had added 2 new subscribers (which turns out to be quite important).

Note: For replication topologies which do include a re-publishing server, the error may be explained by KB941989, which can be solved by installing Cumulative Update 4 (or later updates including the fixes).

To find the cause of this error message, some technical information about how identity values are managed during replication is needed. A key source of information for table articles with identity columns is the MSmerge_identity_range table. This table contains a row for each range of values assigned to each subscriber for each article as well as an additional row holding the entire range of identity values for the table article (this is the row with is_pub_range = 1). In order to make sense of this table, the artid column can be joined to the sysmergearticles table and subid can be joined to the sysmergesubscriptions table. Take note of the max_used column (which only has a value for pub_range rows); this column holds the end of the maximum range that has been allocated for the article (technically 1-past-the-last, since it holds the max of next_range_end, but conceptually it is the end). When this value is near the end of the pub_range, then the available identity ranges are almost exhausted.

One quick way to determine if the problem is due to exhaustion of the available identity range, is with a query similar to the following:

Note: In the (very unusual) case that the subscribers are given larger ranges than the publisher(s), replace pub_range with sub_range in the above query. If this query returns any rows, then the problem has been identified. The table articles listed have exhausted their available identity ranges. If the range_end value is below the maximum value for the identity datatype, then it should be possible to increase this value and solve the problem quite easily (Note: I have not found a documented way to do this "safely" and modifying this table directly is probably dangerous, but it solved the problem for me. YMMV). If the range_end value is the maximum for the datatype, then the underlying datatype will likely need to be changed (or significant compaction of the values will need to be done, somehow) and the article dropped and re-added to the publication.

Other sources that I have come across suggested running the sp_adjustpublisheridentityrange stored procedure. It should be safe to run in any case, although I didn't find it particularly useful.

Another suggestion for similar errors that was suggested on the MSDN Forums is to check the identity value on the publisher and that it is within the range allocated to the publisher (both in MSmerge_identity_range and in the check constraint that replication adds to the table for checking the identity range value).

If all of the above suggestions fail, my best suggestion is to watch the synchronization in SQL Profiler (for server versions where SQL Profiler is not available, AnjLab SQLProfiler is a nice alternative) and to examine some of the replication stored procedures using Management Studio (right click->Modify to see the SQL of the SP) to get ideas for what might be going wrong. In particular, consider examining sp_adjustpublisheridentityrange, MSget_identity_range_info, MSpub_adjust_identity, and similar identity management stored procedures.

Good Luck!

For the unfamiliar, the Exec method of WshShell (used in Windows scripting) runs an application and provides access to that application's standard streams as TextStream objects. The problem with this method is that the blocking behavior of these streams is not defined (as noted in the comments on the StdOut property) and, more importantly, is impossible to use safely. The problem, familiar to anyone who has dealt with reading and writing to child programs, is that it is very easy to block while attempting to read from (or write to) the child process. What makes this problem worse is that TextStream provides no method for dealing with blocking; there is no way to set non-blocking mode or to check if input is ready to be read or to check if it would be safe to write (at least, none that I am aware of).

As a demonstration of the problem, consider the following applications. First, the child program (written in C):

Second, the attempt to read the output of this program from a script (written in JScript): The idea was that the AtEndOfStream property might indicate that there is no more data to read. If you attempt to run this program you will find that that is not the case. Instead, AtEndOfStream indicates that no more input will ever be read. So, the script spins waiting for more output (or the end of output) while the child program is blocked writing to stderr and we are deadlocked. So, what do we do? We can interleave reads to stdout and stderr, but we would still block if the buffer is filled on one of the streams and empty on the other. Unless we can predict the output of the program, or the amounts of information printed to its stdout or stderr will be small enough to not cause it to block, there is no way to safely run the program (again, that I am aware of).

The solution that I came up with (which has its own drawbacks in terms of performance), is to write the program output to files, then read it back in the script once the program has finished. This solves the deadlock problem at the expense of decreasing the performance by requiring the output to be written to disk as an intermediate step (although the OS may not flush it to the physical disk). The code for this solution is presented below:

Note that if the script will not continue to work while the program is being run and nothing needs to be written to the standard input of the program, it would be better to replace Exec with Run, which can wait for the program to finish without the sleep/wait loop.

Remember, Don't ever WshShell.Exec a command directly if you are not sure of its inputs and outputs and your script deadlocking would be a problem.

After some moderate difficulty (mostly due to bugs 507536 and 552480) I have finally managed to setup Eclipse as a build environment for Apache Tomcat.  The process is as follows (Note that $DEVELSERVERDIR can be anything/anywhere that you have access to as a normal user):

1. aptitude install eclipse tomcat6-user
2. Install Java EE Development Tools plugin from the Eclipse WPT Project
3. tomcat6-instance-create $DEVELSERVERDIR
4. cd $DEVELSERVERDIR
5. ln -s /usr/share/tomcat6/lib
6. ln -s /usr/share/tomcat6/bin/bootstrap.jar bin
7. cp /var/cache/tomcat6/catalina.policy conf
8. Configure tomcat and eclipse to your liking and add the Tomcat instance to the Eclipse servers list

At this point you should be able to import/create projects which can be run on your local server instance. (If not, you are in the same boat I was in this morning... and best of luck to you)

Background

Windows remembers all devices which have previously been connected to the system and retains the drivers for those devices such that if the device is reconnected the driver searching and loading process can be avoided. This is a very useful behavior for devices which are commonly connected and disconnected (e.g. USB devices), but it has the side-effect that devices which are used once, or used for a finite amount of time, will forever be remembered by Windows. It is unclear exactly what "remember" means in this context, as I am not exactly sure what sort of storage or pre-loading of the drivers is occurring, but I can confirm that drivers for these "non-present" devices can affect the system, either with compatibility problems introduced by the driver or with performance problems from many accumulated "non-present" devices (Note: I doubt the performance impact is noticeable on all but extreme cases - like replacing your motherboard more than once with different hardware...).

Managing "Non-Present" Devices

The process for viewing these "non-present" devices in Device Manager is outlined in KB315539. They can also be viewed using the Microsoft DevCon utility. In fact, both programs can be used to remove, as well as view, the "non-present" devices. In Device Manager, the devices can be uninstalled just like any other. In DevCon, you must prefix the Device ID with a "@" in order for it to remove the device.

However, neither of these solutions allows for a quick method of removing all "non-present" devices, and on a system with hundreds of such devices this can be a significant hassle. To overcome this difficulty, I have written a script to remove all "non-present" devices which are not legacy or SW devices (since these are often required for other reasons - even when "non-present") using DevCon. The script can also read and write a file listing all devices to be removed (allowing for manual editing of the device list). You can download the script from the Remove Devices project page on the forge.

I was recently bitten by KB910272 (again). For the unfamiliar, this issue causes Sender ID/SPF records with non-class full subnets to be processed incorrectly and mail from those domains to be rejected. The number of such domains is surprisingly large for this problem to remain unsolved in the normal patch cycle... or so it seems to me right now.

To solve the problem, apply the hotfix from KB910272 or, even better, from one of the superseding updates: KB927478 or KB951639.

The HTML select element has received much criticism when used for multiple selection over its usability problems. Although it may be simple enough for experienced users, it must be explained in detail (repeatedly) to the less experienced users, who will always find its behavior to be unintuitive. Recently we have come up against this problem and are attempting to work around it.

For some useful background and some great alternate implementations of multiple-selection see Ryan Cramer's analysis and replacement ideas as well as a jQuery Simple Multi-Select plugin which offers an on-demand replacement for the select multiple elements.

The approach that I took was to attempt to leave the select element alone as much as possible, since it is widely recognized and understood by HTML veterans (and already integrated in huge amounts of legacy code), and make it a little more user-friendly by removing the requirement of holding Ctrl to select multiple options. With the modifications in place, clicking on an option will toggle that option between selected and un-selected, while holding Ctrl or Shift will result in the same behavior as before. The solution is written in JavaScript with jQuery (although there is no reason it couldn't be reworked to remove the dependency on jQuery) and was completed without any browser sniffing (only feature-detection).

The script can be found in the forge on the Improve Multiple Select project page. The script can be directly downloaded from the files section (I suggest against directly linking to it - since the location may change). As always, feedback, suggestions for improvement, bug reports, etc. are greatly appreciated.

When using the Certificate Template MMC Snap-In to modify certificate templates in Windows Server 2003, any modifyable template is saved in the Version 2 certificate template format, which can only be used by Windows Server 2003 Enterprise Edition. This creates a significant annoyance when attempting to use certificate templates on a non-Enterprise Edition server (such as Small Business Server). However, when copying a Version 1 template (and making only minor modifications), there is no reason that the template can't be used as a Version 1 template, if you make some modifications by-hand.

Case in point: Setting up offline L2TP/IPSec Certificate Templates. If you have been following KB 555281, you are likely stuck at How to issue the custom L2TP/IPSec (Offline request) template. Here's the trick:

1. Setup ADSI Edit, or any other LDAP editor
2. Open adsiedit.msc (or your LDAP editor) and browse to CN=Configuration,CN=Services,CN=Public Key Services,CN=Certificate Templates
3. Open the Properties for the template that you would like to use
4. Change msPKI-Template-Schema-Version and msPKI-Template-Minor-Revision from 2 to 1 (not sure if msPKI-Template-Minor-Revision is really required...)
5. Refresh the Certification Authority MMC Snap-In if it is open

That's it. If the template version is set to 1, you can issue the template in any edition of Server 2003.

Note: If you make substantial changes to the properties of the template this trick may not work. The differences in how the template versions are processed can be significant, but this process is likely to work for most simple changes to an existing Version 1 tepmlate.

Recently I discovered and corrected an obscure problem on a client's system relating to SMTP mail not being received from a single remote domain. The ultimate cause turned out to be the cause for an earlier (only partially solved) problem relating to POST data getting lost for the server hosting their website, and it is all the result of the default configuration on their SonicWall firewall.

By default, SonicWall will block/discard fragmented IP packets. This can lead to very difficult to diagnose problems as large packets (packets larger than the MTU of any link between the source and destination) will mysteriously fail to arrive. To solve the problem, follow the instructions to re-enable fragmented packets.

Note: The reason that fragmented packets are disabled by default is reasonable (at least for simple IP implementations). An IP implementation must keep track of fragments received but not yet reassembled so that when other fragments of the packet arrive (possibly much later and out of order) the original packet can be reassembled. Attackers can use this fact to contribute to a DoS attack by sending many packet fragments which do not contribute to complete packets. This will force the victim system to hold the fragments in memory and exhaust system resources. However, I would expect all practical IP implementations have a limited cache size for fragments to mitigate this scenario...

In summary, I find this default configuration completely unacceptable. A "break the Internet" default policy is ridiculous. I'm surprised that this hasn't bitten more people and wasted more time (or that the affected people haven't complained more loudly about their wasted time). Perhaps it is just Montana that is still using carrier pigeons and other forms of transport with small MTUs...

The most recent version of the Microsoft ASP.NET 2.0 AJAX Extensions 1.0 (1.0.61025 according to the support info. in Add/Remove programs) has a bug that just bit me. This library adds a format function to the Date object which provides support for Date and Time Format Strings comparable to the .NET implementation. This is a very handy feature, given JavaScript's lack of a built-in date formatting function. But, if you are going to use it, be careful about the following bug: The time zone offset formats have incorrect sign. For example, if you are in the Pacific Time Zone at UTC-8, Date.format will return formats with UTC+8 (which matches the sign of JavaScript's Date.getTimezoneOffset method).

I created a workaround for the websites that I maintain which does not reimplement Date.format (and likely introduce new bugs) nor require any changes to existing code (with one exception - noted below). This code is a horrible hack and I am almost too embarrassed to post it... but not quite. Here it is:

Just include this code somewhere on the page and it will wrap the Date.format function and negate Date.getTimezoneOffset so that the formatted offset is correct. The significant limitation of the code is that if it is included before Date.format is defined, it will wait for the code to load and try again later. The problem with this approach is that code which is run after Date.format is defined before the fix is installed will still trigger the bug and it will be hard to figure out why that code is not working. Therefore, if possible, include this code immediately after the Microsoft AJAX extensions JavaScript is loaded on the page. Alternatively, use your own workaround or avoid using any of the "z" specifiers in your custom format strings.

Having recently configured fax sending/receiving on both a Windows server (using Windows Fax Services on SBS2003) and a Linux server (using Hylafax on Debian Lenny), I felt compelled to write down a few troubleshooting steps for fixing Caller ID problems. Both of these systems include Caller ID information with received faxes (separate from any TSID), but often this information is missing and it is difficult to determine why. Make sure that each of the following items are satisfied:

• Does the phone line to which the fax is connected have Caller ID service from the phone company? (easy to test using a Caller ID-capable phone)
• Does the modem support Caller ID? (check the specs, or skip to the next step)
• Is Caller ID enabled in the modem? Is it being received? To test this, use the following steps:
  1. Stop the fax service
  2. Connect to the modem using Hyper Terminal, telnet, or cu
  3. Query the status of Caller ID on the modem using AT#CID? (or a different modem-specific command). If the modem reports 0 (disabled), enable it with AT#CID=1 and add this to the modem initialization string so it will be enabled after reboot/reconnect.
  4. While still connected to the modem, make a call to the phone line and watch for Caller ID information to be printed. If no Caller ID information is printed, continue troubleshooting the modem/phone until the information is printed.
  5. Disconnect from the modem when finished and restart the fax service

Once the items above are satisfied, the Caller ID information should be gathered by the fax service and included with received faxes. If not, check that the initialization commands include enabling Caller ID, if it is disabled by default (try restarting the fax service, then step 3 from above. If the Caller ID is disabled, something in the fax service is disabling it - or not enabling it). Otherwise, something else is broken and you should add a comment below on how to fix it.

I recently encountered the following error in Microsoft Access 2000:

Apparently this is a catch-all error for any condition where the database engine (or presumably one thread of the engine) is busy completing a task and something else (such as a VBA macro) attempts to perform a function which requires the engine to perform some task. It is horribly difficult to track down, due to the lack of internal debugging interfaces in Access, but check for macros which may be updating visual elements in a form and getting into a loop (for example, OnCurrent actions cascading in a loop or likewise). In my particular case, the error was only triggered when a filter was applied in a form which contained a subform with a field whose default value depended on a field in the parent form. Once I removed the default value from the field in the subform, the error disappeared. (Note also that this only occurred in Access 2000, not Access 2003)

Good luck in tracking down the source of this error if you encounter it.

In the office we are using an HP OfficeJet 6310 All-In-One (donated by a friend, thanks mate!). I recently encountered a problem while attempting to scan from the device using the provided HP software bundle. The (very uninformative) error message that I received after pressing the Scan Document button was:

The communication problem is often solved by reinstalling the drivers (simply remove the printer from Printers and Faxes and click "Add Device" from the installation CD - no need to reinstall the included software) or by correcting common network misconfigurations (wrong IP, disconnected network cable, etc.). Steps for basic troubleshooting are discussed on HP's Website for USB and Network connections.

If/When the basic troubleshooting procedures don't solve the problem, there is a very involved solution for correcting the driver network connection settings posted by Ken Leon on the HP Forums (along with other useful suggestions/diagnostics in that thread).

However, in one (increasingly common) case, it may be possible to avoid the need to reconfigure the internals of the scanner drivers. If your ISP participates in DNS Hijacking, it may be prudent to rule this out as a cause of the error. It appears that the scan drivers attempt to address the device based on its hostname rather than its IP address (regardless of configuration) and when it resolves the address of the device, the DNS request gets hijacked and the scan drivers attempt to connect to the ISP server instead of the device. To diagnose this, simply disconnect the network from the Internet (and restart the router and computer after disconnecting to clear their DNS cache) and see if the error still appears. If it does, then this is not the problem, if it does not, you have found the problem. To remedy the problem, add an entry to the hosts file which associates the hostname of the device (both the name displayed in its web configuration as the hostname and its MAC address prepended with "HP" as this is often used by the drivers).

I recently encountered the following message in Microsoft Access 2003 when attempting to update any column of a linked table (linked to an MSSQL2005 DB): The interesting part of this story is that there really shouldn't be a write conflict in the data because the linked table in question is in a DB on my local computer which is only being accessed by Access and has no triggers which could be confusing Access. Further investigation, and a useful thread on Bytes, revealed that the problem was columns in the linked table which have the datatype BIT and was allowed to be NULL. Changing the columns to BIT NOT NULL and refreshing the linked table in Access solved the problem.

Update: KB 280730 covers this issue.

I recently encountered the following error message in Microsoft Access 2003: After further investigation, as suggested by a thread on microsoft.public.access.forms, the problem appears to be related to duplicate columns in the form Record Source. However, the error is not limited to simple duplicate columns. In my case, the duplicate name was the result of a table join where the compound names were distinct (i.e. Table1.Col1 and Table2.Col1), but the simple column names were not, which resulted in the error. Perhaps I shouldn't be using joined tables as my Record Source... perhaps.