Daniele Tosatto

After sequencing RSSOwl 2.x with Microsoft Application Virtualization (App-V) you may be able to launch RSSOWL during the monitoring and the launch phase, however after the second launch (and subsequent launches) the application fails to start with an application-specific error:

“There are no more files”

Cause

This occurs due to a sharing violation with the initial configuration file and the directory which needs to be opened for Read/Write access.

Resolution

1. Add an exclusion for %CSIDL_PROFILE%\.rssowl2\ prior to monitoring. You can do this by going to “Tools” and then “Options” in the sequencer. Then click the “Exclusion Items” tab.

2. During sequencing, let RSSOwl launch after it finishes installing during the monitoring phase. Then click through (skip) the Launch window. This will ensure all user settings do not get capture and get regenerated for new users and get properly routed to their profile *.PKG files.

You may run into an unusual issue when running a virtualized sequence of Cygwin under Microsoft Application Virtualization (App-V).  The application will sequence correctly and launch both during the Monitoring phase and the Launch phase, however when you attempt to launch the application in any deployment context you will get the following error:

The Application Virtualization Client could not launch Cygwin Bash Shell 1.0.

An unexpected error occurred. Report the following error code to your System Administrator.

Error code: 46027C5-16D1190A-0000E01E

Cause

While this error indicates that the sequenced application package might be corrupt, simply re-sequencing the package alone will not resolve the issue. The issue is tied to the fact the environment’s working directory must be initiated under a modifiable file system context.

In the case of the Cygwin Bash Shell, it will create a directory under <MNT>\Cygwin\Home\ for the username (which will then get redirected to the PKG file once sequenced properly.)

Resolution

There are two ways to successfully sequence Cygwin:

Prior to Sequencing, create an exclusion for the Sequencing Drive and the Cygwin home directory. If you are sequencing to Q:, you would add in the following path:

Q:\cygwin.001\cygwin\home

(This assumes you are sequencing to Cygwin.001 as the mount and the install directory is Q:\c ygwin.001\cygwin)

If you want to modify the package, you will need to Edit the package and under files, change the attributes for the Q:\<MNT>\Cygwin\home path to de=select override and change the type to “User Data.”

How do you decide between virtual desktop infrastructure (VDI) and session virtualization? And if you have already successfully deployed session virtualization, should you replace it with VDI?

Session virtualization is a centralized desktop computing architecture where multiple users share a single operating system and application image within individual sessions on a Windows Server host. Some key benefits of this architecture are streamlined desktop management, flexible access, and simplified regulatory compliance, all realized by routing the end users to a single desktop image in the datacenter. This sounds a lot like the promise of VDI, specifically of what some vendors, including Microsoft, refer to as (virtual) desktop pools.

This one-to-many relationship between a (more or less) static desktop image and a user population is possible today both with identically configured virtual desktop pools and with session virtualization. Both approaches make the most sense when personalization of the desktop or administrative access to the desktop is not critical for the user’s tasks, or not desirable from an IT support standpoint. This is often the case with so-called task workers, where high user productivity and providing users with a consistent and appropriate user experience specific to their task are important. So which technology—VDI with virtual desktop pools or session virtualization—should a customer deploy? The white paper that Microsoft recently published, Achieving Business Value through Microsoft VDI Together with Session Virtualization, provides you with some criteria to consider in your decision.

Now, what about “personal” virtual desktops: virtual desktops that are dedicated to specific users? What about those customers who deploy a combination of VDI and session virtualization? Well, with desktop virtualization, it always comes down to the use case and the worker profile you are targeting; there is really no one size fits all, and the white paper will actually provide some good, common sense guidance there as well.

The main point is that with Remote Desktop Services you don’t have to choose a single model. Remote Desktop Services in Windows Server 2008 R2 provides customers with a comprehensive platform to explore and deploy these different scenarios, while a whole ecosystem of Remote Desktop Services software and hardware partners provides powerful solutions designed to meet a much broader set of customer requirements. For example, while you could deploy Microsoft’s inbox solution for virtual desktop pools on its own in low complexity environments, environments with higher complexity scale virtual desktop pools on top of Hyper-V should be implemented in conjunction with partner solutions such as Citrix XenDesktop.

If you haven’t already done so, I suggest that you download the beta of Windows Server 2008 R2 SP1, and familiarize yourself with the new virtualization capabilities in it. And make sure you give our partners’ solutions consideration as well, as they will undoubtedly make your life easier as you try and scale up your planned server-hosted desktop environment. As you conduct your evaluation, remember that there is no one-size-fits-all solution. Sessions scale, while personal virtual desktops let you give your users more control. Use your own needs—not the limitations of a technology—to decide which model(s) fit(s) your business best.

Microsoft published a new Application Virtualization (App-V) Knowledge Base article .  If you’re having trouble running virtualized apps on your clients and getting something along the lines of Error Code: xxxxxxx-xxxxxx2A-00002AF9 then you’ll want to check this one out:

Symptoms

