I have been doing more work this week with a customer XenDesktop 5 environment which I referred to in a previous post.

This week we have been looking at why some Active Directory accounts were showing as “Tainted” in Desktop Studio, and how we could fix this.  I was able to reproduce this in our lab so I can show you how to re-produce this scenario and how to fix it.

 

A bit of background information

The AD Identity Service in XenDesktop 5 is responsible for managing all of the Active Directory accounts required for virtual machines.  In particular we will use this service heavily if we are using Machine Creation Services to rapidly create virtual machines.

There are a number of GUI and PowerShell commands that we can use to control the AD Identity Service.  The full PowerShell reference is here.  There are however a couple of simple commands that can get us familiar with the sort of information that is stored in the service:

Get-AcctIdentityPool

This command displays a list of all the Identity Pools in the AD Identity Service
Get-AcctADAccount

This command displays a list of all the AD accounts stored in the AD Identity Service

If I run both of these commands againts my lab environment I get the following output:

AcctIdentityPool An identity pool is the settings that will be used for any AD accounts created within that pool.  So we see a reference to the OU and also the naming scheme that will be used for any accounts created (the properties “NamingScheme” and “NamingSchemeType”).

AcctADAcount lists all of the Active Directory accounts that are “known” by the AD Identity Service.  If you have multiple Identity Pools then we can pass a parameter in the Get-AcctADAccount cmdlet to only show the AD accounts within a specific pool.  However in our Lab we have a single pool.

So what is a “Tainted” Account?

An Active Directory account will be marked as Tainted if the AD Identity Service loses synchronisation between itself and Active Directory.  There might be accidental ways that this can occur, and it will always occur if we delete a Virtual Machine from XenDesktop, but choose to leave the AD account in place.  We can use this to reproduce the scenario in the lab which is useful to demonstrate the repair mechanism.

How do we force an account to become “Tainted”?

If we delete a virtual machine, but choose to leave the Active Directory account intact, the AD Identity Service will mark the account as “Tainted”.

 Choose the VM to be deleted (in this example VDI-001):

Then for the deletion options, we choose to delete the VM but leave the AD Account information in the AD Identity Service:

At this point the Virtual Machine is deleted, and if we look at the AD accounts in Desktop Studio we can see the account has been marked as “Tainted”:

We can also query this with PowerShell by issuing the following command:

Get-AcctADAccount -State Tainted

If we now to ask Desktop Studio to create a new Virtual Machine to replace the one we deleted, it would not be created with the account SAMO2\VDI-001.  For an account to be used by MCS it must be marked as “Available” in the AD Identity Service.  Our VDI001 account is not marked as Available, so Desktop Studio would create a new account following the rules in the Identity Pool.  So in our lab environment the new account would be SAMO2\VDI-006.

How can we release this account for re-use?

We can issue a simple PowerShell command to force the AD Identity Service to synchronise with Active Directory and therefore make this account available to be used with a Virtual Machine.  The command that we use is:

Repair-AcctADAccount -ADAccountName SAMO2\VDI-001

Here is the command being used, and the output showing it was successful:

Once the account has been released, if we can check the State of the account via powershell like this:

Get-AcctADAccount -ADAccountSID {AD Account SID} and we see the following information:

Note that the State property now shows as Available.  If we check Desktop Studio we see the following:

If we create a Virtual Machine in this catalog the machine will be assigned the available AD account VDI001.

How could we repair multiple Tainted accounts?

The commands given above would help you repair a single AD Account at a time.  What about if we have multiple Tainted accounts:

If we issue the following command through PowerShell we can repair all Tainted accounts:

Get-AcctADAccount -State Tainted | Repair-AcctADAccount

If we issue this command we see the following output:

If we wanted to be more specific with this command we have used the -IdentityPoolName switch to only repair the accounts in a specific identity pool.  For example:

 Get-AcctADAccount -IdentityPoolName "London Lab -State Tainted | Repair-AcctADAccount

 

I hope you have found this article useful.  Note that the method I showed to create a Tainted account is one that can be reproduced easily.  There might be other ways that an account can be marked as Tainted which I am not aware of, although the recovery steps should always be the same.