The Sysadmins

Tips and tricks from the Sysadmins

Author: (page 1 of 14)

Deploying Microsoft LAPS – Non-Persistent VDI

Deploying Microsoft LAPS to a non-persistent VDI environment requires a slightly difference approach to traditional machines, especially for those environments that force a reboot after user log off (e.g. Citrix XenDesktop using PVS).


  1. Computer Boots up for the first time after LAPS installation and GPO configuration
  2. LAPS CSE views ms-Mcs-AdmPwdExpirationTime when Group Policy is refreshed which will read 0 as a password has never been set for given computer
  3. New password is set on the Computer, written to Active Directory and the ms-Mcs-AdmPwdExpirationTime attribute is updated giving an expiry date for the password (as per the Group Policy “password age (days)” setting)
  4. Computer is restarted and boots the golden image
  5. LAPS CSE views ms-Mcs-AdmPwdExpirationTime when Group Policy is refreshed, the value is now populated with an expiry time for the password set in step 2
  6. Computer does not update password
  7. LAPS is not functional


Originally I looked at clearing the ms-Mcs-AdmPwdExpirationTime attribute on shutdown with VBS.

Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
' Change ms-Mcs-AdmPwdExpirationTime attribute to 0 
objComputer.Put "ms-Mcs-AdmPwdExpirationTime", "0"
' Write change to AD 

This can also be accomplished with PowerShell but requires you install the Remote Server Administration Tools which wasn’t desirable. Running the script on shutdown was unsuccessful, due to an issue with how Citrix Delivery Controllers manage the shutdown process of the virtual desktops, essentially preventing the script from running. More information here: Logoff Script is terminated early on XenDesktop.  This may not be an issue for you if you are using another VDI solution.

After trying a few other methods, the following has proven to be reliable. The VBS script sets the ms-Mcs-AdmPwdExpirationTime attribute to 0, waits 3 minutes and then runs GPUpdate to trigger a password update. The 3 minute pause is insurance that the ms-Mcs-AdmPwdExpirationTime change has been replicated to other DCs within the same site. With this method you are essentially setting a new password and expiry date at every startup, maybe Microsoft will add this as a feature in a future release of LAPS.

Add this to a startup script either in Group Policy or locally on the golden image with gpedit.msc and enjoy LAPS within your VDI environment!


Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
' Change ms-Mcs-AdmPwdExpirationTime attribute to 0 
objComputer.Put "ms-Mcs-AdmPwdExpirationTime", "0"
' Write change to AD
' Sleep 3 minutes
Set WshShell = CreateObject("Wscript.Shell")
' Run GPUpdate force and target only the computer policies
Result = WshShell.Run("cmd /c echo n | gpupdate /target:computer /force",0,true)
' Exit with code

Internet Explorer 11 – HTML5 Black Screen


You are unable to play HTML5 videos in Internet Explorer 11, the HTML5 player displays a black screen only.


A post on the MSDN Blog states: In order to play HTML5 videos in the Internet Zone, you need to use the default settings or make sure the following registry key value 2701 under HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 is set to 0.

However, when setting the value of 2701 to 0 in this location the value does not stick and reverts back to 3. Process Monitor showed that Group Policy was setting the value to 0, and then back to 3. Despite putting this policy last, and trying various other tactics I was unable to change this behaviour.

To apply this setting, you can also use the following key location: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3.

When set here, the value of 2701 will not revert back to 3 (disabled), and HTML5 video playback will be enabled.

You can set this via GPP as below.


Deploying Microsoft LAPS – Part 2

We recently covered preparing Active Directory and deploying the LAPS CSE/Client to the machines you wish to manage in part 1 of deploying Microsoft LAPS. Part 2 covers “Turning on” LAPS via Group Policy, the LAPS process and how it works once deployed.

Group Policy

On your LAPS management machine, head to C:\Windows\PolicyDefinitions, there you will find AdmPwd.admx and AdmPwd.adml (under en-US). Copy these files into your Group Policy Central Store, if you do not have a Central Store (and do not which to create one) you can launch Group Policy Management Console directly from your management machine, or copy the ADMX/ADML to a Domain Controller where you will be editing the policy.


Create a new GPO and navigate to Computer configuration -> Policies -> Administrative Templates -> LAPS


Password Settings
This is where you’ll choose your password policy. The default is complex passwords, 14 chars and a password age of 30 days (machines will automatically change their password when this is met).

Continue reading

Deploying Microsoft LAPS – Part 1

What is LAPS?

A lot of organisations will use the same local administrator password across all machines, which is a bad idea for a number of reasons. At a basic level, if this password is learnt, it allows anyone to install software as an administrator – at a higher level it facilitates things such as pass the hash, mimikatz and general reconnaissance against your machines (usually with the goal of elevating to Domain Admin).

