Mailbox moves between Exchange Online tenants

For the last several years I've been involved mostly in tenant to tenant migration projects. These projects typically include migration of email, teams, and SharePoint. My focus is on email migration.

For migration, there are a number of third party tools such as MigrationWiz (Bit Titan) and On Demand Migration for Email (Quest ODME) that can be used. I don't know all of the details for all tools, but at least in the case of ODME, the migration is copies mailbox data, but doesn't synchronize it. So, if you migrate data from source to target and the user later deleted data from the source, it is not deleted in the target. Occasionally, this is annoying and causes confusion for users.

Microsoft has tenant-to-tenant mailbox moves in Preview. This type of move is a migration batch like moving mailboxes between on-premises Exchange and Exchange Online. In this case, you get true syncing which is a better quality move. It looks like a bit of a pain to setup and manage, but I expect the experience will improve over time.

• https://docs.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration

The documentation claims that mailbox permissions like Full Access are maintained as long as users are part of the same migration batch. It does not mention inbox rules.

Another interesting item that's coming up is Microsoft 365 cross-tenant SMTP domain sharing. This  allows an email domain to exist in two Microsoft 365 tenants simultaneously and will make it easier to manage incremental migrations between tenants when you want to maintain the same email address. The feature is currently in private preview, but is scheduled to be moved into public preview in June 2022.

You can monitor the development status at:

• https://www.microsoft.com/en-ca/microsoft-365/roadmap?filters=&searchterms=67161
  

Update Source Anchor to ms-DS-ConsistencyGUID

A key part of most Office 365 deployments is directory synchronization with on-premises Active Directory (AD). To maintain a link between individual object in AD and Office 365, one attribute in AD is defined as the source anchor. The source anchor acts as a unique identifier for each object so that you can change properties like UPN and have them replicate to the proper matching object in Office 365.

Older versions of Azure AD Connect used the objectGUID attribute as the source anchor. In many cases, this is a good choice because it is an attribute that doesn't change. However, in complex configurations with multiple AD forests, this can cause an issue during migrations. When a user account is moved from one AD forest to another, it gets a new objectGUID in the new forest. Due to the new objectGUID , Azure AD Connect treats the user as a new user instead of an existing user.

To avoid this issue, we need to use an attribute for source anchor that can be moved between forests. Microsoft now recommends that deployments of Azure AD Connect use the mS-DS-ConsistencyGuid attribute as the source anchor. Unlike objectGUID , this attribute can be modified. So, it can be maintained when users are moved between forests.

I've just recently completed this process and I'll provide some general guidance (for my own reference) and a few items that I didn't see anywhere else.

Updating the Source Anchor

First, read the information from Microsoft on updating the source anchor. You'll need to scroll down a bit to the heading "How to enable the ConsistencyGuid feature - Existing deployment".

• https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-design-concepts#using-msds-consistencyguid-as-sourceanchor

This documentation provides click by click instructions on how to use the Azure AD Connect configuration wizard and work through the Change Source Anchor option. This wizard will:

• Require you to enter Azure AD credentials for a global admin
• Require you to enter a user account with AD FS admin permissions (if integrated with AD FS)
• Do a prerequisite check
• Update necessary settings in Azure AD
• Update necessary settings on connectors for all connected forests
• Update AD FS claim rules

If you're like me, before attempting this you'll scour the web looking for information about how to fix things when they go wrong. Unless things change a lot after I write this, you won't find much. The reason you won't find much is because the wizard does exactly what it's supposed to.

Note: The wizard does not ask you which attribute you want for the source anchor. It is assumed that you want to use mS-DS-ConsistencyGuid.

Change Details

When the wizard is done, a full sync is triggered for all connected forests. As part of the full sync Azure AD Connect reviews the value of the mS-DS-ConsistencyGuid attribute. If the value is blank, the objectGUID value is copied into the mS-DS-ConsistencyGuid value. Then on the next sync cycle the mS-DS-ConsistencyGuid value is sent to Office 365.

If you are using AD FS, the wizard updates the AD FS claims rules for Office 365. I didn't do a detailed review of the rules, but it seems to be similar (if not the same) as the rules Microsoft documents for you to make manual changes. You can see these rules here:

• https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-federation-management#modclaims

The Modify AD FS Claim Rules section in the above link has four rules. The net effect of these rules is to use mS-DS-ConsistencyGuid if it is populated and use objectGUID otherwise. This avoids downtime when AD FS rules have been modified but the mS-DS-ConsistencyGuid hasn't been populated yet.

Permissions to mS-DS-ConsistencyGuid

If you have let the installation and configuration wizards for Azure AD Connect manage all of the service account permissions and AD FS integration, there should be no issues. However, if you've been manually configuring the permissions and AD FS rules, you might need to make changes manually.

The only permission change required when changing the source anchor is ensuring that the service account in each domain has read and write permissions to the mS-DS-ConsistencyGuid attribute. Unfortunately when you attempt to assign these permissions by using Active Directory Users and Computers, you find out that the attribute is not displayed in the GUI for modifying permissions. To set the permissions, use the following command (please note that this is a single line):

dsacls.exe "dc=contoso,dc=com" /I:S /G "contoso\serviceaccount:RPWP;mS-DS-ConsistencyGuid;user"

The above command grants (/G) inheritable (/I:S) permissions to the service account to read (RP) and write (WP)  the mS-DS-ConsistencyGuid attribute on user objects.

Verifying Successful Implementation

Obviously after a successful implementation, your users can still sign in to Office 365, but there are a few other things you can verify:

