Syslog gone mad after vSphere upgrade to vSphere 5.1 update 1

After upgrading a vSphere 5.0 update 2 host to vSphere 5.1 update 1 we noticed an issue with the lsassd daemon. Right after update manager finished with the upgrade the lsassd starts to write a lot of messages. Within the last 5 minutes the syslog server received 170K log messages from the upgraded host alone.

See the screenshot below:


The following message keeps popping up in the logs:

esxihost.domain.loc lsassd[9297]: 0x6eb11b90:Terminating on fatal IPC exception

To work around this issue you need to leave the Windows domain. Select the host – Configuration – Authentication Services – Properties. Click on Leave Domain… The excessive logging hast stopped immediately.


After that you can rejoin to the Windows domain again.

Domain Controller keeps starting in Directory Service Restore mode

After installing the latest batch of Microsoft updates on one of my virtualized domain controllers. I needed to restart the virtual machine. Nothing interesting so far but when the virtual machine was started I logged on with the correct credentials and noticed that the virtual machine was started in

Check the safeboot parameter via bcdedit:


if the safeboot contains DsRepair the domain controller will start in Directory Services repair mode. I don’t know why or who changed the safeboot parameter. But I know how you can delete this value so the VM will start normally. Just run the following command to delete the DsRepair value: bcdedit /deletevalue safeboot and shutdown –r –t 10 to restart the virtual machine.

More information about Directory Services Restore mode can be found here.

ESXi: Leave Windows Domain: The operation is not allow in the current state

Today I was struggling with an ESX host. The ESX host was unable to leave the Windows domain. I got the following error:


From the vSphere client I was unable to fix this issue. Apply Host profile failed also with the same error. So I started a search in the VMware KB and found an article about problems while attempting to join a Windows domain. In this article you’ll find a way to clean up the AD configuration from the CLI.

The solution for me was to stop the lsassd service:

/etc/init.d/lsassd stop

Remove the db directory:

/etc/likewise/db directory

and start the lasassd service again:

/etc/init.d/lsassd start

Now I was able to leave the Windows domain.

View Composer: Error during provisioning: Failed to authenticate to AD

Last weekend I was busy with a vCenter migration from vCenter 4.0 on a 32 bit Windows 2003 server to a vCenter 4.1 update 1 server on a Windows 2008 R2 64 bit VM. The database is already running on a separate database server.  The one thing special in this setup was VMware View Composer. So I started the migration and everything went well. vCenter was up and running and VMware View Composer service was started. So it was time to test the provisioning of new Desktops. I changed the pool to deploy 2 new desktops. The process ended with an error:image

I was unable to fix this by myself so I contacted VMware Support and after a while we came up with the following solution: Login to the VMware View Administrator and browse to the vCenter Server page:View Configuration – Servers and select the vCenter server in the the vCenter Servers window and press edit. Now select the Quickprep user for the Desktop pool with the error and press edit:


And enter the password for the Quickprep user:


After re-entering the password for the Quickprep user, we where ready to test the Desktop pools again. We did a test with an existing Desktop pool and a new pool and both worked as expected. The Desktop pools are working again. I want to thank VMware support for the quick and accurate support.

View Agent is in an unreachable state after deploying a Win XP pool

After the upgrade to VMware View 4.5, I wanted to test a Desktop pool with the new View Agent and Windows XP installed as Guest OS. But when the composer finished his job, it finished with a provisioning error:


So after a quick search I found out that this issue is documented on page 286 from view45_admin_guide.pdf:

Windows XP linked-clone desktops can fail to join the domain if your Active Directory runs on Windows Server 2008.

When linked-clone desktops are provisioned, the linked clones fail to join the domain. View Administrator displays View Composer provisioning error messages. For example:
5/17/10 3:11:50 PM PDT: View Composer agent initialization state error (18): Failed to join the
domain (waited 565 seconds)

