If you would like to read the other parts in this article series please go to:
- Windows Server 2012 R2 and BYOD (Part 1)
- Windows Server 2012 R2 and BYOD (Part 2)
- Windows Server 2012 R2 and BYOD (Part 3)
- Windows Server 2012 R2 and BYOD (Part 4)
- Windows Server 2012 R2 and BYOD (Part 5)
- Windows Server 2012 R2 and BYOD (Part 6)
- Windows Server 2012 R2 and BYOD (Part 7)
- Windows Server 2012 R2 and BYOD (Part 8)
Introduction
If you have been following along throughout this article series, then you know that I have spent a lot of time walking you through the process of configuring Windows Server 2012 R2 to allow a workplace join. As with any complex and time consuming procedure however, things can and sometimes do go wrong. That being the case, I wanted to spend some time showing you how to troubleshoot a failed workplace join just in case you weren’t able to get things working correctly in your own environment.
When it comes to troubleshooting a malfunctioning system, I think that it makes the most sense to start out by checking for the simplest or most common causes of problems and then trying out more elaborate fixes only when the simple stuff doesn’t work.
Verify Active Directory Authentication
OK, this one might seem really obvious, but it is also extremely important so I am going to go ahead and say it. A workplace join cannot work if the user who is attempting to join the Active Directory is having problems with their user account. As you will recall from the earlier articles, I set up a test account named JohnDoe that I am using for workplace join.
I can’t really test this account out on our workstation computer because it is not domain joined. Even so, we need to make sure that the account is working. That being the case, I recommend trying to log into the domain controller. You won’t be able to complete the login process because the user doesn’t have Log On Locally permissions. Even so, the message that you receive is telling. The message shown in Figure A for example, indicates that there is a problem with the account (a bad password in this case), while the message in Figure B more or less confirms that the credentials are good.
Figure A: This message indicates that there is a problem with the credentials.
Figure B: This message indicates that the credentials are good.
Check DNS Name Resolution
The next thing that I recommend checking is to make sure that DNS name resolution is working properly. You should be able to ping each of your servers by its IP address and by its fully qualified domain name from any of the other servers that we set up. Successful pings indicate that DNS name resolution is working within the Active Directory environment. You can see a series of successful pings in Figure C.
Figure C: Check to make sure the servers can ping one another by fully qualified domain name.
If you are having trouble with the PINGs it could be because of a DNS issue, but it could also be because the firewall is blocking ICMP traffic. You could temporarily adjust or disable the firewall until you can confirm where the problem is.
One thing to keep in mind is that a successful ping test between servers does not necessarily mean that name resolution is working properly for the end user device (in our case a Windows 8.1 PC). In order for the end user device to be able to perform a workplace join, the device must be able to resolve the name enterpriseregistration.<your domain>.com.
As you can see in Figure D, the ping should redirect to your ADFS server and then be resolved. For instance, I entered PING enterpriseregistration.byod-lab.com and the ping was redirected to byod-adfs.byod-lab.com.
Figure D: The client machine should be able to resolve enterpriseregistration.<your domain>.com.
Verify Certificate Trust
As you saw throughout the articles in this series, workplace join is highly dependent on certificates being configured correctly. That being the case, the next thing that I recommend doing is to verify that the client device trusts the certificate authority that issued the certificates. The easiest way to do this is to establish a secure connection to the enterprise certificate authority. As you may recall, I set up an enterprise certificate authority on my domain controller. That being the case, the URL that I would use is https://DC.BYOD-LAB.com/CertSRV.
If the client computer trusts the enterprise certificate authority then you should receive a login prompt and you should be able to log into the certificate authority as an administrator. If the trust is not configured properly then you will receive a certificate error. If you are using Internet Explorer, the address bar will turn red to indicate a problem with the certificate.
Check the Event Logs
If you are using a Windows 8 or a Windows RT device then the next thing that I recommend doing is taking a peek at the event logs. Believe it or not, there is actually an event log for the workplace join. You can access the logs by opening the Event Viewer and then navigating through the event logs to Applications and Services Logs | Microsoft | Windows | Workplace Join | Admin. You can see what this looks like in Figure E.
Figure E: The Event Viewer contains a Workplace Join log.
As you can see in the figure above, there are several errors indicating that workplace join discovery has failed and that a connection with the server could not be established.
In that type of situation (which is very common), the next thing that I recommend doing is going to the Details tab. As you can see in Figure F, the Details tab lists a Service URI. This URI is the address that the device uses to connect when attempting a workplace join. In this case, the service URI is https://EnterpriseRegistration.BYOD-Lab.com:443/EnrollmentServer/Contract?api-version=1.0.
Figure F: You need to go to the event Details pane to retrieve the Service URI.
In this type of situation, the next thing that I recommend doing is to open a Web browser and try to establish an https session to EnterpriseRegistration.<your domain>.com. If you receive a 404 error then it means that there is a problem with IIS and that the client cannot find the enrollment site. More often however, you will receive a Page Cannot be Displayed error. This typically points to a certificate problem even though the browser might not explicitly cite a certificate issue.
To check out the certificate, open the IIS Manager and click on the name of your server. Next, click on the Server Certificates icon. When you do, you should see the name of the certificate that the Web server is using. Right click on the certificate and click View.
When the certificate appears, go to the Details pane and look at the certificate’s subject. The CN line of the subject should match the server’s fully qualified domain names as shown in Figure G. There should also be a Subject Alternate Name of enterpriseregistration.<your domain>.com. In my case this subject alternate name would be enterpriseregistration.BYOD-Lab.com.
Figure G: The certificate’s subject name should match the server’s fully qualified domain name.
If the Subject Alternate Name is missing or if it is spelled incorrectly (as it was on my server) then you have found the problem. Unfortunately, you can’t add a subject alternate name to an existing certificate. You will need to request a subject alternate name certificate from your enterprise certificate authority and then add the certificate to IIS.
Conclusion
In this article, I have shown you how to troubleshoot some of the most common problems with domain joins. As long as your certificates are configured correctly and DNS resolution is working properly you should be able to join a device to your device to the Active Directory. Sure, ADFS and the Web server have to be functional as well, but we tested those components as we set them up earlier in the article series.
If you would like to read the other parts in this article series please go to:
- Windows Server 2012 R2 and BYOD (Part 1)
- Windows Server 2012 R2 and BYOD (Part 2)
- Windows Server 2012 R2 and BYOD (Part 3)
- Windows Server 2012 R2 and BYOD (Part 4)
- Windows Server 2012 R2 and BYOD (Part 5)
- Windows Server 2012 R2 and BYOD (Part 6)
- Windows Server 2012 R2 and BYOD (Part 7)
- Windows Server 2012 R2 and BYOD (Part 8)
