This is the final installment in our series of articles about Hype-V security. Thus far, we have looked at how to configure Hyper-V security using Authorization Manager and how to use Hyper-V and Authorization Manager together for maximum security. This article will explain in greater detail how to secure Hyper-V Server and virtual machines using Authorization Manager and best practices. It will focus on Hyper-V security best practices and provide an example of Hyper-V security using Authorization Manager.

Ben Armstrong a.k.a. "Virtual PC Guy" explains which files make up a virtual machine and where virtual machine files are stored.

Consider the following scenario:

• You enable streaming for virtual application packages on a Microsoft System Center Configuration Manager 2007 R2-based computer.
• You are granted the following permissions for the Package class:
  • Read
  • Distribute
  • Delegate
  • Create
  • Manage Folders
• You open the System Center Configuration Manager console.
• You try to create a virtual application package at the following location:

  Computer Management\Software Distribution\Packages

In this scenario, you cannot create the virtual application package. Additionally, you receive the following error message:

User <user> does not have sufficient rights

ErrorCode = 1112017920

If you're using Configuration Manager with your Microsoft Application Virtualization (App-V) packages then you can download the hotfix for this from our new Knowledge Base article below:

KB978755 - Error message when you try to create a virtual application package in System Center Configuration Manager 2007 R2: "User does not have sufficient rights"

J.C. Hornbeck | System Center Knowledge Engineer

Similar to RemoteApp, the RemoteApp for Hyper-V feature allows users to access a specific hosted application remotely, as opposed to the entire desktop. When using RemoteApp, the application runs in the context of a server session; however, RemoteApp for Hyper-V enables remote access to an application running on a Hyper-V virtual machine (VM). That is, this feature allows you to launch applications that are hosted on VMs as remote applications.

This blog outlines setup steps and common troubleshooting tricks for deploying RemoteApp for Hyper-V.

The following are some of the common problems customers may run into when using RTSPS. These are based on specific errors and their likely causes. Please bear in mind that some of these errors may occur under other contexts so understand that the context here is strictly related to RTSP.

Common RTSPS Problem #1:

Users receive the following error on publishing refresh or when trying to stream an application via RTSP:

"The specified Application Virtualization Server has shut down the connection. Try again in a few minutes. If the problem persists, report the following error code to your System Administrator."

"Error Code: xxxxxx-xxxxxx0A-10000009"

This error can occur when one or more of the following conditions are true:

1.) Network Service Account (the account used to authenticate the App-V Server Service does not have access to path to the machine keys:

Location for Windows 2008/R2:

%ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys

Location for Windows Server 2003:

%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys

2.) The Certificate Store lacks the necessary permissions for the NETWORK SERVICE account. When this occurs there will also be an accompanying event in the Application Event Log:

Source: Application Virtualization
Event ID: 44955
Description: Certificate could not be loaded. Error code (-2146893043) Make sure the Network Service account has proper access to the certificate and its corresponding private key file.

When this occurs in Windows Server 2003 as the underlying operating system, you will need to modify the actual certificate store permissions using the WinHttpCertCfg command.

Additional information on using the WinHttpCertCfg.exe tools is available at the link below:

http://msdn.microsoft.com/en-us/library/aa384088(VS.85).aspx

The syntax you will need to use is:

winhttpcertcfg -g -c LOCAL_MACHINE\My -s Name_of_cert -a NetworkService

You can then verify that the security context was properly added by listing the permissions on the certificate using this syntax:

winhttpcertcfg -l -c LOCAL_MACHINE\My -s Name_of_cert

Windows Server 2008 makes the process of changing the ACLs on the private key much easier.  The certificates MMC Snap-in can be used to manage private key permissions. To do so, follow these steps:

1. Create an MMC with the Certificates snap-in that targets the Local Machine certificate store.

2. Expand the MMC down to the certificate you need as shown in the image below and select Manage Private Keys.

3. Use the Security tab to add the Network Service account with Read access.  These instructions are also available in the Security Operations Guide at the following link:

http://technet.microsoft.com/en-us/appvirtualization/cc843994.aspx

http://download.microsoft.com/download/f/7/8/f784a197-73be-48ff-83da-4102c05a6d44/AppV_Secuirty_Operations_Guide.docx

Common RTSPS Problem #2:

Users receive the following error on publishing refresh or when trying to stream an application via RTSP:

