Archive
MED-V: The Case of the Unresponsive Word Window
I recently resolved a long standing issue that affected legacy web applications running inside a MED-V 2.0 workspace. Often web applications will trigger documents and other objects that will launch within their respective host application either through an instance of that application via COM or through a special control via ActiveX (like PDF documents.)
On more than one occasion involving one or more application the parent windowed application (usually a legacy version of Internet Explorer) will trigger an application to launch containing critical data sent to that application by way of the web application. Usually this followed a Java process that would crunch some data and then generate a document object, populate the data and then launch the form from within Microsoft Word. What was happening in every case of this issue was – the Word Window never displayed when running inside a MED-V workspace.
Make sure the problem is not resolved with the super-secret hotfix.
First of all, if you are experiencing the occasional disappearing window, there was an out of band hotfix for the Windows XP RDPShell that addressed disappearing windows. You can call up Microsoft support and request this hotfix by its name (KB2446473.) However, this only addresses a flaw in the RDPShell and did not likely apply in the cases I mentioned above because these problems were not intermittent. They were very consistent and could be reproduced consistently.
Tracking it down . . .
Running the workspace in full screen mode never exhibited the issue. This issue only occurred when running in the seamless mode of MED-V. Launching a parallel command prompt in the workspace and running tlist.exe revealed that the WINWORD.EXE process was running so the application was not crashing. Killing the MEDVGUEST.EXE process from a command prompt prior to attempting to reproduce the problem caused the issue to go away as well. This led to me down the path of investigating what was really going on. The active Word window was being sent behind the browser window and was not being brought to the foreground for the RAIL mechanism used by MED-V to display the active window. Further debugging revealed LockSetForegroundWindow as a common denominator. Some research into the SetForegroundWindow function (http://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx) and/or LockSetForegroundWindow function (http://msdn.microsoft.com/en-us/library/ms633532(VS.85).aspx) yielded a way to control this.
- HKEY_CURRENT_USER\Control Panel\Desktop
- Value: ForegroundLockTimeout
- Data Type: DWORD
Reference: http://technet.microsoft.com/en-us/library/cc957208.aspx
If the time required to launch the Word application window is less than the value specified in the ForegroundLockTimeout, the application will be launched behind the Internet Explorer window.
If the time taken to load the Word window is greater than the time set in ForegroundLockTimeout registry key, the window will be launched on top of Internet Explorer. Setting this value inside the workspace to 0 resolved the issue.
While this may likely resolve all instances of this type of problem bear in mind that I also learned that if the base priority of Internet Explorer is higher than the Microsoft Word window, it will still be launched behind the Internet Explorer window to avoid active window focus change.
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.
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”
MED-V: More Detail on Full-Screen vs. Seamless Mode
I recently had a customer inquire further as to how the mechanics differ between all of the application modes in MED-V. I would have thought this far into the life cycle of MED-V that I had gone into enough detail on the subject. Turns out, while the article I wrote on TechNet a couple of years back (http://blogs.technet.com/b/medv/archive/2011/06/02/med-v-v2-why-would-an-application-fail-in-seamless-mode-when-it-succeeded-in-full-desktop-mode.aspx) gave a good high-level explanation, more clarification is needed.
So in addition to the information I laid out back in 2011, I’ve done some more diving into RAIL (Remote Applications Installed Locally) the inline VPC implementation of TSRemoteApp (now called RemoteApp) where the RemoteApp Server component was ported to Windows XP for the guest integration.
First of there are actually two “full-screen” modes in MED-V 2. One involves starting full screen mode from either the MED-V toolkit or using the command MEDVHOST /fullscreen to launch the workspace in full screen mode with the MEDV Guest services and agents still engaged. If you were to access the Virtual PC out of band using the VPC Window or by double-clicking on the .VMCX file, you would get the warning message about another user being logged on (see http://blogs.technet.com/b/medv/archive/2011/08/24/med-v-v2-strange-message-lt-virtual-pc-name-gt-was-closed-with-a-user-logged-on.aspx)
I outlined the basics of the differences in this high-level chart:
RDPINIT/RDPShell and Active Setup
In addition to items that depend on Explorer.exe such as Login Scripts, Active Setup also does not run. You may can get around this by leveraging group policies and the RUNONCE.EXE command. You can specify the startup applications as a part of a user’s logon settings in Group Policy. Because Group Policy controls these settings, any startup application that you specify runs as expected when the user logs on. To specify the startup applications as a part of a user’s logon settings, follow these steps:
1. In the server Group Policy Management Console (GPMC), select the GPO (that applies to the GUEST OS [XP]) and edit.
2. Click Computer Configuration, and then click Administrative Templates.
3. Click System, double-click Logon and then double-click Run these programs at user logon.
4. In the Run these programs at user logon Properties dialog box, click Enable.
5.Click Show, and then click Add.
6.Type the name of the startup application – runonce.exe /AlternateShellStartup (must include the argument)
7.Click OK two times.
One Final Note on Termination
When a Remote Application is terminated, the process on the XP Guest that is associated with the application is terminated. However, the RDP session remains in a disconnected state until is reset by an administrator. This behavior can be modified by using the group policy “Set time limit for logoff of remote app sessions.”
Any other processes that should be terminated when the Remote Application is terminated can be specified in the following Registry key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs
This is a registry key that the RDP RAIL Shell uses to filter out “system” processes (in addition to rdpshell.exe and rdpinit.exe). Processes configured via this key are ignored by the RAIL Shell. In addition, they will be terminated upon exiting of the RDP session.
A process can be added by adding a REG_DWORD value with a name of the process and a value of 0x0. The following is a list of processes that are terminated by default when a Remote Application ends.
Clipsrv.exe Conime.exe Ctfmon.xe Dwm.exe Imepadsv.exe
Lmsvcs.exe Msgsvc.exe Nddeagnt.exe Netdde.exe Netstrs.exe
Os2srv.exe Proquota.xe Rdpclip.exe Screg.exe Taskeng.exe
Wfshell.exe Win.com
Holy Massive Cloud Software/Resource Release Batman!!
So, Microsoft had a bunch of new releases this week! Windows 8.1, Windows Server 2012 R2, a Bing Facelift. With all that has been going on in the past couple of weeks, it easy to miss something. For those of us who live in the world of virtualization and cloud, some additional (very handy) software and resources have been made available to make our lives much easier in the field.
For starters, we released some well-needed guidance for our VDI folks out there:
Desktop Hosting Reference Architecture Guide
http://www.microsoft.com/en-us/download/details.aspx?id=39285
DaaS (Desktops as a Service) continues to grow – especially in worlds where one-to-many virtual desktops are desired for the reduction of overall density and real estate consumption. In addition, something our internal field engineers have been perfecting over the past few years has also been made public – a performance and optimization guide for the Windows 7 operating system in a virtual desktop (VDI) environment.
Performance Optimization Guidelines for Windows 7 Desktop Virtualization
A Big Release for the BYOD (Bring-your-own-Device) Space, Stronger Security Options for Azure, and Free Stuff!
http://www.microsoft.com/en-us/news/press/2013/oct13/10-07hybridcloudpr.aspx?wt.mc_id=PR_Blog
When you read the above link, you will also learn Microsoft now has Remote Desktop apps for iOS, Mac OS X and Android! Talk about burying the lead! Yes, with the release of Windows Server 2012 R2, we are introducing new Microsoft Remote Desktop end-user applications for iOS, Mac OS X and Android. Just like our modern apps for Windows and Windows RT these provide easy access to virtual machine based desktops, session based desktops and RemoteApp programs, as well as the ability to remote to a PC. With Windows Server 2012 R2 Remote Desktop Services we continue to improve the management and deployment, solutions economics, and end-user experience for virtual desktop and server based computing experiences. In particular, new storage capabilities like tiered storage spaces and online VHD de-dupe dramatically reshape the economics of delivering a remote desktop services solutions. And now these new apps extend a rich Windows experience to a new range of devices.
Except of course WP8 for right now 😦
Azure Updates!
The Windows Azure Multi-Factor Authentication Server (the on-premise version of PhoneFactor) is supported for use with RD Gateway and will function with RDWeb/RDG in an Azure VM, see http://technet.microsoft.com/en-us/library/dn394287.aspx for the most current documentation.
Also there is the Windows Azure Multi-Factor Authentication for Windows Azure Active Directory (http://technet.microsoft.com/en-us/library/jj713614.aspx – the hosted version of PhoneFactor) does not natively integrate with RD Gateway.
Free E-Books from Microsoft!
Finally, a wealth of free books have been released from MS Press revolving around public, private, and hybrid cloud scenarios.
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 v2: Documents Folder Opens up Very Slowly
Chances are if you experiencing this in v2, it is due to the latency of network-based redirected folders for the “My Documents” folder. Either the “My Documents” folder has been redirected to a network drive on a remote server or it has been redirected to the host drive via SMB (UNC path to the host name of the MED-V Client host.) In the case of the latter, even though the drive mapping is to the host, it is using the SMB protocol which is treated like a network redirection.
In previous releases of MED-V, these workarounds were the only way to seamlessly synchronize the documents folder between the host and the guest.
In version 2 of MED-V, instead of leveraging the VPC network stack for folder redirection, it uses the RAIL/RDP method of folder redirection by relocating the guest documents folder to the local host via RDP (\\tsclient\c\etc.) This will drastically improve performance when moving files between the guest and the host. Do not apply group policies for folder redirection to XP workspace or manually redirect the My Documents folder. If integration components and folder redirection was enabled in the underlying VPC configuration, MED-V will automatically provide the RDP-based synchronization between the workspace and host documents folder.
SCVMM: Service Principal Names (SPNs) Required for Proper SCVMM 2008 Functionality
SCVMM 2008, 2008 R2, as well as future versions of SCVMM rely on kerberos and kerberos delegation functionality for its security and authentication model. You may encounter various problems with SCVMM related to authentication and authorization if the underlying platform service principal names (SPNs) are not properly set.
For Virtual Console Support for Hyper-V Hosts (VMCONNECT.EXE) – This will be required on Hyper-V Hosts. Use the following command to set and verify SPNs.
setspn -s "Microsoft Virtual Console Service/HOSTNAME" computername setspn -s "Microsoft Virtual Console Service/hostname.fqdn.etc" computername
For P2V Support.
Use the following command to set and verify SPNs.
setspn -s "Microsoft Virtual System Migration Service/hostname.fqdn.etc" computername setspn -s "Microsoft Virtual System Migration Service/hostname" computername
For VS2005 Hosts and the VMRC utility
– This will be required on Virtual Server 2005 Hosts. Use the following command to set and verify SPNs.
setspn -s vmrc/hostname.fqdn.etc:5900 computername setspn -s vmrc/hostname:5900 computername setspn -s vssrvc/hostname.fqdn.etc computername setspn -s vssrvc/hostname computername
For RDP Support.
Use the following command to set and verify SPNs.
setspn -s TERMSRV/hostname.fqdn.etc computername setspn -s TERMSRV/hostname computername
For all Hosts.
Use the following command to set and verify SPNs.
setspn -s HOST/hostname computername setspn -s HOST/hostname.fqdn.etc computername
HTTP (may needed for authentication on SSP if VMM server is using Remote SQL.)
Use the following command to set and verify SPNs.
setspn -s HTTP/hostname.fqdn.etc computername setspn -s HTTP/hostname computername
SQL VMM Database
Depends on port and instance type:
Named Instance.
Use the following command to set and verify SPNs.
setspn -s MSSQLSvc/hostname.fqdn.etc:Port computername
setspn -s MSSQLSvc/hostname.fqdn.etc:InstanceName computername
Default Instance.
Use the following command to set and verify SPNs.
setspn -s MSSQLSvc/hostname:1433 computername setspn -s MSSQLSvc/hostname.fqdn.etc:1433 computername
Here are some links to some excellent articles:
SCVMM 2008 and 2008 R2: Error when Connecting through VMConnect or RDP: 0x8009030e
You may notice that you may run into problems with credentials going stale when trying to connect to a Virtual Machine from the SCVMM 2008 or SCVMM 2008 R2 console. When this happens, you get the following error when launching VMConnect.exe to connect to the VM:
An authentication error has occured (Code: 0x8009030e)
Remote computer: computername.domain.com
You will also get this error when trying to RDP or connecting through the Hyper-V Management console as well.
The result code 0x8009030e refers to SEC_E_NO_CREDENTIALS in this context or:
“No credentials are available in the security package.”
The security credentials stored by the Hyper-V Host are stale and need to be reset for this particular virtual machines. Other virtual machines may be affected as well but this setting is actually stored on a per-VM basis.
There is no equivalent way to delete existing stale or missing credentials for Hyper-V hosts in SCVMM. This needs to be corrected on the Hyper-V host.
On the Hyper-V Host, open up the Hyper-V Management Console. Select the host, the select “Hyper-V settings”
In the Hyper-V Settings option, under User Credentials, uncheck “Use default credentials automatically”
Connect to the Virtual Machine again, it will prompt to enter username and password.
Enter credentials, check the box “Remember my credentials”.
VMCONNECT and RDP should be successful. Once verified, return to the Hyper-V Settings option, under User Credentials, check “Use default credentials automatically”
madvirtualizer
The Mad Virtualizer at Microsoft 