Monday, November 9, 2015

Exchange Server 2003/2007 to Exchange Online migration challenges

We have customers who maintain Exchange Server 2003/2007 and Windows Server 2003 still. Those latecomer customers obviously want Exchange Online from Office 365 instead of 2-hop migration to the latest Exchange Server 2016. 

Since no full Microsoft support for those legacy things (Exchange 2003/2007, Windows Server 2003) it can be tricky to provide Exchange Online migration soon. Here my short issue collection so far

Issue #1. New Outlook Office 365 (Office 2016 based) is not compatible with Exchange Server 2003/2007.

With the release of Office 365 application package based on Office 2016 it is no longer possible to connect Office 365 Outlook to Exchange Server 2007 (and obviously Exchange Server 2003).
It is best practice first to update client versions prior to Exchange Online migration in order to prepare clients for the new Exchange environment. But you stuck here because new Outlook 2016 won't connect to Exchange Server 2003/2007 and obviously you will upgrade your Office installation right after mailbox switchover to Exchange Online to reduce downtime with your current mail system. If you did Office 365 package installation prior mailbox synchronization to Exchange Online you will get following message for your on-premise based Outlook profiles:
The resource that you are trying to use is located on an unsupported version of Microsoft Exchange.
You have some workaround for Exchange Server 2007 based migration deployments:
Deploy Office 365 based on Office 2013 and prevent it automatic upgrade to Office 365 2016.

Issue #2. Active Directory powershell module is not working with legacy systems out-of-the-box

When we migrate to Office 365 we usually do some site surveys, infrastructure readiness checks and etc. We usually do those checks with PowerShell and I don't feel VBScript is something often usable today. Active Directory powershell module is not present at Windows Server 2003 and Windows Server 2008 Domain Controllers out-of-the-box.

My fellow Slava Fedenko described here in deep details how to enable it for Windows 2003/2003R2/2008 in some non-supported way. 
Supported way is that you need Active Directory Web Services (Active Directory Management Gateway Service) enabled on at least one Domain Controller.
You have strict prerequisites:
Windows Server 2003 R2 with Service Pack 2 (SP2);
Windows Server 2003 SP2;
Windows Server 2008;
Windows Server 2008 SP2;
.NET Framework 3.5 with Service Pack 1
Hotfixes to install:

KB969166 for .NET Framework 3.5 SP1
KB969429 for Windows Server 2003 SP2-based Domain Controller

KB967574 for Windows Server 2008 pre SP2-based Domain Controller

You may also choose to not make any changes to Domain Controllers (btw hotfixes will require domain controller reboot). And install free Quest (Dell) AD PowerShell module called "ActiveRoles Management Shell for Active Directory".

Issue #3. New certificate encryption algorithms are not compatible with Windows Server 2003

Microsoft provides native free tools for
Staged migration and Cutover migration from Exchange 2003/2007 on Windows Server 2003. In both cases RPC over HTTP (or Outlook Anywhere) is strict prerequisite for such kind of migrations. 
In its turn Outlook Anywhere also requires certificate purchased from public CA like GoDaddy, GeoTrust, etc. You may discover that public CA often use new encryption algorithms which are not available with legacy operating system like Windows Server 2003 (even fully patched). Windows Server 2003 Service Pack 2 does not ship with support for SHA2.
When installing a certificate issued with a SHA-2 signature algorithms (which includes SHA-256, SHA-384, and SHA-512) on Windows Server 2003, the following error is displayed: 
"The integrity of this certificate cannot be guaranteed. This certificate may be corrupted or may have been altered."
You may also have Certificate status:
"This certificate has an nonvalid digital signature"
Microsoft has released a hotfixes in order to provide limited compatibility for certificates issued with SHA-2 signature algorithm:
kb968730 - for Windows Server 2003 SP2
kb938397 - for Windows Server 2003 SP1/SP2

Issue #4. RPC Proxy Server Extension Is not Loading Properly

RPC Proxy Server Extension is not loaded properly sometimes on Windows Server systems. I've seen it few times. RPC Proxy Server Extension is an configurable IIS component of Outlook Anywhere for Exchange Server 2003/2007.
Following 404 error (Not Found Error) is logged in the IIS log on your legacy Exchange RPC proxy server:
2004-01-01 13:13:31 192.100.100.1 RPC_IN_DATA /rpc/rpcproxy.dll mail.contoso.com:6002 443 CONTOSO\username 192.100.100.2 MSRPC 404 2 1260
This 404 error may be caused by a disabled or non-functioning Web service extension. 




1. On the Exchange Server, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager on your RPC proxy server.

2. Under the icon for your RPC proxy server, click Web Service Extensions.

3. In the right pane, click RPC Proxy Server Extension, and then click Properties.

4. Confirm that the path of the Rpcproxy.dll file is correct. The correct location is the following:

%systemroot%\system32\rpcproxy\rpcproxy.dll

For example, the correct location could be the following:

c:\windows\system32\rpcproxy\rpcproxy.dll