"No connection could be made because the target machine actively refused it."

"Error code xxxxxx-xxxxxx2A-0000274D"

This error can happen during publishing/refresh or during streaming. It usually occurs when one or more of the following conditions are true:

• Potential issue with firewall on the server running the App-V Management server or streaming server. Either create and inbound rule that allows RTSPS Port 322 or an inbound rule that allows for the application/service sghwdsptr.exe (for the dispatcher) and sghwsvr.exe (for the core.)
• Listener Port Configuration for server is configured incorrectly or the port is specified incorrectly in the OSD file.

Assuming your configuration is the default in 4.5 and later for RTSPS, watch for the following common URL errors:

a. <CODEBASE HREF="RTSP://APPVSRV:554/off2010RC1_mnt/off2010RC1_mnt.sft"

- Wrong Protocol

 

b. <CODEBASE HREF="RTSPS://APPVSRV:332/off2010RC1_mnt/off2010RC1_mnt.sft"

- Wrong Port (RTSPS default port changed with 4.5)

 

c. <CODEBASE HREF="RTSPS://APPVSRV:554/off2010RC1_mnt/off2010RC1_mnt.sft"

- Wrong Port (forgot to change port after changing protocol)

 

Common RTSPS Problem #3:

Users receive the following error on publishing refresh or when trying to stream an application via RTSP:

"The certificate chain was issued by an authority that is not trusted."
"Error code: xxxxxx-xxxxxx2A-80090325"

This error occurs when the cert being used on the App-V server either is not issued by a trusted authority, or if it is self-signed certificate, it has not been imported into the trusted root folder of the server's certificate store.

Viewing the certificate from within the Certificates MMC-Snap-in (for local computer) will show the certificate with a red X denoting that it is not trusted.

Self-signed certificates can be trusted by installing the certificate in the Trusted Root Certification Authorities Store. If you are using an online CA, you will need to collect certain data and verify the certificate before doing further PKI troubleshooting.

Load the Certificates MMC snap-in focused on the local computer. This requires Administrator credentials.

1.) Click Start, then Run, type mmc.exe, and press Enter.

2.) Click the File Menu and select Add/Remove Snap-in.

3.) Click the Add button. Select Certificates from the list of snap-ins, and click Add.

4.) Select Computer Account, and click Next.

5.) Select Local Computer, and click Finish.

6.) Click Close, and then click Ok.

7.) Expand Certificates (Local Computer).

8.) Expand the Personal folder, and select Certificates.

9.) Export the certificate. In the list of certificates, select the one you want to export.

10.) Right-click and select All Tasks and then Export…

11.) This will start the Certificate Export Wizard. Click Next.

12.) Select No, do not export the private key. Click Next.

13.) Select DER encoded binary X.509 (.cer) and click Next.

14.) Enter the location and file name for the file, and click Next. I usually use appvcert.cer

15.) Click Finish. Click Ok.

After you are finished exporting the .CER file, you can then run the following command against it to verify the certificate:

certutil -urlfetch -verify appvcert.cer >appvcert.txt

As you can see, I have redirected the output to this command to a file. To quickly search for status errors, use the findstr command to list the error status for each certificate in the chain.

Common items you may want to search for include:

• 0x800b0109
• 0x80092013
• 0x80072ee7
• UNTRUSTED
• failed
• terminated
• Expired

To determine if the certificate is published in Active Directory run the following command:

certutil -store "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRootDomain?cACertificate?one?objectClass=certificationAuthority" SerialNumber

The serial number can be found by double-clicking the exported *.CER file and clicking on the "Details" tab.

Common RTSPS Problem #4:

Users receive the following error on publishing refresh or when trying to stream an application via RTSP:

"The target principal name is incorrect."
"Error code: xxxxxx-xxxxxx2A-80090322"

This is usually caused by the path to the server in the OSD mismatching the name specified for the certificate. It can also occur if the name specified for the publishing server via (RTSPS) does not match the name of the same machine specified in the OSD.  For example: Name specified for the certificate is the FQDN but the OSD only references the NETBIOS name.

Common RTSPS Problem #5: Poor Streaming Performance

This was first addressed in Hotfix Package 5 for Microsoft Application Virtualization 4.5 Cumulative Update 1: August 2009 http://support.microsoft.com/?kbid=973873. It has also been included in Service Pack one for App-V 4.5.

