Bringing Legacy Blog Back to Cover Legacy Products

Just about a year ago, I moved all new posts over to Technet.com. In spite of that, this blog still continues to get much attention due to a lot of the existing content proving to be very useful for users. For that I am extremely happy to help and it recently gave me an idea. I have been mulling over how I should focus my current blog over at Technet with regards to information, guidance, and support tips. While I have a lot of great information coming (a lot of new products/product versions in the pipeline) I also have a wealth of information I’ve been needing to post tat was related to existing products and legacy products (Softgrid/App-V 4.x/MED-V V1, etc.) I also realize there is a strong user community and install base still present who may not be moving off until the products get closer to end of life.

– Steve Thomas

With this said, I decided that I would use this blog on WordPress in the future for legacy product information (App-V 4.x/Softgrid/MED-V V1/VMM 2008/VPC) while keeping my blog over at Technet more related to current and forward technologies (App-V 5.0/UE-V/Hyper-V 2012/Win8/Win2012.)

Additional Considerations for Using App-V With TSRemoteApps

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:

http://download.microsoft.com/download/2/5/E/25EEFF4E-A81A-464F-9AB1-98FA1EF755AA/App-V%20Remote%20Desktop%20Services.docx

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

Planning for a Microsoft VDI Deployment

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:

http://www.microsoft.com/virtualization/en/us/products-desktop.aspx

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:

http://blogs.technet.com/b/virtualization/archive/2009/07/13/microsoft_1920_s-new-vdi-licensing_3a00_-vdi-suites.aspx

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

http://blogs.msdn.com/b/rds/archive/2009/08/19/microsoft-vdi-overview.aspx

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:

http://technet.microsoft.com/en-us/library/cc730930(WS.10).aspx

Windows 2008 R2:

http://technet.microsoft.com/en-us/library/dd378828(WS.10).aspx

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.

From: http://technet.microsoft.com/en-us/library/dd883277(WS.10).aspx

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 (http://go.microsoft.com/fwlink/?LinkId=122183).
•  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:

 http://www.microsoft.com/showcase/en/us/details/5e9fe509-a9e2-43a0-99e9-c79b655a3412

 And a good document as well:

 http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=bd24503e-b8b7-4b5b-9a86-af03ac5332c8

 RD Web Access Information:

 http://technet.microsoft.com/en-us/library/dd883265(WS.10).aspx

 RD gateway Information:

 http://technet.microsoft.com/en-us/library/dd560672(WS.10).aspx

 Why VDI for Hyper-v Whitepaper:

 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f0533021-ca5a-4330-b839-1efedad14479

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

 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=5F630FFC-5F30-4B5F-8B2B-8AFB42E14D35&displaylang=en

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

 http://technet.microsoft.com/en-us/edge/ff832960.aspx?query=1&Category=virtualboy