Troubleshooting MED-V V2 Workspace Authentication

One feature introduced into MED-V v2 is the option to allow a seamless authentication experience for the user if desired. While MED-V v1 allowed for the synchronization of the MED-V Client credentials with the user account inside the MED-V guest workspace operation system, some users wanted a more seamless experience that allowed a single sign-on process between the Windows logon to the host workstation all the way through the guest workspace authentication process. In essence, a user would only need to type his or her password only once. This was not possible in the first release of MED-V.

To facilitate this requires workspaces to be joined to the same domain as the MED-V host. This is a requirement for MED-V v2.  In MED-V v2, authentication in MED-V occurs twice. W a user starts the MED-V host either credentials must be entered or saved credentials can be used. These will then need to be refreshed when a user changes their password. The first time a published application is triggered or a workspace is started via the host agent, the user will be prompted for credentials.

There are several aspects of end-user authentication that you can control, including the following:

• Caching the credentials thus storing in the Windows Credential Manager (on the host.)
• Not caching the credentials: This means every time a user starts the workspace through the host agent or triggers the workspace through a published application, the user will be required to supply a username and password.

By default, credential storing is disabled, but you can change this setting through one of the following methods:

• While you are creating the MED-V workspace package.
• After you have deployed the MED-V workspace. Edit the MED-V cmdlet parameter UxCredentialCacheEnabled to set the DisablePasswordSaving registry value.
• Modifying the DisablePasswordSaving registry value directly. This value controls whether the password saving check box appears on the MED-V (actually RDP) client dialog window and whether the MED-V credential prompt is displayed.

The DisablePasswordSaving Registry Value

This value (also a group policy option) is stored in the following key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftVirtual MachinePolicies

The value DisablePasswordSaving is either 0 or 1.  If the value is 0, the MED-V prompt is presented and a check box to accept is available and cleared. If the end user selects the check box, credentials are cached for subsequent use. The end user also has the benefit of only being prompted when the password expires. If the end user does not select the check box, the Remote Desktop Connection (RDC) Client prompt is presented instead of the MED-V prompt, and the check box to accept is cleared. If the end user selects the check box, the RDC Client credential is stored for later use.

If the value is 1, the Remote Desktop Client does not validate the credentials when the end user enters them. If the end user caches the credentials through the RDC prompt, there is a risk that incorrect credentials might be stored. In this case, the incorrect credentials must be deleted in the Windows Credential Manager.

The Windows Credential Manager

Stored credentials are found in the Credential Manager control panel item on the Windows 7 host. When passwords fall out of sync, one of the first steps will be to remove any stored credentials in this item. Look for credentials beginning with the TERMSRV prefix. While caching the end user’s credentials provides the best user experience, it does pose some risks. When credential caching is enabled, the end user’s domain credential is stored in a reversible format within the Windows Credential Manager. As a result, an attacker could write a tool that runs as either a system level process or an end user process and that retrieves the end user’s credentials. You can only lessen this risk by setting DisablePasswordSaving to Enabled. This same concern exists when MED-V authentication is disabled but the Terminal Services policy setting is enabled.

 

Password Expiration

By default, the MED-V installation sets a registry key in the guest to suppress the “password about to expire” prompt. The end user is only prompted for a password change on the host. Credentials that are updated on the host are passed to the guest.

If you use Group Policy in your environment, know that it can override the registry key causing the password prompts from the guest to reappear.

Username Hints

Username Hints for connections to the MED-V workspaces will also be stored on the host. If credentials are prompting and your policies do not allow for any credential caching, you still will have username hints. They can be purged by removing them from HKEY_CURRENTUSERSoftwareMicrosoftVirtual PCServers.

Split Domain Authentication

It is not recommended to use Split Domain Authentication scenarios for MED-V v2. This is a scenario where both the user name and user domain credentials differ between workspace and host. This also includes a local authentication to either the host or workspace.  To verify the user name and domain for the MED-V workspace, launch a published command prompt and run the following commands:

Echo %USERDOMAIN%%USERNAME%

Workspace Virtual PC’s joined to Different Domain

Scenarios where the workspace operating system is joined to a different domain than the host computer are not supported.

MED-V 1.0: How to Correct Auto-logon Errors with Revertible Workspaces

A requirement of using revertible workspaces in MED-V 1.0 is to have auto-logon enabled. Otherwise, you will get the following error when trying to start the workspace:

“Failed to start the Workspace, because auto-logon must be enabled when a revertible machine is started.”

You will get this if either of the following registry values are set incorrectly or not set in the registry in the guest operating system:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

AutoAdminlogon – Must be set to 1.

DefaultUsername – Must be correct

DefaultPassword – Must be correct

Correcting this using the VM pre-requisite tool is recommended. Then you can pack the image as a new version. Please note that if you are using pre-staged Images, It will not download the new image. You will need to delete the local cache before it pulls down the next version of the image. Saving a V1 and V2 in the same Pre-staged folder will always cause the most recent version to be used.

MED-V v1.0: Virtual PC Engine Crashes

When you attempt to start a MED-V 1.0 workspace using a test image or a deployed image, the Virtual PC engine may crash and generate a Fault Report using Windows Error Reporting. Subsequently, the MED-V Workspace will fail to start.

The Virtual PC engine crash will show the following fault:

{virtual pc.exe, 6.0.210.0, unknown, 0.0.0.0, ffff08ef}

You will also see the following event in the Application Event Log:

