Windows Server 2012 R2 – User centric IT and BYOD (TechEd Europe – part 1)


In the bring-your-own-device trend, there were still a few disadvantages over domain joined machines. Access to resources had to be very well thought of. In the R2 release of Windows Server 2012 there’s now an interesting new feature called “workspace join”. In combination with products like Windows Intune or System Center Configuration Manager 2012 R2 it is now possible to add workgroup devices to Active Directory without needing a domain join. So the original user is still full owner of the device. Home-pc’s, tablets or smartphones, devices can be added to the Active Directory by using the workspace join to create a certificate based secure trust. Those certificates can be organised into multiple certificate templates and managed centrally.

To make sure that a device being added is not in malicious hands, a 2nd factor authentication request is sent to the Read more of this post

SCOM alert – Max concurrent API reached

EDIT (11/03/2014): 2nd possible cause found for the SCOM alert and added to the article (at the bottom).

If you got a recently patched Operations Manager environment then the current version of the basic OS management pack includes new intelligence to check for problems due to the maximum amount of NTLM or Kerberos PAC password validations a particular server can handle at a time.


Performance issues; these can be veeery hard to troubleshoot due to the large amount of variables in your environment (from storage to networking to server hardware or virtualization performance etc etc). If you had your storage engineers, your network specialists and your HyperV or Vmware gurus run all the tests they can think of, try to look at the following as well (or better: SCOM could have done it preventively already 😉

Besides performance issues which are not only difficult but also often subjective, you can see some strange application behaviour. Read more of this post

Kerberos authentication and delegation: ServicePrincipalNames


One of the errors that often reoccur when deploying a service is the Kerberos authentication failing for some reason when another system depends on your service. Depending users or services try to log on to your service but are not allowed to access it. This is not a problem with the enduser but with the rights of the service account on which the service itself is running. The service account doesn’t have the right to delegate access or impersonate the enduser. About 9 times out of 10 this is caused by inproper Kerberos rights due to a faulty SPN (or ServicePrincipalName) configuration and sometimes due to the delegation settings on the service account.

First lets take a look at how SPNs work in theory. An SPN consists of 2 parts

  • Service type
  • Service name [:service port]

Read more of this post