Windows Tip Sheet

Outlook Migraines ... er, Migrations

Stop migration sickness in Exchange with a painless script and registry change.

I recently got an e-mail from David Kounas in Pittsburgh. Seems he was working with a client on an Exchange migration, where the majority of the clients were running WinXP and Outlook 2003 in its default, cached configuration. In that mode, Outlook operates primarily from its local, "offline" store and synchronizes that store with the server on a continuing basis. The migration in question was from Exchange 5.5 to Exchange Server 2003.

Cached Address Book
Because the migration basically involved two separate e-mail systems—Exchange 5.5 and Exchange 2003—significant efforts were being made to ensure users could still e-mail one another. They created Contact objects in the AD domain that supported the Exchange Server 2003 installation, using those objects to represent un-migrated Exchange 5.5 mailboxes. Prior to migrating a mailbox, they removed the Contact object. Once the mailbox was migrated, it would show up as a regular mailbox-enabled user in Active Directory.

The problem was that migrated users were unable to e-mail recently migrated users. The migrated users' offline address books in Outlook 2003 were still caching the old Contact object, which by this point was gone. The offline address books, which Outlook was consulting first, weren't being updated quickly enough. They didn't want to permanently turn off Outlook's cached mode, as it has some significant operational advantages—like not locking up when network connectivity is on the fritz, which is what prior versions of Outlook would do pretty routinely. But something needed to be done. They figured the solution would be to temporarily disable cached mode until the migration was over, thus eliminating the problem with the cached address book. David asked me if I knew of a script that would help.

As luck would have it, I have a shell script that can scan through each computer object in a domain and “do something with it.”

'connect to the root of AD
Dim rootDSE, domainObject
Set rootDSE=GetObject("LDAP://RootDSE")
domainContainer = rootDSE.Get("defaultNamingContext")
Set oDomain = GetObject("LDAP://" & domainContainer)

'start with the domain root
WorkWithObject(oDomain)

Sub WorkWithObject(oContainer)
   Dim oADObject
   For Each oADObject in oContainer
      Select Case oADObject.Class
         Case "computer"
               'oADObject represents a COMPUTER object;
               'do something with it
               '** YOUR CODE HERE **
         Case "organizationalUnit" , "container"
               'oADObject is an OU or container...
               'go through its objects
               WorkWithObject(oADObject)
      End select
   Next
End Sub

You'll need to run this on a domain member, of course, as someone with admin permissions on each computer that will be targeted. Coming up with code to look for XP boxes (the company had a few other clients) was also easy, using a simple WMI query, which would be added where the shell script says "**YOUR CODE HERE **":

sComputer = oADObject.Name
Set objWMIService = GetObject("winmgmts:" _
 & "{impersonationLevel=impersonate}!\\" & _
 strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
 ("Select * from Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
 If objOperatingSystem.Version = "5.1.2600" Then
  'computer is XP – do something with Outlook
 End If
Next

The problem was I didn't know how to help David "do something with Outlook." Fortunately, he figured it out on his own. The registry key is:
HKEY_CURRENT_USERS\Software\Policies\Microsoft\Office\11.0\Outlook\Cached Mode
It needs to be set to 0 to disable cached mode.

This key resides under the Policies branch of the registry, which means it's related to Group Policy; the ADM templates relating to Office 2003 would allow you to push this setting out via Group Policy object, rather than a script. Because the setting only affects Outlook 2003, you could apply it to the entire domain and only affect the necessary computers.

Micro-Tips

Anything living under the Policies branch of the registry can be managed via Group Policy and will be automatically unset if the GPO is ever unlinked. Anything else in the registry can be set via GPO but is referred to as a “preference,” and tattoos the registry. Remove the GPO and the preference will remain configured.

If you're trying to get better control over your patch management, you may want to block users' access to Office Update, forcing them to rely only on updates that you've tested and approved for deployment. Microsoft has an article on blocking access at http://www.microsoft.com/office/ork/2003/journ/blockOU.htm. Keep in mind, though, that when Windows Update v5 releases (possibly late this year or early next), it will replace Office Update as a source of patches for Office and most other Microsoft business products.

More Resources
The Office 2003 Resource Kit includes the ADM templates to manage Office via Group Policy. Download it from here.

Looking for help on subtle Group Policy problems? http://www.GPOAnswers.com provides a great discussion forum and other GPO resources.

You can also modify many Outlook settings with a PRF file. Check out:
http://www.microsoft.com/office/ork/2003/journ/PRFwhitepaperintro.htm for more info.

About the Author

Don Jones is a multiple-year recipient of Microsoft’s MVP Award, and is Curriculum Director for IT Pro Content for video training company Pluralsight. Don is also a co-founder and President of PowerShell.org, a community dedicated to Microsoft’s Windows PowerShell technology. Don has more than two decades of experience in the IT industry, and specializes in the Microsoft business technology platform. He’s the author of more than 50 technology books, an accomplished IT journalist, and a sought-after speaker and instructor at conferences worldwide. Reach Don on Twitter at @concentratedDon, or on Facebook at Facebook.com/ConcentratedDon.

comments powered by Disqus
Most   Popular