Common RTSPS Problem #6

When using RTSPS and a 3rd party Certificate Authority some clients may receive the following error message during a refresh after a user login:

The revocation function was unable to check revocation because the revocation server was offline.
Error code: 450260-24C02F2A-80092013

Please see this blog post for the resolution:

http://blogs.technet.com/appv/archive/2008/09/18/softgrid-app-v-client-receives-an-xxxxxx-xxxxxx2a-80092013-error-during-refresh.aspx

General Tips on using self-signed certificates:

The use of certificates is much more streamlined for App-V version 4.5 and above. When constructing a certificate for use with RTSPS, you can leverage a web server template and share the certificate with an IIS service (especially if you are securing web management service access.)

If bypassing Internal CA's or 3rd-party certificates, you can make use of self-signed certificates. If your App-V Server is residing on a Windows 2003 Server, you can use the SelfSSL tool from the IIS Resource Kit Utility. SelfSSL (SelfSSL.exe) can help you generate and install a self-signed SSL certificate.

Information about the IIS Resource Kit can be found here:  http://support.microsoft.com/kb/840671

The IIS 6.0 Resource Kit can be found here:  http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499

Here are some syntax hints as well:

selfssl.exe /N:CN=app-v-ms /K:1024 /V:7 /S:1 /P:443

- Creates, Installs, and Binds the Certificate.

selfssl.exe /T

- Adds the certificate into the Trusted Root Store

You can then verify the certificate using the Certificates MMC Snap-in or CERTUTIL.EXE

Ensure the certificate you generate is for Server Authentication (or both Server and Client Auth.) Pay close attention to Name and Friendly Names

Windows Server 2008 has a built-in feature inside of the IIS Manager for creating self-signed certificates.

1.) Open IIS Manager and navigate to the server node (identified by your server name.)

2.) In Features view, double-click Server Certificates.

3.) In the Actions pane, click Create Self-Signed Certificate.

4.) On the Create Self-Signed Certificate page, type a friendly name for the certificate in the Specify a friendly name for the certificate box, and then click OK.

Hope this helps,

Steve Thomas | Senior Support Escalation Engineer

This blog is a follow-up to the RemoteApp for Hyper-V blog at http://blogs.msdn.com/rds/archive/2009/12/15/remoteapp-for-hyper-v.aspx.

Introduction

Similar to RemoteApp, the RemoteApp for Hyper-V feature allows users to access a specific hosted application remotely, as opposed to the entire desktop. When using RemoteApp, the application runs in the context of a server session; however, RemoteApp for Hyper-V enables remote access to an application running on a Hyper-V virtual machine (VM). That is, this feature allows you to launch applications that are hosted on VMs as remote applications.

This blog outlines setup steps and common troubleshooting tricks for deploying RemoteApp for Hyper-V.

Supported Operating Systems

The supported SKUs for this feature are as follows:

• Guest operating systems on the Hyper-V server (all client operating systems):

1. Windows® 7 Enterprise, 32-bit edition; Windows 7 Ultimate, 32-bit edition
2. Windows Vista® Enterprise with Service Pack 1 (SP1), 32-bit edition; Windows Vista Ultimate with SP1, 32-bit edition
3. Windows® XP Professional with SP3, 32-bit edition

• Client operating system

1. Windows 7 64-bit / 32-bit

As outlined in the “RemoteApp for Hyper-V” blog, this feature can be deployed in either of the following two ways:

1. Stand-alone scenario

The administrator completes the following steps:

a. Set up the Hyper-V computer and install a supported guest operating system as outlined above in the “Supported Operating Systems” section.

For more information, see http://technet.microsoft.com/en-us/library/cc753637(WS.10).aspx.

b. Install the applications on the guest operating system and create RemoteApp RDP files specific to each application that would be launched as RemoteApp programs. How to create RemoteApp RDP files is explained in detail below.

c. Share these RDP files with the end user to launch this application as a RemoteApp program.

d. The user then launches these RDP files and enters their credentials to get access to the RemoteApp programs hosted on the guest operating system on the Hyper-V computer.

2. Virtual Desktop Infrastructure (VDI) scenario

The administrator completes the following steps:

a. Set up the entire VDI solution, which would involve deploying RD Connection Broker, farms, and personal desktops.

