One meeting to allow them all

The day is getting closer where you can look to Microsoft Office 365 Skype for Business to be able to meet all the capability of your UC collaboration platform in the cloud. The hardest part is knowing what is available and what would you need to purchase to make the complete package for your organisation.
E3 licenses will get you the Skype for Business cloud platform for IM/P, Web and Video Conferencing within your organisation and federated Skype for Business partner organisations. The additional steps to making your UC experience complete needs to include additional services in my opinion.

  1. Allowing participants to join your organisations meetings by a phone number, which is commonly known as a PSTN Audio Conferencing Bridge
  2. Allowing participants to join your organisations meetings by any video conferencing endpoint, which I call a Video Interop Bridge
  3. Allow the public and your employees to make/receive standard phone calls, which Microsoft have called Cloud PBX
    1. Plus a Voice Plan (carrier call rates)

Lets break down what these additional services are and why they complete a collaboration platform.
Once you adopt a collaboration platform you soon realise it is only as good as the customers, partners and employees that are stripped with the same colour as you, in this case sky blue.

We have Skype for Business, BUT we have plenty of customers and partners that have different flavours and they can’t join our meetings and collaborate.

This is where we must add the capability for external parties to join our business collaboration with ease.

Join by phone

First thing, make your meeting accessible (at a minimum) via the PSTN. At a base level offer a phone number for a party to join via a standard phone call. Everyone has a mobile or desk phone and we can cover this off pretty easy.
This is achieved via the PSTN conferencing user license in Office 365.

Join with a video conferencing device

Secondly, make your meetings accessible via any video conferencing endpoint. This is the next level collaboration for your organisation. Acknowledging that not all parties are doing things the same as you and allow them to join via a video interoperability services that is available through Polycom and Microsoft.
This is achieved via Polycom Real Connect services user license obtained through Polycom and added to your Office 365 license bundles in the portal.

What do I have as a result?

Subscribing to these two services on top of your base Skype for Business license will give your employees the ability to create meetings with additional details for participant joining. As shown below in a calendar invite created by the meeting organiser.

In the above image, both sets of meeting details for phone and video conferencing are automatically added via the user licenses. If the scheduler doesn’t have the license, then the Skype meeting doesn’t include the detail. Simple.

PSTN Calling

The last piece of the puzzle is allowing your employees to make PSTN calls to domestic and international numbers from their Skype for Business account. This was commonly referred to as Enterprise Voice in an on-premises deployment but has taken on a different name in the cloud service called “Cloud PBX”. Cloud PBX enables your employees with a direct inward dial number for inbound and outbound calling. Microsoft grants you the capability of punching digits into the Skype for Business client to normalise to a phone number, but you’ll need a voice plan associated with that user with call rates.
At the time of writing Cloud PBX is available, but the voice plans have not been made available to the public in the Australia region.


If I want the complete all inclusive collaboration platform for my organisation, I can purchase the user subscription licenses to achieve nirvana.

  1. PSTN Conferencing Add-on
  2. Polycom RealConnect for Office 365
  3. Cloud PBX with a Voice Plan

Licenses 1 and 2 in my opinion are a must if you plan to use Skype for Business as your collaboration/meeting space. While license 3 is when you start looking at Skype for Business to replace your existing telephone system (PBX) capability.

Brisbane O365 Saturday

On the weekend I had a pleasure of presenting to the O365 Saturday Brisbane event. Link below
In my presentation I demonstrated a new feature within Azure AD that allows the automatic assigment of licences to any of your Azure subscriptions using Dynamic Groups. So what’s cool about this feature?
Well, if you have a well established organisational structure within your on-premise AD and you are synchronising any of the attributes that you need to identity this structure, then you can have your users automatically assigned licences based on their job type, department or even location. The neat thing about this is it drastically simplifies the management of your licence allocation, which until now has been largely done through complicated scripting processes either through an enterprise IAM system, or just through the service desk when users are being setup for the first time.
You can view or download the presentation by clicking on the following link.
O365 Saturday Automate Azure Licencing
Throughout the Kloud Blog there is an enormous amount of material featuring the new innovative way to use Azure AD to advance your business, and if you would like a more detailed post on this topic then please place a comment below and I’ll put something together.

Azure AD Connect – Using AuthoritativeNull in a Sync Rule

There is a feature in Azure AD Connect that became available in the November 2015 build 1.0.9125.0 (listed here), which has not had much fanfare but can certainly come in handy in tricky situations. I happened to be working on a project that required the DNS domain linked to an old Office 365 tenant to be removed so that it could be used in a new tenant. Although the old tenant was no long used for Exchange Online services, it held onto the domain in question, and Azure AD Connect was being used to synchronise objects between the on-premise Active Directory and Azure Active Directory.
Trying to remove the domain using the Office 365 Portal will reveal if there are any items that need to be remediated prior to removing the domain from the tenant, and for this customer it showed that there were many user and group objects that still had the domain used as the userPrincipalName value, and in the mail and proxyAddresses attribute values. The AuthoritativeNull literal could be used in this situation to blank out these values against user and groups (ie. Distribution Lists) so that the domain can be released. I’ll attempt to show the steps in a test environment, and bear with me as this is a lengthy blog.
Trying to remove the domain listed the items needing attention, as shown in the following screenshots:

This report showed that three actions are required to remove the domain values out of the attributes:

  • userPrincipalName
  • proxyAddresses
  • mail

userPrincipalName is simple to resolve by changing the value in the on-premise Active Directory using a different domain suffix, then synchronising the changes to Azure Active Directory so that the default or another accepted domain is set.
Clearing the proxyAddresses and mail attribute values is possible using the AuthoritativeNull literal in Azure AD Connect. NOTE: You will need to assess the outcome of performing these steps depending on your scenario. For my customer, we were able to perform these steps without affecting other services required from the old Office 365 tenant.
Using the Synchronization Rules Editor, locate and edit the In from AD – User Common rule. Editing the out-of-the-box rules will display a message to suggest you create an editable copy of the rule and disable the original rule which is highly recommended, so click Yes.

The rule is cloned as shown below and we need to be mindful of the Precedence value which we will get to shortly.

Select Transformations and edit the proxyAddresses attribute, set the FlowType to Expression, and set the Source to AuthoritativeNull.

I recommend setting the Precedence value in the new cloned rule to be the same as the original rule, in this case value 104. Firstly edit the original rule to a value such as 1001, and you can also notice the original rule is already set to Disabled.

Set the cloned rule Precedence value to 104.

Prior to performing a Full Synchronization run profile to process the new logic, I prefer and recommend to perform a Preview by selecting a user affected and previewing a Full Synchronization change. As can be seen below, the proxyAddresses value will be deleted.

The same process would need to be done for the mail attribute.
Once the rules are set, launch the following PowerShell command to perform a Full Import/Full Synchronization cycle in Azure AD Connect:

  • Start-ADSyncSyncCycle -PolicyType Initial

Once the cycle is completed, attempt to remove the domain again to check if any other items need remediation, or you might see a successful domain removal. I’ve seen it take upto 30 minutes or so before being able to remove the domain if all remediation tasks have been completed.

There will be other scenarios where using the AuthoritativeNull literal in a Sync Rule will come in handy. What others can you think of? Leave a description in the comments.

Azure AD Connect – Multi-valued Directory Extensions

I happened to be at a customer site working on an Azure project when I was asked to cast a quick eye over an issue they had been battling with. They had an Azure AD Connect server synchronising user and group objects between their corporate Active Directory and their Azure AD, used for Office 365 services and other Azure-based applications. Their intention was to synchronise some additional attributes from their Active Directory to Azure AD so that they could be used by some of their custom built Azure applications. These additional attributes were a combination of standard Active Directory attributes as well as some custom schema extended attributes.
They were following the guidance from the Microsoft article listed here. As mentioned in the article, ‘Directory extensions allows you to extend the schema in Azure AD with your own attributes from on-premises Active Directory‘. When running the Azure AD Connect installation wizard and trying to find the attributes in the dropdown list, some of their desired attributes were not listed as shown below. An example attribute they wanted to synchronise was postalAddress which was not in the list.

After browsing the dropdown list trying to determine why some of their desired attributes were missing, I noticed multi-valued attributes were missing, such as the description standard Active Directory attribute which I knew was a multi-valued attribute.

I checked the schema in Active Directory and it was clear the postalAddress attribute was multi-valued.

The customer pointed me back to the Microsoft article which clearly stated that the valid attribute candidates included multi-valued strings and binary attributes. With the time I had remaining, I reviewed their Azure AD Connect implementation and tried a few techniques in the synchronisation service such as:

  • refreshing the schema of the on-premise Active Directory management agent
  • enabled the attribute in the properties of the on-premise Active Directory management agent as by default it was not checked