Log Name: Application
Source: MED-V Workspace
Date: 9/22/2009 12:24:30 PM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: CSS-W013
Description:

The following information was included with the event:

Failed intializing the service log: System.TimeoutException: Timed out waiting for the shared memroy client to initialize
at Kidaro.Foundation.Log.PrettyLogProxy.InitializeSharedMemoryClient()
at Kidaro.Foundation.Log.PrettyLogProxy.Start()
at Kidaro.Workspaces.Service.WorkspaceService.ServiceStartThread()

Failed intializing the service log: System.TimeoutException: Timed out waiting for the shared memroy client to initialize
at Kidaro.Foundation.Log.PrettyLogProxy.InitializeSharedMemoryClient()
at Kidaro.Foundation.Log.PrettyLogProxy.Start()
at Kidaro.Workspaces.Service.WorkspaceService.ServiceStartThread()

Cause

This can happen if the MED-V Workspace (the workspace installation) binaries have been installed along with the client on the physical host machine. The MED-V workspace installer should only be run inside the virtual machine being used to create the workspace.

To resolve this issue, please do the following:

1.) Uninstall both the MED-V Workspace and the MED-V Client.

2.) Reinstall the MED-V Client.

MED-V 1.0: Single Sign-on (SSO) fails even though it is properly set in the Workspace Policy

MED-V offers a feature where persistent workspaces can leverage a host machine or domain account for single sign-on. This property is enabled only when Workspace is persistent is selected.

When you configure Single Sign-on for a workspace policy in the MED-V management console (per guidelines specified here: http://technet.microsoft.com/en-us/library/ee348992.aspx) you may find that the workspace will either:

– Logon automatically using the local administrator account.

or

– Prompt for a local login inside a Virtual Machine Window (especially if domain joined).

This can be caused by one of the following:

– A failure to either set the VM setup script’s “Join Domain” component properly in the management console.

– A failure to join the domain due to an underlying issue

– Not including the “Disable Auto-login” component as the last step in the VM setup script.

If this is happening you will need to verify the following:

– If the “Join Domain” option is not included, please add it per the guidelines in the following link: http://technet.microsoft.com/en-us/library/ee348997.aspx

– If there is a failure to join the domain or connect to the domain, it is best to check the System Event Log in the workspace’s guest OS. There are several ways to access this event log from MED-V. A common way is to publish the Start Menu or a Command Prompt (CMD.EXE) within the workspace policy and launch the Event Viewer directly. Refer to the following link for publishing applications: http://technet.microsoft.com/en-us/library/ee348923.aspx

– The “Disable Auto-login” component should be added as the last step in the VM setup script following the “Join Domain” component.

MED-V Version 1.0: Issue with Double-single (smart) Quotes and Their Use in a MED-V Workspace Policy

MED-V Version 1.0: Issue with Double-single (smart) Quotes and Their Use in a MED-V Workspace Policy

When you go to test or deploy a MED-V v1.0 workspace, you find that published applications do not work. Path appears not to be correct according to the error even though you have specified the path correctly in the MED-V Management Console.
This is an uncommon, but sporadic issue that occurs when copying and pasting quotation marks from Microsoft Word or some other application that uses “smart quotes” will cause published applications in MED-V to fail.

For example:

If you are copying the following from Microsoft Outlook or Microsoft Word:

“C:\Program Files\Internet Explorer\iexplore.exe”

And pasting it directly into the published applications tab in the MED-V Management Console, you may get an error (as well as an incorrect icon) when testing the deployed workspace.

You should always type in the application path or copy and paste from a text editor such as Notepad.

MED-V 1.0: Workspace Fails to Start with “Adjusting VM Window” Message

Has this ever happened to you?

You receive the following error when attempting to launch a MED-V workspace.

“Failed to start Workspace ‘Workspace_name’

“Starting the session failed in the following phase: Adjusting VM Window.”

This issue can arise if there is a dialog box triggered from Virtual PC. This issue has been seen happening with first-time deployments that also involve first time launching of the Virtual PC engine.

A common specific cause of this is found on Windows Vista and Windows 7 where their is an underlying firewall alert that does not appear within regular user contexts but will display immediately with an administrative account. You will see the following message:

“Windows Firewall has blocked some features of this program”

“Windows Firewall has blocked some features of Virtual PC 2007 SP1 on all public, private, and domain networks.”

If you find that when starting the workspace from an Administrative account you get this error, you can enable firewall exemptions for the Virtual PC 2007 SP1 program through the Windows Security Alert dialog box. Once this has been done, a re-attempt of the workspace launch should not get this error again.

A more proactive approach would be to push these firewall exemption rules down via group policy or pre-launch the Virtual PC Console on the workstation as an Administrator and that will also trigger this alert.

MED-V 1.0 SP1: “No MED-V Workspace is defined” error post upgrade to SP1

I have been continuing to point out little nuances that occur when upgrading MED-V 1.0 RTM clients to SP1. These are usually few and far between. One particular client issue you may run into deals with immediate workspace use post-upgrade. After upgrading from MED-V 1.0 to MED-V 1.0 SP1 using the client upgrade installation (.MSP file) you may get the following error after upgrade:

“No MED-V Workspace is Defined” or “No MED-V Workspace has been defined for the current user.”

This is a known issue with the upgrade. The only option for mitigation is to either reboot the host workstation or close the MED-V client by completely logging out of Windows and logging back on and restarting the client.