Archive for the ‘RDS’ Category

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”

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 (  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

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




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

Is it the “System” that’s really too busy to complete the request or is it App-V?

Chances are, if you have deployed App-V in a large-scale TS/RDS environment, you may have come across this intermittent error message:

Application Virtualization Error – The System is too busy to complete the request.  If the problem persists, please report it to your system administrator

Sometimes it is followed by a specific error code.

Error code 1690140A-200001CD

The error may even follow another error such as:

The Application Virtualization client could not be started. The Application Virtualization Service is not running. Report the following error code to your System Administrator: Error Code: 4602847-0FA10612-00006003.

Normally, when we get messages about the “System” being too busy to complete the request it is misleading. What is really too busy to complete the request is the App-V front end component.

When The SFTTRAY command launches, if it sees another instance of itself running, it tries to pass off whatever it was supposed to do to the existing sfttray process. If it sees that other instance but the handoff times out because the other instance isn’t responsive, it will return with this message. The error message really is telling you that SFTTRAY (or another front end component such as VAPPLAUNCHER or SFTDDE) is unable to complete the request because an App-V client component is too busy to complete the request.

There could be many underlying causes to this resulting from the SFTLIST.EXE (client service) being too busy or even the desktop configuration controller component (SFTDCC.EXE) not being responsive. If this is tied to a global DC refresh, or periodic DC refresh we could have a known issue with SFTDCC not releasing handles.

The 6th Hotfix for 4.6.0 addresses this and is available:

RTSPS Channels

We recently also came across another cause of this issue and it is outlined here:

In this case, the RTSPS protocol was the culprit. RTSPS (RTSP over SSL) is limited to 255 channels and each package takes two channels.  If the total number of channels exceeds this value then the error above is generated. To resolve the issue, decrease the maximum number of channels in use at any given time by scaling out the number of RTSPS servers.

RTSP Scaling

Along that line, even if you are using RTSP, this could also be tied to scaling issues. If your DC/publishing refresh intervals are set to frequently (especially for terminal servers) you may be putting too much of a load on the SFTDCC process. Try reducing the frequency of periodic refreshes and/or increase the number of App-V Management servers for load-balancing purposes.

If you are running Citrix XenApp on a Terminal Server/RDS Server, you could be waiting on another seamless session to logoff. A good thing to verify is that the Citrix WFSHELL process releases SFTDCC properly:

  • On the Citrix server, start Registry Editor.
  • Locate and then click the following registry key:
  • Right-click LogoffCheckSysModules, and then click Modify.
  • In the Value data box, type sftdcc.exe, and then click OK.
    Note If multiple values exist, separate the values by using a comma. For example, use the following format:
  • Exit Registry Editor.

And finally, as always, try to follow the guidelines as recommended in the following KB article (if you are running Windows 2003 x86 – all of them.)
Under the section, “General Terminal Server Recommendations when running the App-V client” some applicability varies depending on the operating system platform and version.

  • “Pre-cache all applications 100%. “(Applies to all operating systems and platforms.)
  • “If you use Windows Server 2003 or older, implement a reboot cycle of the Terminal Servers . . .” (Should not need to do this on Windows Server 2008 and later.)
  • “Implement UPHClean on the Terminal servers.” (not needed on Windows Server 2008 and later.)
  • “Implement the following registry changes and reboot the servers” (Page Pool Memory settings not needed on Server 2008 X64 and later)
  • “Verify that none of the App-V Application packages have following Virtual services if so remove them or set them to disabled.” (Still a good idea for all TS/RDS servers.)

What about the 00006003 error?

Ah yes, I alluded to that earlier. Often when this is happening, a third part filter driver is preventing the App-V Client service (SFTLIST.EXE) from starting. Check for encryption, or storage security-related applications.

Steve Thomas

Categories: App-V, RDS Tags: , , , , , , , , , ,

Additional Considerations for Using App-V With TSRemoteApps

August 1, 2011 4 comments

Some of the most common problems App-V users have when configuring App-V virtualized applications for TSRemoteApps (RemoteApp in RDS) fall into two categories:

1.) Applications not launching properly and/or the incorrect application is launching instead: Do not Use *.ico paths of virtual applications as icon paths. This is outlined in the following documentation:

Even if the App-V packages are distributed to the terminal servers via SCCM, the remote application would still have to be published within the RemoteApp Manager using the following modification:

Location: %SYSTEMDRIVE%\Windows\CCM\VAppLauncher.exe

Command line argument: /launch “App Name”

Like with SFTTRAY, VAPPLAUNCHER will need to locate the EXE or DLL file to map icons so you should not use the .ico file but instead use a .DLL or .EXE for the icon.

2.) File Type Associations will require SFTTRAY and/or VAPPLAUNCHER published separately as a RemoteApp

The reason for this is because published RemoteApps are entered in an “white-list” on the server.

When an application has required command-line parameters, they are also checked. Chances are you will have more than one published virtual application, so you do not want SFTTRAY (or in the case of SCCM integration, VAPPLAUNCHER) limited to that one use. When you associate a file type association with a RemoteApp, that could easily happen. When a document that has an FTA associated with a RemoteApp is opened, the shell API used to launch the document with the RemoteApp does not accept command-line arguments as an input. Instead it just runs the application as it is associated in the registry on the RDS server. When the RDS service performs the white-list check to see whether the executable that will open the document is allowed, it only checks the executable, and not the command-line arguments that will not be used. If SFTTRAY or VAPPLAUNCHER is not published on its own, this will happen.

– Steve Thomas

Microsoft Virtualization Engine and Management Updates

