UAG – Top 10 Things to do after you’ve installed it

The UAG needs a lot of tweaking after you’ve installed it, here is a list of my top 10 things to do to get started:

  1. Make sure you have SP1 update 1 installed – KB2585140.
  2. If something is not working (like a Remote Desktop link), run the Best Practice Analyser. This will highlight any issues, like certificate errors that are stopping the application from working.
  3. Increase the default session timeouts – ‘Inactive session timeout=300 seconds’ and ‘Trigger automatic logoff after 60 mins’. Way to low for most environments. Increase to suit yours.
  4. Enable access for mobile users – This is disabled by default.
  5. Customise your portal – Not easy to do, but the sooner you brand it the better.
  6. Integrate with a two factor authentication product to increase security.
  7. When adding Active Directory integration update the search root and scope to include the domain only, i.e. the root, enable subfolders and leave nested groups blank so every group in the domain is queried. Takes longer but less hassle for Ops teams.
  8. Once you have configured authorisation don’t move the groups to another OU in Active Directory or your authorisation will break.
  9. To clean up the logon page, remove the language bar, deselect ‘Enable users to select a language’ from the Authentication -> Trunk configuration settings.
  10. Update the language files to customise all the logon and portal text.

And 1 to remember!

  1. If you are going to modify your Login.asp file make sure when you update the user logon page fields you do NOT use a leading forward slash, e.g. ‘/CustomUpdate/Login.asp’ is incorrect. The correct format is ‘/CustomUpdate/Login.asp’. Read a full outline here


  1. Check the protocols and encryption available via the best  public website checker –
  2. Install JVM for web monitor in IE –
  3. Disable TCP chimney, Receive Side Scaling and Taskoffload to resolve client endpoint issues as per this post:


Event ID 10154 after promoting 2008 R2 Domain Controller

Fark. What a day. Another spurious event log error.

What’s worse than getting event log errors after deploying an OS… How about after promoting a domain controller. It creates far too many questions and far too few answers!

After building out a new Active Directory forest I noticed the following event log errors in the 2008 R2 Domain Controllers:

The WinRM service failed to create the following SPNs: WSMAN/servername.fqdn; WSMAN/servername 
Additional Data 
The error received was 1355: %%1355.
User Action 
The SPN can be created by an administrator using setspn.exe utility.

This appears to be caused by the NETWORK SERVICE not being given the necessary permissions on the domain controller AD object to make write changes.

I tried a number of things to get this to work and I think I have found the solution.

Adding the necessary values with SETSPN manually does not resolve the issue because the NETWORK SERVICE attempts to write the WSMAN SPN values each time the WinRM service is started.

You can apply the necessary permissions manually with ADSIEDIT or via the command line with dsacls.

The domain controller AD object resides in the Domain Controllers OU. If you apply permissions directly to the domain controller object they will (should!) be replaced by the permissions held on the AdminSDHolder object. In my testing this what not the case, however all the documentation I’ve read indicates differently.

Anyhow, the AdminSDHolder object resides in the System container in every domain and is used to secure privileged users, groups and objects from modification. A background process on the PDC emulator runs every 60 minutes and compares the ACL of the AdminSDHolder object with the ACL of the protected users, group and computers. If there are any differences it overwrites them. Read more about this here.

When I applied the necessary permissions to the AdminSDHolder object only, I could not get the permissions to overwrite on the domain controller object. I waited a couple of hours and even forced the SDPROP process to run. No joy.

I used adfind.exe as described in the Technet article above and confirmed that the \Users\Domain Controllers group is a protected group and as the domain controller objects reside in the Domain Controllers group they should be protected.

I can see the AdminSDHolder ACL being applied to the Domain Controllers group, but not the objects contained with the Domain Controllers. Weird.

I don’t yet know why the ACL of the domain controller object wasnt overwritten , but this was consistent across multiple domains I tested this on. This will need further investigation as all evidence points to the domain controller objects being protected. I also recreated the issue on a vanilla Windows 2008 R2 SP1 ISO to eliminate any other potential causes. When testing with the vanilla ISO, I also received the same error as above, just with a different error code in the message ‘The error received was 8344: %%8344.

To work around this issue I applied permissions directly to the domain controller and AdminSDHolder objects with dsacls:

dsacls “CN=AdminSDHolder,CN=System,DC=domain,DC=com” /G “NETWORK SERVICE:WS;Validated write to service principal name”

dsacls “CN=domaincontroller,OU=Domain Controllers,DC=domain,DC=com” /G “NETWORK SERVICE:WS;Validated write to service principal name”

After that just stop and start the WinRM service and check the System log. Event ID 10154 should be gone.