• Review the AD FS claim rules for Office 365 and verify that they were modified.
• Review the mS-DS-ConsistencyGuid attribute on several user objects to verify that it has been populated.

On one deployment, we had an error in the Azure AD Connect full sync for one domain immediately after finishing the wizard. The domain that finished properly updated the mS-DS-ConsistencyGuid attribute and the domain with the error didn't. Running an incremental sync didn't fix it. We needed to force a full sync again to get the attribute updated properly.

When viewing the value of the mS-DS-ConsistencyGuid attribute in Active Directory Users and Computers, the value might be displayed in special characters for some users. This is a display error in Active Directory Users and Computers. This is not something you need to fix.

For Further Reading

• Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1
• Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 2
• Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 3 

Remove Proxy Address from Office 365 User

I ran into an issue today where I needed to remove a proxy address from a cloud-based administrative user in Office 365 that was unlicensed. This user had a proxy address that was conflicting with a proxy address that was being synced with Azure AD Connect for another user account.

The cloud user was originally created as byron@OnPremDomain.com and renamed to be byron@CloudDom.onmicrosoft.com. When this was done, the original address (byron@OnPremDomain.com) was kept as a proxy address. You could view both addresses when using Get-MsolUser. This address caused a synchronization error for an on-premises user named byron@OnPremDomain.com.

To resolve this error, I need to remove byron@OnPremDomain.com from the list of proxy addresses. However, you can't do this with Set-MsolUser. The mechanism for managing proxy addresses in Office 365 is Set-Mailbox. But, without a license, there is no mailbox for the user account.

The solution is to add a license temporarily:

1. Add a license for byron@CloudDom.onmicrosoft.com which creates a mailbox.
2. Use Set-Mailbox -EmailAddresses to remove the incorrect proxy address.
3. Verify Get-MsolUser shows only the correct proxyaddresses.

Updating SIP Addresses in Skype for Business

When you migrate to Office 365, the preferred configuration is to have user email addresses and UPNs the same. Having a single identity makes it easier for users to understand.

If you are implementing Skype for Business in Office 365, it will take the UPN of the user as the Skype address. Again, keeping a single identity is good.

However, if you have an on-premises implementation of Skype for Business, then the Skype identity is configured in the attribute msRTCSIP-PrimaryUserAddress.  This attribute contains a SIP (session initiation protocol) address that looks like an email address but with “sip:” at the start. For example: “sip:user@contoso.com”.

The SIP addresses defined in your on-premises Skype for Business may or may not match the email addresses of the users. You need to verify whether the addresses match. If the SIP address does not match the email address, it is easy to change.

On the Skype Server run the following PowerShell command:

Set-CsUser -Identity userUPN -SipAddress "sip:emailaddress"

When you update the SIP address for UserA there are two considerations:

• UserA will be signed out of Skype within about 1 minute. After UserA is signed out, they need to sign in again by using their new SIP address.
• Any users with UserA as a contact are not updated immediately. These users need to sign-out and sign-in again for the contact to be updated and properly view presence information. However, this only works if the address book as been updated.

Address book updates are the big gotcha in SIP address updates. By default, Skype for Business clients use a cached address book that only updates once per day. Even if you force address book updates on the server, the new address information is not retrieved until the next day unless you manually delete the cached address book files from the client to force a reload.

To address this problem, you can switch clients to use an online address book. Clients using the online address book query the Skype for Business server each time they search the address book. When using the online address book, changes show up within a few minutes.

Address book look ups are controlled by client policies. By default, there is one policy named Global. You can update this policy to use online address book resolution with the following command:

Set-CsClientPolicy -Identity Global -AddressBookAvailability WebSearchOnly

Alternatively, you can create a new policy and assign that to users incrementally:

New-CsClientPolicy -Identity OnlyWebAB -AddressBookAvailability WebSearchOnly
Grant-CsClientPolicy -Identity UserName -PolicyName OnlyWebAB

The new client policy takes effect the next time the user signs in. To increase the likelihood that users have the new policy, you should configure it and then wait until the next day before making large scale changes.

Some useful links:

• Video showing results of changing SIP address
• Anatomy of a SIP Address Change Part #2
• Forcing Lync Address Book Web Query
• Troubleshooting addressbook issues in Lync 2013/Skype for Business

SourceMailboxAlreadyBeingMovedTransientException

Today while moving a mailbox from on-premises to Office 365 in a hybrid environment, I got the following error:

Transient error SourceMailboxAlreadyBeingMovedTransientException has occurred. The system will retry (5/620).

This error occurs when a previous move attempt did not get cleaned up properly. From a bit of reading, this should timeout and fix itself after about 2 hours. However, since I didn't want to wait that long, I did the following that got it going again.

• IISReset.exe to restart the web services
• Restart the Microsoft Exchange Mailbox Replication service

It is possible that only one of those two items was required, but I was more concerned about getting the move going than recording exact details.

Firefox Error Accessing Office 365

Microsoft is having a certificate trust issue today for Firefox when accessing Office 365 services. I haven't bothered digging into the details, but it's something to do with trust checking by using OCSP (Online Certificate Status Protocol).

The error you see is "SEC_ERROR_OCSP_INVALID_SIGNING_CERT" and looks like this:

Other browsers are not affected. So, you work around this by using Chrome, IE, or Edge.

If you prefer to continue using Firefox, you can modify the setting for certificate verification with the following steps:

1. In the address bar, type about:config and press Enter.
2. Click the I accept the risk button.
3. Scroll down to security.ssl.enable_ocsp_stapling and double-click it to set the value to false.

