Myth 2:
You must use 3rd party tools to automate
the Outlook profile changes
FALSE
This is even more false than
the first item since Outlook 2007 will correct itself automatically!
Yes, you read that correctly. Outlook 2007 will sense the change and use
the Autodiscover feature to find the target AD and automatically reset
the Exchange server connection settings. For Outlook 2003 clients you
can use Microsoft's Exchange Server Profile Redirector Tool which for us
has a 90-95% success rate.
The profile redirector can be easily deployed from a
logon script. You can place the redirector files in the netlogon share
and execute it from a logon script like this:
%logonserver%\netlogon\exprofre.exe /targetgc=
DC2.targetcompany.com /n /v
You may notice that we are not
using many of the switches here. That is by design.
By not adding the /F switch we are removing
Outlook Favorites. By omitting the /A switch Outlook must download a new
copy of the address book.
Since we omitted /O the OST file will be
renamed instead of deleted. If you have strange problems with Outlook
after test migrations you may want to add the /O switch in order to nuke
OST files as they can be a problem. We left the/N switch in order to
clear the nickname cache.
ExProfre is pretty sophisticated since it only makes
changes when it detects the original mailbox is gone (converted to a
Mail-Enabled object for example) and there is an entry in the target
domain for the user.
Here is the link to the tool:
http://www.microsoft.com/downloads/details.aspx?FamilyId=56F45AC3-448F-4CCC-9BD5-B6B52C13B29C&displaylang=en
TimeSaver- Outlook
problems will represent 5-10% of your help desk calls and the default
fix for nearly all Outlook problems is to create a new fresh profile.
Myth 3:
Delegates and customized
Mailbox Permissions are lost- FALSE
FALSE
This is false since the source
rights on the mailbox will come over as part of the Move-Mailbox
process. In cross-forest migrations the original AD accounts in ForestA
can be used to access the mailbox in ForestB. This behavior is supported
by default by Move-Mailbox but not always desired. If for example, you
plan for the users to begin using accounts in ForestB to access
mailboxes in ForestB then the old Access Control Entries for ForestA
could create some problems. We found that the legacy credentials may
work for accessing the mailbox in ForestB but other Exchange functions
in the new Forest did not work with the old credentials. This problem
can be overcome by nesting certain Forest groups into each other for a
true Forest trust or you can simply write a script to remove the old
ACLS from the new mailbox. Here is an example of that code:
Get-Mailbox -Server "TARGETSERVER" | Get-ADPermission
| where { ($_.IsInherited -eq $false) -and ($_.User -like
“LEGACYDOMAIN\*") } | Remove-ADPermission -confirm:$false
Get-Mailbox -Server "TARGETSERVER" | Get-MailboxPermission
| where { ($_.IsInherited -eq $false) -and ($_.User -like
"LEGACYDOMAIN\*") } | Remove-MailboxPermission -confirm:$false
The permissions are split between ADPermission and
MailboxPermission so you must run two commands to remove them
completely. Moreover, there is no -server option with Get-ADPermission
or Get-Mailboxpermission so you have to first enumerate the object using
Get-Mailbox. Once you have the users for a particular server you can
pipe the results to get the permissions limited by the ACLS that contain
the domain name you wish to remove. You can then pipe the results to
remove the permissions.
It is also important to note that Delegates will also
come over but remember that with Outlook, the X.500 address is used
behind the scenes to link users with mailboxes. So for this to work, you
need to copy the LegacyExchangeDN value from each mailbox in the source
domain and populate the migrated target object with a matching X500
proxy address. This will ensure that the delegate remains linked with
the appropriate user. Here is a Microsoft article that explains the
process in a little more detail:
http://support.microsoft.com/kb/555197
The Move-Mailbox command should take care of this by
itself, but it would be a good idea to write a script to collect the
attribute then report on it after a group has been migrated just to make
sure things are set as they should be. We don't want end-user complaints
to be our indicator that a directly entry is wrong!
|