• For more information about deploying VDI farms, see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e33b0953-e89a-4b97-a6fe-60da44add5c7.
• For more information about deploying VDI personal desktops, see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0d278f5c-37fa-43fb-8032-614c7bf1d617.

b. Install the applications on the guest operating systems in the farm or personal desktop, and create RDP files according to the farm or personal desktop deployment.

c. Share these RDP files with the end user so that they can launch these applications as RemoteApp programs.

d. The user then launches these RDP files and enters their credentials to get access to the RemoteApp programs hosted on the guest operating system on the Hyper-V computer.

To set up guest operating systems on which we can enable RemoteApp for Hyper-V:

1. Windows XP SP3 32-bit guest operating system

a. Setting up the guest operating system

1. Install Windows XP Professional SP3, 32-bit edition, on the Hyper-V computer as a virtual machine.

2. Enable Remote Desktop on this VM.

3. Install the Windows XP SP3 RemoteApp for Hyper-V package on this VM.

Note: The update package for Windows XP SP3 can be found here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=2f376f53-83cf-4e5b-9515-2cb70662a81b&displaylang=en

4. Restart this VM after the package is installed.

5. Change the following regkey on this VM:

• Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
• Set the value of fDisabledAllowList to 1.

b. Creating the RDP file

1. Launch Remote Desktop Connection (MSTSC) and click Save As to save the RDP file that the administrator can use for the RemoteApp for Hyper-V feature.

2. Here is a sample RDP file for the stand-alone scenario described above:

The RDP file launches Notepad from the Windows XP SP3 guest operating system. The administrator can follow the steps below to create the RDP file.

As can be seen from the sample RDP file, the administrator would do the following:

1. Change the parameters

• “remoteapplicationmode:i:1”
• Alternate shell:s:rdpinit.exe

2. Add the parameters

• RemoteApplicationName:s:<user friendly name>
• RemoteApplicationProgram:s:<path to the application>
• DisableRemoteAppCapsCheck:i:1
• Prompt for Credentials on Client:i:1

After modifying the RDP file, the administrator saves the RDP file. For each application that he wants to publish as a RemoteApp program, the administrator creates an RDP file in a similar way as described above.

2. Windows Vista with SP1 32-bit guest operating system

a. Setting up the guest operating system

1. Install Windows Vista SP1 Enterprise or Ultimate, 32-bit edition on the Hyper-V computer as a VM.

2. Enable Remote Desktop on this VM.

3. Install the Windows Vista SP1 RemoteApp for Hyper-V package on this VM.

Note: Update the package for Windows Vista SP1:

http://www.microsoft.com/downloads/details.aspx?familyid=097B7478-3150-4D0D-A85A-6451F32C459C&displaylang=en

4. Restart this VM after the package is installed.

5. Change the following regkey on this VM:

• Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
• Set the value of fDisabledAllowList to 1.

b. Creating the RDP file

1. Launch Remote Desktop Connection (MSTSC) and click Save As to save the RDP file that the administrator can use for the RemoteApp for Hyper-V feature.

2. Here is sample RDP file for the stand-alone scenario described above:

The RDP file launches Notepad from the Windows Vista SP1 guest operating system. The administrator can follow the steps below to create the RDP file.

As can be seen from the sample RDP file, the administrator would do the following:

1. Change the parameters

• “remoteapplicationmode:i:1”

2. Add the parameters

• RemoteApplicationName:s:<user friendly name>
• RemoteApplicationProgram:s:<path to the application>

After modifying the RDP file, the administrator saves the RDP file. For each application that he wants to publish as a RemoteApp program, the administrator creates an RDP file in a similar way as described above.

3. Windows 7 32-bit guest operating system

a. Setting up the guest operating system

1. Install Windows 7 Enterprise or Ultimate, 32-bit edition on the Hyper-V as a VM.

2. Enable Remote Desktop on this VM.

3. Change the following regkey on this VM:

• Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
• Set the value of fDisabledAllowList to 1.

b. Creating the RDP file

1. Launch Remote Desktop Connection (MSTSC) and click Save As to save the RDP file that the administrator can use for the RemoteApp for Hyper-V feature.

2. Here is sample RDP file for the stand-alone scenario described above:

The RDP file launches Notepad from the Windows 7 guest operating system. The administrator can follow the steps below to create the RDP file.

As can be seen from the sample RDP file, the administrator would do the following:

