Are you still Using MED-V? If so, do NOT install this update

If you are currently still running MED-V 2.0, be very aware of a known issue. If you install the RDP/RDC 8.1 update for Windows 7 SP1, you may notice after installing the update, you are seeing application crashes of the MED-V Workspace. This update is labeled KB2830477. It was originally released last year and there were sporadic reports of problems with MED-V hosts running it. It has recently been re-released (February 11, 2014) and I have noticed many more reports of this occurring. This issue has been reported for both XP Mode and MED-V in the Technet forums as well.

http://social.technet.microsoft.com/Forums/windows/en-US/ffe5c710-9fb1-4540-9d85-9d76e3a79846/kb2830477-causes-problems-in-wn7-x64-and-xp-mode?forum=w7itprovirt

Right now, there is an investigation ongoing. I would advise in the meantime that you do not install this update on MED-V hosts. If you have already installed this update on MED-V hosts and are experiencing the problem, you can simply uninstall the update and the issues should disappear.

Please note that this is an optional update. This update is not needed for MED-V or Windows 7 functionality. It is not a security update either. It may provide enhanced features if you need to connect your Windows 7 host to Windows Server 2012 or Windows Server 2012 R2-based RDP Sessions or RemoteApps.

Here is the subsequent KB article on the update:

KB2830477: “Update for RemoteApp and Desktop Connections feature is available for Windows”

http://support.microsoft.com/kb/2830477/en-us

Why is it important to Become Familiar with WMI Troubleshooting? Pt. 1

Often in Virtualization and Management Products like SCVMM, MED-V, Config Manager, UE-V, and App-V the symptom of an issue appears in the respective System Center or MDOP product but the root cause is often caused by an anomaly in an underlying operating system component. Often that component is WMI. For this reason, it is invaluable have a solid understanding of WMI and WMI troubleshooting. WMI is often a component that can cause problems due to one or more of the following WMI issues:

• Corrupted repository
• Incomplete namespace
• Access Denied
• Invalid String in WMI property/data
• Unexpected value
• Memory leak
• Code Defect by WMI Provider

One of the most common errors encountered is error 0x800706BA – RPC Server Unavailable.

This error has context. If it is during connecting to a WMI namespace, it is usually because:

• The machine does not exist.
• The machine cannot respond because the appropriate firewall exceptions have not been made. Check firewall settings.

If it is during operation, it is likely because:

• The client machine doesn’t have correct firewall settings for asynchronous call backs.
• Connecting to a machine which doesn’t exist.

First I would verify the firewall rules. I would make sure the following rules are set:

• WMI (ASync) Properties – In Program: %SYSTEMROOT%\System32\WBEM\unsecapp.exe
• WMI (DCOM) – In Port: TCP 135 Program: %SYSTEMROOT%\System32\svchost.exe
• WMI (WMI) In-Out Program: %SYSTEMROOT%\System32\svchost.exe

I deal with WMI problems all the time. I generally follow this little troubleshooting checklist for RPC errors:

1. Use the WMI Control MMC (WMIC.MSC) to ensure that the service is working on the local system.
2. If the problem involves communicating with a remote system then use the WMI Control to test the ability to connect to the remote system
3. For Access Denied type issues verify that the DCOM and WMI Service settings are at default values, and the Network Service account has been granted impersonation rights.
4. Check the service settings if the WMI service fails to start or if client programs cannot communicate with the service. In some cases you may need to reregister all the modules to recover the service.

Here’s a Short Blog with a very Important Message (T-MINUS LESS THAN 6 MONTHS)

Early last year I wrote a blog specifying how MED-V does NOT affect the Windows XP EOL Support issue: http://blogs.technet.com/b/gladiatormsft/archive/2012/07/30/how-med-v-affects-windows-xp-end-of-life-support-policy-it-doesn-t.aspx 

