This is an wired issue I had recently when I was working on a Windows domain decommission project. Let me use company.local, ad.company.local and abc.com as the example. ad.company.local is the child domain of company.local. There are two way trusts between abc.com and company.local domain. abc.com is the old domain. All most all computers are in ad.company.local (AD) domain. All end users account are in AD domain.

The old Windows domain abc.com needs to be decommissioned. All other servers have been already decommissioned except 2 domain controllers. I suggested to delete the trust between abc.com and company.com and then decommission abc.com DCs. But there was concern that there might be something we missed since abc.com is so old and has been used for so long. The team decided to disconnect all abc.com DCs from the network and check if they will affect anything. We planned a maintenance window for the test. The issue came out when DCs were offline. End users could not access the on premise Microsoft Dynamics CRM website. IE showed them error message “This Page can’t be displayed”

This Page can’t be displayed

• Make sure the web address https://dynamics.abc.com is correct.
• Look for the page with your search engine.
• Refresh the page in a few minutes:
• Make sure TLS and SSL protocols are enabled. Go to Tools> Internet Options > Advacend > Settings > Security

Take a close look, there are 3 Microsoft CRM application and database servers in AD domain. They are 2 IIS servers and 1 database server. Users access the CRM website via https://dynamics.abc.com. DNS is not the issue because dynamics.abc.com point to the statc IP address of dynamics web server which is the member server of AD domain. abc.com zone is managed by AD DNS server. The CRM WEB site is configured with integrated authentication, users don’t need enter user name and password when they already logon their PC with their domain accounts. But at the time no user could access the CRM web site via IE. When they use Google chrome to access https://dynamics.abc.com, chrome popped up a window to ask user name and password which IE did not. Once user entered the correct username and password, they could login the CRM site. So I believe the issue is related to user authentication and automatic logon.

According to Microsoft article Configuring Internet Explorer for Automatic Logon article, the website URL https://dynamics.abc.com should be in the IE local Intranet zone list. I have checked that we have a group policy put the the URL in the list already. I suspected that IE did pass around the username and password, but something went wrong when server check credentials. Did it caused by abc.com DC offline? User accounts and all Dynamics servers are in AD domain, not in abc.com domain. How come abc.com DC offline could cause issue? After reconnect abc.com domain controllers to the network, Dynamics CRM website is back to normal, users can automatic logon again. What is the root cause? How can we fix it? Different opinion came out, certificate issue, IE settings, CRM server side settings, etc. I believe the root cause is related to abc.com DC.

To find out the root cause, I built a lab environment with cloned 3 Dynamics CRM related VMs, one ad.company.com DC, one company.com DC and two test PCs. I didn’t clone abc.com DC into the lab to repeat the scenario that abc.com DC was offline. Then I removed the GOP for put the CRM URL into local Intranet zone list. Accessing the website from the test PC, IE asked for the username and password like Google chrome did. After entering correct user name and password, I successfully got into CRM website! But it was not good enough, users like automatic logon.

I put the GOP back. Then I removed the trust between abc.com and company.com in the lab. The problem is fixed! Amazing Right? All CRM servers are not in abc.com domain, all users are not in abc.com domain, but without abc.com DC, IE automatic logon just did not work because of the trust between abc.com domain and AD domain! New lesson learnt – when you need decommission a domain with two way trust to other domain, always remove the trust first, or you will have some weired issue like this.