1. Change the parameters

• “remoteapplicationmode:i:1”

2. Add the parameters

• RemoteApplicationName:s:<user friendly name>
• RemoteApplicationProgram:s:<path to the application>

After modifying the RDP file, the administrator saves the RDP file. For each application that he wants to publish as a RemoteApp program, the administrator creates an RDP file in a similar way as described above.

Some facts about the RemoteApp for Hyper-V feature

1. This feature is enabled by setting the following registry key on the Guest VM:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList, and setting the value of fDisabledAllowList to 1.

This means that we are disabling the application allow list on the VM, which means that any application from the VM can be launched as a RemoteApp program. The administrator does not have control over what applications are published or what applications can be launched. After the customer has the created RDP file, he can change the “RemoteApplicationName:s:” parameter and launch any application by setting the correct application path.

Troubleshooting issues that you might observe when enabling this feature

1. While launching RemoteApp for HyperV, you see the error “Windows cannot start the RemoteApp program.”

a. You might observe this error while enabling this feature.

b. This might happen if the fDisabledAllowList regkey is set to 0 on the VM.

c. Change the following regkey on this VM:

• Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList.
• Set the value of fDisabledAllowList to 1.

2. While launching RemoteApp on Windows XP SP3, the application does not launch and the connection is stuck in the details pane.

a. You might observe this error while enabling this feature on Windows XP SP3.

b. If you see this error, there is probably a missing parameter in your created RDP file.

c. Check to see if your created RDP file has alternate shell:s:rdpinit.exe.

d. If this parameter is missing, add this parameter to the RDP file and this should solve your problem.

3. "The remote computer does not support RemoteApp" error

a. You might observe this error while enabling this feature on Windows XP SP3.

b. If you see this error, there is probably a missing parameter in your created RDP file.

c. Check to see if your created RDP file has DisableRemoteAppCapsCheck:i:1

d. If this parameter is missing, add this parameter to the RDP file and this should solve your problem.

4. While launching RemoteApp on Windows XP SP3 / Windows Vista SP1, the application might get stuck in Remote Desktop

a. You might observe this if the update package for Windows XP SP3 or Windows Vista SP1 is not installed correctly on the VM.

b. Uninstall the package and restart the VM to make sure that the package is completely removed.

c. Now, reinstall the package and following the setup instructions as described above for Windows XP SP3 or Windows Vista SP1.

5. While launching RemoteApp, the credential window is shown in the details pane.

a. You might observe this error while enabling this feature on Windows XP SP3.

b. If you see this error, there is probably a missing parameter in your created RDP file.

c. Check to see if your created RDP file has Prompt for Credentials on Client:i:1.

d. If this parameter is missing, add this parameter to the RDP file and this should solve your problem.

We recently noted some of the changes to support for ConfigMgr 2007 over on our support team blog but I wanted to also mention one big App-V 4.6 related change here:

Microsoft Application Virtualization 4.6 is now supported on ConfigMgr 2007 R2 with ConfigMgr 2007 SP2

System Center Configuration Manager 2007 R2 with System Center Configuration Manager 2007 SP2 now supports Microsoft Application Virtualization 4.6 Desktop Client and Client for Remote Desktop Services. This client release enables support for Windows 7 and Windows Server 2008 R2 and support for 64-bit operating systems. 

No software updates are required.

Enjoy!

J.C. Hornbeck | System Center Knowledge Engineer

Brien M. Posey: In my previous article, I explained that Hyper-V’s export function could be used as a mechanism for cloning virtual machines if you do not have System Center Virtual Machine Manager. In this article, I want to conclude the series by showing you how the export process works.

Microsoft’s VDI solution offers two deployment scenarios: virtual desktop pools and personal virtual desktops. Virtual desktop pools are not dependent on a specific Active Directory schema level; however, personal virtual desktops do need a Windows Server 2008 or Windows Server 2008 R2 schema.

Here are the Active Directory requirements for personal virtual desktops:

• 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 from 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.

We are almost there with XenDesktop 4 on ESXi.

John Kelbley: I mentioned in my last post the diskshadow command line tool that was introduced in Windows Server 2008.  Jose Barreto did a nice job over viewing the command in his blog, so I won't cover the same ground.  I’m going to walk you through how I use diskshadow to create a consistent, restorable, consolidated backup of Hyper-V and running VMs.