An application on an App-V client fails to launch with the following error:

The Application Virtualization Client could not launch application name.
No such host is known.
Error Code: xxxxxxx-xxxxxx2A-00002AF9

Cause

This issue can occur if the server name specified in the HREF attribute in the application .osd file is incorrect.

Resolution

To resolve this issue, perform the following steps:

1. On the App-V Management Server, open the application .osd file and scroll down to the following line:

<CODEBASE HREF=”rtsp://servername:554/ApplicationDirectory/Application.sft”

2. Verify that the server name specified in the HREF attribute is correct.

Example: If the App-V Management Server name is Appv-Svr, the HREF attribute should look like the example below:

<CODEBASE HREF=”rtsp://Appv-Svr:554/ApplicationDirectory/Application.sft”

3. Once the sever name is corrected in the application .osd file, open the Application Virtualization Client MMC snap-in on the App-V client and refresh the Publishing Server.

4. Launch the application on the App-V client.

For the latest version of this information please see the following new Knowledge Base article:

KB2271253 – A virtualized application on a Microsoft App-V client fails to launch with Error Code: 2A-00002AF9

The Remote Desktop Services Component Architecture Poster is available in PDF format on the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=200520).

This poster provides a visual reference for understanding key Remote Desktop Services technologies in Windows Server 2008 R2. It explains the functions and roles of Remote Desktop Session Host, Remote Desktop Virtualization Host, Remote Desktop Connection Broker, Remote Desktop Web Access, Remote Desktop Gateway, and Remote Desktop Licensing and RemoteFX.

Microsoft published a new Knowledge Base article that documents the supported command line options for the Microsoft App-V 4.5 Management Server. If you want to check it out see the following link:

KB2384955 – Supported command line options for the Microsoft App-V 4.5 Management Server installer.

When streaming a Microsoft App-V package with Configuration Manager 2007, you can experiencing issue “0A-400000C8″.  If you set the advertisement to “Stream virtual applications from distribution point” then it would fail, but if you set the advertisement to “Download content from distribution point and run locally” then everything worked just fine.  When the application failed it would generate a 0A-400000C8 error similar to the one below:

You can receive this error when you have a proxy configured that is interfering with the streaming of the package.  Since streaming uses HTTP and downloading does not, this is why one worked and the other didn’t.

When ForeFront TMG Web Proxy Server is in place, the problem is caused by the malware inspection feature .

If you are using Forefront TMG be sure to add the SCCM (streaming enabled) Distribution Point to the Malware Destination Exceptions.

You wont see this error with Application Virtualization Management Server when using RTSP or RTSPS as streaming protocol.
You wont see it even with SCCM if “Download content from distribution point and run locally” is selected because this uses BITS to transfer the whole package to the client and run it locally. Since SCCM uses HTTP/HTTPS for streaming the connection will go to the proxy server and will be killed by Malware Inspection.

If you see “an unexpected error” with the Error Code like: 0A-400000C8 try to disable the Proxy on the Clients for further research.

Microsoft Update/WSUS will not offer the App-V 4.5 SP2 update if you do not have Microsoft Application Error Reporting installed on the Microsoft Application Virtualization client.

To install Microsoft Application Error Reporting, follow these steps:

1. Locate the Microsoft Application Error Reporting install program, dw20shared.msi, which can be found in the \Support\Watson folder on the MDOP release media.

2. To install the software, run the following command:

msiexec /i dw20shared.msi APPGUID={ValueFromTableBelow} REBOOT=Suppress REINSTALL=ALL REINSTALLMODE=vomus

Note If you need to find the product code, you can use the Orca.exe database editor or a similar tool to examine Windows Installer files to find the value of the ProductCode property. For more information about using Orca.exe, visit the following Microsoft website:

http://go.microsoft.com/fwlink/?LinkId=150008

The RD Gateway Capacity Planning in Windows Server 2008 R2 is now available on the Microsoft download center.  This document contains scalability results, testing methodologies, analysis, and guidelines for RD Gateway. It describes the most relevant factors that influence the capacity of a given deployment, methodologies to evaluate capacity for specific deployments, and a set of experimental results for different combinations of usage scenarios and hardware configurations.

The Remote Desktop Services Migration Guide is now live on TechNet.  This document provides guidance for migrating the Remote Desktop Services role services in Windows Server® 2008 R2 and for Terminal Services in Windows Server 2008 to Remote Desktop Services in Windows Server 2008 R2.

This migration guide contains step-by-step instructions for migrating the following role services:

• Remote Desktop Session Host (RD Session Host)
• Remote Desktop Virtualization Host (RD Virtualization Host)
• Remote Desktop Connection Broker (RD Connection Broker)
• Remote Desktop Web Access (RD Web Access)
• Remote Desktop Licensing (RD Licensing)
• Remote Desktop Gateway (RD Gateway)

The migration guide provides an overview of the Remote Desktop Services migration and what will be migrated for Remote Desktop Services role services, tasks that apply to migrating all the role services, and the migration process.