Examine the path entry carefully because it could be incorrectly set to the following:
%systemroot%\system32\rpcproxy.dll
For example, the current location could be set to the following:
c:\windows\system32\rpcproxy.dll
This incorrect path can appear to be correct at a quick glance.

Issue #5. No supported tools for mailbox management without Exchange Server in Hybrid Identity scenario

You more likely want to make legacy Exchange Server 2003 (or 2007) 
decommission after you've migrated all Exchange 2003/2007 mailboxes to Exchange Online. It won't be a problem with Office 365 Cloud Identities and it will be an issue with "DirSynced" ("AADSynced") Synchronized Identities (and Federated Identities as well). The only supported way for Synchronized/Federated Identities is to maintain at least one Exchange 2010+ Server on premise with free Exchange Hybrid Edition product key applied. So the only cost in this case is Windows Server license applied to this server (Windows Server Standard is a great choice here) and hardware/or VM resources dedicated to. As you might guess it can be still huge requirement for small customer.

Following methods not officially supported but work for simple daily Exchange administrative tasks without installing Exchange Server 2010/2013.
 

Prerequisites:
- AD Powershell module loaded (import-module activedirectory);
- DirSync/AADSync installed and works.
1. "Create mailbox" script actually creates mailuser with primary e-mail flastname@contoso.com which will be represented in Exchange Online as a mailbox after DirSync/AADSync cycle (and after Exchange Online license assignment):

$FirstName="FirstName"
$LastName="LastName"
# Set default password aB123456
$defaultpwd = ConvertTo-SecureString -string "aB123456" -asplaintext -force
# Domain UPN suffix
$domainsuffix="contoso.com"
# Office 365 tenant name
$tenantname="contoso.onmicrosoft.com"
# OU where to make provisioning
$OU="OU=New York,DC=CORP,DC=CONTOSO,DC=COM"
# Try to remove spaces here from generated samaccountname if exist
$samaccountname=$FirstName.substring(0,1)+$LastName -replace "\s", ""
$DisplayName=$FirstName+" "+$LastName
$mailnickname=$samaccountname
$Mail=$mailnickname+"@"+$domainsuffix
$targetaddress="SMTP:"+$mailnickname+"@"+$tenantname
$userprincipalname=$Mail
$proxyaddresses=@()
$proxyaddresses+=("SMTP:"+$Mail),$targetaddress

New-ADUser -Name $DisplayName -AccountPassword $defaultpwd -Enabled $true -SamAccountName $samaccountname -UserprincipalName $userprincipalname -GivenName $FirstName -Surname $LastName -DisplayName $DisplayName -EmailAddress $mail -Path $OU -OtherAttributes @{mailnickname=$mailnickname;targetaddress=$targetaddress;proxyAddresses=$proxyaddresses;msExchHideFromAddressLists=$false;} 

2. "Create mail-enabled security or distribution group" script 
creates distribution group with primary e-mail groupname@contoso.com which will be represented as Distribution Group in Exchange Online after DirSync/AADSync cycle:

$GroupName=Read-Host "Enter GroupName"
$GroupCategory=Read-Host "Enter Group Category: Security(1) or Distribution(0)"
$GroupScope=Read-Host "Enter Group Scope: Global(1) or DomainLocal(0) or Universal (2)"
$Description=Read-Host "Enter Group Description text record"
$OU="OU=Groups,OU=New York,DC=CORP,DC=CONTOSO,DC=COM"
$domainsuffix="contoso.com"
$msExchHideFromAddressLists=$false
$reportToOriginator=$true
$reportToOwner=$false
$oOFReplyToOriginator=$false

# remove spaces from Group Name
$SamAccountName=$GroupName -replace "\s", ""
$mailnickname=$SamAccountName
$Mail=$mailnickname+"@"+$domainsuffix
$proxyaddresses=@()
$proxyaddresses+=("SMTP:"+$Mail)

New-ADGroup -Name $GroupName -SamAccountName $SamAccountName -GroupCategory $GroupCategory -GroupScope $GroupScope -DisplayName $GroupName -Path $OU -Description $Description -OtherAttributes @{mailnickname=$mailnickname;mail=$mail;msExchHideFromAddressLists=$msExchHideFromAddressLists;reportToOriginator=$reportToOriginator;reportToOwner=$reportToOwner;oOFReplyToOriginator=$oOFReplyToOriginator}

3. Hide mailbox from 
Exchange Online Global address list after DirSync/AADSync cycle:

$User="samaccountname"
Set-ADUser -identity $User -replace @{msExchHideFromAddressLists=$true} 

4. Hide distribution group from 
Exchange Online Global address list after DirSync/AADSync cycle:

$Group="samaccountname"
Set-ADGroup -identity $Group -replace @{msExchHideFromAddressLists=$true}
5. Add new SMTP alias to Exchange Online mailbox after DirSync/AADSync cycle
$User="samaccountname"
$Mail="newalias@contoso.com"
$ADUser = get-aduser -identity $User -Properties proxyAddresses
$ADUser.proxyAddresses +=("SMTP:"+$Mail)
Set-ADUser -instance $ADUser