Little did I know how widely pulicized this would be (re: quoted in The Register and others – http://www.theregister.co.uk/2012/08/01/windows_xp_medv_no_go/)

Today’s a good reminder for all that we are now within six months. If you are looking to start a Windows XP migration please be advised that if the purpose of migration is to avoid unsupported or expensive custom extended support agreements, then MED-V will not resolve these concerns. Everything in that article is still valid. If you are still on XP, please feel free to comment on what your migration blockers are below. Are you being held back by a legacy LOB app or is it an Internet Explorer 6 issue?

MED-V V1: How to Update the Policy Update\Polling Interval

Within MED-V V1, you can modify the default policy interval by modifying one of the XML files on the client. While the official documentation alludes to this:

“A typical MED-V Management Server can support 5000 users based on the recommended hardware configuration. The client-server communication is lightweight: clients are normally configured to poll the server for policy every 15 minutes, and image updates every 4 hours (Can be changed using MED-V configuration)”

What is does not state is how exactly you change the policy update interval from the default interval of 15 minutes.

To modify the Policy Update Interval, this would have to be done on the client side. You can do this by editing the Configuration.XML located in %ALLUSERSPROFILE%\MED-V\Local\Config

The value is UpdaterTimeInterval and it is found under the element as displayed in the example below:

<Configuration>
<SpecialFileProcessor>
<WorkspaceKeys type="System.String">Kidaro.KeysStorage.KeysConfigurationFileProcessor</WorkspaceKeys>
<ClientPolicy type="System.String">Kidaro.Policy.Server.PolicyFileProcessor</ClientPolicy>
</SpecialFileProcessor>
<!-- Should the service update the configuration from the server. -->
<EnableServer type="System.Boolean">true</EnableServer>
<!-- Time interval in seconds between updates of configuration files. -->
<UpdaterTimeInterval type="System.Int32">900</UpdaterTimeInterval>
</Configuration>

Increase the default UpdaterTimeInterval value of 900 (15 minutes in seconds) to desired interval then save the file and restart the MED-V Client service.

MED-V: To Cache Credentials or to not Cache Credentials (Ramifications of Disabling “DisablePasswordSaving” vs. Enabling it)

How’s that for a double negative? Disabling the disabling of password saving. In essence, allowing users to cache/save passwords for SSO (single-sign-on) when authenticating to MED-V workspaces. In MED-V, if the credentials do not match, or you do not check the box to have your credentials
remembered, you are presented with the standard RDP prompt for access to the virtual machine.

This is not to be confused with the initial MED-V prompt for authentication (first appearing during first-time-setup) which looks like this: 

Both RDP and MED-V can allow for the caching of credentials, however, while MED-V only temporarily caches credentials in memory, RDP will cache using the Credential Manager. The MED-V authentication mirrors that of RDP in that the Windows 7 host is connecting via RDP to the Windows XP virtual
machine. Depending on how you have configured MED-V settings for authentication, the end user is typically prompted at some point to enter their password, either the first time MED-V is started or the first time that they try to open a published application. If LogonStartEnabled has been configured,
it will happen when MED-V starts in the user session. Otherwise, it will occur when you first launch a published MED-V application. Caching credentials seems like it would make sense as it does improve the user experience, but there are trade-offs.

Unintended Inconvenience

• If the user accidentally mistypes their credentials in the logon dialog and specifies to cache them, the incorrect credentials are saved and the user will be prompted to re-enter their credentials each time the VM is started or resumed. This state will persist until the user credentials are manually cleared.
• If the user selects to cache their password and later the password expires or credentials domain name has been renamed, the user will be prompted to re-enter their credentials each time the VM is started or resumed until the cached password is cleared.

MED-V has a special credential manager that helps to avoid the above inconvenience. It allows you to control aspects of credential caching including:

• Whether the credentials the end user enters are stored in Credential Manager.
• In what manner the end user is presented with the option of entering and saving their password. For example, if MED-V is configured to start when the end user logs on to the host but Authentication is disabled, the end user is only prompted one time during logon. In this case, credentials are valid until the end user logs off from the host. If it is necessary, you can use Credential Manager to remove any stored end-user credentials. By default, credential storing is disabled, but you can change this setting either before or after workspace deployment.

Pre MED-V Workspace Deployment

While you are creating the MED-V workspace package, you can modify the PowerShell (though the New-MedvConfiguration cmdlet) by setting the UxCredentialCachingEnabled to either 1 or 0. This simply tells MED-V whether or not the “Remember My Credentials” will be in place for MED-V FTS and RDP
authentication prompts.

After MED-V Workspace Deployment

The MED-V Credential component cannot override the Group policy Remote Desktop Connection Client “Do not allow passwords to be saved” value. This is represented in the registry by the DisablePasswordSaving value. One way you can set this post-deployment is by  modifying this policy. This policy controls whether the password saving check box appears on the RDP client dialog window and whether the MED-V credential prompt is displayed.

My favorite way of disengaging credential caching altogether is by changing the UxCredentialCacheEnabled in WMI to FALSE.

The WMIC command easily can do this:

WMIC /namespace:\rootMicrosoftMedv PATH setting set uxCredentialCacheEnabled=FALSE

After that, the option to save the password will no longer be available:

 

 

If you also want to manually leverage the RDP policy to DisablePasswordSaving, you can do so by going to the following registry key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftVirtual MachinePoliciesDisablePasswordSaving 

Play it Safe

While users prefer caching the credentials to avoid retyping in the credentials, there are risks associated with doing so.  When credential caching is enabled, the end user’s password is stored in a reversible format through CredMan (the Windows Credential Manager.) This opens up the user to potential issues should a
malicious program somehow get on to that system and is able to run as SYSTEM.  The credentials could then be retrieved. The only way to reduce this exposed surface area is by setting DisablePasswordSaving to Enabled and modifying the UxCredentialCacheEnabled property.

 

 

Running a MED-V application that depends on presence may not properly show presence when hovering over it in the System Tray

Let’s review some basic information about how MED-V: The way MED-V V2 works is the Windows 7 host machine connects to the Guest Virtual PC through an RDP-style connection. This basically turns the Windows XP Virtual PC into a mini-RDP server. This must always be in the back of your mind while you test your applications under a MED-V solution. Leveraging RDP removes the need for a hooking DLL to be injected into the guest OS and cuts down on the overhead of the MED-V Guest Agent.

Since applications that run under MED-V are basically the same to the Windows 7 host as applications running remotely on an RDS or Terminal server, you will encounter specific limitations in cosmetic desktop features. For example, the AeroPeek style thumbnail preview of the remote application will not be visible. Window titles will show an appended (Remote) to differentiate it from the local applications.

In addition to what comes through the remote connections, MED-V will republish (pass along) critical messages that appear in the Windows XP system tray. For example, password expiry notices and update notices from WSUS (or Configuration Manager) will also appear on the local desktop. Applications that publish to the Windows XP System tray in the guest will also appear in the host (with an appended “Remote.”)

One item that is not simply a cosmetic issue that you will need to be aware of when considering MED-V for application remediation are applications that have presence indicators in the system tray. Changes in presence often cause a change in icon or icon color as well as their pop-out status message. While these status icons will appear in the Host system tray, there will be potential issues with changes in user presence updating icons properly.  Applications such as Communicator, Windows Messenger, and Lotus SameTime may not always update/change presence notifications properly when running in a MED-V workspace.

Let’s use the example of a user being signed in initially as “available.” When the use steps away and becomes idle, the system tray icon may not initially reset the icon appearing in the host to “Away” even though the user is away from their desk.

MED-V: How to Customize and Repackage a Workspace using PowerShell

 One of the benefits of MED-V 2 was the introduction of PowerShell to control, manage, and deploy the MED-V workspace. A good example of where PowerShell comes in handy is when you have a workspace that you have already configured and packaged – but now you need to make an adjustment to the configuration for future deployments of that workspace. A walkthrough of how to do this is as follows:

1. Navigate to the directory where the workspace package was created.
2. After making a backup of this directory, notice that you have both a .REG file and a .PS1 file. The .REG file contains the basic configuration. You can use the PS1 file to set advanced settings an regenerate the MED-V workspace.
3. Open the .PS1 file in the integrated script editor. You will notice it looks like the script below:

   import-module -Name “Microsoft.Medv”
   $regFileInfo = New-MedvConfiguration -VmNetworkingMode “BRIDGED” -UxLogonStartEnabled “False” -UxCredentialCacheEnabled “True” -FtsMode “Attended” -VmMultiUserEnabled “False” -FtsAddUserToAdminGroupEnabled “True” -FtsStartDialogMsg “A virtual environment is being created for application compatibility. The first time setup process can take several minutes to complete.” -FtsFailureDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsRetryDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsSetUserDataEnabled “True” -FtsSetJoinDomainEnabled “True” | Export-MedvConfiguration -Path “C:medv2-packagesWindows XP Compatibility.reg” -PassThru
   if ($regFileInfo) #If the .Reg file was created, then create the workspace package
   {
    New-MedvWorkspace -WorkspaceName “Windows XP Compatibility” -VhdFilePath “C:vpcMedv-ws-xp.vhd” -SettingsFilePath “C:medv2-packagesWindows XP Compatibility.reg” -VhdRegPath “C:Program FilesMicrosoft Enterprise Desktop VirtualizationMEDV_InternetZoneHighSecurity.reg,C:Program FilesMicrosoft Enterprise Desktop VirtualizationMEDV_RestrictedBrowsingMode_Apply.reg” | Export-MedvWorkspace -Path “C:medv2-packagesWindows XP Compatibility.msi” -Overwrite
   }

    

Let’s say you wanted to adjust the FtsAddUserToAdminGroupEnabled option and set it to “false.” You could simply make the adjustment in the .PS1 file and repackage the workspace.

You could even add in additional advanced options (Boolean.) For example, if you wanted to disable host guest network printer sharing, you could add an additional parameter to the script to add the –UxPrinterSharingEnabled parameter and set it to “False.” Once you have made the changes, save the new .PS1 file and close the Powershell ISE. By the way, you can use the WMI reference for additional options:

http://technet.microsoft.com/en-us/library/gg548518.aspx

Repackaging a Workspace Using PowerShell.

If you are doing this customization, you will need to re-package the workspace using the PS1 file.

1. Open a PowerShell command prompt as Administrator.
2. Change to the current directory of the of the workspace package.
3. Execute the PS1 file. This will start the process of creating the workspace package with these customized settings. Once the packaging process is complete you can deploy the newly created setup, MSI and workspace package.

Some issues with the MED-V V2 Toolkit and how to Remediate them

I wanted to address some issues that have been seen with the MED-V Toolkit. These are minor/cosmetic issues and can easily be remediated.

MED-V Toolkit Freezing

There is a known issue where the MED-V Administration toolkit freezes when attempting to change the logging level while MED-V first time setup is in progress. This is caused by the MED-V workspace needing to be completely setup before changing the logging levels using the Administration toolkit.  If this happens before FTS completes, allow the MED-V first time setup to complete before changing the MED-V logging levels using the toolkit. If more verbose logging is needed during first time setup for troubleshooting use the registry to set the Event Log Level

• Registry Key: HKEY_LOCAL_MACHINESOFTWAREMicrosoftMedvv2Diagnostics
• Data Type: DWORD
• Value: EventLogLevel

Levels include the following: 0 (None), 1 (Error), 2 (Warning), 3 (Information), 4 (Debug). Default setting is 3.

Wrong icon appears for the MED-V Toolkit

There are cases where the MED-V Administration toolkit will display the wrong icon in the taskbar. Instead of the correct icon, it is the icon of another MED-V application. This happens when MED-V is configured to use Normal Start and an application is used to start MED-V. Whatever application is used to start MED-V is the application ICON that will be shown for the MED-V toolkit or other MED-V related UI.  This is a known product code issue. If this happens, here are some remediation steps to try to alleviate the issue.

1. Change the startup type of MED-V to the default fast start
2. Change the user settings for the taskbar properties to Never combine. Do the following:
3. Right-click the taskbar and then click Properties.
4. In the Taskbar and Start Menu Properties dialog box, click the Taskbar tab.
5. In the drop-down bar for the Taskbar buttons box, select Never combine.
6. Click OK.

How does each Version of MED-V use Proxies?

In Version 1, the MED-V Management Console, will use the IE proxy settings of the current user to connect via HTTP to the MED-V Policy Server. If the proxy server is not configured correctly, it will trigger an Event ID 75 error:

“The MED-V Server is unreachable at <URL> “

Please check your connectivity and try again.

In fact, any operation in the MED-V Management Console (v1) will use the user’s proxy settings including the uploading of images to an image distribution server. For the MED-V Client service and application, it is different in that it uses the system’s proxy configuration for all operations including authentication, policy, and image download.

MED-V Version 2

For MED-V Version 2, there are no images or policies to download. So the likelihood of proxy issues with MED-V agents specifically will likely not be an issue although it is important to point out that Host and guest proxy configurations are not automatically kept in sync by MED-V.

Setting Proxies at the System Level

For Windows XP,  you use the proxycfg command to set system account proxies.

For Windows Vista and Windows 7, you would use the netsh command:

netsh winhttp set proxy – http://technet.microsoft.com/en-us/library/cc731131(WS.10).aspx

Software Update to block RSA keylengths <1024 has been Released to the Download Center

Today (August 14th) an update was released that, once applied, will block RSA certificates with keys less than 1024 bits. The software update was released to the Download Center.

The security advisory is located at http://technet.microsoft.com/security/advisory/2661254.
The KB article is available at http://support.microsoft.com/kb/2661254.
 
The update is available now to allow organizations to assess the impact of this update and to reissue certificates with larger key sizes, if necessary, before the update is sent out through Windows Update. Previous blogs may have mentioned it being released to Windows Update this month. That is no longer the case. The update is planned to be sent out through Windows Update on October 9, 2012.

Please refer to the KB article for direct links to download the update for your supported version of Windows.