Paul Wilson: If you have read some of my recent blogs, you know that I have been spending time testing XenDesktop 4 and Microsoft Windows 2008 R2 Hyper-V. I thought I would take a moment and highlight the top seven things I have learned during this testing. Some of these items I briefly mentioned in my previous blog Optimizing Windows 7 for FlexCast Delivery posted a few weeks ago.

Installing Hyper-V on a server establishes the server as a virtualization server. Each virtual machine you install on the server must be assigned resources to use and then be configured. The number of virtual machines you can run on any individual server depends on the server’s hardware configuration and workload.

Aidan Finn: Patrick Lownds, a fellow virtualisation MVP over in the UK, has provided a couple of useful links if you are running Hyper-V on HP equipment.  The first is a post on best practice guidance if you are running Hyper-V on a HP EVA SAN.  There is a whitepaper that goes through HP’s recommendations on this.  It was interesting to see they saw a fixed VHD’s get 7% more IOPS at 7% less latency than dynamic VHD’s.

The ProTips for HP are also available.  They’re not easy to find but Patrick provided me with a link.  The idea here is that HP SIM agents (which you should be installing, even if you don’t use the HP or other management software) detect hardware issues.  OpsMgr then picks up the alert and notifies VMM using the HP Pro Tips.  VMM can then take action, e.g. migrating VM’s from one host to another in the cluster.

 

Kurt Roggen: This is a free ebook for IT professionals who want to learn more about the latest Microsoft virtualization technologies, including Hyper-V and Remote Desktop  Services in Windows Server 2008 R2, Microsoft Virtual Desktop Infrastructure,  Microsoft Application Virtualization 4.5, Microsoft Enterprise Desktop Virtualization, Windows Virtual PC and Windows XP Mode, System Center Virtual Machine Manager 2008, and Microsoft’s private and public cloud computing platforms including Windows Azure.

Chapters covered:

• Why Virtualization?
• Server Virtualization
• Local Desktop Virtualization
• Remote Desktop Virtualization
• Virtualization Management
• Cloud Computing

Download here

Just a quick heads up that we recently published our prescriptive guidance (aka recipe) for sequencing the Microsoft Office 2010 beta using Microsoft Application Virtualization 4.6.   Please note that:

This article describes one method that you can use to successfully sequence the Beta version of the 2010 Microsoft Office system for use with Microsoft Application Virtualization (App-V) 4.6. The method that is described in this article is not the only method that is available. You may have to change the information in the article as appropriate for your particular environment. 

This process should work on the final version of Office 2010 but of course until it's released we can't make any guarantees.  We'll update the article with any changes (if needed) once it ships.

KB980861 - Prescriptive guidance for sequencing the Beta version of the 2010 Office system in Microsoft App-V

Enjoy!

J.C. Hornbeck | System Center Knowledge Engineer

Holy crap. I though Windows Server 2008 TS was a PITA to configure. Wait until you see R2.

Here's an issue we see every once in a while and since I didn't see the details published anywhere I thought I'd go ahead and do that here.

Consider the following scenario:

1.  You install the App-v 4.x server and set the packageroot (content directory) to an alternate location (not the default).
2.  You delete the included Default Application, package and content from the disk.
3.  You upgrade the server to a newer version of App-V.

After completing the steps above, when clients attempt to stream a virtualized application they receive one of the following errors:

A network error occurred error :  XXXXXXXX-XXXXXXXX-20000194

or

A network error occurred error :  XXXXXXXX-XXXXXXXX-10000003

Cause:

This is caused by an invalid value for SOFTGRID_CONTENT_DIR in the registry.

Resolution:

To resolve this issue, complete the following steps:

1.  Start RegEdit

2.  Navigate to the following key:

HKLM\Software\Microsoft\Softgrid\4.5\Server

3. Set the SOFTGRID_CONTENT_DIR value to the proper content directory location.

4.  Restart the server.

More Information:

During the server upgrade, the installer first searches for the defaultapp.sft file location. After getting the defaultapp.sft file path, the installer then gets the content directory path from the SOFTGRID_CONTENT_DIR registry key. If the defaultapp.sft file path is not the same as SOFTGRID_CONTENT_DIR registry entry, the installer overrides the value of SOFTGRID_CONTENT_DIR. If there is no defaultapp.sft file (i.e. it has been deleted), the installer overrides the value of SOFTGRID_CONTENT_DIR anyway with the default installation content directory (PROGRAM_FILES\Microsoft System Center App Virt Management Server\App Virt Management Server\Content).

