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.