Getting up and running with Workplace Join

A key part of Microsoft’s strategy for supporting tablets and smartphones in the enterprise is Workplace Join, which lets devices register with Active Directory:

When you join your personal device to your workplace, it becomes a known device and will provide seamless second factor authentication and single-sign-on to workplace resources and applications. When a device is Workplace-Joined, attributes of the device can be retrieved from the directory to drive conditional access for the purposes of authorizing issuance of security tokens for applications.

Devices currently supported are Windows 8.1 (RT or x86) and Apple iOS, with Android in preparation. It is a kind of lite version of domain join, enabling single sign-on but not group policy (centralised control of device settings). In order to control device settings, you can use ActiveSync (limited but includes password requirements and remote wipe) or device management through the cloud-based InTune.

I set myself the task of implementing Workplace Join on my test network, mainly using the guide here. It was somewhat arduous. Here are a few points to note.

Workplace Join is also called Device Registration and is a feature of Active Directory in Windows Server 2012 R2. It depends on Active Directory Federation Services (ADFS).

I wasted some time juggling with certificates and Service Principal Names (SPNs). On my test network I have Active Directory, Certificate Server and ADFS on the same virtual machine, which is not recommended. Here are some things to note.

You need a Server Authentication certificate which includes a Subject Name and two Subject Alternative Names, one of which is In order to get this out of Certificate Server I ended up copying and modifying a template to allow this additional data to be entered when the certificate is requested. I did not need to purchase any certificates; it all works as long as the Enterprise CA (Certification Authority) certificate is trusted by the device.

IIS will need this certificate as the default web site must accept secure connections to

I got into difficulty when configuring ADFS. Initially I used the same name for the Federation Service Name as the computer name. This in turn caused a conflict with the registration of an SPN for the ADFS service account, probably because I have too much installed on one box. SPNs are used by Kerberos for secure communications and each SPN must be unique. The solution was to remove ADFS and re-install, using a different Federation Service Name. Then I modified DNS so that all three names – computer name, Federation Service Name, and enterpriseregistration – resolve to the same box.

I have not published my ADFS to the internet so mine is only an intranet solution for now.

Once all this was resolved I was able to run the PowerShell scripts to enable the Device Registration Service, and to check Enable device authentication in ADFS:


Of course my first efforts at actually using Workplace Join on a device (I used Surface RT and Surface Pro) failed with a generic 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.

The first thing to check is that your device can access the device registration service over HTTPs. Open a browser and go to this URL:


If this does not resolve, or returns a certificate error, you need to fix this before registration will work. Possible reasons:

  • Your device does not trust the certificate
  • IIS has the wrong certificate
  • A necessary service is not running on the server (check ADFS and the Device Registration Service as well as IIS)
  • The device cannot access the Certificate Revocation List for your domain

There is also an event log for workplace join, buried in the Applications and Services section, even on Windows RT.

Once fixed, I was successful and saw my devices show up in Active Directory under Registered Devices.