Recipient Type Values in Active Directory

Recipient Type Values

Technical Level : Intermediate

Summary

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

Details

  • 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
New-MailUser 
Enable-Mailuser
Get-MailUser Get-MailUser
objectClass: top;person;organizationalPerson; user
msExchRecipientDisplayType: 6 RecipientType: MailUser RecipientTypeDetails: MailUser
msExchRecipientTypeDetails: 128 RecipientType: MailUser RecipientTypeDetails: MailUser
Mail-Enabled Contact
New-MailContact 
Enable-MailContact
Get-MailContact Get-MailContact
objectClass: top;person’organizationlaPerson;contact
msExchRecipientDisplayType: 6 RecipientType: MailContact RecipientTypeDetails: MailContact
RecipientType: MailContact RecipientTypeDetails: MailContact
Mail-Enabled Distribution Group
New-DistributionGroup 
Enable-DistributionGroup
Get-DistributionGroup Get-DistributionGroup
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 
Enable-DistributionGroup
Get-DistributionGroup Get-DistributionGroup
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
New-MailUser 
Enable-Mailuser
Get-MailUser Get-MailUser
objectClass: top;person;organizationalPerson;user
msExchRecipientDisplayType: 6 RecipientType: MailUser RecipientTypeDetails: MailUser
msExchRecipientTypeDetails: 128 RecipientType: MailUser RecipientTypeDetails: MailUser
If Licensed
Get-Mailbox
RecipientType: MailBox
RecipientTypeDetails: MailBox

On-Premises Mailbox Objects

Mailbox (User)
New-MailBox 
Enable-MailBox
Get-MailBox Get-MailUser
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"} Get-MailUser
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
New-RemoteMailbox 
Enable-RemoteMailbox
Get-RemoteMailbox Get-Mailbox
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-RemoteMailbox 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: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin-mso_exchon-mso_o365b/recipient-type-values/7c2620e5-9870-48ba-b5c2-7772c739c651

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 https://support.office.com/en-gb/article/Import-or-copy-the-Auto-Complete-List-to-another-computer-83558574-20dc-4c94-a531-25a42ec8e8f0?pid=CH100776981033&CorrelationId=f2cb4593-2782-4f5c-9928-dc0c7d5a76e3&ui=en-US&rs=en-GB&ad=GB&ocmsassetID=HA010097887 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’

https://support.microsoft.com/en-us/help/2199226 for more details.

Office 365 – fix shared mailboxes that are not synchronising from Exchange Online

How to fix issues synchronising and displaying emails in secondary or shared mailboxes in Exchange Online.

When migrating from Exchange on-premise to Office 365, users can experience issues displaying emails in secondary or shared mailboxes. When their mailboxes were hosted on-premise, users didn’t have this problem, since the Exchange servers were nearer to the users and Outlook could operate in online mode without experiencing the cached mode limitations.

The issue arises when users have access to multiple mailboxes, or mailboxes with many folders, which have been auto-mapped through mailbox permissions. This issue is described in the following Microsoft article, and is due to the 500 folder limit in Outlook .ost files: https://support.microsoft.com/en-gb/help/3115602/performance-and-synchronization-problems-when-you-work-with-folders-in

Microsoft recommends 3 potential fixes for this issue:

  1. Delete folders to reduce the folder count. This is often not possible since data needs to be retained, or needs to be separated into folders. Or there may just be so many additional mailboxes that it is not practical to have less than 500 folders across all of them.
  2. Turn off cached mode for shared folders as below. However. since you Exchange servers are now in the cloud, whilst changing this setting will show all of the emails, not only will you be unable to access the emails when offline, but performance will be heavily dependent on network conditions. Frequently this will cause performance problems with Outlook; whilst these shared mailboxes were hosted on an on-premise Exchange server, moving them to the internet can make it too slow to access them in Online mode.  

The solution is, therefore, the third recommendation by Microsoft. We recommend that clients skip the first 2 workarounds, and implement this from the start for any power email users who access a number of shared mailboxes. Unfortunately, this will require manual configuration by the end user, so a combination of automapping and manual configuration may be a good compromise.

  1. Disable automapping for each secondary mailbox as per 2646504 – ‘How to remove automapping for a shared mailbox in Office 365’.
  2. Add the account as a secondary account into Outlook via the Add New Account dialog box in Outlook. Simply add the email address of the account, as long as you have full access then it will allow you to add the profile.

Note that when diagnosing this issue it is very useful to use the Get-MailboxFolderStatistics cmdlet, which you can use to calculate if the user is near or over the 500 folder limit across all of their mailboxes.

Office 365 Online resources

This is a collection of useful resources for Office 365 deployments:

Porting phone numbers to Skype for Business

We had an interesting Skype migration, where we needed to migrate 10,000 numbers from BT to Microsoft Phone System for Skype for Business.

With BT you have to port the entire block in one go, so we had no way of porting numbers in batches as users migrated over to Skype for Business. So, we needed a way for users to continue to be able to receive calls as they migrated onto S4B, but whilst the numbers were still with BT. Since calls were still coming into an old PBX, the initial thought was to program the PBX to forward numbers as and when users were migrated. However, since we were migrating about 100 users a day, this would basically be a full time job to program all the forwarders on the PBX, and would also be very prone to error, since the old PBX had to be programmed via a terminal application with no scripting support.

However, we realised that users were already used to forwarding their own numbers to their mobile phones, so they can forward their own calls in this way using their desk phone (a feature of the old PBX). What we therefore did was allocate 10,000 temporary local numbers in Skype for Business, and then ask each user to forward on their old desk phone to their temporary number as they get migrated. Once this is done, users receive all their calls on their old number using S4B (either client or Polycom desk phone), and can make outbound calls (which doesn’t show their number anyway). This made the whole migration process a lot easier, and placed the onus on the user to set up a simple call forward, less prone to error and easy for them to correct if they make a mistake.

The final job will be one off number port, at which point we will map all the ported numbers to the users using a PowerShell script, and job done!

 

Configuring PowerShell to work behind a proxy server

 

PowerShell won’t update help, or let you connect to online repositories, without configuring it to work with your corporate web proxy servers. Unfortunately it does not use the system settings, so you have to do this manually.

If you try and use an online command such as update-help, you will get an error like this:

PS C:\WINDOWS\system32> update-help
update-help : Failed to update Help for the module(s) 'ActiveDirectory, AppBackgroundTask, AppLocker, AppvClient,
Appx, AssignedAccess, BestPractices, BitLocker, BitsTransfer, BranchCache, CimCmdlets, ClusterAwareUpdating, ….Unable to
connect to Help content. The server on which Help content is stored might not be available. Verify that the server is
available, or wait until the server is back online, and then try the command again.

At line:1 char:1
+ update-help
+ ~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (:) [Update-Help], Exception
+ FullyQualifiedErrorId : UnableToConnect,Microsoft.PowerShell.Commands.UpdateHelpCommand

To fix this, you need to configure your proxy settings in your PowerShell profile as follows (note that this requires local administrator rights):

  • Open an administrator-level PowerShell command prompt
  • Run the following command to register the PSGallery Repository
Register-PSRepository -Default -Verbose

  • Then you will be able to edit your profile:
notepad $PROFILE

Note: it will prompt you to create this if it does not exist. Then add the following lines, modifying as you see fit for your environment:

[system.net.webrequest]::defaultwebproxy = new-object system.net.webproxy('http://proxyname:port')

[system.net.webrequest]::defaultwebproxy.credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true

 

Restart PowerShell. Note that you will need to have scripts enabled in order to load the profile.

Now, you can run update-help again and it should have no issues.

You can also now connect to Office365 using PowerShell, see https://www.msdonkey.com/office365/connecting-to-office-365-using-powershell/

Special characters in UPN and email addresses in Office 365 migrations

This is a workaround in order to migrate mailboxes to Office 365 which have special characters.

You may run into an issue migrating from on premise Exchange to Office 365, where some accounts fail due to illegal characters in email addresses or UPNs. Having spoken to Microsoft about this, the official line is that no special characters are supported, therefore you should remove them if at all possible. However, we found during a large migration that in some cases they can be retained.

Note that the Microsoft article linked below does not mention UPNs, however we found that special characters in UPNs will cause users and shared mailbox migrations to fail.

The result of our testing was as follows:

  • Distribution Lists don’t require any changes and will still work
  • User accounts and shared mailboxes need any illegal characters removing from UPN, mail and primary SMTP address in proxyaddresses attribute, but these can be added back in as SMTP aliases, and should then be retained once the account is migrated.

Note: I would suggest that special characters are simply removed, rather than replaced with anything else. There are different types of characters, so removing them works for anything. It is not required to change the Display Name in the GAL, only the email address and whilst that is what people will see if they reply to an email, and they will still receive emails on the old address. This will be very difficult to manage if we have different rules for different areas of the business, different characters etc.

You can follow the process below to make changes to affected accounts in your on premise Active Directory before they can be migrated. To be clear, the process is as follows (for users and shared mailboxes):

  1. Remove any special characters from UPN, mail, and primary SMTP address
  2. Add back the primary SMTP address as an alias (if still required)
  3. All other aliases and attributes can remain as-is, including display name.

Example:

Display name: R&D Team Mailbox – leave as-is

UPN: Change R&DTeamMailbox to RDTeamMailbox

Change Primary SMTP: From R&DTeamMailbox.com to RDTeamMailbox@domain.com (remove &)

Add back the primary address as an alias: R&DTeamMailbox.com