This is an issue we're aware of and it should be fixed in the next version of the server, but if you run into this in the mean time this is how you can fix it.

J.C. Hornbeck | System Center Knowledge Engineer

The Microsoft Virtual Desktop Infrastructure (Microsoft VDI) involves multiple role services. To develop a true high availability solution for this setup, you need to understand the high availability solution for each role service. This blog post identifies the key pieces of the Microsoft VDI solution and provides details on the high availability options available.

Key Microsoft role services that should be made highly available

1. Remote Desktop Session Host (RD Session Host) in redirection mode
2. Remote Desktop Connection Broker (RD Connection Broker)
3. Remote Desktop Virtualization Host (RD Virtualization Host)
4. Remote Desktop Web Access (RD Web Access)
5. Remote Desktop Licensing (RD Licensing) and Remote Desktop Gateway (RD Gateway)

High availability options for each role service 1. RD Session Host in redirection mode

A high availability solution for the RD Session Host server consists of high availability of the hardware, as well as high availability of the Remote Desktop Session Host role service.  You can use multiple RD Session Host servers and round robin DNS to provide high availability at both levels. High availability is obtained by virtue of the Remote Desktop Protocol (RDP) client trying all the IP addresses returned by the DNS server. All the RD Session Host servers should be running in active-active mode.

2. RD Connection Broker

Similar to RD Session Host, the RD Connection Broker role service can be made highly available at both the hardware and the service level by clustering multiple servers running the RD Connection Broker role service. Failover clustering guarantees that in the event of hardware or software (service) failure on the active node, a failover is triggered. In other words, a new active node would be selected at that time.  A step-by-step guide about how to configure an RD Connection Broker server in active-passive mode for high availability will be available soon on TechNet.

3. RD Virtualization Host

The Microsoft VDI solution supports highly available Hyper-V virtual machines. Setting up a failover cluster environment with multiple Hyper-V hosts will ensure that in the event of a hardware failure on a Hyper-V host, the virtual machines will fail over to another Hyper-V host and automatically start. If the Remote Desktop Virtualization Host Agent service fails, this service is configured to restart automatically. Thus all the Hyper-V virtual machines would be available all the time.

4. RD Web Access

High availability of the RD Web Access role service is achieved by deploying it in an active-active mode. Multiple RD Web Access servers can be configured as part of a Network Load Balancing (NLB) cluster to achieve this. You could also use round robin DNS in place of an NLB cluster to make the RD Web Access role service highly available.

5. RD Licensing and RD Gateway

For high availability of RD Licensing and RD Gateway, see the following:

· Deploying Remote Desktop Licensing Step-by-Step Guide (http://technet.microsoft.com/en-us/library/dd983943(WS.10).aspx)

· Improving TS Gateway availability using NLB (http://blogs.msdn.com/rds/archive/2009/03/24/improving-ts-gateway-availability-using-nlb.aspx)

Unsupported high availability deployment configurations

There are two deployment configurations that are not supported:

1. Clustering RD Connection Broker servers on RD Virtualization Host servers.
2. An active-active RD Connection Broker installation.

More information about setting up highly available VDI

A step-by -step guide for high availability of all the components mentioned above will be published soon.

Glossary

· Active/Active failover cluster model. All nodes in the failover cluster are functioning and serving clients. If a node fails, the resource will move to another node and continue to function normally, assuming that the new server has enough capacity to handle the additional workload.

· Active/Passive failover cluster model. One node in the failover cluster typically sits idle until a failover occurs. After a failover, this passive node has enough capacity to serve the new application without any performance degradation.

A Virtual Hard Disk (VHD) is a file that encapsulates a hard disk image. VHDs can be used in new and interesting ways. VHDs first were created to be the storage media for Virtual Machines (VMs).  Today, VHDs are used to ship trial versions of software, used in backup solutions, used for bug triage (e.g. customers can convert a physical disk to virtual and share it), and even used to store multiple boot environments.  VHDs are a very flexible storage container and are not tied to any single file system format.  Since June 2005, Microsoft has made the VHD Image Format Specification available to third parties under the Microsoft Open Specification Promise (OSP).