This issue can occur if your Active Directory runs on Windows Server 2008. The Windows Server 2008 readonly domain controller (RODC) is not backward-compatible with Windows XP virtual machines.

1 Check the View Composer log for the following error message:
0x4f1: The system detected a possible attempt to compromise security. Please ensure that you
can contact the server that authenticated you. By default, the View Composer log file is generated in the Windows Temp directory: C:\Windows\Temp \vmware-viewcomposer-ga-new.log
2 On the parent virtual machine, apply the Windows Server 2008 RODC compatibility update for Windows XP. See Microsoft Support Article 944043 at the following location:
3 Take a snapshot of the updated parent virtual machine.
4 Recompose the linked-clone desktops from the updated parent virtual machine and snapshot.

You can also find the solution on

This issue occurs when Windows XP desktops fail to join the Windows 2008 Active Directory domain.

To resolve this issue:

  1. Ensure that the Windows XP Master is updated with the latest Microsoft patches.
  2. Ensure that the Windows Server 2008 read-only domain controller (RODC) compatibility pack for Windows Server 2003 and Windows XP clients is installed in the master virtual machine.
    For more information and to download the patch, see the Microsoft Knowledge Base article 944043.
    Note: The preceding link was correct as of January 28, 2011. If you find the link is broken, provide feedback and a VMware employee will update the link.
    After applying the patch, create a new snapshot for use with linked clone pools or convert the virtual machine to a template for full clone or deployment using Sysprep.

After applying the latest Windows XP updates and the patch mentioned above. I was able to deploy the XP desktop pool again. So if you are deploying View desktop with Windows XP in a Windows 2008 domain. Install the patch mentioned in KB944043.

Note. I saw this issue only on desktops with the latest View 4.5 agent installed. The desktop pool with the View 4.0 agent did work as expected.


Source Link

How To: Configure vSphere 4.1 Active Directory Authentication

In this post I will show you how to setup Active Directory Authentication in vSphere 4.1.

What do we need tot do:

– Before you start. Please make sure that DNS and NTP are fully functional.
– Create an AD group called "ESX Admins" on a Windows Domain Controller
– Add users to that group
– Configure ESX/ESXi server’s "Directory Services"

If your ESX hosts and Active Directory Domain controllers are able to find each other via DNS, you’re ready to go to the next step of this setup. We need to create a group called “ESX Admins” and add the users with administrator permissions in vCenter to this group. When you choose a different name for the group, you will not be able to use Active Directory Authentication. I found this in the vsp_41_esx_server_config.pdf:

vCenter Server registers any selected Windows domain user or group through the process of assigning permissions. By default, all users who are members of the local Windows Administrators group on vCenter Server are granted the same access rights as any user assigned to the Administrator role. Users who are members of the Administrators group can log in as individuals and have full access.
Users who are in the Active Directory group ESX Admins are automatically assigned the Administrator role.

After creating the ESX Admins group it’s now time to join the ESX host to the Windows Domain. When you’re managing a small environment, you can do this with five a six mouse clicks per ESX host.

Continue reading

Powershell: Set Logon Hours for all the users in an OU


With the script in this post you’re able to set logon hours to a bunch of users. All you have to do is to setup logon hours for a “template” user and define this “template” user into the $template variable.


The other step is to define the $ou variable with the path to the OU. In my case this was ict-freak/Gebruikers.

The script will now read the default logon hours and will apply them to the users in the OU.

$template = "" # This is a user with the default logon hours
$ou = "" # the full path to your ou "domainname/ouname1/ouname2"

# Get the logonhours from the template user
$template = Get-QADUser $template -IncludedProperties logonhours
[array]$logonHours = $template.DirectoryEntry.logonHours

# Get all users
$users = Get-QADUser -OrganizationalUnit $ou

# Loop through all the users
foreach($user in $users){
    Set-QADUser $user.Name -oa @{logonHours = $logonHours}


I found this trick here: