Over the last few months I have had a couple cases where GP either will not connect or it connects intermittently from workstations and remote desktop servers.  On one case while troubleshooting a user rebooted their computer and received the error “Trust Relationship between this Workstation and Primary Domain Failed”.  The network administrator could log into GP fine on the SQL Server and never had an issue doing so.  They could intermittently ping the SQL server by name from any of the computers.  I recreated the scenario in a test environment and captured the errors seen in my support cases.  In another unrelated case workflow sent emails to users intermittently.  At the end of this blog I will provide why the setup caused the issues.

I set up my test environment with a firewall, a DC, a SQL/GP server, and a remote desktop server.  The IP addresses are as follows:

Firewall                               10.0.0.1

DC01                                   10.0.0.2

RDS 2019                            10.0.0.50

SQL2019GP                        10.0.0.25

 

On the SQL server with GP installed it would login just fine every time.  GP worked just fine but looking up workflow users failed.  

Researching the issue they logged into the Domain controller and reviewed DNS.  It showed DNS updated and was registering the server correctly at least part of the time.  The DNS record for the server had updated the day before but not since.

 

The network administrator demonstrated the client machines would from time to time not connect.  Testing the ODBC connection when the client cannot connect we would see the test fail.

The administrator went to a command prompt on the Remote Desktop Server and pinged the SQL server by name.  It resolved properly but the ping replies failed.  This tells us DNS is resolving the name “sql2019gp” to the IP address of 10.0.0.25 but the traffic is being blocked.  So we moved on to the SQL server and reviewed the firewall.

Checking the firewall showed the firewall was set to “Private networks” instead of the expected “Domain networks”.  The determination of which firewall profile use is done by the computer's “Network Location Awareness” service. 

The determination is done roughly as follows: 

If the computer connects to a network the IP address range is checked, if it is not a private network a “Guest or public network” firewall profile is used

If the computer connects and the IP network is a private network address range (i.e. 192.168.0.0 - 192.168.255.255 or 10.0.0.0 - 10.255.255.255 or 172.16.0.1 - 172.31.255.255 ) a “Private network” firewall profile is used

If the computer connects to a private network and a domain controller is located a “Domain network” firewall profile is used. 

In our case the computer had found a private network but did not detect the domain controller.

 

The computer not detecting the domain controller on a private network is a good indication DNS is not setup correctly.  On domain joined computers you will only want to use internal DNS servers when connected to the internal network in the office or over a VPN.  Each computer and service on the network is registered in DNS on a local domain so external servers such as 8.8.8.8 will know nothing of the internal network. 

 

If internal DNS is working correctly you can ping the domain by name and the IP address of one of the domain controllers will be the reply address.  In my test environment I used testinggp.local as the domain.  Pinging from the SQL server it returned the following.

 

This is a clear indication the server is using an external DNS server and not a local DC for DNS.  Checking the network adapter on the SQL server we see the Preferred DNS server is set to 8.8.8.8

 

 

 

Removing the unwanted External DNS from the network adapter so the settings look like this

 

 

 

Trying to ping the domain name testinggp.local from the SQL server succeeds and gives us the IP address of the DC

To have the firewall select the correct firewall profile we can wait for the server to run a routine check which takes several hours, reboot the SQL server, or a little trick is to just restart the “Network Location Awareness” service.

 

After the service restarted checking the firewall shows it is now on the “Domain networks”

Going back to the Remote Desktop Server we see the ODBC Data Source Test succeeds.

 

The reason a mix of internal and external DNS servers on the SQL server will have this affect is when a name resolution has to be done by the server the first DNS server is used.  If the DNS response is slow the next server is queried.  The server will not drop back to the fist server again until another slow response is received.  If the external server keeps responding quickly it may be used for weeks without issue.  If the computer can it registers its name and IP address in DNS to make lookup easier for other computers.   

Computers have passwords just like users.  Computer passwords are updated automatically if they expire and the computer and talk to the DC.  If they cannot talk to the DC when the password expires the trust between the computer and the domain is broken.  Receiving that error is just part of the puzzle.

 The bottom line is a simple DNS setup error on the SQL server caused a great deal of issues.  These issues included GP clients not connecting, intermittent workflow issues, and computers failing on the network.

To properly configure DNS on domain joined computers review the following link

 https://docs.microsoft.com/en-us/windows-server/networking/dns/dns-top