Don't Forget to Mop Up

I mentioned that over the weekend I swapped out a domain controller in a Windows Server 2008 domain.  It happened to be the ONLY domain controller, which, although not recommended, made things a little trickier.  In most respects everything went well.  But I found later on that clients were taking far longer to login than they used to.  Even Windows 7 clients, which normally login very fast (faster than XP or Vista in my opinion).  I began digging and within minutes found the source of the problem.

Step 1 - Event Logs

I opened the Event Viewer on one of the Windows 7 clients and dove into the System log.  Nothing there at all.  Then the Security log.  Nada.  Then the Application log.  Voila!

Log Name:      Application
Source:        Group Policy Drive Maps
Date:          5/17/2009 8:55:57 AM
Event ID:      4098
Task Category: (2)
Level:         Warning
Keywords:      Classic
User:          SYSTEM
Computer:      Desktop4.acme.local
Description:   The user 'V:' preference item in the 'Drive Mappings  {3B6D54F2-E7DC-45A5-A66E-59C16CE2CB1A}' Group Policy object did not apply  because it failed with error code '0x80070035 The  network path was not  found.' This error was suppressed.

There was an entry for each of the allocated drive mappings, as well as one for the printer mapping:

Log Name:      Application
Source:        Group Policy Printers
Date:          5/17/2009 8:56:41 AM
Event ID:      4098
Task Category: (2)
Level:         Warning
Keywords:      Classic
User:          SYSTEM
Computer:      Desktop4.acme.local
Description:   The user 'HP Deskjet F4200 series' preference item in the  'Drive Mappings {3B6D54F2-E7DC-45A5-A66E-59C16CE2CB1A}' Group Policy object  did not apply because it failed with error code '0x80070709 The printer  name is invalid.' This error was suppressed.

It was Group Policy Preferences which were tripping up, because the "network path" it mentions indeed changed.  The V: drive (among other drive mappings) specified in the GPP setting was pointing to a UNC path that no longer existed.  The UNC path was for the previous DC server name.  While I moved the data and shares over to the new DC and it worked fine, the GPP was not updated.  The net result was that each client was trying to find the share to reconnect the local drives and causing it to wait during logins.

The printer mapping failed to resolve because the client from which it was shared happened to have been reloaded with the same operating system but someone forgot to share out the printer again.  Once the printer was shared and listed in the directory, everything synched up fine.  But next up, I had to update the GPP settings for the drive mappings.

Step 2 - Updating Group Policy Preferences

I could have remoted into the domain controller to do this, but since I had already installed the RSAT for Windows 7, I simply opened Group Policy Management on the client:

Right-click on the "Drive Mappings" GPO and select "Edit":

Right-click on each of the drive mappings to the right, and select "Properties".  From there, I simply replaced the old server name component of the UNC path with the new server name (e.g. "Dragon"):

Once I updated all of them, I simply closed the GPM console, opened a CMD console on the client and typed GPUPDATE and hit Enter.  After a few seconds the Group Policy settings were refreshed and I type NET USE to list all the drive mappings.  They were all present and accounted for.  To verify UNC resolution, I simply enter a drive letter to list a directory...

C:> V:  (press Enter)

V:> DIR  (press Enter)

All is good.

Conclusion

In the past, I would have used a login script to manage drive mappings, but there are some logistical issues with that method which are better served with GP Preferences.  It still amazes me that admins are still using scripts to map drives, printers, make registry changes, add or remove shortcuts, edit environment variables, modify INI files, add files and folders, and so on.

Don't get me wrong.  Being a script developer, I still insist scripts are the way to go for many tasks, but for these types of issues you're way better off using GP Preferences.  In this particular scenario, GP Preferences saved me at least a few hours of work and having the built-in integration with Event logging, it was much faster and easier to diagnose the problem and take the appropriate action to resolve it.