OWA and Moving Mailboxes to Office 365

Lets imagine a scenario where you are using an on-premises Exchange Server and users' use Outlook Web App, and then you move some mailboxes to the Office 365 cloud with Hybrid Coexistence enabled. The user might not know their mailbox has been moved and so yesterday they went to https://mail.company.com/owa, but today they need to visit https://outlook.com/owa/company.com (where company.com is the domain name in your login name).
But becuase the user does not know that their mailbox has been moved when they visit https://mail.company.com/owa they get an error that their OWA URL is out of date.
To fix this, and provide the user with the correct URL (https://outlook.com/owa/company.com) then you need to set the TargetOwaURL property of the Organization Relationship that you have configured for your Office 365 service domain.

Set-OrganizationRelationship name -TargetOwaURL https://outlook.com/owa/company.com

Now when users login with an account that has been moved to the cloud they will be told that their mailbox has moved, and that they should visit https://outlook.com/owa/company.com.
Some organizations though have an issue with this URL - it does not mention the company name in the domain name bit, and a name such as http://webmail.company.com/owa would be preferred for mailboxes moved to the cloud. To present the user with this URL after they login to on-premises OWA or for a URL that you can just tell them to use you need to do two things:

1. Create a CNAME record in DNS for webmail that has outlook.com as the target FQDN. The CNAME record can be anything that is not already in use for the domain (for example it could be mail if that is not in use).
2. The TargetOwaURL property of the Organization Relationship needs to be http://webmail.company.com/owa. The TargetOwaURL must finish with /owa or the on-premises OWA redirect page will error and the domain name used must be the domain name in your login name.

The outlook.com server will take the CNAME value provided by the browser and do realm discovery on this name - that is it will redirect you to the correct login server for your domain.

Assign Specific Licences in Office 365 Via PowerShell

To add specific licences to users in Office 365 without using the portal, and to assign subsets of the licences available requires two things. First you need to enumerate the licences and licence service plans, then you need to assign the new plan you have created to your users. This can be performed in bulk and is repeatable unlike when using the portal.
First, enumerate the licence plans and create your own licence:

1. Open Microsoft Online Services Module for Windows PowerShell and connect to the service
   • $cred = Get-Credential
   • Connect-MsolService -Credential $cred
2. Get-MsolAccountSku | Format-Table AccountSkuId, SkuPartNumber
   • The second column in this list is referenced in the next command as [SkuPartNumber]
3. $ServicePlans = Get-MsolAccountSku | Where {$_.SkuPartNumber -eq "[SkuPartNumber]"}
4. $ServicePlans.ServiceStatus
   • This returns all the service plans
5. $MyO365Sku = New-MsolLicenseOptions -AccountSkuId [tenantname:AccountSkuId] -DisabledPlans Comma_Seperated_List_From_ServicePlan_Output

Secondly you need to assign the licence to the user(s):

1. Set-MsolUser -UserPrincipalName user@domain.com -UsageLocation GB
2. Set-MsolUserLicense -UserPrincipalName user@domain.com -AddLicenses [tenantname:AccountSkuId] -LicenseOptions $MyO365Sku
3. Repeat for any other licences you want to apply for other users or other licence options you want to apply to this user.

For reference, the SkuPartNumber's that we discovered are:
Inside ENTERPRISEPACK Sku:

• OFFICESUBSCRIPTION (this is Office Professional Plus)
• MCOSTANDARD (this is Lync)
• SHAREPOINTWAC (this is Office Web Apps)
• SHAREPOINTENTERPRISE
• EXCHANGE_S_ENTERPRISE

Inside DESKLESSWOFFPACK Sku:

• SHAREPOINTWAC
• SHAREPOINTDESKLESS
• EXCHANGE_S_DESKLESS

Inside EXCHANGEARCHIVE Sku

• EXCHANGE_S_ARCHIVE

With thanks to Donte Henry (Avanade) and Tim Heeney (Microsoft). Discovered during the Office 365 MCM Class for Exchange 2010 MCM's.

Office 365 and Dynamic Distribution Groups

Updated Dec 8th 2011 to remove reference to LegacyExchangeDN

In Office 365 with Hybrid Deployment, if you create Dynamic Distribution Groups on the on-premises Exchange organization, these objects are not replicated to Office 365 via DirSync. Therefore for mailboxes in the Office 365 cloud they will not see the Dynamic Distribution Group in their Global Address List, and so therefore can only email the members of the list by sending an email directly to their email address.
To show the Dynamic Distribution Group in the GAL in the cloud, you need to add a MailContact to the cloud that represents the Dynamic Distribution Group. This MailContact object should have the following mappings:

On-Premises DDL	Cloud MailContact
Name	Name
proxyAddress	ExternalEmailAddress
Alias	Alias

Note that this MailContact object is made in Office 365 or Exchange Online and not in the on-premises AD. It is not replicated to the cloud via DirSync. If it exists on premises then the name for the DDL will appear twice in the on-premise GAL, once as a DDL and once as a contact object.
To determine the information need for the cloud contact object, run the following in Exchange Management Shell on premises:

Get-DynamicDistributionGroup | fl Name,EmailAddresses,LegacyExchangeDN

An alternative is to create the DDL in both the cloud and on-premises, but this can only happen if the attributes you are filtering on on-premises are replicated to the cloud via DirSync.

Migrate to Office 365 Using the Command Line

Cutover Migrations and Staged Simple Exchange Migrations from on-premise and hosted email systems can be done by the remote PowerShell command line (Powershell to Exchange Online). The help for New-MigrationBatch claims that migrations from Hotmail are possible, but the actual commands are not working at this time.
Doing a migration via the command line is possible, and is documented below, but if you can do it via Exchange Control Panel it is considerably easier.
To migrate you need to create a migration connection string. This is done with Test-MigrationServerAvailability. Once you have this object you can use it in the migration with New-MigrationBatch.
To grant access to one user account to all mailboxes perform the following in Exchange Management Shell:

• Get-Mailbox | Add-MailboxPermission -User domain\user -AccessRights FullAccess

To connect to Exchange Online do the following:

1. Start the Windows Powershell
2. $cred=Get-Credential tenant_admin@tenant.onmicrosoft.com
3. $EOSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/PowerShell/ -Credential $Cred -Authentication Basic -AllowRedirection
4. Import-PSSession $EOSession -AllowClobber

To perform the migration do the following:

1. $MigrationSettings = Test-MigrationServerAvailability -Exchange -Credentials (Get-Credential) -ExchangeServer internal-exchange-fqdn -RPCProxyServer external-outlook-anywhere-fqdn
• Enter credentials of account that has FullAccess rights to all mailboxes
2. New-MigrationBatch -Exchange -Name unique-name-for-migration  -ExchangeConnectionSettings $MigrationSettings.ConnectionSettings -MaxConcurrentMigrations 10 -TimeZone "Pacific Standard Time"
3. Start-MigrationBatch

To see the status of the migration do one of the following:

• Get-MigrationBatch OR Get-MigrationStatus

Once the migration has completed (Get-MigrationBatch | Format-List Status shows Completed) then complete the migration to finish:

• Complete-Migration

Enable-OrganizationCustomization

Exception has been thrown by the target of an invocation is an error you can see in Office 365 Rich Coexistence when you are first configuring the settings.
This is due to the hydration status of your tenant at Office 365. Each Office 365 tenant is not "hydrated" by default. Hydration is the adding of lots of settings in the Exchange Online directory service per tenant - by default lots of tenants do not need these settings and so rather than creating the settings per tenant, each tenant shares these common settings.
To enable your own Transport Rules, Free/Busy Rich Coexistence and custom RBAC settings require that all the "common" settings in the directory are copied to the tenants area of the directory. To do this means you need to run the Enable-OrganizationCustomization cmdlet in remote PowerShell to Exchange online.
Once this is done the GUI will create RBAC, rules, free/busy etc. without throwing Exception has been thrown by the target of an invocation error.
The exact steps to perform on your Office 365 tenant before configuring RBAC, rules or coexistence are as follows:

1. Start the Windows Powershell
2. $cred=Get-Credential tenant_admin@tenant.onmicrosoft.com
3. $EOSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/PowerShell/ -Credential $Cred -Authentication Basic -AllowRedirection
4. Import-PSSession $EOSession  -AllowClobber
5. Enable-OrganizationCustomization

Adding Servers to ADFS 2.0 Farms - Subject Alternative Name Issues

When you add additional servers to an ADFS 2.0 farm and you have used a subject alternative name from your certificate to create the first server in the farm the additional servers will not be able to join the farm. If you have used the subject name on the certificate all works fine.
You get the following error message:

The Subject name of the SSL certificate for the Default Web Site on this computer should match the name of the Federation Service to which you are trying to join this computer.

You also get the following error:

No certificates matching the Federation Service name were found in the Local Computer certificate store. Install the certificate that represents your Federation Service name in the Local Computer certificate store, and then try again.

The help file for ADFS 2.0 says "the actual name text is determined by either the Subject field or, if necessary, the Subject Alternative Name field of the certificate", but the addition of additional servers does not work if you have used a Subject Alternative Name.
So how do you get around this. With thanks to Tim Heeney and Roberto Martinez Lima from Microsoft and the rest of the class on the inagural Office 365 Microsoft Certified Master class (a subset of the Exchange 2010 MCM program) we worked out the answer. You need to install the additional servers from the command line - the problem is a user interface bug in the ADFS 2.0 setup program.

FsConfig.exe JoinFarm /PrimaryComputerName ADFS-SRV-1 /ServiceAccount fabrikam\adfsservice /ServiceAccountPassword password /CertThumbprint "ef 72 a6 78 c0 ab 4a bf 07 10 7e e4 86 f5 5e ba 2a 3c 99 6b"

The thumbprint needs to be the thumbprint of the certificate used on the first ADFS server and imported into the computer certificate store on the additional ADFS servers.
On running the FsConfig command above you should get a series of green Passed statements. Existing databases can be removed with /CleanConfig switch. A yellow warning about an existing website can be ignored unless you have broken the website previously!

Mismatched Archive GUID for Moving Archive to Office 365

If you create an archive in Office 365 for a mailbox on-premise you might find that it does not work - the actual archive is not (as of time of writing) created correctly. What's the way around it? The way around it is to create the archive on-premise and then move the archive to the cloud.

But you get this error message:

Recipient 'Aaron Con' has mismatched archive GUID (19ec252e-00b2-463f-b9b4-7012fabfa60e). Expected value: 00000000-0000-0000-0000-000000000000.
Click here for help... http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.218.11&t=exchgf1&e=ms.exch.err.Ex71CCCD
Exchange Management Shell command attempted:
'c607a1af-5608-424d-8ea1-447dcad60003' | New-MoveRequest -Remote -ArchiveOnly -RemoteHostName 'mail.fabrikam.student027.mcmexch.ms' -ArchiveDomain 'o365.fabrikam.student027.mcmexch.ms'

This is caused because the archive has been created on-premise and then before this change is synchronised to the cloud the move occurs. The actual steps to do the above are as follows:

1. Create local archive
2. Synchronise changes to the cloud
3. Move the archive to the cloud
4. Wait until the move request completes (run Get-MoveRequest identity via Remote PowerShell to Exchange Online)
5. Check that archive in cloud is provisioned with Get-MailUser identity | FL *archive* run via Remote PowerShell to Exchange Online. This will take a few minutes before the ArchiveDatabase value is populated.
6. Synchronise changes again, so that the changes in the cloud are pushed back to on-premise
7. Login as the user and access the cloud archive.

Office 365 DirSync Schedule

The DirSync process sync's every three hours by default, with  a random number between 1 and 10 minutes is added to the SyncTimeInterval to provide an additional time buffer to this three hour period.
This schedule can be changed by editing Microsoft.Online.DirSync.Scheduler.exe.Config in C:\Program Files\Microsoft Online Directory Sync. Change <add key="SyncTimeInterval" value="3:0:0"> to read a different value for hours:minutes:seconds and restart the Microsoft Online Services Directory Synchronization Service.

Note that increasing the time sync interval will result in changes to the Active Directory not being synced until this time period has passed and so the longer the interval the greater risk that objects disabled or removed in the on-premise Active Directory are not replicated to Office 365 and therefore remain as a valid account within Office 365.

Lab Environment: Set All Users With Non-Expiring Passwords

Using Active Directory Module for Windows Powershell (part of Windows 2008 R2 Active Directory and downloadable for earlier versions of AD) use the following cmdlet to set all your user to have non-expiring passwords. Great for lab environments:

Get-ADUser | Set-ADAccountControl –PasswordNeverExpires $True

Free/Busy Cross-Forest Working One Way Only

Or indeed, not working at all! I had the issue of it working one way only (On-Premise Exchange organization > Office 365) but the other way (cloud to on-premise) did not work at all.

The answer is shown in this video

http://www.microsoft.com/showcase/en/us/details/a16a9d39-416a-4b01-a88f-5ff511580424

This covers the reasons why Free/Busy (and the other federation features of MailTips, archive and move mailbox might not work both ways in a Hybrid Coexistence setup for Office 365 or between two Exchange on-premise organizations.

The reason I found was the Organization Relationship contained the wrong list of domains. There are three domains (at least) that are needed in the organization relationship. These are:

• Primary SMTP Namespace Domain (i.e. fabrikam.com)
• Namespace for other organization (i.e. service.fabrikam.com)
• Exchange Delegation domain (i.e. exchangedelegation.fabrikam.com)

In the organization relationship on-premise (or Org A if you are doing two on-premise organizations) set the following domains after the relationship is created. This includes the primary SMTP namespace and the service namespace for the other organization. This can be set with the following Exchange Management Shell cmdlet:

Set-OrganizationRelationship -Identity "To Cloud" -DomainNames "service.fabrikam.com","fabrikam.com" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True –TargetOwaUrl https://outlook.com/owa/fabrikam.com -ArchiveAccessEnabled $True –MailboxMoveEnabled $True

In Org B (or on Office 365) use a similar cmdlet, but use the Exchange Delegation namespace and the primary SMTP domain. Also Office 365 does not let you set the MailboxMoveEnabled property to $True

Set-OrganizationRelationship -Identity "To On-premises" -DomainNames "exchangedelegation.fabrikam.com","fabrikam.com" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True -ArchiveAccessEnabled $True

Supposedly Service Pack 2 for Exchange 2010 will do all this and more for you with the Hybrid Configuration Wizard, but its always useful for troubleshooting to discover what changes and why when you run a wizard to do things!

CRM Router and Exchange 2010

To configure the CRM Email Router with Exchange 2010 you need to do the following. Not all of these points are clearly documented on the internet.

1. Create a mailbox (CRM_Router@domain.com)
2. Set password never to expire
3. Ensure that the mailbox is not hidden from the address list
4. Login to above mailbox
5. Enable impersonation with the following Exchange Management Shell command

   New-ManagementRoleAssignment –Name: "ApplicationImpersonation-CRM Router" -User: "CRM_Router@domain.com" –Role:"ApplicationImpersonation"

6. [Optional] See http://blogs.msdn.com/b/crm/archive/2009/12/21/how-to-configure-microsoft-dynamics-crm-4-0-e-mail-router-on-premise-with-microsoft-exchange-server-2010.aspx for EMS commands to limit the scope of the CRM_Router user account
7. Configure the CRM Email Router as per http://snackbox.microsoft.com/pages/snackdetail.aspx?itemId=152&userId=&caid=&csId=%257b4c712394-1373-4d8e-b85e-369111823def%257d%2540%257b4a9965c4-db36-4193-9e83-32347ea3b0f1%257d
8. Ensure that CRM_Router@domain.com is a CRM System Administrator level account.