I Often get questions around how best to install Exchange updates or service packs. This Blog Post attempts to answer that Question.

To start with, I recommend having a Patch management Policy. A Good Patch management policy document should have the following listed:

1. How often should the updates / service pack be installed. ( e.g. Service Pack - once every quarter / critical updates - ASAP)

2. Applications which would possibly have a dependency on the Patch / Service pack. ( BB, Backup, antivirus , archiving, other 3^rd party products ).

These 3^rd party products should be tested for any dependencies on the Update / Service pack.

3. Sequence of server roles to install the Patches on.

Internet facing servers / sites should patched first

Non-internet facing should be after all internet facing sites are updated.

4. AV should be disabled for the time of installation.

5. StartDagServerMaintenance.ps1 before install & StopDagServerMaintenance.ps1 after success to disable replication & re-enable it after SP installation is complete

Additional Reading : http://technet.microsoft.com/en-us/library/bb629560.aspx

6. The Servers must be re-started if the installation of an update / Service pack prompts for a restart.

7. Tests which need to performed to validate services are up & running as expected.

8. Tests which need to be performed to validate the Updates / Service Pack is installed correctly.

*Features

~95.5% reduction in IOPS

Exchange 2013 is capable of being deployed in a multi-site worldwide architecture with a single namespace. ( using multiple technologies )

Auto re-seed to spare disk. ( but needs operational maturity )

*Good to know

CAS is now a protocol proxy only. (2 layers V/S 5 layers)

No longer supports MAPI Clients ( only outlook anywhere )

No MAPI on CAS only RPC-over-HTTP

ECP is now EAC

Notification to admin when certificate is expiring ( EAC )

Maximum DB per server; Enterprise Edition- 50, Standard Edition - 5

one thread per DB

Hard block on 2003 to 2013 migration. (even cross forest )

New server gets into maintenance mode once it is installed

Quota notification e-mail is generated during users login ( V/S every day at midnight in Exchange 2010 )

A Quick blog on how to execute an Exchange PowerShell script (.ps1 extension) from a command prompt.

A .ps1 cannot be executed from a Command prompt. to execute it one needs to use a PowerShell shell. Further if this script calls any exchange cmdlet, it would require to be executed in an Exchange Management Shell.

The following command does all three in one line. i.e. run the script from c:\script\script.ps1 ( which is an exchange script ) from a command prompt.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -psconsolefile "C:\Program Files\Microsoft\Exchange Server\V14\Bin\exshell.psc1" -file "C:\script\script.ps1"

ADMT
At the time of writing this Blog;

ADMT 3.1 - 32 Bit version. ( Will not install on Windows 2008R2 )
This installer has SQL 2005 Express Edition ( with necessary service pack integrated into the installer )

ADMT 3.2 - 64 Bit Version. ( The first & only version which will install on Windows 2008R2 )

SQL 2008
There are many download options available on the Microsoft website,
* Express Edition & Enterprise Edition
* 32 Bit & 64 Bit
* With & Without Service pack integrated.

Your mileage will vary depending on what version of SQL, Windows & ADMT you use.

For the purpose this migration, I used ADMT 3.2 on a windows 2008 R2, member server with SQL 2008 sp3 Express Edition ( x64 )
This was installed in the target forest.
Password Export Server was installed on a Domain Controller in the source forest.

How to Check the version of SQL ?

Type these commands in a cmd prompt:

sqlcmd -S.
select @@version
go

Additional Reading: Link, Link

3. Moving the Active Directory account using ADMT

ADMT is a great tool for Migrating and Restructuring Active Directory Domains ( user accounts, passwords, groups & group membership, computer accounts & much more.)

However It is very important to note that ADMT DOES NOT touch Exchange attributes.

ADMT can be executed before prepare-move request, after prepare-move request or skipped if we want to use a linked account.

Assuming Prepare-move request was executed first, when executing ADMT we need to merge the account with an existing MEU.

Below are screen grabs of the ADMT wizard. the critical options are highlighted.















 

If ADMT is run prior to the Prepare-MoveRequest.ps1 script is executed, we would need to execute Prepare-MoveRequest.ps1 with the -OverWriteLocalObject Switch.

Further reading Link

4. The Actual Move of Mailboxes.

Having prepared the environment, moving the mailbox should now be a breeze. Given that Moving mailbox is a large topic, so In order to keep this blog concise, I shall jump straight to the command & explain only what is relevant.

1. MRSProxy or NO MRSProxy

   MRSProxy encapsulates all communication between the organizations in HTTPS packets thus making the move seamless.

   Assuming the source forest has Exchange 2010 SP2 or above, enable MRSProxy in the source forest.

   Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSProxyMaxConnections 50

   Details can be found Here

   In the event that the source forest does NOT have an Exchange 2010 server, we cannot use the MRSProxy. So we skip the above step & use the -remotelegacy in lieu of -remote switch in the move command.

2. Command to Move the Mailbox across the forests ( pull the mailbox from source forest to the target forest )

   First save the credentials in two variables:

   ( target forest )

   $LocalCredentials = Get-Credential

   ( source forest )

   $RemoteCredentials = Get-Credential

   Then execute the command based on whether the source forest has MRSProxy enabled or not.

   • With MRSProxy DISABLED in the source ( even if there is a E2010 server in the source )

   New-MoveRequest

   -Identity johndoe@tailspintoys.com

   -RemoteCredential $RemoteCredentials

   -TargetDeliveryDomain 'tailspintoys.com'

   -RemoteGlobalCatalog dcx01.contoso.com

   -RemoteLegacy

   • With MRSProxy enabled in the source (on a server e2010.contoso.com )

   New-MoveRequest

   -Identity johndoe@tailspintoys.com

   -RemoteCredential $RemoteCredentials

   -TargetDeliveryDomain 'tailspintoys.com'

   -RemoteGlobalCatalog dcx01.contoso.com

   -Remote

   -RemoteHostName E2010.contoso.com

   Note: -RemoteHostName is the E2010 servers where we have enabled the MRSProxy

   When the above commands are executed, it will result in the source mailbox turning into a Mail User ( MEU) & the Target Mail User (MEU) into a user mailbox.

   Source forest:

   User Mailbox> Mail User ( MEU )

   Target forest:

   Mail User (MEU) > User Mailbox

   Before Move:

   

   Move Command:

After Move:

1. 

   Note: Issues to be aware of when moving across forests

   1. Outlook nickname cache is best cleared ( from the client side )
   1. Update OAB & replicate to the CAS servers. Have the users wait till it downloads or ask them to manually download the OAB.
   1. Depending on how end-users have created their outlook rules, it could break. You might need to re-create the outlook rules.
   1. Shared mailboxes + their users & manager + delegate sets should be moved together. you cannot have a manager in one forest & delegate in a different forest
   2. This Mailbox pull will result in the source mailboxes being hard deleted. Ensure you have a backup in case you need to retrieve the mailbox
   1. "Suspend this move when it is ready to complete" option is not available when moving across forest.

   Additional Reading.

   http://technet.microsoft.com/en-us/library/dd351123.aspx

   http://blogs.technet.com/b/exchange/archive/2010/08/10/3410619.aspx

5. Ensuring Mail flow between source & target during the co-existence phase.

The Method described below would work fine if we have to migrate all the mailboxes from the source forest to the target forest rapidly & in one scheduled activity. This is because both the source & target forest are authoritative for the same SMTP domain.

This drawback ( of having to move all the mailboxes in one scheduled outage ) would be acceptable if the number of mailboxes is small or the actual move would happen in a short span of time. However this is not a common scenario as most migrations would take several hours if not days or weeks.

In the event that the move of mailbox takes several hours, days or weeks, we would need to have e-mail flowing between the source forest, ( mailboxes which are going to be migrated ) & the target forest ( mailboxes which have already been migrated ) Thus a migrated user can send an e-mail to a user who is yet to be migrated & vice-versa.

The additional steps to achieve this would involve:

 

1. Add a new accepted domain e.g. @tailspintoys.local in the target forest and also add this domain as a secondary SMTP address to the target forest objects.

Thus we have an additional secondary SMTP e-mail address of johndoe@tailspintoys.local

set-emailaddresspolicy -id "Default Policy" -enabledemailaddresstemplates SMTP:@tailspintoys.com,smtp:@tailspintoys.local

update-emailaddresspolicy -id "Default Policy"

 

2. Modify the move command used earlier. Change the TargetDeliveryDomain to tailspintoys.local

e.g. New-MoveRequest -Identity johndoe@tailspintoys.com -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'tailspintoys.local' -RemoteGlobalCatalog dcx01.contoso.com -RemoteLegacy

Thus the Target address on the MEU in the source forest after the mailbox is moved will be johndoe@fabrikam.local besides the expected proxy addresses.

Once Executed, we will now have the MEU in the source having a target address of tailspintoys.local

 

3. Create appropriate connectors for mail flow.

In order to have e-mail flowing between the two forests we would need to configure connectors in both the forests. This procedure could vary depending on how the existing mail flow is configured.

Here are the PowerShell commands used in my lab:

source_to_target mail flow

Source send connector

new-SendConnector

-Name 'source_to_target'

-Usage 'Internet'

-AddressSpaces 'SMTP:*.tailspintoys.local;1'

-IsScopedConnector $false

-DNSRoutingEnabled $false

-SmartHosts 'ex01.fabrikam.com'

-SmartHostAuthMechanism 'None'

-UseExternalDNSServersEnabled $false

-SourceTransportServers 'ex01.contoso.com'

Target receive connector

new-ReceiveConnector

-Name 'source_to_target'

-Usage 'Internet'

-Server 'EX01.fabrikam.com'

-Bindings '0.0.0.0:25'

-RemoteIPRanges '10.10.10.103'

target_to_source_and_internet mailflow

target send connector

new-SendConnector

-Name 'target_to_source_and_internet'

-Usage 'Internet'

-AddressSpaces 'SMTP:*;1'

-IsScopedConnector $false

-DNSRoutingEnabled $false

-SmartHosts 'ex01.contoso.com'

-SmartHostAuthMechanism 'None'

-UseExternalDNSServersEnabled $false

-SourceTransportServers 'EX01.fabrikam.com'

source receive connector

new-ReceiveConnector

-Name 'target_to_source_and_internet'

-Usage 'Custom'

-Server 'Ex01.contoso.com'

-Bindings '0.0.0.0:25'

-RemoteIPRanges '10.10.10.11'

-AuthMechanism 'Tls, ExternalAuthoritative'

-PermissionGroups 'AnonymousUsers, ExchangeServers'

Note1: usage = internet as this would not require authentication.

Note2: RemoteIPRanges is the IP address of the server used in the send connector matching this receive connector. This will result in only the identified server being able to send e-mail over this receive connector.

Note3: For this example I have chosen to create a separate send & receive connector in both the forests. However you could also achieve this by modifying the existing receive connectors instead of creating new receive connectors.

6. Additional configuration needed.

• AutoDiscovery for outlook clients ( also used by free-busy )  Reference link
• Free-busy / Availability information.
• Redirecting OWA across forests
• Linked mailboxes
• Shared / Resource mailboxes

I hope to cover these in future blogs, time permitting.

Additional Reading Link1 Link2 Link3

Thank you for reading this far & I hope this blog was useful for your cross-forest migration.

Next Blog: How Groups can be migrated across forests & what kind of issues can crop up.