Here are a listing of significant Microsoft management and Virtualization engine downloads and updates at all levels of the stack:

Storage Virtualization:

Microsoft iSCSI Target Software:

iSCSI Software Target is an optional Windows Server component that provides centralized, software-based and hardware-independent iSCSI disk subsystems in storage area networks (SANs).


Microsoft App-V 4.6 Service Pack 1


Windows Server 2008 R2 SP1:

Hyper-V Server 2008 R2 SP1:

Updated Hyper-V Management Tools for Windows 7 SP1 now available

Update to the Hyper Best Practices Analyzer:


SCVMM 2008 R2 SP1:

Updated Configuration Analyzer for SCVMM to include 2008, 2008 R2, and 2008 R2 SP1

Remote Desktop Services Connector for System Center Virtual Machine Manager

Planning for a Microsoft VDI Deployment

April 13, 2011 2 comments

In the past, desktop virtualization administrators have used Microsoft for only part of their VDI (virtual desktop infrastructure) while using solutions from VMWare of Citrix as the primary basis.

You may be already familiar with Microsoft’s client-hosted enterprise desktop virtualization solution – MED-V. VDI is Microsoft’s server-based desktop virtualization solution combining all of the following for engine support all the way to complete end-to-end management:

  • Hyper-V
  • Windows 7
  • Windows Server 2008 R2
  • System Center Virtualization Manager
  • Remote Desktop Services
  • RemoteFX

Windows Server 2008 R2 Service Pack 1 adds two new components (RemoteFX and Dynamic Memory) that fill two holes related to management flexibility and user experience that now make Microsoft almost a non-brainer choice for your VDI solution.

Microsoft’s virtualization main page is found here:

First things first,

Licensing Information regarding VDI. One of the first things customers want to know is what are the costs and the potential cost savings:

In terms of how it works, here is Microsoft’s VDI solution at a high level:

The next items of concern are often what infrastructure changes will need to be made. Moving to a VDI environment will require the presence of a Windows 2008 or Windows 2008 R2 domain controller (depending on the Hyper-V/RDS platform being used.) You will also need to update the schema accordingly to support these domain controllers and subsequent services required for the VDI environment.

Here are the outlines of the Windows 2008 and Windows 2008 R2 Schema changes:

Windows 2008:

Windows 2008 R2:

You will need to have Windows 2008 Schema changes minimally however, the minimum AD domain level supported is Windows 200 native. Windows 200 mixed or Windows 2003 interim are not supported.


The following are important considerations about assigning a personal virtual desktop to a user in AD DS:

  • To deploy personal virtual desktops, your schema for the Active Directory forest must be at least Windows Server 2008. To use the added functionality provided by the Personal Virtual Desktop tab in the User Account Properties dialog box in Active Directory Users and Computers, you must run Active Directory Users and Computers from a computer running Windows Server 2008 R2 or a computer running Windows 7 that has Remote Server Administration Tools (RSAT) installed.
  • You must use a domain functional level of at least Windows 2000 Server native mode. The functional levels Windows 2000 Server mixed mode and Windows Server 2003 interim mode are not supported.
  • Ensure that the RDVH-SRV computer meets the Hyper-V installation prerequisites (
  •  The user account and the virtual machine must both be members of an Active Directory domain.
  • Personal virtual desktops can only use Windows client operating systems. You cannot install Windows Server® 2008 R2 on a virtual machine and assign it as a personal virtual desktop.
  • A user can be assigned only one personal virtual desktop at a time.
  • A virtual machine can be assigned as a personal virtual desktop to only one user at a time.
  • The name of the virtual machine in the Hyper-V Manager tool must match the fully qualified domain name (FQDN) of the computer.

 Sizing Concerns:

Alongside of instructure changes and concerns is capacity planning. Here is a good webcast on planning and sizing session virtualization and bandwidth for VDI:

 And a good document as well:

 RD Web Access Information:

 RD gateway Information:

 Why VDI for Hyper-v Whitepaper:

 Windows 2008 R2 SP1’s RemoteFX feature for Hyper-V

 If you have time, also check out the VDI videos on technet Edge:

Description and Explanation of the “Failed unregistering callback tracking connected process termination” Error 997 in App-V

April 11, 2011 8 comments

Have you ever noticed that periodically you may see the following error in the SFTLOG.TXT and/or the Windows Application event log:

Failed unregistering callback tracking connected process termination (error: 997).

You will also see the following in the Event Log:

Log Name:      Application
Source:        Application Virtualization Client
Event ID:     
Task Category: (3)
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      <name>
Failed unregistering callback tracking connected process termination (error: 997).
Event Xml:
<Event xmlns=”“>
    <Provider Name=”Application Virtualization Client” />
    <EventID Qualifiers=”16384″>3219</EventID>
    <TimeCreated SystemTime=”2010-09-18T19:34:05.000000000Z” />
    <Security />

Here is the following explanation of situations where this event may occur:

When one of the App-V client’s front-end component (i.e. UI or SFTTRAY) connects to the SFT Listener, the Listener opens a process handle to that front-end component, and will call a system API that will automatically monitor for that process handle being signaled (i.e. the process exited), and invoke a callback function in the Listener if that occurs.  If the front-end component disconnected normally, the monitoring of the handle is canceled. It appears to the App-V front end component that when the unregistration of the callback function was tried – in this case, the callback function had already been queued up or was in the process of executing which caused this warning to be reported.

In most cases this message is benign. This will often happen when the SFTDCC processes overlap with publishing refreshes and will also happen often on TS/RDS logoffs – especially with Server 2008 and beyond. You will also see this paired with User Profile Service registry closure events.