If you currently deploy your Local Administrator Account via Group Policy Preferences, this makes things even easier for an attacker to obtain the shared local administrator password. The CPASSWORD value is easily searchable against SYSVOL and Microsoft provide the 32-byte AES key which can be used to decrypt the CPASSWORD. Alan has a great post here why you should stop using Group Policy Preferences for deploying Local Administrators.

So what can we do?

LAPS – Local Administrator Password Solution! This is Microsoft’s solution to managing Local Administrator account passwords across an organisation. LAPS solution features include:

• Sets a unique randomly generated password PER machine
• Automatically change the Local Administrator Password every x days
• Stores Local Administrator Passwords as an attribute of the Computer Object in Active Directory
• Password is protected in AD by AD ACL, so granular security model can be easily implemented
• Password is protected during the transport via Kerberos encryption

Deployment Steps

  1. Installs LAPS onto management machine
  2. Extend Schema and prepare Active Directory
  3. Deploying LAPS client to those machines you wish to manage
  4. Configure Group Policy to enable and set the relevant policies

This post will cover steps 1, 2 and 3.

Management Machine

First off, we’re going to install the management portion of LAPS. Download LAPS here and next, next through the installation. On the custom setting page choose all of the management tools. The AdmPwd GPO Extension is required if the machine you’re installing the management portion on will also be managed by LAPS.

Continue reading

Deploying XenClient Enterprise Engine with SCCM

This post will explain how to automate the deployment of XenClient Enterprise Engine 5.5.5 using SCCM 2012 R2. There is very little information on how to achieve this, so hopefully this will help those looking for a solution. Thanks goes to a post made by Greg Roll early last year on the Citrix discussion forums which pointed me in the right direction. There were a few bits missing and lacking detail, which I will cover.

Preparing the files

Download the XenClient Windows Installer (xce-engine-setup-5.0.exe under additional software) and run it on a disposable Virtual Machine. When prompted, select the latest Engine ISO and continue


Select Resize Windows


Leave these options unticked


Next to start the installation and select no when prompted to reboot

Continue reading

Unifi Wireless – 1. Installing the Controller

This mini-series will guide you through installing and configuring Ubiquiti’s Unifi Wireless solution using 802.1x, Windows NPS (radius) and Group Policy. This post will cover the installation of the Unifi Controller. The following posts will cover configuring the controller, NPS and deploying Wireless settings via Group Policy to your endpoints. I will add any relevant or helpful links at the bottom of each post.

The setup for this mini-series is as follows:

  • Server 2012 R2 member server hosting the Unifi Controller and Network Policy Server (NPS)
  • Windows 7/8.1/10 Clients
  • Unifi Controller

Unifi Controller Installation

From the Server 2012 R2 member server:

  1. Install the latest Java. Unifi recommend that if you are using an x64 operating system to install both x86 and x64 version of Java for the Unifi controller service to correctly start
  2. Offline Java Installs:
  3. Install the latest Unifi Controller:
  4. Accept the defaults, but untick “Start Unifi Controller after installation”


The controller installs into “C:\Users\%username%\Ubiquiti Unifi” by default and there is no way to change this when installing, however moving it isn’t too difficult. Simply Copy the entire folder and move it to the required location e.g. C:\Ubiquiti Unifi.

Now that the installation has been moved, you will want to configure the Unifi Controller to run as a service. If this is not done, the Unifi Controller will need manually starting by a logged in user. When the user logs out, the controller software will close.

From an elevated command prompt run

java –jar "C:\Ubiquiti Unifi\lib\ace.jar” installsvc

Start the service with

net start “Unifi Controller"


Continue reading

Remote Desktop iOS 8.1.0 – Error 0x03000008


In a recent update to the iOS Remote Desktop client (8.1.0 and above) you receive the following error when connecting using a Remote Desktop Gateway: Can’t connect to the Remote Desktop Gateway. Contact your network administrator for assistance. (Error code: 0x03000008)

iPhone iPad Error 0x03000008

Confirmed on the Remote Desktop Services blog here.


1. Review the TerminalServices-Gateway operational event log on the Remote Desktop Gateway server and look for EventID 301 which states: The user “DOMAIN\user”, on client computer “”, did not meet resource authorization policy requirements and was therefore not authorized to resource “”. The following error occurred: “23002”.


The resource IP should be one of your RDS servers, note healthy connections to the Gateway should (typically) specify the FQDN of the RDS server it is trying to connect to: The user “Domain\user”, on client computer “”, met resource authorization policy requirements and was therefore authorized to connect to resource ““.

Continue reading

Older posts