VMware Horizon Community
lookandfeel
VMware Employee
VMware Employee
Jump to solution

After re-installing the view agent, the View Desktop cannot log on to the domain

Hi,

I have a problem with the administration of View Desktops. Our customer use a View 4.0 environment. Everytime when I re-installs the view agent in a XP desktop machine (deployed desktop pool with Composer enabled), after the reboot of the machine a login at the customers microsoft domain is not possible.

Every time I must remove the machine from the ad domain, after that I had to take this machine into the domain again. But I cannot install the view agent succesfully, when the machine is a member in the domain. So I delete the machine from the ad domain, re-install the agent, and take the machine in the domain again.

So whats wrong?

Have anybody the same or a similiar problem?

Regards,

Andre

Reply
0 Kudos
1 Solution

Accepted Solutions
david1234
VMware Employee
VMware Employee
Jump to solution

Can you please confirm if these are linked clones? If so this behaviour is expected, the proper and supported approach to updating the Agent for example is to perform this on the Master image and not the linked clone itself and then performing a recompose.

I believe the cause of this comes down to 2 files:

sim.datsimvol.dat

Frankly I am still not exactly sure what these files specifically do. 

View solution in original post

Reply
0 Kudos
3 Replies
david1234
VMware Employee
VMware Employee
Jump to solution

Can you please confirm if these are linked clones? If so this behaviour is expected, the proper and supported approach to updating the Agent for example is to perform this on the Master image and not the linked clone itself and then performing a recompose.

I believe the cause of this comes down to 2 files:

sim.datsimvol.dat

Frankly I am still not exactly sure what these files specifically do. 

Reply
0 Kudos
hmartin
Enthusiast
Enthusiast
Jump to solution

David is spot on. We had the same problem. The two files, sim.dat and simvol.dat are likely marked a hidden and system and located on the root of the user data disk (I believe). Permanently deleting these files before reinstalling the View Agent will resolve the problem. When these files are present and you reinstall the agent (upgrade, downgrade, reinstall - it does not matter), this triggers the VMware QuickPrep process which, among other things, apparently tries to join the computer to the domain, effectively breaking the kerberos password between the VM and its computer account.

VMware told us that upgrading the View Agent on a View Composer VM (as opposed to upgrading it on the parent VM) is not supported. Our permanent solution was to abandon the use of View Composer. Recomposing won't be practical for us until we test and repackage several hundred SMS packages anyway. Yes, there's ThinApp, but building and testing a few hundred 'virtual' apps is going to take awhile.

lookandfeel
VMware Employee
VMware Employee
Jump to solution

Hi David,

Hi Martin!

Thank you for your answers. You're right. Everytime when I re-install the agent on a linked clone desktop machine, this vm canot log on to the domain after the reboot.

Normally I always modifiy the parent vm, but in this case I hava another problem in the view environment, so I want to test some things with only one linked clone machine.

The other way - deleting the simvol.dat (the sim.dat I cannot find) before installing the agent - failed.

I think to abandon the Composer could work, but you have to use much more storage for the desktops. But I can understand that you have several other problems by using the composer.

Kind regards,

Andre

Reply
0 Kudos