Category Archives: Office 365

Fix for SSO with Office 365 ProPlus (2016) and ADFS

If you are using an Office 365 ProPlus version prior to 1808, along with Windows 10 1703 or later, you may have an issue where Office applications do not use SSO to sign in, and after users enter their email address, they then have to enter their username and password again in the ADFS login form. This is due to issues with Web Account Manager (WAM), which is used for authentication instead Azure Active Directory Authentication Library (ADAL) with Office 365 ProPlus on recent versions of Windows. Other issues we have seen include:

  • Being unable to obtain a license for Office at all, and Office going into reduced functionality mode, especially if you are using Shared Computer Activation
  • Activation issues after changing password or UPN
  • Repeated requests to enter passwords
  • Showing users a screen asking if they want to add the account to Windows

Fortunately, there is a fix for this, which is listed in a Microsoft article, which lists several symptoms but doesn’t specifically mention SSO issues.

Firstly, if you are running a Windows 10 build later than 1703, you will be using ADAL. So firstly, make sure you have this enabled in your ADFS infrastructure.

Enable ADAL Enable WS-Trust 1.3 for Desktop Client SSO ADAL

In your ADFS console, check the following endpoint shows enabled (/adfs/services/trust/13/windowstransport):


If not, run the following PowerShell command on your ADFS server to enable the endpoint for WS-Trust 1.3:

Enable-AdfsEndpoint -TargetAddressPath "/adfs/services/trust/13/windowstransport"

Apply the ADAL registry fix

Now you may find that SSO still does not work, and that users get a second username and password prompt, instead of SSO taking care of it. This is listed at

Create a Group Policy Object to add the following registry value at user login, or test using a reg file:

Windows Registry Editor Version 5.00

In my testing, this reverted the Office sign in process to the proper behaviour, SSO is seamless and transparent, the user never has to enter their credentials.

Single Sign on (SSO) with Chrome & Firefox and ADFS 4.0

This is how to enable SSO with browsers other than IE and Edge using ADFS 4.0. This is done by adding the browser user agents to the ADFS config.

First, confirm the current config:

Get-AdfsProperties | select -ExpandProperty wiasupporteduseragents

MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Windows Rights Management Client

Now we add Chrome, Firefox, and any other Mozilla compatible browser:

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0")

Check the result:

MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Windows Rights Management Client

Now, restart ADFS:

net stop adfssrv
net start adfssrv

Note that you could also add individual browsers instead of Mozilla/5.0 in case you wanted some browsers supported and not others. For example you might use Firefox for Global Admin users connecting to Office 365, so they can be signed into the Windows with one account, and use an Admin account to login to Office 365 using Firefox. So you could use something like this:

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Chrome" + "Firefox")

Test using Chrome or Firefox, and you should find that SSO is working properly.

Note that Firefox also requires some client side configuration. Type in about:config and add the address of your ADFS server (e.g. to network.automatic-ntlm-auth.trusted-uris.



If you have any issues or want to remove this, you can reset the list to the default as follows:

Set-ADFSProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "MS_WorkFoldersClient","=~Windows\s*NT.*Edge")

Best practices for Office 365 Admin accounts

