Friday, January 17, 2014

Workplace Join discovery failed on Windows RT 8.1

For Windows 8.1 and Windows RT 8.1, users start enrollment from the Windows RT device. The users must complete the following tasks:

1. On the Windows 8.1 device, the user selects Settings, clicks PC Settings, then clicks Network, and finally, clicks Workplace.
2. The user enters their user ID in the (ID) field.
3. The user clicks Turn on and provides their password.
4. The user agrees to the Allow apps and services from IT admin dialog box, and clicks Turn on.


During step 3, I received the following error: "Confirm you are using the correct sign-in info, and that your workplace uses this feature. Also the connection to your workplace might not be working right now. Please wait and try again."

To troubleshoot the issue, I had a look at the Events for Workplace Join in Event Viewer on the Client : Event Viewer > Application and Service Logs > Microsoft > Windows > Workplace Join > Admin. Here I saw Error Event 102: Workplace Join discovery failed. Exit code 0x80072EE7 with Error Message: The server name or address could not be resolved.

At last I found the workaround for this issue: To fix this I had to disable CRL Check in Internet Explorer Advanced Settings: Unchecked the option "Check for server certificate revocation" (not recommended in production environments).
Source: Workplace Join discovery failed. Exit code 0x80072F19


After that everything went fine finally. Happy that Windows RT enrollment can go further now :-)

Note: The names of the devices that users enroll should appear in the Windows Intune administrator console within a few hours of enrollment.

3 comments:

  1. It didn't work for me on Windows 8.1 laptop. domain disjointed but over a work group

    ReplyDelete
    Replies
    1. Did you followed the steps in this blogpost? It must be working this way..

      Delete
  2. Here are certain things to check... but first be careful that there are no typos in the entry "enterpriseregistration" (I ran into this)... now for the checks to do ... SAN of the Service Communication Cert (Technical Jargon for ADFS Cert) should contain "enterpriseregistration.abc.local" (basically enterpriseregistration.UPN of your Domain). There has to be a CNMAE with the same entry enterpriseregistration.abc.local pointing to the ADFS Server. CRL Location must be reachable. SSL Binding should be correct (can be found using NETSH HTTP Show SSLCERT) , Get-AdfsDeviceRegistrationUpnSuffix must list the UPN used by your users and show proper binding @ 443 (remember no IIS in 3.0) ,if not use Add-AdfsDeviceRegistrationUpnSuffix. Best to use the same service account for adfs and DRS services. IE settings must have "Check for Server certificate revocation" unchecked under advanced settings on the client if that location is via some pointer that the client cant reach like LDAP. The step mentioned on this page worked for me :)

    ReplyDelete