Sunday, June 16, 2019

Unable to remove RDS Session Host

A customer had a failed RDS Session Host which needed to be removed from a cluster.  We were not able to login to the failed host as it was blue screening and needed to be forcefully removed.

Even using PowerShell with the -force switch we were unable to remove the server getting the following error:

"Unable to cleanup the RD Session Host server"


To remove the server we needed to install SQL Management Studio and connect to the RD Broker Windows Internal Database (WID) which is a lightweight install of MS SQL.

SQL Management Studio was downloaded and installed from the following link:


https://go.microsoft.com/fwlink/?linkid=2094583

Make sure you run SQL Management Studio as "Administrator" and you should be able to connect to the following instance as a Domain Admin:

\\.\pipe\MICROSOFT##WID\tsql\query


The server needs to be removed from two tables:
  • rds.Server
  • rds.RoleRdsh
Make note of what ID number the server you want to remove is... mine is ID 4 as shown in the screenshots below.



Next I used the following command to remove the failed server from the RD Broker database:


use RDCms;
delete from rds.RoleRdsh where ServerID = '4';
use RDCms;
delete from rds.Server where Id = '4';


I strongly recommend a full backup of the SQL database be taken before making any changes.

Hope this post was helpful.

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:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso

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!

Sunday, April 28, 2019

Cisco Router messed up SMTP TLS with Office 365

Mail routing from Office 365 to an on-premise Exchange Server was working successfully.

Mail flow from the on-premises Exchange Server to Office 365 was failing.

Email in the queue was generating:

LastError : 451 5.7.3 STARTTLS is required to send mail


I had a valid SMTP certificate bound to with Enable-ExchangeCertificate and my Send Connector to Office 365 was TLS enabled - yet we had a TLS error.

This was caused by a Cisco Router 1941 with SMTP inspect causing issues.

The router has the following line in the config:

"ip inspect name CBAC smtp"


After removing this line with "no ip inspect name CBAC smtp" mail flow started working successfully.