Given that other browsers don't use this type of security, it's fairly safe to disable.

Everyone Dynamic Group with Office 365 Hybrid

Many organizations have configured a dynamic distribution group that includes all users with mailboxes. This Everyone group is used for sending out company notifications and the like. Because this group is dynamic, it's automatically updated as new mailboxes are added and removed.

When you implement hybrid mode with Office 365, the dynamic group will include on-premises mailboxes but not cloud mailboxes. This is because cloud mailboxes are a different recipient type that is not included. Cloud mailboxes are MailUser recipients (an AD user with an email address but no mailbox).

One way to fix this is to modify the dynamic distribution group to include MailUser recipients. The screenshot below has enabled Users with external e-mail addresses.

This will include users with cloud mailboxes. This is the recipient filter for the dynamic distribution group:

((((RecipientType -eq 'UserMailbox') -or (RecipientType -eq 'MailUser'))) -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox')))

Note that everything after the two recipient types is added automatically when you set the filter. So, don't include that information when you set a filter. If you do, those requirements will be in there twice.

Unfortunately, the recipient type UserMailbox includes on-premises resource mailboxes and the MailUser recipient type includes cloud resource mailboxes. To exclude those from our dynamic distribution group we need to manually configure the filter. We can do this by excluding the following values for RecipientTypeDetails:

• RoomMailbox
• EquipmentMailbox
• RemoteRoomMailbox
• RemoteEquipmentMailbox

I set the following filter to achieve this:

((((RecipientType -eq 'UserMailbox') -or (RecipientType -eq 'MailUser'))) -and (-not(RecipientTypeDetailsValue -eq 'RemoteRoomMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'RoomMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'RemoteEquipmentMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'EquipmentMailbox')))

Now, the next challenge is allowing cloud users to see this dynamic distribution group. This is an issue because Azure AD Connect does not synchronize dynamic distribution groups to Office 365. For more information about this see:

• Exchange Hybrid Mode and Dynamic Distribution Groups

Removing a Cloud Mailbox from A Synced User

The title for this post is a bit incomplete because there wasn't enough space for a full explanation. Here is the scenario I had...

Before setting up hybrid mode for an Exchange 2010 organization, a user account was created in Office 365 with the same UPN as a user account in on-premises. The on-premises domain had been added to Office 365, but directory synchronization was not yet in place.  As part of testing, the user account had been give an Office 365 license, which then created an online Exchange mailbox.

When directory synchronization was configured, the on-premises AD account was matched with the existing cloud user. However, the on-premises user has an on-premises mailbox and the cloud user has a cloud mailbox. When viewing the cloud user in Office 365, you could see the mailbox in the cloud.

Because there was an existing cloud mailbox I couldn't move the on-premises mailbox up to Office 365. There was also no way to remove the cloud mailbox to allow the on-premises mailbox to replace it. If the user license was removed, then the cloud mailbox was removed, but came back again when the license was re-added.

To fix this I had to delete the cloud user account and recreate it. To delete the cloud user account, I moved it into an organizational unit that Azure AD Connect was not syncing. Then I purged the user account in Office 365 with the following cmdlet:

Remove-MsolUser -UserPrincipalName user@domain.com -RemoveFromRecycleBin

Finally I moved the user back to an OU that was synchronized. This recreated the cloud user account without a mailbox and the account was identified as having an on-premises mailbox.

New Hybrid Free/Busy Fails Cloud to On-Prem

When you configure hybrid mode, calendar sharing is automatically configured between on-premises and cloud users. You don't need to configure anything. However, in some cases, you may need to perform an IISreset.

On a recent project implementing implementing hybrid mode for an Exchange 2010 organization, we enabled hybrid mode and tested connectivity. Everything looked good for mail flow and mailbox moves. However, free/busy lookups failed from the cloud users to on-premises. When we tried to view the on-premises users' calendars the status was "No Information".

When you're not sure what's going on, it's always a good idea to use the Remote Connectivity Analyzer to test things out. There is an Office 365 tab which includes a Free/Busy test. When I ran this test, it was successful, as shown in the figure below. However it still wasn't working.

It's been a while since I've implemented Hybrid for Exchange 2010. With a quick search, I found this blog post that reminded me that an IIS reset will fix this up:

• https://jesperstahle.azurewebsites.net/?p=242

Most Exchange IIS related issues resolve themselves after a period of time. That period of time might be 12-16 hours, but usually there is some background process that refreshes things.

In this case, hybrid mode had been configured for multiple days. The free/busy lookups required an IISreset or a server reboot to fix.

This fix is certainly relevant for Exchange Server 2010. It may also be relevant for later versions of Exchange Server.

Must Run O365 Hybrid Wizard with IE

Today I made the mistake of downloading and attempting to run the Office 365 Hybrid Deployment Wizard by using Firefox. When you do, the app starts to launch and the fails. When you click on the Details button to open the log file, you see this under the error summary:

Deployment and application do not have matching security zones.

Download the app from within IE and no problems.

Link to download the wizard:

• https://aka.ms/HybridWizard

UPDATE: Also worth noting that a similar error with the wizard not running occurs if the .application file extension is not associated with Internet Explorer.

• https://paulrobichaux.com/2017/06/30/office-365-hybrid-configuration-wizard-wont-launch/ 

Script to Synchronize Primary Email Address with UPN

When planning an Office 365 implementation, it is best practice to start by assuming that UPN for signing in to Office 365 should match the user email address. If you don't configure it this way, then users have two separate items (their UPN for signing in and their email address) that look very similar. In many cases users are confused by the similarity.

If you are synchronizing  your on-premises Active Directory with Office 365 (in most cases you do) then you need to set the UPN for the on-premises user accounts with the correct UPN. The UPN from on-premises user accounts is synchronized to Office 365 to create the ID for signing in.

Most organizations are not using the UPN on user accounts for authentication on-premises. The option has been there since Windows 2000, but most organizations still use the domainname\username format for authentication. However, you need to verify if any user accounts are using the UPN for authentication before making this change. At minimum, you should communicate with your application and system administrators to see if they are aware of anything that might use UPNs. If your organization has issued certificates to users, they might be using UPN as the unique identifier for the certificate.

The script below does the following:

• Obtains a list of all users where the proxyAddresses attribute has a value. This is done so that the result include only user accounts with an Exchange attributes configured.
• Identifies the primary email address based on the all caps "SMTP:" text.
• Strips out the "SMTP:" text from the primary SMTP address.
• If the new UPN and the existing UPN do not match the user account is updated and the change is logged.

The location and name of the log file are configured in $logfile. You need to manually configure this variable and verify that the necessary folders exist.

  

 #Log folder must already exist  
 $logfile = "C:\Scripts\SyncUPN.txt"  
   
 #Adds timestamp to log file  
 Get-Date | Out-File -FilePath $logfile -Append  
   
 #Obtains only users with valid proxyAddresses attribute   
 $users = Get-ADUser -Properties proxyAddresses -Filter {proxyAddresses -like "*"}  
   
 #Prepare variables for processing status  
 $total = $users.count  
 $current = 0  
   
 Foreach ($u in $users) {  
   #Find primary SMTP address for user  
   $primarySMTP = $u.proxyAddresses | Where-Object {$_ -clike "SMTP:*"}  
       
   #Remove "SMTP:" to create the new UPN value  
   $newUPN = $primarySMTP.Substring(5)  
       
   #Set the new UPN value only if required  
   If ($u.UserPrincipalName -ne $newUPN) {  
     $u.DistinguishedName + " Old UPN: " + $u.UserPrincipalName | Out-File -FilePath $logfile -Append  
     $u.DistinguishedName + " New UPN: " + $newUPN | Out-File -FilePath $logfile -Append  
     Set-ADUser $u -UserPrincipalName $newUPN      
   } #end if  
   
   #Processing status  
   $current += 1  
   Write-Progress -Activity "Processing users to update UPN to primary email address" -Status "Progress: $current" -PercentComplete ($current/$total*100)   
        
 } #end foreach  

Script to Remove Old Domains from User Email Addresses

When managing email addresses and domains in Exchange Server, old email addresses are never removed automatically. This is good because it ensures that email addresses on a mailbox are never accidentally lost. However, you may want to clean up old domains or address formats that are no longer in use.

Some common scenarios where you might want to remove an old domain:

• An SMB deployment of Exchange Server where a .local domain was added as the first domain for email addresses.
• Old GroupWise addresses are left in place from an older migration.
• Obsolete domain left over from a company merger many years ago

I often find that obsolete domains are identified when I run IDFix as part of preparing to migrate to Office 365. To simplify the removal of obsolete domains, I have created the following script.

A few things to note:

• You need to set $RemovePattern to identify the domain to be removed. Any email addresses matching this pattern will be removed from proxyAddresses attribute in Active Directory objects.
• The script uses Get-ADObject rather than Get-ADUser to make sure that the domain is removed from distribution groups too.
• This version of the script is capable of removing multiple instances of a matching email address. So, if a user has several email addresses in the old domain, all of them are removed.
• At the end of the script, I use Write-Progress to display a status bar. It's not necessary, but if there is a large number of users it's nice to see activity on the screen instead of just waiting and hoping it's doing something.

 #This pattern is used to match the email addresses being removed.  
 #Test that this pattern finds the correct users and email addresses  
 #before running this script.  
 #Example: $pattern = "smtp:*@olddomain.com"  
 $RemovePattern = "smtp:*@olddomain.local"  
   
 Import-Module ActiveDirectory #only required for 2008 R2  
   
 #Get the users that have an email address that matches the pattern  
 Clear-Host  
 Write-Host "Querying objects...This may take a moment"  
 Write-Host ""  
 $objects = Get-ADObject -Filter {ProxyAddresses -like $RemovePattern} -Properties ProxyAddresses  
   
 #Identify address being removed from first user for warning  
 [String]$proxyexample = $objects[0].proxyaddresses -like $RemovePattern  
   
 #Display warning and get confirmation  
 Write-Host "You are going to remove email addresses that match the following pattern:"  
 Write-Host -ForegroundColor Red "$RemovePattern"  
 Write-Host ""  
 Write-Host "This is an example from the first object:"  
 Write-Host -ForegroundColor Red "$proxyexample"  
 Write-Host ""  
 Write-Host "This will modify $($objects.count) objects"  
 Write-Host ""  
   
 $confirm = Read-Host "Enter Y to continue"  
 If ($confirm -ne "Y") {Break}  
   
 #Prepare variables for processing status  
 $total = $objects.count  
 $current = 0  
   
 #Processing users to remove addresses  
 Foreach ($o in $objects) {  
     
   #Build list of addresses to remove for object  
   #required because there might be multiple that match  
   $proxy= New-Object System.Collections.ArrayList  
   
   Foreach ($a in ($o.ProxyAddresses)) {  
     If ($a -like $RemovePattern) {  
       $proxy.add($a) | Out-Null  
     } #end if  
   } #end foreach  
     
   #Remove each bad address  
   Foreach ($p in $proxy) {  
     Set-ADObject $o -Remove @{'proxyAddresses'=$p}  
   }  
     
   #Pause  
   
   #Processing status  
   $current += 1  
   Write-Progress -Activity "Removing email addresses that match pattern" -Status "Progress: $current" -PercentComplete ($current/$total*100)   
 } #end foreach  

Making Sense of Office 365 Plans

If you're just starting to look at Office 365 as a solution for your organization, the various plans can be overwhelming and confusing. I'm going to try and boil down all of the Office 365 plan information to just the essentials that allow you to make an informed decision.

This is all based on research done March 2017 and the prices I include are Canadian dollars. You should verify that these features and prices are still correct for your scenario before making any decisions. I've includes some links at the bottom of this article to Microsoft documentation for you to verify. Microsoft should be keeping that content up to date.

I'm going to focus on Office 365 plans for small business and enterprise. However, whether you are small business, non-profit, enterprise, or education, there are basically three generic Office 365 plans available:

• Office 365 desktop apps (Word, Excel, Outlook, etc)
• Cloud services (Exchange, Skype for Business, etc)
• Office 365 desktop apps and cloud services

Most of the organizations I work with are looking for the cloud services. The initial driver most of them have is replacing an older installation of Exchange Server. At the same time, they can evaluate whether including Office 365 desktop apps is appropriate. I do not have any customers subscribing to only the Office 365 desktop apps.

The Office 365 plans for small business (300 user max) are:

• Office 365 Business (desktop apps)
• Office 365 Business Essentials (cloud services)
• Office 365 Business Premium (Business + Business Essentials)

The Office 365 plans for enterprise (unlimited users) are:

• Office 365 ProPlus (desktop apps)
• Office 365 Enterprise E1 (cloud services)
• Office 365 Enterprise E3 (ProPlus + E1 + a few cloud features)
• Office 365 Enterprise E5 (E3 + cloud telephony)

It is possible to continue using your existing OEM, retail, or volume licensed edition of Microsoft Office with Office 365 cloud services. So, if you recently purchased 100 volume licenses of Office 2016, that is not a lost investment. You can use those licenses until you are ready to upgrade to a newer edition of Office and then evaluate whether you prefer to purchase new volume licenses for Microsoft Office or change your Office 365 licensing to include the desktop apps.

Office 365 Desktop Apps

The Office 365 desktop apps are similar to the Microsoft Office Suite that you can buy retail, OEM, or through volume licensing. The biggest difference you'll notice is that these apps are streamed to desktops from Office 365 rather than a traditional installation (however it looks the same from a user perspective). This means that they are automatically updated outside of the Windows Update process. This should make the apps more secure because they will be updated faster than most organizations typically deploy updates. However, you do loose control over the update process and this may be a concern in organizations with specialized plugins.

The licensing for the Office 365 desktop apps is per named user rather than per computer. Each user can have up to five instances of the Office 365 desktop apps on devices. This allows a single user to put the Office 365 desktop apps on a work computer, a work laptop and a home computer. However, this does not mean that an organization with 20 users and 20 computers should purchase just 4 user licenses and install the Office 365 desktop apps 5 times per license. You need to license the Office 365 desktop apps for each user.

Licensing for Office 365 desktop apps is verified by signing in to Office 365. On each computer with the Office 365 desktop apps, you need to sign in to Office 365 at least every thirty days to verify that the license is still valid. This is a concern only in scenarios where a mobile computer would not have Internet access for more than 30 days.

Office 365 Business and Office 365 ProPlus contain the same apps:

• Outlook
• Word
• Excel
• PowerPoint
• OneNote
• Access

However, there are minor differences in app functionality. The following features are available only in Office 365 ProPlus and are not available in Office 365 Business:

• Outlook:
• Information Rights Management (IRM)
• Data Loss Prevention (DLP)
• Access:
• Database Compare
• Excel:
• Spreadsheet Compare
• Spreadsheet Inquire
• Power Map
• Power Pivot
• Power Query
• Power View
• Support for Group Policy-based configuration
• Support for Office add-ins, ActiveX, and browser helper objects (BHO)
• Roaming settings

For a complete comparison of features, see Office Applications Service Description.

Note that some older documentation may reference that:

• "Access is not included in Office 365 Business." Update: Access is included with Office 365 Business starting in November 2016.
• "Outlook in Office 365 Business cannot access Exchange in-place archives." Update: The current version of Outlook in Office 365 Business can access in-place archives (also referred to as archive mailboxes). See Outlook license requirements for Exchange features.

Office 365 Plans with Cloud Services

Most cloud services in the small business and enterprise plans are the same. All of the small business and enterprise plans include the following:

• Mailbox and calendar
• Office Online apps - web-based versions of Word, Excel, and PowerPoint
• OneDrive - personal file storage
• SharePoint Online - shared file storage
• Skype for Business - teleconferencing and instant messaging
• Active Directory integration - synchronizes Active Directory users into Office 365
• Yammer - Group discussions

The Office Online apps are very useful for performing quick edits to documents stored in OneDrive or viewing email attachments. In most cases, users prefer to continue using standard Microsoft Office desktop apps. However, in a very cost conscious organization, with limited needs, the online Office apps may be sufficient.

The graphic below summarizes some of the similarities and differences between the small business and enterprise plans:

Some differences to highlight are:

• The small business plans are limited to 300 users. However, you can have a mix if small business and enterprise licenses in a single Office 365 tenant.
• The small business and E1 plans have 50 GB mailboxes with 50 GB archives. The E3 plan has a 100 GB mailbox with unlimited archives. For small business and E1 plans, you can purchase an Archiving add-on for unlimited archiving.
• Only the E3 plan supports litigation hold and data loss prevention for email.
• The small business and E1 plans have 1 TB of OneDrive storage per user. The E3 plan has 5 TB of OneDrive storage per user.
• SharePoint Online has 1TB of storage per Office 365 tenant and then 500 MB additional storage per licensed user. Storage consumed by Office 365 Teams come out of this pool.
• All plans include Skype for Business, but only enterprise plans can add unified communications.
• Only enterprise plans have meeting broadcast that allow presentations to thousands of users.
• Only the E3 plan supports Azure Rights Management to encrypt and secure files.

Why Wouldn't I use Office 365?

The main reason you might not be able to use Office 365 is compliance and recovery purposes. For example, you can recover deleted items in Exchange Online for up to 30 days (only 14 days by default). There is no option to recover deleted data older than that.

It's possible for you to work around this issue, but it's not inexpensive. You will need to implement some sort of third-party backup or archiving solution. However, you'll need that type of system if you have Exchange on-premises anyway. It just becomes more complicated to backup data in the cloud. That said, third-party vendors have recognized this need and more backup and compliance products for Office 365 are being made available.

Recommendations

Most smaller organizations do not need the extra features included in the enterprise plans. The differences Business Essentials and E1 are mostly whether you can add on other features. The core level of functionality is mostly the same. If you have less than 300 users the Business Essentials and Business Premium plans are what you should evaluate first due to the cost savings.

For a very small organization, of 5 or 10 users, it's a pretty easy decision to use Office 365 based only on avoiding the cost of the local Exchange Server and hardware. But, you also avoid other costs like backup software, anti-spam software, and anti-virus software for a local Exchange server.

For slightly larger organizations, you might do a cost comparison and see that the cost of on-premises Exchange is about the same as Office 365 licensing. However, Office 365 is giving you high availability across multiple data centers that you probably can't implement your self. Then throw in the ability to have large mailboxes (up to 50 GB), that most on-premises instances of Exchange don't allow, and Office 365 is a winner on features.

For even larger organizations, you might find that Office 365 licensing is more expensive than purchasing and managing on-premises Exchange. However, Office 365 is more than just email. There are additional features like Skype for Business, OneDrive, and SharePoint Online. So, while you may start evaluating Office 365 as a replacement for on-premises email, remember about the extra value the additional services provide and identify whether those services are useful for your organization. Maybe having video conferencing with Skype for Business is a big value add in your organization.

If you have more than 300 users, you can mix business and enterprise plans in the same Office 365 tenant. However, you probably want to be consistent and stick with the enterprise plans to avoid user and helpdesk confusion. Imagine that you implement a Group Policy object for managing Office 365 Proplus but half of your users are using Office 365 Business so that the GPO doesn't apply. It would be a mess.

If your organization is academic or non-profit, check out the Office 365 licensing available specifically to your type of organization. There are academic and non-profit licenses equivalent to business and enterprise plans. At time of writing the plans with only cloud services were free. The plans that include Microsoft Office apps are heavily discounted compared to business and enterprise plans. It almost becomes foolish to keep running your own internal Exchange server.

Useful Links

The following are some of the links I found useful:

• Office 365 Plan Options
• Office 365 Platform Service Description
• Exchange Online Limits
• Outlook versions and features for Exchange
• SharePoint Online software boundaries and limits

Site Mailboxes Deprecated in SharePoint Online

Just saw a notification in my Office 365 portal that site mailboxes are being removed from SharePoint online. Existing site mailboxes will continue to function for now, but after March 2017 you cannot create new site mailboxes.

It is recommended that you use Office 365 groups for collaboration instead. An Office 365 group behaves like a combination of a distribution group and shared mailbox combined with storage in SharePoint. It's a more complete collaboration solution, but you can use just the features that you want.

In September 2017, a process will begin to transition site mailboxes to Office 365 groups.

Here is a link with more info about Office 365 groups:

• https://go.microsoft.com/fwlink/?linkid=831908

O365: Unable to Create Distribution Group

Microsoft is aggressively encouraging Office 365 customers to use Office 365 groups instead of traditional distribution groups. In the Exchange admin center, when you select to create a distribution group, you get a popup to create an Office 365 group instead, as shown below.

There is one difference between this popup and if you actually selected an Office 365 group. This window has an option to create a distribution list. You can see it in the screenshot above by the red arrow. I'm pointing out that option because I didn't see it at first and was only made aware of it by Microsoft.

I should also note that another work around is to create a distribution list in the Office 365 admin center. That option is still available and is the same as creating a distribution group in Exchange admin center.

Office 365 Tech Support is Good!

As a technology professional, I dread calling tech support sometimes. Most of the time when you contact tech support (for any software), you get a front line person that is not terribly knowledgeable or useful. That first level person has access to a knowledgebase that is similar to what you could find by searching online. When that person can't help, they pass you up to a higher level of support that can likely fix your issue.

The other problem with most tech support is timeliness. You are often kept on hold for an extended period of time or are forced to contact support via email or web form and hope that they get back to you within a few hours. It's almost never quick.

My experience with Office 365 support today was amazing. I had a question on Sunday morning at about 11am and had an answer within 10 minutes. Here is what it looked like....

1. I'm working on some labs and find that in the Exchange admin center, when I attempt to create a distribution group it actually prompts me to create an Office 365 group instead. I confirm this is the case in my own personal Office 365 tenant and a test tenant I'm working with for lab development.
2. In the Office 365 admin center, in Support, I selected Let us call you. This option is not available until you at least attempt to search for a resolution to your problem.
3. The Let us call you option showed an estimated wait time of 10 minutes. So, I entered my phone number and waited.
4. Within about 5 minutes, I got a call from a very helpful person at Office 365 Support (thank you Bel).
5. She listened to my concern and did a remote view on my system to confirm the issue and identified it as a bug. She offered a work around of creating the distribution list in the Office 365 admin center (which does work) instead of the Exchange admin center.
6. She also followed up with an email that stated she confirmed the issue in her own test environment and has reported it as a bug in the Exchange admin center user interface. Nice to know that there is a process in place to take care this rather than just giving me the work around.

Here is what was awesome:

• Support was fast and I knew about how long it would take to be contacted. Sometimes the ambiguity of dealing tech support is the worst part. And, this was Sunday morning, not business hours.
• The support person wasn't working from a script. She listened to my issue and then wanted to confirm it by remote viewing. There wasn't a long process of "well, let's try this...." I was not treated like a dummy as most tech support does.
• This level of support is available to anyone. I don't have any special support contract. In fact the tenant for my email that I used to send the support request costs only about $12 per month. That's awesome support for a low cost product.

Update: Since this post, I've learned from Microsoft that the UI change for creating distribution groups in Exchange admin center is not a bug, but a design change. For details, see my other post here: http://byronwright.blogspot.ca/2017/01/o365-unable-to-create-distribution-group.html

Office 365 vs. On-Premises Exchange Server

A large client is currently running Exchange 2010 and is evaluating moving to Office 365 vs upgrading to Exchange Server 2016. I talked with them about it and thought it would be useful to document it for future reference.

If you are a very small organization, then Office 365 is a slam dunk. It's going to perform better and be more cost effective than your could ever implement on your own. This is even before we consider the cost of the the consultants to get your on-premises Exchange up and running.

For mid-sized and large businesses there are more things to think about....

Cost

Direct cost is the first thing everyone wants to evaluate when considering Office 365. Your exact costs are going to vary depending on how you want to implement Exchange and which Office 365 plans you think are appropriate. So, I'm going to let you figure out the exact costs, but here are the things you need to consider:

On premises:

• Exchange Server licenses
• Exchange Server CALs (basic and enterprise if required)
• Hardware for the Exchange servers
• Storage for the Exchange servers
• Backup software and storage
• Antispam and antivirus solution

 Office 365:

• Monthly or yearly license (subscription-based)

High Availability

On-premises Exchange Server can be made highly available. This is done by configuring multiple Exchange servers in a database availability group (DAG) and by using load balancers. This configuration is well understood but definitely requires some planning and expertise to implement.  In most cases, hardware load balancers are used which are an additional cost.

Other high availability considerations for on-premises Exchange include redundant Internet connections, and alternate data centers. To provide a solution that is truly highly available, it takes a lot of redundant infrastructure.

Office 365 is highly available out of the box. You don't need to do anything, that's just the way it's designed. Your data is automatically located in multiple data centers in your region. If one data center fails, your data is still safe in another data center and you're still able to access it. This is one of the big advantages for Office 365, particularly for mid-sized organizations that might not have the resources to deploy office 365 across multiple data centers.

Authentication

On-premises Exchange Server uses Active Directory (AD) for authentication. When users are on a domain joined computer, authentication is performed automatically by Outlook. Externally, the AD username and password are used.

For Office 365, there are multiple ways that authentication can be configured. First lets talk about user accounts...

Very small organizations might choose to create user accounts in Office 365 manually. For these organizations, the users will sign in by using their email address and a password that is set in Office 365. This password could be different from the AD password on-premises and there is no synchronization of the passwords between AD and Office 365.

Larger organizations will use Azure AD Connect to synchronize user accounts with Office 365. This avoids the need to manually create the accounts. Azure AD Connect also has an option to synchronize passwords with Office 365. This simplifies password management for users. It also simplifies password resets when users call the help desk.

When passwords are synchronized with Office 365, all authentication is still handled by Office 365. There is no reliance on any on-premises infrastructure for the authentication process. So an on-premises service outage does not cause an Office 365 service outage.

Very large organizations may consider using Active Directory Federation Services (AD FS) for Office 365 authentication instead of password synchronization. When AD FS is implemented, Office 365 directs authentication requests to AD FS which then authenticates the request against AD. This is significantly more complex to configure than password synchronization but provides the following benefits:

• True single sign-on where workstation credentials are passed through for authentication just like on-premises Exchange.
• When an on-premises AD account is locked or disabled, this also applies to Office 365 authentication. Without this, disabling an Office 365 account is a separate process.

A key point to remember is that if your AD FS infrastructure is down, so is Office 365 authentication.

Account Lockout

For on-premises Exchange, the account lockout policies in AD are applied to authentication for Exchange mailboxes. The only exception is if a device such as a proxy is performing pre-authentication. If pre-authentication is performed then the device providing pre-authentication might have more restrictive policies than what is configured in AD.

When password synchronization is used with Office 365, there is a account lockout mechanism included in Office 365. After 10 failed attempts, an account is locked for 1 minute and if account lockout is triggered multiple times the lockout time is increased each time. This account lockout mechanism is not configurable.

When AD FS is used with Office 365, the account lockout policies in AD are used.

Mailbox and Archive Size

In on-premises Exchange, the maximum size of mailboxes and archive mailboxes is limited by the storage design. Or, more often by the cost of the storage being used. Using direct attached storage (DAS) with 7.2K SAS drives (rather than a SAN) is the most cost effective solution to provide large mailboxes and archives.

In Office 365, the maximum size of mailboxes and archive mailboxes is limited by the license assigned to the mailbox:

• Kiosk: 2 GB mailbox, no archive
• E1: 50 GB mailbox, 50 GB archive
• E3: 50 GB mailbox, unlimited archive
• E5: 50 GB mailbox, unlimited archive

Online Reading and Editing Attachments

In Exchange 2010, there was basic functionality for rendering attachments as web content in OWA. In Exchange 2016, this functionality is not included. Instead, you need to implement Office Online Server. Office Online Server is included with most volume licensing agreements for Exchange Server 2016.

Implementing Office Online Server is not terribly complex for a single server, but requires at least an additional virtual machine. If you want the functionality to be highly available you need to implement multiple servers and load balancing.

Office 365 includes the ability to read and edit attachments by default. No additional configuration is required.

Spam and Antivirus Filtering

For on-premises Exchange, you need to purchase additional products for spam and anti-virus filtering.

Office 365 licenses include Exchange Online Protection for anti-spam and virus protection at no additional cost.

Network Configuration

Most implementations of on-premises Exchange Server require you to implement proxies, load balancers, and firewalls. External access from the Internet to the Exchange servers also need to be configured.

For Office 365, you just need to ensure that clients on the internal network can communicate with Office 365 over the Internet.

Client Communication

Most on-premises deployments of Exchange server use Outlook in cached mode. However, because the internal network is reliable and fast, you can implement Outlook in online mode instead. This can be useful if you are concerned about the size of cached data on computers that are shared by multiple users.

Outlook clients must communicate with Office 365 servers over the Internet. This may result in higher Internet bandwidth usage. Generally, Outlook cached mode is used to minimize network utilization and provide better performance over networks with high latency.

Recent versions of Outlook cache only recent data in a mailbox rather than the entire mailbox. This mitigates concerns about large mailboxes being cached in local profiles. The amount of data cached is configurable.

Migration

Exchange Server 2016 can co-exist with Exchange Server 2010 or Exchange Server 2013. Migration is just a matter of moving mailboxes to Exchange Server 2016. There is almost no impact on users and the Outlook client is automatically redirected to the new mailbox location.

Office 365 can be integrated with Exchange Server 2010 or later by using hybrid mode. Once in hybrid mode, mailboxes can be migrated to Office 365 with minimal impact on users. Outlook is automatically reconfigured when mailboxes are moved.

Backup

Most common backup software can be used for backup with an appropriate agent on the Exchange servers. The restore functionality in the software varies but most can restore individual mailboxes or databases. This software is an extra cost.

There are third party options available for backing up Office 365 mailboxes, but there is no built-in functionality in Office 365 for this purpose.  However the same Single Item Recovery available in on-premises Exchange can be used in Office 365 to recover items for up to 30 days (default 14 days) after they are removed from deleted items.

Microsoft maintains multiple copies of mailbox data to avoid the need to restore from backup due to server error.

If you use E3 licenses, you can implement a hold on mailboxes to permanently retain messages received or sent from mailboxes. This held data is searchable for discovery purposes. Data holds can also be implemented for specific retention periods. Microsoft is positioning this type of hold to replace journaling and archiving solutions.

Management

For an on-premises Exchange deployment you need to perform the following management tasks:

• Monitor performance
• Monitor hardware for failures
• Update firmware
• Apply operating system updates
• Apply Exchange Server updates
• Manage mailboxes

On a system that is properly designed, there is minimal need to monitor performance (you built it with some head room), but there is an ongoing need to address issues such as failed indexes and large delivery queues. These issues are not relevant for Office 365 management.

As a cloud-based service, you are not responsible for any monitoring or updates in Office 365. Management of user mailboxes is still required.

New management tasks for Office 365 include:

• Managing directory synchronization
• Managing user licenses

Directory synchronization typically requires little management. There may be occasional troubleshooting, but it is rare. Generally once directory synchronization is configured, it just works.

Processes for creating new mailboxes do need to be modified to include assignment of Office 365 licenses. This can be scripted and run as a scheduled task if it is not required to be time sensitive.

If all users are migrated to Office 365 a local Exchange server is still maintained for management purposes. This is required because changes are made in the local AD and synchronized to Office 365. However, outages for this management server do not affect Office 365 users only management functionality. Microsoft provides a free license for this purpose.

Additional Features

Many Office 365 deployments begin as a replacement for on-premises Exchange. However, for mid-sized and large organizations, when you do a raw comparison of Exchange on-premises costs and Office 365 licensing costs, you may find that Exchange on-premises is actually a lower cost.

You need to consider that Office 365 includes more than just Exchange functionality. Depending on the licenses you select, there are various features. Also note, that you can mix and match licenses as required to give different features to different users to meet the needs of your organization.

For an accurate list of Office 365 plan features, see the Microsoft web site. However, here's a quick summary you can use to get a general idea of what's included with each license type:

• Kiosk:
• Exchange Online
• SharePoint Online
• E1: Kiosk features plus
• One Drive for Business (1TB)
• Skype for Business
• Yammer
• E3: E1 features plus
• Office 365 Proplus (desktop office suite)
• Azure Rights Management
• E5: E3 features plus
• Cloud PBX

These extra features provide more value than just Exchange online. I've been surprised at the number of larger organizations that have subscribed to Office 365 with E3 licenses as their preferred method of deploying Microsoft Office. Skype for Business is also a bit of a pain to implement on-premises and having that included with the E1 licenses is beneficial.