VMware Player and Group Policy Allow Log on Locally

Problem:
You receive the following error message when trying to enter Unity on a guest virtual machine in VMware Player: The virtual machine cannot enter Unity mode. Check that Unity is supported for this guest operating system and that the latest version of VMware Tools is installed.

Solution (short version):
Check to make sure the __vmware__ group is in Allow log on locally in Computer Configuration > Security Settings > Local Policies > User Rights Assignment on the host computer… especially if the computer is a member of Active Directory with Group Policy Objects applying to the Computer object in AD.

Solution (long version!):
Without getting into the XP Mode vs. VMware Player discussion, one of my favorite features of both VMware Player and VMware Workstation is Unity. Much like XP Mode in Windows 7, Unity allows you to run applications inside of a virtual machine (VM), but make them look like they are running within the host operating system. Definitely a cool feature to have if you have any users that have one or two Windows XP apps and don’t want to be slowed down by running a full window of the OS just to get to them.

I came across a rather perplexing problem while trying to get a Windows XP Professional virtual machine (VM) working inside of VMware Player on a Windows 7 Professional box that is part of Active Directory. Like I’ve done numerous other times, I clicked on the Virtual Machine menu and then clicked on Enter Unity.

And then I get this: The virtual machine cannot enter Unity mode. Check that Unity is supported for this guest operating system and that the latest version of VMware Tools is installed.

ARG! Yes, the latest version of the VMware Tools are installed. Yes, Windows XP Professional (running as a guest OS) is supported in VMware Player 3 on Windows 7 Professional (as a host OS). Google’ing for error this error message didn’t get me anywhere.

So, when in doubt, hit the Event Log first:

Jackpot! I had tons of Event ID 100 coming from vmauthd as Errors in the Application Event Log.

The Event ID 100 for vmauthd was actually two seperate errors:

  • Failed to retrieve token for vmware user (error 0)
  • Failed to retrieve token for VMware user: Logon failure: the user has not been granted the requested logon type at this computer (1385).

Jackpot, again! So, it looks like we’re actually having a user logon/authentication problem with the VMware user. VMware Player creates a group, __vmware__ (note that is two underscores before and after the “vmware” with no spaces), and a user, __vmware_user__ (same as before, two underscores before and after with no spaces) when you install VMware Player. Now, I’m sure I read about this a few years ago in documentation, but it isn’t the kind of thing that is at the front of your mind when you’re troubleshooting this kind of problem.

So after some poking around on the box, I decided to put the computer into an OU that had no Group Policy applying to the computer. I uninstalled and re-installed VMware Player and, miraculously, Unity works all of a sudden. Reboot after reboot, no problems. I put the computer back into the original OU, forced a Group Policy update, and kaboom… Unity dies again. Clearly, we have something going on in Group Policy causing the problem. After some additional poking, I found that VMware Player puts the __vmware__ group into Allow log on locally in Computer Configuration > Security Settings > Local Policies > User Rights Assignment on the host computer (Windows 7 Professional in my case).

Yep… the Group Policy applying to the host in Active Directory was modifying Allow log on locally and wasn’t including the __vmware__ group. I updated the Group Policy and voila:

Unity is working!!!

Kyle Beckman

Kyle Beckman

Kyle is a Systems Administrator with 15+ years of experience. He currently works in Higher Education supporting everything from smartphones to desktop PC's to Hyper-V Failover Clusters. (If it has a IP address, he probably supports it!) He has also worked in Small Business IT consulting supporting a wide variety of businesses and non-profit organizations.

Kyle is also the Vice President of the Atlanta Windows Infrastructure and Virtualization User Group (WINVUG).You can find additional articles he's written on 4sysops.com.
Kyle Beckman

1 Comment

Add a Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

© trekker.net