the trust relationship between this workstation and the primary domain failed

[w00005414]

Help! We are running View 4.6 with Windows 7 desktops (linked clone non-persistent desktops) and we have had 2 virtual desktops in the last 2 days fail on user login with this error message

"The trust relationship between this workstation and the primary domain failed".

This used to happen to us with our View 4.5 install with XP desktops and it was a nightmare to resolve.

I logged in as the local admin on one of the affected virtual desktops and found entries like this in the event viewer

"NtpClient was unable to set a domain peer to use as a time source because of failure in establishing a trust relationship between this computer and the " domain in order to securely synchronize time. NtpClient will try again in 3473457 minutes and double the reattempt interval thereafter. The error was: The trust relationship between this workstation and the primary domain failed. (0x800706FD)"

Notice above that it refers to the domain as the " domain.

Here is another event viewer entry in the event viewer

"handleEncrypt ERROR = consumeToken FAILED: 2148074257"

With our XP desktop what seemed to help fix the issue were the following steps...

1. We made sure the pool was set to delete a desktop after use instead of refresh (now we have ours set to refresh because it is faster)

2. We switched from using the flexible virtual NIC to using the VMXNET3 virtual NIC since it performs better.

3. We shut off dynamic DNS registering in the master image (but with View 4.6 the agent it turns it right back on so we can't change that)

4. We made sure the ESX servers were set to sync time with the same external NTP host as our primary domain controller and set the VMware Tools app to sync the desktops machine time with it's ESX host.

5. We changed the ExecScriptTimeout REG_WORD value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\vmware-viewcomposer-ga to be 40000 milliseconds instead of the default of 20000.

I ran the support.bat script on an affected virtual desktop and here is a link to the results,

https://wcweb.wheatonma.edu/upload2/docs/w00005414/vdm-sdct-20110908-1133-agent.zip

https://wcweb.wheatonma.edu/upload2/docs/w00005414/vdm-sdct-full.log

https://wcweb.wheatonma.edu/upload2/docs/w00005414/vdm-sdct.log

Any help you can offer would be greeeeaaatly appreciated. I can't call VMware tech support because our support renewal is in the process of being paid... until then I can't call tech support

[Linjo]

Sounds like a time-sync problem. How do you sync time?

// Linjo

[w00005414]

Hi Linjo,

We have our 2 ESX hosts set to sync time with pool.ntp.org and we have the VMTools application set to sync the clients time with the ESX server that is hosting it.

I checked the times on the 2 ESX hosts and they look correct and the "NTP Client" has a status of "Running" on both.

The Domain Controller we have set with the PDC Emulator roll is also pointing to the same external NTP server.

[ngruetter]

What's the status of the virtual machines in the view administrator console? are they available?

I had a similar problem at a customer.

I had the error message in view administrator "customization operation timed out" and in Windows 7 the same error like you "the trust relationship between this workstation and the primary domain failed".

I did the following on win 7 golden image:

- Set the default DHCP gateway. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, select "Obtain an IP address automatically," click Advanced, click ADD under the Default Gateways list, and type the default DHCP gateway.

- Disable Internet Protocol version 6 (IPv6).

- Follow the instructions in the Microsoft Support Knowledge Base article, Unable to Join Windows Server 2008 R2 or Windows 7 Computer to Active Directory Domain.

See http://support.microsoft.com/kb/2008652.

In particular, add the following Windows registry key to the parent virtual machine:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

Value Name: NeutralizeNT4Emulator

Value Type: REG_DWORD

Value Data: 0x1

- In the DNS tab of the Advanced TCP/IP Settings dialog box, remove extraneous DNS servers from the list of DNS server addresses.

- On the parent virtual machine, start the Windows Registry Editor.

a Select Start > Command Prompt.

b At the command prompt, type regedit.

- In the Windows registry, locate the vmware-viewcomposer-ga registry key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\vmware-viewcomposer-ga

- Click Edit and modify the registry value.

Value Name: ExecScriptTimeout

Value Type: REG_DWORD

Value unit: Change milliseconds to 40000

The default value is 20000 milliseconds.

The timeout value is increased. You do not have to restart Windows for this value to take effect.

Take a snapshot of the parent virtual machine and create the linked-clone desktop pool again.

hope this helps you....

regards,

Nicola

[ngruetter]

I wouldn't use the vmware tools for time sync. Synchronize the time with your domain controllers (windows standard tools...)

[w00005414]

Hi Ngruetter,

Sorry it has taken me a bit to get back to you. Thanks for the suggestions.... if you don't mind I have a few questions.

1. I tried disabling IPv6 on the master image and recomposing (and I tried removing dynamic DNS out of the picture by shutting off the "Register this connection's address in DNS" which is something I did when troubleshooting the same XP pool issue last semester) but unlike with XP the view agent software re-enabled both options within the linked clone desktops after the recompose.

2. I checked all 3 of our Windows 2008 domain controllers and none of them had the NT4 Emulation registry entry enabled but I will look to add the NeutralizeNT4Emulator entry to the Windows 7 master image.

3. I didn't have any extraneous DNS servers listed in the DNS tab of the Advanced TCP/IP Settings dialog box

4. We already had the ExecScriptTimeout registry entry set to 40000 milliseconds (something we learned when our XP pool had this issue).

5. What IP address should I add into the "Default gateways" section you mentioned? Is it the IP address of the default gateway for the subnet the virtual desktop is on or should it be the IP address of the DHCP server? On a physical Windows 7 box I tried adding the default gateway for the subnet the machine was on and after a reboot that IP was removed.... maybe because it received that same gateway IP from DHCP?

Thanks

[w00005414]

One other wrinkle to this issue is on 8/29 we lost power to one of our 3 domain controllers on campus because of Hurricane Irene. I wonder if since that DC was down for about 2 days could that cause the domain join issue (or timeout)? We found another desktop in the pool today that had the trust relationship error and we looked inside the C:\Windows\debug\NetSetup.LOG file and noticed that the last time this virtual desktop tried to join the domain was on 8/29.... coincidence? I've attached the NetSetup.LOG file to this post. I noticed at the end it is trying to do an "offline join to the domain" which seems odd to me. It mentions our domain controller wcdc.wheatonma.edu but that wasn't the one that was down during the storm.

My guess is if we did a recompose now that all the DCs are up it would fix any remaining, lingering desktops that had the trust relationship issue.

Thanks for any help you can offer

[w00005414]

The trust relationship with the linked clones desktops is still happening. Today I tested adding a bunch of extra PCs to the pool and switching it over to "Delete" the vm after use instead of "Refresh" (which is what got us through this problem with our small XP pilot pool) but the time it takes to delete the Windows7 VMs and rebuild them was about 7-8 minutes and we came drastically close to having no more VMs available.

I read on experts exchange that someone suggested setting the following group policy on the AD container where my virtual desktops live

"Computer Configuration" -> "Policies" -> "Windows Settings" -> "Security Options" -> "Local Policies" -> "Security Options"  and set the option "Disable machine account password changes".

Is anyone else doing this? Is anyone else running into this problem? I don't want to cause more problems but this issue is killing me!

[gstrouth · Accepted solution]

Had the same problem problem and here is an explanation:

Computers use their machine account password for authentication with Active Directory. By default, computers are configured to change their machine account passwords every 30 days. This setting affects nonpersistent desktops in the following ways:

1. When you deploy the nonpersistent desktop, the pristine snapshot of the desktop contains the original password.
   
2. After 30 days, the machine account password automatically changes.
   
3. Active Directory accepts the new password for authentication.
   
4. When you restart the nonpersistent desktop, it reverts to the pristine snapshot which contains the original password.
   
5. Authentication with Active Directory fails because the pristine snapshot does not contain the new machine account password.
   

If a problem occurs that is related to the password change, users are likely to see an error message similar to the following one when they try to log in to the desktop:

The trust relationship between this workstation and the primary domain failed

Avoiding issues related to the machine account password change

To avoid this issue, disable the automatic password change, as follows:

1. On your gold image, open the Registry editor.
   
2. Navigate to the following key:
   HKLM\System\CurrentControlSet\services\Netlogon\Parameters
   
3. Change the value of DisablePasswordChange to 1.
   

[w00005414]

Cool, thanks gstrouth for sending this. Is the document that you pasted a document from the VMware knowledge base? If so, do you have a URL? I just want to make sure I'm following their suggestions/best practices.

[w00005414]

Sorry to beat this already dead horse but I just read this article on how View Composer and linked clones work

http://myvirtualcloud.net/?p=1237

and it says that View (starting at 4.5) maintains a separate file named the internal disk for each linked clone and that small disk is where machine account passwords are stored in case the machine account password does change.

Here are some quotes...

"View Composer creates an internal disk on the linked clone. This  small disk contains configuration data for QuickPrep/Sysprep. It is also  used to store machine password changes that Windows performs every 30  days as per policy setting and stores the machine account password  retrieved from Active Directory in this disk. This ensures domain  connectivity is maintained when a checkpointed desktop is refreshed."

and

"In many Active Directory environments, the machine account password is  changed periodically. If the View Composer Agent detects a password  change, it updates the machine account password on the internal disk  that was created with the linked clone. This way when the linked clone  is reverted to the snapshot taken after the customisation during a  refresh operation, the agent will be able to reset machine account  password to the latest one."

I wonder if my install of View was having trouble either storing the new machine account password in this internal file or it wasn't looking to it for the updated password after the machine was refreshed?

I noticed inside the folders for my linked clones there is a file named something like this "win7pub25_11-internal.vmdk". I did a recompose of the pool this morning so I would think that this file would have been deleted and rebuilt but in some cases the file goes one day and in an extreme case goes back more than a month and a half which doesn't make sense to me.... I thought a recompose wiped everything (machine accounts in AD, the files and folders where the vms live on the datastore etc...) and started from scratch?