I next checked the Azure AD Connect release notes (here) and quickly noticed the cause of the issue which had to do with the version of Connect they were using, which was a few releases old. It was from version released in April 2016 which added support for multi-valued attributes to Directory Extensions, while the version running by the customer was from only a couple of months earlier.
After upgrading Azure AD Connect to currently released version, the customer was able to successfully select these multi-valued attributes.

Microsoft are very good at keeping the release notes upto date as new versions of Azure AD Connect are released, currently every 1-2 months. The lessons learned are to check the release notes to view the new features and bug fixes in releases to determine if you need to upgrade the tool.

Understanding Outlook Auto-Mapping

Auto-mapping is an Exchange & Exchange Online feature, which automatically opens mailboxes with Full Access permissions in a delegate’s Outlook client. The setting is configurable by an Administrator when Full Access permissions are assigned for a user. Once enabled, the periodic Autodiscover requests from the Outlook client will determine which mailboxes should be mapped for a user. Any auto-mapped mailboxes with be opened by the Outlook client in a persistent state and cannot be closed by the user. If users want to remove the auto-mapped mailbox from their Outlook client, Administrative intervention is required to remove the Full Access permission, or clear the auto-mapping flag.

There are two scenarios where you may want to use this configuration:

  • You would like mailboxes to automatically open & persist in Outlook, for users who are assigned full access permissions
  • When users require access an Online Archive associated with the delegating mailbox – the Online Archive isn’t available if you add the mailbox via the “Open these additional mailboxes” console in a mailbox profile. Note that the Online Archive is also available via “Open Another Users Mailbox in Outlook Web App and in some cases, when the delegating mailbox is added as an additional mailbox in the Outlook profile (this has proven to be unreliable depending on identity & permission assignment.)

The auto-mapping feature may be undesirable for users who have access to a large number of mailboxes (taking up valuable Outlook screen real estate), or for users who want to control which mailboxes are open in their Outlook client.

If we take a look at the Autodiscover response for my Office 365 mailbox, we can see the AlternativeMailbox options that advertise a Shared Mailbox (including its Online Archive) for which I have Full Access permissions & auto-mapping enabled.

[code language=”XML”]<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="">
<Response xmlns="">

<DisplayName>! Shared Mailbox</DisplayName>
<DisplayName>In-Place Archive – ! Shared Mailbox</DisplayName>


Auto-Mapping Principles

  • By default, auto-mapping is enabled whenever Full Access permissions are granted to the mailbox via Add-MailboxPermission. It must be explicitly set to false if you want it disabled for a user i.e -Automapping:$false
  • At this time, it is not possible to view the state of the auto-mapping setting for a mailbox (whether it has been enabled/disabled)
  • If you are using Mail-Enabled Security Groups to grant Full Access permissions, auto-mapping will not work for the group members. The auto-mapping feature must be assigned by granting Full Access to individual user objects

Managing the Setting

It is enabled per-user, for new or existing Full Access delegates:

[code language=”PowerShell”]Add-MailboxPermission -AccessRights FullAccess -User -Automapping:$true[/code]

You can disable auto-mapping for a single user, by removing the user’s Full Access permission and then reinstating the permission with the -automapping:$false parameter defined:

[code language=”PowerShell”]Remove-MailboxPermission -AccessRights FullAccess -User
Add-MailboxPermission -AccessRights FullAccess -User -Automapping:$false[/code]

In Exchange Online, auto-mapping can be removed for all existing Full Access delegates on a mailbox by running the command:

[code language=”PowerShell”]Remove-MailboxPermission -ClearAutoMapping[/code]


That’s it, simple! Hopefully this helps to explain the nuances of Outlook auto-mapping.

Modern Authentication and MAPI-HTTP

