Tuesday, May 21, 2019

Azure AD Seamless SSO - Prompts on Connecting to aadg.windows.net.nsatc.net

At a customer site when attempting to access the https://myapps.microsoft.com/companydomain.com portal to test Single Sign-on with Azure AD, we were constantly being prompted "Connecting to aadg.windows.net.nsatc.net".

We had gone through significant troubleshooting on the issue but could not find a resolution online.  This troubleshooting included but was not limited to:
  • Confirmed that we have received the Kerberos ticket from the AZUREADSSOACC with “klist get AZUREADSSOACC”
  • Added https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net to the Trusted Sites
  • Confirmed the servicePrincipalNames on the AZUREADSSOACC are correct
  • Validated the Single sign-on is enabled on the Azure AD Portal and in the Azure AD Connect tool
Troubleshooting sites we went through included:


After speaking with Microsoft, they mentioned that "https://autologon.microsoftazuread-sso.com" must also be in the "Local Intranet" zone.
This is due to the default security setting "Automatic logon only in Intranet zone".  If this was set to "Automatic logon with current user name and password" this would have also fixed the issue but is not as secure.
After making this change Single Sign-On works.

Wednesday, May 15, 2019

Office 365 Tab not working in Exchange Admin Center

After running the Hybrid Configuration Wizard, the Office 365 tab doesn't work by default which catches out many people.  The tab is found at the top of Exchange Admin Centre where it says "Enterprise" and "Office 365".

When you click Office 365 it directs to "Get the most from Office with Office 365" webpage asking you to purchase the product.

After running the Hybrid Configuration Wizard, you must schedule an outage and perform an IISReset on your Exchange 2016 CAS Servers.  After doing an iisreset you will find that the Office 365 tab works as expected.

Wednesday, May 8, 2019

Exchange 2010 and Exchange 2016 co-existance Free/Busy Issues

I have a lab environment containing Office 365, Exchange 2016 and Exchange 2010.  Free busy is not working from O365 --> 2010 or Exchange 2016 --> 2010.

The Autodiscover record points all EWS requests to Exchange 2016 Web Services Virtual Directory for the Availability Service.

The Availability Service on the Exchange 2016 server is failing to lookup requests on Exchange 2010 mailboxes.

It is also important to note, the 2016 server is the one setup in Hybrid with O365, so it is responsible for looking up all Availability requests on-premises.

After doing some research into the issue, I identified that the InternalNLBBypass URL on the Exchange 2010 server must point and resolve directly to the Exchange 2010 server.  It must not be set to $null or point to the Availability Service on Exchange 2016 (in my lab that being mail.avantlab.com.au).

Exchange 2016 Web Services Virtual Directory:

Exchange 2010 Virtual Directory:

As soon as setting the InternalNLBBypassURL to point directly at Exchange 2010, this resolved the issue.

See my lab all working:

  • Arya is in Office 365
  • Jon is on Exchange 2010
  • Bran is on Exchange 2016
And yes, they are all Game of Thrones characters :)

I blogged this one as I could not find much information online regarding this!