Administering Office 365 requires special consideration in order to ensure that your service is both manageable and secure. Optimal configuration requires a balance between security, usability, and availability, so all of these need to be considered when planning a strategy. However, the following is a general set of guidelines that can be applied to most deployments, whether they are federated or cloud only.

  • Create separate ‘Admin’ accounts for IT staff which are cloud accounts (using, don’t assign internal user accounts admin roles. When your domain is federated, these accounts will still work if there is any issue with ADFS.
  • Enable MFA for all Office 365 Admin accounts.
  • Set the password policy for cloud accounts so that it at least matches your on-premises password policy. Even if your domain is federated via ADFS, the password policy will apply to cloud only admin accounts. Note that you can only enforce password age and length, not complexity. If your on-premises policy is not particularly secure, set the policy to at least 10 characters long, and advise your admin users to use a mixture of capital and lower case letters, numbers and special characters. This won’t affect internal users, since the password policy is enforced by Active Directory.
  • Don’t assign admin accounts a license. It is not generally required, and this will prevent a mailbox being created and the accounts appearing in the GAL, which could cause confusion. However, there are some instances where a license may be required for Exchange or Intune admin functions which can make this problematic, in which case assign a license only when required.
  • Limited the number of Admin accounts, we generally recommend less than 5 in order to minimise attack surface.
  • Use  the principle of ‘least privilege’, use roles other than global admin e.g. Exchange Online Administrator, or helpdesk administrator where possible.
  • Review the Secure Score site periodically – and try and get your score as high as possible.
  • Have a separate admin account for scripting purposes, with no MFA but usually disabled. To do this set Sign In Status to Blocked, and only enable it when you need to run a script. Alternatively it is possible to use an MFA enabled account if you install the old PowerShell modules e.g. There are limitations with this however, and you will have to enter 2FA credentials every time you run the script, credentials cannot be stored in a variable.

Note that these recommendations are line with NCSC/CESG guidelines:

Microsoft Office 365 Security Guidance: Administrator good practice

Also see Security best practices for Office 365

Using this strategy has the following benefits:

  • Avoids Admin users having to use 2FA to sign in to Office on their desktops, which can be especially annoying if you are using Shared Computer Activation. Although this could be avoided using a conditional access policy.
  • It is more secure, the user is not signed in with a global admin account all the time.
  • The admin accounts can be used to resolve any issues with ADFS, which can prevent internal users from signing in.
  • Sometimes there may be no internal users who require admin access, if the tenant is managed by a third party. So using this strategy will work in any situation.

There are however drawbacks to this approach

  1. In order to administer Office 365, IT staff will need to use InPrivate or incognito browser mode, and connect to Office 365 with their 2FA. This is an inconvenience.
  2. The external accounts are available from the internet, which is not always the case with ADFS. This is mitigated through strong passwords and MFA.
  3. You need to make sure that Admin accounts are disabled when users leave, this is often overlooked. This requires robust leavers process for IT staff.

Office 365 Hybrid Configuration Wizard does not run

You may find that when you run the Exchange Hybrid Configuration Wizard that it does not run. If you launch it from Exchange Admin Center, or from the Exchange Online Admin Center, it may just flash up and do nothing.

The solution is to change the file association for .application files to Internet Explorer. However, if you try in the Control Panel, you will find that this is impossible:


The solution is to do this using good old Windows Explorer.

  • Check you are viewing file extensions in Windows Explorer (View > File name extensions)
  • Right click in your Documents folder or somewhere, create a new file called test.application
  • Right click on it and choose Properties, and change the application to Internet Explorer


Now you should be able to run the application


Securing B2B guest access in Office 365 / Azure AD

    If you integrate your Enterprise applications with Azure AD, you may want allow your users to invite external users in a secure manner, without enabling guest access to any other resources, or having to involve admins every time a guest needs to be added.

    Microsoft document how to allow your users to manage guest access here:

    So there are 2 ways to do this, either you let Admins add your B2B users, or you can let your own users do this. This article focuses on the latter, enabling your users to add guests, whilst doing so in a secure manner. The Microsoft article above does not discuss how to securely enable guest access in the first place, so this is the focus of this post.

    Note that if you just want to control access to Teams, SharePoint, OneDrive and Office 365 groups, all of these are controlled separately and you don’t need to do follow this first section. See the end of this post for more detail.

    Securing guest access to applications

    As already mentioned, Admins can add guests to the directory, so if you want complete control of guest access then do not turn on the settings below. Once an admin has added a guest, users can then invite the guests to various resources as required.

    Steps to allow Guests to invite users to specific applications are documented here, I am going to assume you have done this:

    However, these steps are not enough on their own, once you have allowed users to manage access to an individual application, you need to follow the steps below to complete the process. Note that these settings are tenant wide, so will also apply to other applications, and the domain restrictions will also apply to Teams or SharePoint, so bear that in mind before you start restricting guests to specific domains.

    Guest invitation settings

    If you want to allow collaboration without requiring the intervention of Admins, and want to enable guest access outside of Teams or SharePoint e.g. to B2B applications that you have integrated with Azure AD, you need to enable users to invite guests at the Tenant level:

    Enable users to add guests on the tenant

    • Go to the Office 365 Portal at
    • Settings -> Security & privacy -> Sharing
    • Click Edit and then allow users to add new guests


    Enable users to add guests in Azure AD

    Note that the same setting can be accessed in Azure AD, so alternatively can be set here:

    • Go to the Azure Portal at, then open the Azure Active Directory blade
    • Click Users under Manage
    • Click User Settings, and then Manage external collaboration settings:
    • Set Members can invite to Yes (you should generally set Guests can invite as No)


    Now this is rather open by default, so we can then restrict the types of guests as follows:

    Setting Collaboration restrictions

    Now, choose how restrictive you want to be by setting the collaboration restrictions to one of the options:

    • Allow invitations to be sent to any domain
    • Deny invitations to the specified domain
    • Allow invitations only to the specified domain

    If you need users to be able to invite guests, you can use a whitelist to ensure that they can only invite users at from domains of your choosing. So you could add in the domains of your partners here, to ensure that users can collaborate with your partners, but not other external users.

    If possible, use the last option and enter the domains of your partners. Note that this will also affect other areas e.g. SharePoint and Teams, so you should add the domains of all of your partners here. Note that this setting will prevent even an Admin from adding a guest from an unauthorised domain directly to Azure AD, but if this is required you could briefly add a domain to the list.

    Users can then add guests using the Access Panel at, but only the domains which are allowed.

    Putting it all together


    Now users can invite guests to the app that they have been assigned as an owner:


    If another domain is tried, they will get an error:


    This will also apply to Teams:


    Restrict access to the Azure AD portal

    • Go to
    • Click Users under Manage
    • Click User Settings
    • Under Administration porta, click Yes – Restrict access to Azure AD administration portal


    If you do this then users will be unable to use Azure AD from the portal:


    Other guest settings


    If you only need to enable Guest access for Teams collaboration, you just need to go to, then Settings > Services & add-ins > Microsoft Teams > Settings by user/license type



    SharePoint and OneDrive guest access is also controlled separately in the SharePoint Admin center:


    Office 365 Groups

    You may want to turn off the following switches under Admin Center > Home > Services & add-ins > Office 365 Groups:

    • Let group members outside the organization access group content
    • Let group owners add people outside the organization to groups


How to obtain an Exchange Hybrid Edition product key for your on-premises Exchange 2007 or Exchange 2003 organization

This was previously at

The new Hybrid Wizard is here:

Note The Hybrid Configuration wizard that’s included in the Exchange Management Console in Microsoft Exchange Server 2010 is no longer supported. Therefore, you should no longer use the old Hybrid Configuration wizard. Instead, use the Office 365 HybridConfiguration wizard that’s available at For more information, see Office 365 Hybrid Configuration wizard for Exchange 2010.



If your on-premises Exchange organization is running Exchange 2007 or Exchange 2003, and if you want to connect your organization to Office 365 and your Exchange Online organization, you must install at least one on-premises Exchange 2013 or Exchange 2010 Service Pack 3 (SP3) server. This server is used for hybrid deployment connectivity that seamlessly connects your on-premises Exchange and ExchangeOnline organizations.

To avoid the additional cost of an Exchange 2013 or Exchange 2010 SP3 server license, you may qualify for a free Hybrid Edition product keyfor Exchange 2013 or Exchange 2010 SP3.


Obtain a Hybrid Edition product key

You can request a Hybrid Edition product key if all the following conditions apply to you:

  • You have an existing, non-trial, Office 365 subscription.
  • You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 server in your on-premises organization.
  • You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the HybridEdition product key.

To obtain a Hybrid Edition product key for your Exchange 2013 server or Exchange 2010 SP3 server, go to the Exchange hybrid productkey distribution wizard.

Note If the licensing tool does not work as expected, you can continue to receive Exchange licensing support at


Need help to set up your hybrid deployment? Access a customized, step-by-step hybrid deployment configuration checklist at the ExchangeServer Deployment Assistant.

Need more information about Exchange 2013-based hybrid deployments? See Exchange Server 2013 hybrid deployments.

Need more information about Exchange 2010-based hybrid deployments? See Exchange Server 2010 hybrid deployments.

For more information about features across Office 365 options for Exchange Online, see Exchange Online Service Description.

Securing Guest Access in Azure AD

Office 365 can enable new ways of collaborating with suppliers and business partners. However, it is important to understand the security implications of this, and you will probably want to lock this down initially.

By default, any user can invite external third parties into your Office 365 tenant, where they may have access your sensitive data. So in order to secure your data and applications, you should change the default settings.

External Collaboration Settings

By default, normal users can invite guest to Azure AD. So Members can invite should be turned off, and you should also turn off Guests can invite.

Note that users can still invite guests if an Admin has added them to Azure AD already. So if an Admin has added guests to Azure AD directly, they could then be added to any app by any user, so this should be avoided. To change the collaboration settings:

  • Navigate to
  • Open Azure Active Directory
  • Click User Settings
  • Click Manage external collaboration settings, under External users at the bottom

Both bottom options below should be set to No:

Now you may still need guests to have access to individual apps. This can still be done either by Admins, or delegated to business users.

Inviting guests to your directory

  • You can invite guest users to the directory, to a group, or to an application.
  • The invited user’s account is added to Azure Active Directory (Azure AD), with a user type of Guest
  • The guest then has to redeem their invitation to gain access
  • You can either send the guest user a direct link to a shared app, or the guest user can click the redemption URL in the invitation email.

Inviting Guests to apps:

  • Either an admin can add guests to Azure AD, and then application owners can invite users to individual apps
  • Or, applications can be setup as self-service, so that application owners can add guests directly. This is the option we should use.


1. Add guest users to the Azure Active Directory (admin)

After a guest user has been added to the directory in Azure AD, an application owner can send the guest user a direct link to the app they want to share.

This is not normally a good idea, since the guests could then be added to other apps, even if collaboration settings have been disabled

2. Add guest users to an individual application (admin)

This could be done if you do not want business users themselves to be able to invite guests for any reason, i.e. you want absolute control.

  • Sign in to the Azure portal as an Azure AD administrator.
  • In the navigation pane, select Azure Active Directory.
  • Under Manage, select Enterprise applications > All applications.
  • Select the application to which you want to add guest users.
  • On the application’s dashboard, select Total Users to open the Users and groups pane.
  • Select Add user.
  • Under Add Assignment, select User and groups.

3. Business users adding guests to an application

First, the application has to be configured for self-service:

Then a group can be assigned as an owner as follows (see for details):

  • Enable self-service group management for your tenant
  • Create a group to assign to the app and make the user an owner (note that the group has to be in AAD not on premise, since they need to able to manage group membership)
  • Configure the app for self-service and assign the group to the app


The users can then invite users to the app:


B2B Guest Inviter role

There is also a Guest Invitier role, however you generally don’t want to use this, since this will effectively allow them to invite anyone to anything the same as an Admin (as it says above, Admin and users in the guest inviter role can invite).

Managing Distribution Lists on-premises in hybrid Office 365

A simple way for your users to manage distribution list membership with hybrid Office 365 environments with Active Directory on-premises, Azure AD Connect synced to Azure AD and Exchange Online.

With Exchange on-premises, users may be used to managing Distribution Lists (DLs), using Outlook to open the DL and edit the group membership that they are the owners of. However, once you move to Exchange Online, these can no longer be managed using Outlook, since the DL is synced from your on-premises AD, and cannot be edited in Azure AD. So, the DL has to be managed in your on-premises AD. Your help desk can do this with Exchange Admin tools, however, it is not very convenient for users to have to call the help desk every time that they want to edit DL membership.

The issue is documented here:, however, Microsoft do not offer any solutions. This is a workaround we use to enable your users to manage DL membership with no special tools, in a manner which is easy to use.

Edit your DLs to make them manageable

First, you need to make sure that your DLs are editable by the owners. Check the box below, or do this using PowerShell e.g.

Create a shortcut to Search Active Directory

This works on any Windows machine, and you do not need any AD tools installed.

  • Right click on your desktop or in a folder
  • Choose Create new shortcut
  • Enter rundll32.exe dsquery,OpenQueryWindow as the location

Now just run your shortcut, and if you are the owner you can edit the DL membership. You could also deploy the shortcut via SCCM or GPO to make this easy for users. You can also find this via the

Note that you can also do this as follows, but this is less than ideal and will usually result in an error when selecting the Network in Windows Explorer:

· Open Windows Explorer.
· Click Network in the bottom left, and press OK to the error message that pops up
· Click Search Active Directory at the top

Recipient Type Values in Active Directory

Recipient Type Values

Technical Level : Intermediate


Both mailbox creation and deletion failure scenarios heavily involve verifying the current recipient type values across all directories – especially in a directory synchronised environment. For example; if a user is listed on-prem as a remote mailbox with a cloud archive, then you should expect EXO to have a primary and an archive mailbox for this user. If it doesn’t, then troubleshoot for a synchronisation failure somewhere between on-prem and EXO.

The three attributes you will be dealing with are the following, and there are many possible values for each:

  1. msExchRemoteRecipientType
  2. msExchRecipientDisplayType
  3. msExchRecipientTypeDetails


  • msExchRemoteRecipientType
RemoteRecipientType (in PowerShell)

Note: You should only see the above value populated if the customer has a directory sync’d environment, and they either migrated a mailbox to the cloud or if they used new-remotemailbox to provision a cloud mailbox.

1 ProvisionMailbox
2 ProvisionArchive (On-Prem Mailbox)
3 ProvisionMailbox, ProvisionArchive
4 Migrated (UserMailbox)
6 ProvisionArchive, Migrated
8 DeprovisionMailbox
10 ProvisionArchive, DeprovisionMailbox
16 DeprovisionArchive (On-Prem Mailbox)
17 ProvisionMailbox, DeprovisionArchive
20 Migrated, DeprovisionArchive
24 DeprovisionMailbox, DeprovisionArchive
33 ProvisionMailbox, RoomMailbox
35 ProvisionMailbox, ProvisionArchive, RoomMailbox
36 Migrated, RoomMailbox
38 ProvisionArchive, Migrated, RoomMailbox
49 ProvisionMailbox, DeprovisionArchive, RoomMailbox
52 Migrated, DeprovisionArchive, RoomMailbox
65 ProvisionMailbox, EquipmentMailbox
67 ProvisionMailbox, ProvisionArchive, EquipmentMailbox
68 Migrated, EquipmentMailbox
70 ProvisionArchive, Migrated, EquipmentMailbox
81 ProvisionMailbox, DeprovisionArchive, EquipmentMailbox
84 Migrated, DeprovisionArchive, EquipmentMailbox
100 Migrated, SharedMailbox
102 ProvisionArchive, Migrated, SharedMailbox
116 Migrated, DeprovisionArchive, SharedMailbox
  • msExchRecipientDisplayType
RecipientType (In PowerShell)
-2147483642 MailUser (RemoteUserMailbox)
-2147481850 MailUser (RemoteRoomMailbox)
-2147481594 MailUser (RemoteEquipmentMailbox)
0 UserMailbox (shared)
1 MailUniversalDistributionGroup
6 MailContact
7 UserMailbox (room)
8 UserMailbox (equipment)
1073741824 UserMailbox
1073741833 MailUniversalSecurityGroup
  • msExchRecipientTypeDetails
RecipientTypeDetails (In PowerShell)
1 UserMailbox
2 LinkedMailbox
4 SharedMailbox
16 RoomMailbox
32 EquipmentMailbox
128 MailUser
2147483648 RemoteUserMailbox
8589934592 RemoteRoomMailbox
17179869184 RemoteEquipmentMailbox
34359738368 RemoteSharedMailbox

The following tables list what the attribute values should be across on-premises and Exchange Online for the various possible recipient types. These are taken from normal examples;

Mail Objects

Mail-Enabled User

objectClass: top;person;organizationalPerson; user
msExchRecipientDisplayType: 6 RecipientType: MailUser RecipientTypeDetails: MailUser
msExchRecipientTypeDetails: 128 RecipientType: MailUser RecipientTypeDetails: MailUser
Mail-Enabled Contact

objectClass: top;person’organizationlaPerson;contact
msExchRecipientDisplayType: 6 RecipientType: MailContact RecipientTypeDetails: MailContact
RecipientType: MailContact RecipientTypeDetails: MailContact
Mail-Enabled Distribution Group

objectClass: top;group
sAMAccountType: 268435457
groupType: 8 GroupType: Universal GroupType: Universal
msExchRecipientDisplayType: 1 RecipientType: MailUniversalDistributionGroup RecipientType: MailUniversalDistributionGroup
RecipientTypeDetails: MailUniversalDistributionGroup RecipientTypeDetails: MailUniversalDistributionGroup
Mail-Enabled Security Group

New-DistributionGroup -Type Security 
objectClass: top;group
sAMAccountType: 268435456
groupType: -2147483640 GroupType: Universal, SecurityEnabled GroupType: Universal, SecurityEnabled
msExchRecipientDisplayType: 1073741833 RecipientType: MailUniversalSecurityGroup RecipientType: MailUniversalSecurityGroup
RecipientTypeDetails: MailUniversalSecurityGroup RecipientTypeDetails: MailUniversalSecurityGroup

Mail Users

Mail-Enabled User

objectClass: top;person;organizationalPerson;user
msExchRecipientDisplayType: 6 RecipientType: MailUser RecipientTypeDetails: MailUser
msExchRecipientTypeDetails: 128 RecipientType: MailUser RecipientTypeDetails: MailUser
If Licensed

RecipientType: MailBox
RecipientTypeDetails: MailBox

On-Premises Mailbox Objects

Mailbox (User)

objectClass: top;person;organizationalPerson;user
RemoteRecipientType: None
msExchRecipientDisplayType: 1073741824 RecipientType: UserMailbox RecipientType: MailUser
msExchRecipientTypeDetails: 1 RecipientTypeDetails: UserMailbox RecipientTypeDetails: MailUser
Mailbox (Shared)

New-Mailbox -Shared 
Enable-Mailbox -Shared
Get-Mailbox | Where {$_.RecipientTypeDetails -eq "SharedMailbox"}
objectClass: top;person;organizationalPerson;user
RemoteRecipientType: None
msExchRecipientDisplayType: 0 RecipientType: UserMailbox RecipientType: MailUser
msExchRecipientTypeDetails: 4 RecipientTypeDetails: SharedMailbox RecipientTypeDetails: MailUser
Mailbox (Room)

New-Mailbox -Room 
Enable-Mailbox -Room
Get-Mailbox | Where {$_.RecipientTypeDetails -eq "RoomMailbox"}
Get-Recipient| Where {$_.ResourceType -eq "Room" -and $_.RecipientType -eq "Mailuser"}
objectClass: top;person;organizationalPerson;user
msExchResourceMetaData: ResourceType:Room ResourceType: Room ResourceType: Room
RemoteRecipientType: None
msExchRecipientDisplayType: 7 RecipientType: UserMailbox RecipientType: MailUser
msExchRecipientTypeDetails: 16 RecipientTypeDetails: RoomMailbox RecipientTypeDetails: MailUser
Mailbox (Equipment)

New-Mailbox -Equipment 
Enable-Mailbox -Equipment
Get-Mailbox | Where {$_.RecipientTypeDetails -eq "EquipmentMailbox"}
Get-Recipient| Where {$_.ResourceType -eq "Equipment" -and $_.RecipientType -eq "MailUser"}
objectClass: top;person;organizationalPerson;user
msExchResourceMetaData: ResourceType:Equipment ResourceType: Equipment ResourceType: Equipment
RemoteRecipientType: None
msExchRecipientDisplayType: 8 RecipientType: UserMailbox RecipientType: MailUser
msExchRecipientTypeDetails: 32 RecipientTypeDetails: EquipmentMailbox RecipientTypeDetails: MailUser

Remote Mailbox

Remote Mailbox (User) – Provision

objectClass: top;person;organizationalPerson;user
msExchRemoteRecipientType: 1 RemoteRecipientType: ProvisionMailbox
msExchRecipientDisplayType: -2147483642 RecipientType: MailUser RecipientType: UserMailbox
msExchRecipientTypeDetails: 2147483648 RecipientTypeDetails: RemoteUserMailbox RecipientTypeDetails: UserMailbox
Remote Mailbox (Shared) – Provision Not Available
RemoteMailbox (Room) – Provision

New-RemoteMailbox -Room 
Enable-RemoteMailbox -Room
Get-RemoteMailbox | Where {$_.RecipientTypeDetails -eq "RemoteRoomMailbox"}
Get-Mailbox | Where {$_.ResourceType -eq "Room"}
objectClass: top;person;organizationalPerson;user
msExchRemoteRecipientType: 33 RemoteRecipientType: ProvisionMailbox, RoomMailbox
ResourceType: Room
msExchRecipientDisplayType: -2147481850 RecipientType: MailUser RecipientType: UserMailbox
msExchRecipientTypeDetails: 8589934592 RecipientTypeDetails: RemoteRoomMailbox RecipientTypeDetails: RoomMailbox
Remote Mailbox (Equipment) – Provision

New-RemoteMailbox -Equipment 
Enable-RemoteMailbox -Equipment
Get-RemoteMailbox | Where {$_.RecipientTypeDetails -eq "RemoteEquipmentMailbox"}
Get-Mailbox | Where {$_.ResourceType -eq "Equipment"}
objectClass: top;person;organizationalPerson;user
ResourceType: Equipment
msExchRemoteRecipientType: 65 RemoteRecipientType: ProvisionMailbox, EquipmentMailbox
msExchRecipientDisplayType: -2147481594 RecipientType: MailUser RecipientTypeDetails: RemoteEquipmentMailbox
msExchRecipientTypeDetails: 17179869184 RecipientType: UserMailbox RecipientTypeDetails: EquipmentMailbox

Migrated Mailboxes

Remote Mailbox (User) – Migrated
Get-Mailbox | Where {$_.RecipientTypeDetails -eq "UserMailbox" -and $_.RemoteRecipientType -eq "Migrated"}
objectClass: top;person;organizationalPerson;user
msExchRemoteRecipientType: 4 RemoteRecipientType: Migrated RemoteRecipientType: Migrated
msExchRecipientDisplayType: -2147483642 RecipientType: MailUser RecipientType: UserMailbox
msExchRecipientTypeDetails: 2147483648 RecipientTypeDetails: RemoteUserMailbox RecipientTypeDetails: UserMailbox
Remote Mailbox (Shared)- Migrated
Get-RemoteMailbox | Where {$_.RecipientTypeDetails -eq "RemoteSharedMailbox"}
Get-Mailbox | Where {$_.RecipientTypeDetails -eq "SharedMailbox" -and $_.RemoteRecipientType -match "Migrated"}
objectClass: top;person;organizationalPerson;user
msExchRemoteRecipientType: 100 RemoteRecipientType: Migrated, SharedMailbox RemoteRecipientType: Migrated, SharedMailbox
msExchRecipientDisplayType: -2147483642 RecipientType: MailUser RecipientType: UserMailbox
msExchRecipientTypeDetails: 34359738368 RecipientTypeDetails: RemoteSharedMailbox RecipientTypeDetails : SharedMailbox
Remote Mailbox (Room) – Migrated
Get-RemoteMailbox | Where {$_.RecipientTypeDetails -eq "RemoteRoomMailbox"}
Get-Mailbox | Where {$_.RecipientTypeDetails -eq "RoomMailbox" -and $_.RemoteRecipientType -match "Migrated"}
objectClass: top;person;organizationalPerson;user
ResourceType: Room
msExchRemoteRecipientType: 36 RemoteRecipientType: Migrated, RoomMailbox RemoteRecipientType: Migrated, RoomMailbox
msExchRecipientDisplayType: -2147481850 RecipientType: MailUser RecipientType: UserMailbox
msExchRecipientTypeDetails: 8589934592 RecipientTypeDetails: RemoteRoomMailbox RecipientTypeDetails: RoomMailbox
Remote Mailbox (Equipment) – Migrated
Get-RemoteMailbox | Where {$_.RecipientTypeDetails -eq "RemoteEquipmentMailbox"}
Get-Mailbox | Where {$_.RecipientTypeDetails -eq "EquipmentMailbox" -and $_.RemoteRecipientType -match "Migrated"}
objectClass: top;person;organizationalPerson;user
ResourceType: Equipment
msExchRemoteRecipientType: 68 RemoteRecipientType: Migrated, EquipmentMailbox RemoteRecipientType: Migrated, EquipmentMailbox
msExchRecipientDisplayType: -2147481594 RecipientType: MailUser RecipientType: UserMailbox
msExchRecipientTypeDetails: 17179869184 RecipientTypeDetails: RemoteEquipmentMailbox RecipientTypeDetails: EquipmentMailbox

I take no credit for this, I am just saving this for posterity since it is incredibly useful, original source here:

Outlook Autocomplete when migrating to Office 365

During a recent Office365 migration, one of the questions that arose was what would happen to Outlook Autocomplete entries (also known as the Nickname cache) when migrating users from on-premise Exchange, to Office365. Many users rely on this list, and a common complaint when this goes missing is ‘my contacts have disappeared’. In fact users just often don’t use contacts because it requires manual steps to save someone’s details, they just rely on the fact that once they have emailed a user, Outlook remembers the name and they just have to start typing it and Outlook completes the address for them.

The answer, as with many things in IT, is ‘it depends’. Largely it depends on the Outlook client version.

Microsoft Office Outlook 2007 and earlier versions store the AutoComplete list in a nickname (.nk2) file on the disk. This is local to the PC, so if users login to a new PC, the cache won’t be there. Luckily you just need to find the nk2 file, copy it to the new PC, and then import it into Outlook. See for details on how to do this.

Outlook 2010 and later store the autocomplete list in a hidden folder in the user’s mailbox. The great thing about this is that when setting up a new PC if the user opens the same mailbox then the list will be there already as soon as the mailbox is opened. So when migrated to Office365, this hidden folder is migrated along with the user’s email. When they  login to their mailbox through Outlook, it should be available.


Also note that Outlook Web App uses its own auto complete list, this is not the same as the one used by Outlook.


One final thing to note, is that if users autocomplete list is lost or accidentally deleted, one way of repopulating it is to draft an email with all of the users contacts in, and save it (but do NOT send!). This adds all of the addresses to the cache.


See ‘Information about the Outlook AutoComplete list’ for more details.