Note that the full list of special characters is as below, from https://support.microsoft.com/en-us/help/2001616/a-user-s-office-365-email-address-unexpectedly-contains-an-underscore

 

space character
` apostrophe
( opening parenthesis
) closing parenthesis
single quotation mark
& ampersand
\ pipe
= equal sign
? question mark
/ forward slash
% percent

Connecting to Office 365 using PowerShell

A brief set of instructions to connect to Office 365 online services using PowerShell, including Azure AD, Exchange Online, and Skype for Business Online.

Note: If you are behind a proxy server, you will need to follow this in order for this to work: https://www.msdonkey.com/powershell/configuring-powershell-to-work-behind-a-proxy-server/

1. Install the 64-bit version of the Microsoft Online Services Sign-in Assistant: Microsoft Online Services Sign-in Assistant for IT Professionals RTW.
2. Install the Microsoft Azure Active Directory Module for Windows PowerShell with these steps:
○ Open an administrator-level PowerShell command prompt
○ Run the command:

Install-Module MSOnline

Get your credentials and connect:

$creds = Get-Credential
Connect-MsolService -Credential $creds
Get-MsolUser (to test)

Note: If your account is 2FA enabled, just use the command: Connect-MsolService and then enter your credentials and 2FA authentication.

I would also highly recommend changing the window title, especially if you connect to multiple tenants. This reduces the chances of making a change on the wrong tenant!

$host.ui.RawUI.WindowTitle = "CustomerX: Production"

If you also want to manage Skype Online:

Download and install the Skype for Business Online Connector module.

To connect to Skype Online:

Import-Module SkypeOnlineConnector
$SkypeSession = New-CsOnlineSession -Credential $creds
Import-PSSession $SkypeSession
Get-CsExternalUserCommunicationPolicy (to test)

To connect to Exchange Online:

$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $creds -Authentication Basic -AllowRedirection
Import-PSSession $ExchangeSession
get-mailbox (to test)
Get-Organizationconfig (useful)

Note: If you have MFA enabled you need to install the old Exchange PowerShell module, see here: https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/mfa-connect-to-exchange-online-powershell?view=exchange-ps

See https://docs.microsoft.com/en-us/office365/enterprise/powershell/connect-to-office-365-powershell and https://docs.microsoft.com/en-us/office365/enterprise/powershell/manage-skype-for-business-online-with-office-365-powershell for more information.

Also https://docs.microsoft.com/en-us/office365/enterprise/powershell/connect-to-all-office-365-services-in-a-single-windows-powershell-window

Checking your Office 365 ProPlus version and features for Windows Desktop applications

How to check the version of your Office 365 desktop applications. If you have an Office 365 subscription, either home or business, you will probably be aware that your Office applications are updated from time to time.

Features are added, bugs are fixed, and performance is (hopefully) improved over time. So you may want to know what version you are running, and what the features are of that version.

Checking your Office 365 version

Firstly, you need to check which version of Office 365 you have installed.

  1. Open any Office application, such as Word or Excel, and create a new document.
  2. Choose File, then Account
  3. The version is shown below e.g. 1705

 

There are 2 ways to view the update history for Office 365 desktop, which will tell you which features were added in this version.

 

1  What’s new in Office 365

For Office 365 Subscribers:

https://support.office.com/en-us/article/what-s-new-in-office-365-95c8d81d-08ba-42c1-914f-bca4603e1426?ui=en-US&rs=en-US&ad=US

Or if you are an Office 365 Insider:

https://support.office.com/en-us/article/what-s-new-for-office-insiders-c152d1e2-96ff-4ce9-8c14-e74e13847a24?ui=en-US&rs=en-US&ad=US

These pages give a high level overview of the features added in the various releases. If you scroll down you can see features added in previous releases.

 

2  Update history for Office Insider for Windows desktop

This gives a more detailed list of changes

https://support.office.com/en-us/article/update-history-for-office-insider-for-windows-desktop-64bbb317-972a-4933-8b82-cc866f0b067c

For more information see :

When do I get the newest features in Office 2016 for Office 365?

https://support.office.com/en-us/article/when-do-i-get-the-newest-features-in-office-2016-for-office-365-da36192c-58b9-4bc9-8d51-bb6eed468516?ui=en-US&rs=en-US&ad=US

Also see https://docs.microsoft.com/en-gb/officeupdates/release-notes-office365-proplus to see which version you get depending on your update channel.

Accessing Office 365 documents from Office 2013

The Skydrive integration with Office 2013 is really nice. But what about Office 365? If you try opening a document from your portal, you get an error saying that the correct version of Word is not installed.

But what you can do is just add your portal as a location in Word etc.

Click on Add a place, then Office365, and enter your credentials. You can then browse your document libraries from with Word, or other office 2013 apps.