If you haven’t heard, Modern Authentication (aka ADAL), has now officially gone GA ( – which means that if you are utilising Office 365 services, particularly Exchange Online, and Office 2013/2016 as your client, you should really be looking at enabling this functionality for your end users.

For those unfamiliar with Modern Auth, there are numerous benefits, but one of the most obvious for end users is it removes the need for the use of ‘save my credentials’ when signing into Exchange Online and provides a true SSO experience when combined with ADFS Federation.

Now, the process for enabling Modern Auth is very well documented in the above blog post, but the short version is:

  1. Enable Modern Auth on the Tenant side via a powershell command
  2. Enable Modern Auth on the client side via a registry key

What isn’t explicity called out as a pre-requisite however is that your Outlook client also needs to also be running in MAPI over HTTP mode.  Now, for a large percentage of environments, this is probably not an issue – but if you are like a recent customer of ours, you may have specifically disabled the use of MAPI-HTTP.  Now there are a number of valid reasons of why you might have wanted to do this (theirs was they were using an old version of Riverbed that didn’t support optimization using the MAPI-HTTP protocol), but as it turns out, the introduction of the MAPI over HTTP protocol to replace the legacy ‘RPC over HTTP’ protocol over 3 years ago was actually one of the precursors into allowing all this fancy Modern Authentication stuff to work.

For full details around what MAPI-HTTP protocol brought in and the benefits it introduced, I recommend reading this great blog post from the Microsoft Exchange team.

But in short, if you find that you have enabled Modern Auth as per the described steps, and you’re still getting the ‘basic auth prompt’ – I’d go ahead and check to see if the following registry key has been set (via GPO or otherwise)

Key: HKEY_CURRENT_USER\Software\Microsoft\Exchange
DWORD: MapiHttpDisabled
Value: 1

The above needs to either be deleted, or set to ‘0’ in order for Modern Auth to work.  The support article KB2937684 also gives you some more info around ensuring MAPI-HTTP is enabled for your Office 2013/2016 client.

Note that changing this value does not take effect until the client next performs an ‘autodiscover’ to switch over.  Depending on the situation, this may cause the user to see the following pop up:


Generally speaking, I’d recommend you test the registry update first with a subset of pilot users, before rolling this out to the wider audience.  Once that is confirmed working, then you can look at rolling out Modern Auth to your end users.

Configuring Intune Service to Service Connector for Exchange Online with a Service Account

If you are considering the use of Intune Conditional Access with Exchange Online it is generally recommended that you configure the Intune Service to Service Connector.  While it is not mandatory, it does provide your Intune Administrators the ability to report on the effectiveness of the Conditional Access Policies on your mobile ActiveSync clients within your Exchange Online environment.  In addition, if you wanted to enforce the use of the Outlook iOS/Android app using Exchange ActiveSync policies, as per my previous blog post here, setting up the connector would allow you to configure the ActiveSync access rules straight from the Intune Admin Portal.

The steps to configure the connector are already covered in the newly reskinned Enterprise Mobility Documentation, with the specific steps located here – but the purpose of today’s blog is to clarify how you would do this “properly” in a Production environment using a Service Account, as the specifics of this are glossed over in the documentation.

If you note the article, you will see a comment that “Microsoft Intune uses the email address of the currently logged in user to set up the connection”.  That means if you executed the steps using your administrative account (which is what most people will end up doing if they weren’t paying attention), Intune will actually configure the connector to use your account from then onwards to perform its regular syncs (every 2 hours for a quick sync, and daily for a full sync).  This is not exactly great, as now this functionality is tied to a specific user, of which that account could be expired, disabled or terminated based on the employment status of that person.   Ideally, you want to be using a Service Account for this purpose.

In order to do this you are going to need the following:

  • A cloud identity to act as the Service Account
  • An Intune License assigned to the Service Account
  • An Exchange Online license assigned to the Service Account

You may question why the licenses are required, but unfortunately that’s just the limitations imposed by Microsoft.  All Intune Administrators (regardless of whether they are Tenant or Service Administrators) must have an Intune license.  Furthermore, the Service to Service Connector requires that the account have a valid email address (and thus a mailbox), necessitating the need for an Exchange Online license.

Step 1 – Grant the Service Account Intune Admin Access

  1. Log into your Intune Management Portal with an admin account that already has Tenant or Service Administrator privileges
  2. Under Admin -> Administrator Management -> Service Administrators add your service account (e.g.
    Note:  You won’t be able to do this unless the account has an Intune License assigned to it

Step 2 – Grant the Service Account Exchange Admin Access

  1. Log into the Exchange Online Admin Portal with an admin account that has Organization Management privileges
  2. Under Permissions -> Admin Roles create a new role
  3. Provide a relevant Name and Description
  4. Leave the Write Scope as Default
  5. For the Roles ensure that you include:
    • Organization Client Access
    • Recipient Policies
  6. For Members add the service account

Step 3 – Set up the Intune Service to Service Connector

  1. Log into your Intune Management Portal with the Service Account
  2. Under Admin -> Microsoft Exchange -> Set up Exchange Connection select the Set up Service to Service Connector button at the bottom
    Note:  If the service account doesn’t have an email address (i.e. Exchange Online License with a mailbox), you will get an error indicating so.  Also, if the service account doesn’t have an Intune license assigned, it will throw up an ‘unexpected error’.IntuneS2S-SetUp
  3. Click OK when prompted.  Use this opportunity to verify that the correct account is being used (i.e. you haven’t forgotten to sign out with your original admin account)IntuneS2S-Account
  4. It will take about 10-15 mins for it to verify the account and configure the connection, but once it is successful, you will see a status update with a green tick like below:IntuneS2S-Success

Optional Step – Hide Mailbox of Service Account

Since we’ve had to give the service account an exchange mailbox (which it doesn’t use), it’s probably a good idea to hide it from the GAL so users don’t get confused.

  1. Log into the Exchange Online Admin Portal
  2. Under Recipients -> {Search for user} -> Edit -> General and select Hide from Address lists

And there you have it, a much more secure and cleaner way to configure your Intune Service to Service connector for Exchange Online!

Managing SharePoint Online (SPO) User Profiles with FIM/MIM 2016 and the Granfeldt PowerShell MA

Forefront / Microsoft Identity Manager does not come with an out-of-the-box management agent for managing SharePoint Online.

Whilst the DirSync/AADConnect solution will allow you to synchronise attributes from your On Premise Active Directory to AzureAD, SharePoint only leverages a handful of them. It then has its own set of attributes that it leverages. Many are similarly named to the standard Azure AD attributes but with the SPS- prefix.

For example, here is a list of SPO attributes and a couple of references to associated Azure AD attributes;

  • UserProfile_GUID
  • SID
  • SPS-PhoneticFirstName
  • SPS-PhoneticLastName
  • SPS-PhoneticDisplayName
  • SPS-JobTitle
  • SPS-Department
  • AboutMe
  • PersonalSpace
  • PictureURL
  • UserName
  • QuickLinks
  • WebSite
  • PublicSiteRedirect
  • SPS-Dotted-line
  • SPS-Peers
  • SPS-Responsibility
  • SPS-SipAddress
  • SPS-MySiteUpgrade
  • SPS-ProxyAddresses
  • SPS-HireDate
  • SPS-DisplayOrder
  • SPS-ClaimID
  • SPS-ClaimProviderID
  • SPS-ClaimProviderType
  • SPS-SavedAccountName
  • SPS-SavedSID
  • SPS-ResourceSID
  • SPS-ResourceAccountName
  • SPS-ObjectExists
  • SPS-MasterAccountName
  • SPS-PersonalSiteCapabilities
  • SPS-UserPrincipalName
  • SPS-O15FirstRunExperience
  • SPS-PersonalSiteInstantiationState
  • SPS-PersonalSiteFirstCreationTime
  • SPS-PersonalSiteLastCreationTime
  • SPS-PersonalSiteNumberOfRetries
  • SPS-PersonalSiteFirstCreationError
  • SPS-DistinguishedName
  • SPS-SourceObjectDN
  • SPS-FeedIdentifier
  • SPS-Location
  • Certifications
  • SPS-Skills
  • SPS-PastProjects
  • SPS-School
  • SPS-Birthday
  • SPS-Interests
  • SPS-StatusNotes
  • SPS-HashTags
  • SPS-PictureTimestamp
  • SPS-PicturePlaceholderState
  • SPS-PrivacyPeople
  • SPS-PrivacyActivity
  • SPS-PictureExchangeSyncState
  • SPS-TimeZone
  • SPS-EmailOptin
  • OfficeGraphEnabled
  • SPS-UserType
  • SPS-HideFromAddressLists
  • SPS-RecipientTypeDetails
  • DelveFlags
  • msOnline-ObjectId
  • SPS-PointPublishingUrl
  • SPS-TenantInstanceId

My customer has AADConnect in place that is synchronising their On Premise AD to Office 365. They also have a MIM 2016 instance that is managing user provisioning and lifecycle management. I’ll be using that MIM 2016 instance to manage SPO User Profile Attributes.

The remainder of this blog post describes the PS MA I’ve developed to manage the SPO attributes to allow their SPO Online Forms etc to leverage business and organisation user metadata.

Using the Granfeldt PowerShell Management Agent to manage SharePoint Online User Profiles

In this blog post I detail how you can synchronise user attributes from your On Premise Active Directory to an associated users SharePoint Online user profile utilising Søren Granfeldt’s extremely versatile PowerShell Management Agent. Provisioning and licensing of users for SPO is performed in parallel by the DirSync/AADConnect solution. This solution just provides attribute synchronisation to SPO User Profile attributes.


In this solution I’m managing the attributes that are pertinent to the customer. If you need an additional attribute or you have created custom attributes it is easy enough to extent.

Getting Started with the Granfeldt PowerShell Management Agent

First up, you can get it from here. Søren’s documentation is pretty good but does assume you have a working knowledge of FIM/MIM and this blog post is no different.

Three items I had to work out that I’ll save you the pain of are;

  • You must have a Password.ps1 file. Even though we’re not doing password management on this MA, the PS MA configuration requires a file for this field. The .ps1 doesn’t need to have any logic/script inside it. It just needs to be present
  • The credentials you give the MA to run this MA are the credentials for the account that has permissions to manage SharePoint Online User Profiles. More detail on that further below.
  • The path to the scripts in the PS MA Config must not contain spaces and be in old-skool 8.3 format. I’ve chosen to store my scripts in an appropriately named subdirectory under the MIM Extensions directory. Tip: from a command shell use dir /x to get the 8.3 directory format name. Mine looks like C:\PROGRA~1\MICROS~4\2010\SYNCHR~1\EXTENS~2\SPO

Managing SPO User Profiles

In order to use this working example there are a couple of items to note;

  • At the top of the Import and Export scripts you’ll need to enter your SPO Tenant Admin URL. If your tenant URL is ‘’ then at the top of the scripts enter ‘’. The Import script will work with but the export won’t.
  • Give the account you’re using to connect to SPO via your MIM permissions to manage/update SPO User Profiles


As mentioned above I’m only syncing attributes pertinent to my customers’ requirements. That said I’ve selected a number of attributes that are potentials for future requirements.

Password Script (password.ps1)

Empty as described above


A key part of the import script is connecting to SPO and accessing the full User Profile. In order to do this, you will need to install the SharePoint Online Client Components SDK. It’s available for download here

The import script then imports two libraries that give us access to the SPO User Profiles.

‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.UserProfiles.dll’

‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.dll’

Import values for attributes defined in the schema.


The business part of the MA. Basically enough to take attribute value changes from the MV to the SPO MA and export them to SPO. In the example script below I’m only exporting three attributes. Add as many as you need.

Wiring it all together

In order to wire the functionality together, I’m doing it just using the Sync Engine MA configuration as we’re relying on AADConnect to create the users in Office365, and we’re just flowing through attribute values.

Basically, create the PS MA, create your MA Run Profiles, import users and attributes from the PS MA, validate your joins and Export to update SPO attributes as per your flow rules.

Management Agent Configuration

As per the tips above, the format for the script paths must be without spaces etc. I’m using 8.3 format and I’m using the Office 365 account we gave permissions to manage user profiles in SPO earlier.

Password script must be specified but as we’re not doing password management it’s empty as detailed above.

If your schema.ps1 file is formatted correctly you can select your attributes.

I have a few join rules. In the pre-prod environment though I’m joining on WorkEmail => mail.

My import flow is just bringing back in users mobile numbers that users are able to modify in SPO. I’m exporting Title, Location and Department to SPO.


Using the Granfeldt PowerShell MA it was very easy to manage user SharePoint Online User Profile attributes.

Follow Darren on Twitter @darrenjrobinson

Office 365 – AADSTS50008: SAML token is invalid

If you’ve made it to this post because you are troubleshooting your AD FS sign in with Office 365 due to “AADSTS50008: SAML token is invalid” I still recommend you do all the standard troubleshooting steps provided in this article below the image:


Generally speaking, if you’re getting issued a token from your AD FS server and Microsoft’s STS is stopping you from logging in, it would be because of your token signing certificate:

Has your Token-Signing Certificate changed since you last told Microsoft?


It’s never a bad idea to re-run the following:

[code language=”PowerShell”]Update-MsolFederatedDomain -DomainName [verified domain][/code]

Executing this MSOL cmdlet will get Microsoft’s STS service to check your Metadata, which in turn will update any certificate changes you may have made. If you’re really clever you can go to your WS-Federation Metadata and check what you’re telling the world is your public token signing certificate.

  1. Navigate to https://<AD FS Namespace> in Internet Explorer.
  2. Search for KeyDescriptor use=”signing” in the metadata document.
  3. If you copy the raw certificate data from <X509Certificate> into a text file and save with extension ‘cer‘ you can validate it matches what’s in your AD FS console > Service > Certificates > Token-Signing

Good, we have that under control. I experienced an issue the other day where I still got the error post running this cmdlet and performing the above nifty check….. Head scratches. Firstly, I know that my AD FS services has processed my sign on attempt and given me the required information to take to Office 365 and log in. Secondly, I know that my signing certificate is correct. Still the error remains;

We received a bad request.
Additional technical information:
Correlation ID: 82121251-3634-4afb-8014-fb5298d6f2c9
Timestamp: 2016-03-04 00:25:35Z
AADSTS50008: SAML token is invalid

My issue was a little unique but worth a notable mention on the internet. In my scenario, If I left my browser page up with the error shown above for a length of time, suddenly if my browser refreshed I would get dropped into whatever it was I was trying to authenticate to. So my authentication was successful with Microsoft after a point in time. I highlight those words cause I literally had to say them out loud to myself before I found the fix. Looking at the AD FS servers where my token is issued from, I took a quick look at the time. I then took a look at the time on the AD workstation I was trying from, they both seemed to be in synchronisation with each other.  What about from my BYOD Surface that I use at Kloud which uses a internet time source?

Great Scott! 7 minutes difference!

My token was being accepted by Office 365, but only once Microsoft had caught up to the future from which I had came from. This isn’t unreasonable from Microsoft to not allow my issued token until that time had actually happened in Microsoft cloud land. This wasn’t an issue that showed its face as easily with internal applications as all domain controllers and workstations were following orders from the time source in the domain. The problem was that the domain couldn’t synchronise with a internet time source at the time master. So it was slowly but surely sneaking ahead. Once we had come back from the future, the issue with ‘AADSTS50008: SAML token is invalid’ was resolved and authentication was instantaneous on the first attempt once again.

I don’t want to put the fear of the ‘internet time gods’ on you, I believe that there is some kind of threshold that Microsoft will allow. Just not in 10 minutes time or maybe tomorrow, in the future.  Possibly the magic number for token timestamp issuance is plus or minus 5 minutes. Once I rolled the AD FS servers time back within a couple of minutes/seconds of the internet time gods, tokens were accepted. Now over to the AD and Network teams to restore order on a wider scale.

Yammer Activation in All Eligible Tenants

In an effort to drive the collaboration experience and further the adoption of Yammer, Microsoft announced on the 2nd of February that Yammer now meets all of Office 365’s security and compliance requirements and Yammer will be activated across all Office 365 tenants that contain a Yammer subscription. This will be a retrospective activation as well as being enabled by default for any new tenants. The rollout will be in three stages:

  • Wave 1 has commenced as of February 1, 2016 and includes Office 365 customers with a business subscription who purchased fewer than 150 licenses that includes Yammer and who have zero or one custom domain for Yammer.
  • Wave 2 starts on March 1, 2016 and includes Office 365 customers with a business subscription who purchased fewer than 5,000 licenses that includes Yammer. This does not include customers with an education subscription.
  • Wave 3 starts on April 1, 2016 and includes all remaining customers with a business subscription and all customers with an education subscription.

As Yammer is automatically activated, users with a license that includes Yammer can immediately start accessing the service through Office 365 and Yammer features will be available from within other Office 365 apps. The activation process will either create a new Yammer network or connect to an existing Yammer network that has all or a subset of domains managed within the Office 365 tenant.

Microsoft are continuing to work towards deeper integration between Yammer and Office 365 and this change will lay the ground work for new features. One of the exciting new capabilities coming in the first half of this year is integration with Office 365 Groups adding  the ability to initiate Skype for Business calls, access OneDrive for Business files, schedule Outlook calendar meetings and create tasks within Planner, all from within a Yammer group.

I’ve had a number of customers choose not to deploy Yammer to their user bases for one reason of another and it is possible to block this from occurring. As of February 2016, the Yammer license is an option that can be disabled. Previously the Yammer license was embedded and enabled by default into E plans; provisioning of the Yammer service is what activated a users’ ability to get into Yammer. If your business is not yet ready to adopt Yammer, it will now be necessary to revoke the Yammer license via PowerShell for individual users.

For more information, see

Follow ...+

Kloud Blog - Follow