Blog: Windows

Several of our customers have been confused recently regarding the number of Microsoft licenses they own.  The issue is confused by Microsoft’s process itself.  When a customer purchases licensing they are issued an Open Business Authorization certificate which states the number of licenses purchased.

The client is also issued a set of keys to install the purchased licenses.  The license number and the number of times the customer can use the key are very confusing.  In fact the key can be used roughly 5 times per 1 license.  As an example, if a customer purchases 10 Windows Server licenses, the associated key may state a quantity of 50.  This actually means you can activate the key 50 times on the same 10 licenses.

If you seem to have extra licenses that magically appeared, make sure you are looking at your certificate and not the number associated with the keys.

When roaming profiles are loaded and saved from and to the server over the network, sometimes the profile will load as temp or local.  The type and status should be roaming.  After renaming or copying the old profile and then recreating it, it works for a few times, and then same thing happens over and over.  You can spend a lot of time recreating profiles and fixing other things that might break when going from profile to profile.  The trick is to check the cable back to the switch.   Check the client on another run if possible, or use a fluke to test the cable(s) and connections.  The cable might test good one time and bad the next.  This is where just enough packet can be lost to corrupt the profile being saved or loaded. 

A customer called with a  laptop that would not connect to any mapped drives.   Investigating found that attempting to map via name would not work but mapping via IP did work.  DNS was working properly and the file server would ping by name or IP.  Logged in with an administrator account and all mapped drives came up properly.   Finally discovered that this machine had not been on the domain for some months and there were old cached credentials for the file server in stored credentials.  These are stored by path so it was using those credentials by default when attempting to map by name but not when mapping by IP.  Removal of these stored credentials allowed the mapping to complete properly. 

We recently encountered some machines running Windows Embedded with the Write Filter enabled that were losing their trust relationship with an Active Directory domain due to mismatched passwords associated with computer accounts. [more]

Cause: After 30 days (default), machine account password expires. The password is updated on the machine as well as in AD. At some point, the machine is rebooted. Since the machine is running in Read Only mode (write filter enabled), the password associated with the computer account is reverted back to the password that is stored with the image on the machine. Since that password does not match the one stored in AD (the updated password), the machine can no longer communicate with the DC and the trust is broken.

Resolution: Windows Embedded Standard (from XP forward) has the ability to retain specific registry keys across reboots. It is called the Registry Filter service (Regfilter), and it works like this: determine what you want to retain, and configure it in a specific area of the registry. The service will monitor the specified key for changes, if there are any it'll both keep them in memory and write them in a specific way to c:\regfdata. From then on, any system call to read or write to that key will instead be reading from and writing to the key in memory and in c:\regfdata. When using a prebuilt HP image, keys for the Terminal Services Client Access License (TSCAL) and Domain Secret Key (key that holds the secret password for the issue above) are already added to the regfilter registry key. This process didn’t seem to be working with the current HP image we were using. However, the most current image on HP’s site did work.

When troubleshooting file shares not working to several computers, I was presented with an error saying I could not connect. The specific message was “Not enough server storage is available to process this command.” I was able to find an article discussing this at http://support.microsoft.com/kb/225782/.  After increasing the registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\... LanmanServer\Parameters\IRPStackSize by a decimal value of 3 and rebooting, the file share immediately started working. The value should be increased by increments of 3.

If you need to make modifications to a drive mapping in a logon script that uses the “Net Use <drive> \\computername\sharename” command, be sure to add a line above to delete the previous map using “Net Use <drive> /delete”.  If the previous drive mapping isn’t deleted and recreated, it can continue to use the old drive mapping location.

Who remembers the DOS days when files could only be 8 characters long with 3 character extensions?  Do you remember when Microsoft introduced long files names in Windows 95?  In order to maintain backward compatibility, the system still created 8.3 files names.  Well every version of Windows still does that, even Windows 7.  This can be disabled for performance reasons by setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem:NtfsDisable8dot3NameCreation=dword:00000001 (http://support.microsoft.com/kb/121007) but you never know when you will need them. [more]

I was running an application that had been installed down under C:\Program Files, and it’s configuration file was there, and I needed to pass that as a parameter to the program.  I tried using quotation marks, backslashes to quote the spaces, backslashes to quote the quotation marks, quotation marks to quote the quotation marks – everything I could think of it and still did not work.  Using the short file name with no spaces worked great.

I had some directories created that were made up of only spaces and I could not delete or rename them.  The Windows Easy Transfer would get stuck in a loop because of these, so I decided I better delete or rename them.  I did a dir/x to find the short names, and then I could access them using that.

If you want to find the “short name” path, just run the good ole’ trusty DOS COMMAND.COM.  It’s still there, even on Windows 7!.  Just enter command at the command prompt and a cd if your prompt does not indicate your path.

One side effect to look out for.  Since the short name is based on the first few characters of the long name, renaming the long name and leaving the first few characters the same will result in the short name staying the same.  So you cannot just rename the file to “long file name with spaces-old.txt” to get it out of the way if something is accessing LONGFI~1.TXT.  Renaming it to .old would work.

When making registry changes, it is a good practice to export the key first.  But many times, we are adding new items and not just modifying values on existing items.  So if you import from the file you exported to, it does not remove the new items that were added.  To do that, add a line at the top of the registry file with a minus in front of the key, like this, for example:

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones]

This will cause this key, all it's subkeys, and items to be removed first, then the rest of the information will be added back.  If the key does not exist, then no error occurs.  This is probably a good practice to follow when putting together a .REG file to deploy so that nothing else will be under that key.