Archive

Archive for the ‘MED-V’ Category

MED-V: The Case of the Unresponsive Word Window

July 24, 2014 1 comment

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.

Categories: MED-V, VPC Tags: , , , , ,

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

Categories: MED-V, RDS, VPC Tags: , , , , , ,

MED-V: More Detail on Full-Screen vs. Seamless Mode

November 26, 2013 Leave a comment

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:

medv-seamless-vs-fullscreen-vs-vpc

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

 

 

Categories: MED-V, RDS, VPC Tags: , , , , ,

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.

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

February 26, 2013 1 comment

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.

How does each Version of MED-V use Proxies?

September 4, 2012 Leave a comment

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 proxyhttp://technet.microsoft.com/en-us/library/cc731131(WS.10).aspx

Categories: MED-V, VPC Tags: , , ,

MED-V V1 Disaster Recovery


Disaster recovery in MED-V v1 is a very straight-forward and seamless process. Offline access is available for those clients who have already cached their MED-V client authentications. One of the first steps in ensuring a good disaster recovery plan for this version of MED-V is to establish continuity through offline access. This will assume all images that the users need will have been downloaded. Information on MED-V v1 credentials and offline access can be found here:

http://blogs.technet.com/b/medv/archive/2010/09/22/med-v-v1-connection-settings-and-credential-management.aspx

For the MED-V server, since the configuration is all XML-based, the process for backing up crucial data is very easy and does not even require a system state backup. In my MED-V v1 environments, I simply backup the XML configuration, the reporting database, and the server-side images. This process is outlined in the following article:

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

The article is pretty straightforward on the key locations for images and configuration:

\Med-V\Med-V Server Images

\Program Files\Microsoft Enterprise Desktop\Servers\ConfigurationServer

It also goes through the restoration process which is just as straight forward. The article does not mention the reporting database. While true, reporting is an option in MED-V V1 and is not required for the server to be operational, most organizations still using MED-V v1 are making use of the reporting database. If the database is locally available on the MED-V server (i.e. though SQL Server Express) please ensure that you are backing up the database (defaults to “medv”) manually using SQL Management Studio Express or through whatever means your database administrators backup databases.

– Steve Thomas

Categories: MED-V, Virtualization, VPC Tags: , , ,