App-V Hidden Drive Letter ADM File

In our environment, our users love their drive letters, and they do so to the Nth degree. As part of a change control process, myself and a colleague have scheduled the deployment of the App-V Client across our business estate to allow us to begin provding the users with user-centric real-time streamed applications to meet their business needs.

We today discovered the true nature of our Nth degree network drive letter because after some review, it became aparent that not a single letter (beyond the usual C, D, E for local disks) was free for company-wide use which caused us pain on the inside. We came to the conslucsion that people in our business very rarely use floppy disk drives anymore, and even less people (zero to my best guess) use a second floppy disk drive, which means that the B: drive would be available across the estate.

Using the Microsoft App-V ADM file for Group Policy (available for download from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=25070), I re-configured our GPO to force the clients to use the B: drive instead of the App-V default Q: drive. I tested the configuration change on my own machine (ICT dogfooding for everyone), and also streamed a couple of applications to verify the drive letter change didn’t cause any issues, and I came to an idea. If the App-V virtual file system is inaccessible by the user because of the ACLs that App-V applies to it, and because the user has no reason to be meddling in the App-V virtual file system drive, why, display it to them?

I took a look at the Windows Explorer, Hide these specified drives in My Computer policy in the User Configuration portion of Group Policy however for reasons beyond me, Microsoft only gave you a very limited set of options in this policy (Hide A, Hide A and B, Hide A, B and C, or Hide All Drives). This policy was probably useful in the legacy days where you only wanted to restrict use of local floppy disk drives, however it’s not very useful in the 21st century.

The way around this, is to build your own custom ADM file to change the options for disabling the drive letters.

I have this evening created a custom ADM file for such a purpose, and in my example, the file is crafted to allow you to hide the B drive, or no drives, however you can add as many options to this file as you like.

How you configure the file to restrict particular drives is based on a binary value using a reverse alphabet table. Details for calculating this can be found on the Microsoft Support article Using Group Policy to Hide Specific Drives (http://support.microsoft.com/kb/231289). If you aren’t ocomfortable trying to do this in your head, you can simply copy and paste the table out of the article into Notepad and do your working in there.

Simply add the ADM file to an existing GPO and link it to an OU which contains users in AD, and you’re all set.

If you want to only restrict a single letter, then you can simply edit my file by modifying the label for, and the binary value for the BOnly item. The file is shared and free for you to download from my Windows Live SkyDrive account. I’m also happy to take comments or answer emails with questions about how to modify the file.

The Tiny and The Behemoth

Last week I was having a discussion with a colleague (@LupoLoopy) regarding Group Policy processing times and the ago old question of do you create a small handful of behemoth GPOs, or do you create lots of small targetted GPOs for specific purposes?

In this iteration of the debate, I was on the side of small and targetted and my colleague was on the side of the behemoth.

After the discussion, I did a bit of online digging, and turned up a post on the TechNet Magazine at Microsoft by Darren Mar-Elia, a Group Policy MVP. The outcome of the article is that, in his opinion, and based on research by using User Environment timers for monitoring the processing of Group Policy objects, small and targetted seems to be the best strategy.

When a GPO is updated with a change by an administrator, the client will have to process all of the settings within the GPO to determine which settings have changed and determine which settings it needs to apply, however in small and tightly targetted GPOs, there are much fewer settings per GPO which means even in a high churn Active Directory environment, fewer client-side settings need to be re-evaluated.

In largely static environments where there is a very low rate of churn, it could be entirely suitable to use fewer larger GPOs to apply larger configuration setts in bulk, however this will depend on the environment, and following the advice in the link below will allow you to determine the best scenario for your environment.

For anyone interested in reading the full article, you can see it at http://technet.microsoft.com/en-us/magazine/2008.01.gpperf.aspx.

Failure with Concessions

Today wasn’t the greatest day for me in one respect. Unfortunatly I flunked my 70-236 Configuring Exchange Server 2007 exam for the second time, and strangely, with months more Exchange experience under my belt (and I mean that because we’ve faced our share of issues and undertaken our share of mini-projects on infrastructure engineering since my last attempt), and with loads of preperation, I actually scored roughly 75 points lower than my first attempt.

I purchased a three exam pack through Prometric earlier in the year which expires December 31st 2011, so I’ve got to try and get two exams passed before the end of the year still, with MDOP being my next exam and still undecided on the third, but Exchange better look out, as once I’ve done my two remaining in the pack, I’ll be going back for my MCITP for Exchange Server 2007 and 2010.

The concession in all of this is a feeling of self-enlightenment. Tomorrow, my trusty laptop will be going back to the office from home so that I can re-deploy it with SCCM to install my yummy new SSD disk (I would clone the disk, but I have a feeling BitLocker might not accept that too kindly). To make sure I didn’t loose any data, I hooked up my VPN this evening and made sure that all of the data on my laptop was safe and sound on the file servers and work, and then I turned my attention to OneNote.

I’m an avid OneNote user, and will use it over written notes whenever I possibly can. Being a Windows Phone 7 user, I also enjoy the OneNote integration in the phone giving me super access to my personal notes. I quickly realised that through the course of migrating through various working practices at work, I had one notebook in my SharePoint 2010 MySite and another locally on the laptop, and then a third in the Windows Live SkyDrive cloud. I’ve just combined them all into my SharePoint 2010 MySite notebook and I feel great for it.

Unification for the win 🙂

Redirecting Windows Home Server 2011 Remote Web Access for Internal Clients

Windows Home Server 2011 features an impressive remote access site allowing you access to your digital media as well as remote access to your home computers. One of the components which allows all of this functionality to work is the Client Connector. This software element, installed on the client computers (which can be PCs or Macs for the record) enables the Home Server to backup your systems, along with enabling the features required on your system for the RemoteApp Remote Desktop Services connections to remote onto your PC from anywhere online.

In the Home Server Launchpad, the main user facing element of the Client Connector, there is a link for Remote Web Access which directly launches a browser session to the Windows Home Server 2011 Remote Web Access site, after you have configured your free homeserver.com domain with Microsoft and GoDaddy (this is configured using the Windows Home Server 2011 Dashboard).

In a normal home scenario with a router from your ISP or that you purchased elsewhere, clicking the Remote Web Access link will launch the Home Server Remote Web Access site using the homeserver.com domain you registered as the URL. In my not-so-normal home network, I use a Cisco PIX firewall as my edge device means I have a problem.

Unlike a router, the PIX cannot route packets back through the same interface where the packet was initially received.

This sentence from the Cisco PIX Frequently Asked Questions explains the problem in one. Clicking the Remote Web Access link launches the browser session to the correct URL, however because that URL resolves to the Internet IP associated with the outside interface on the PIX means the traffic flow is not permitted back through the firewall.

Being a Windows Systems Administrator, I like things on Windows, which means I prefer to run my infrastructure services like DNS and DHCP on the Home Server instead of allowing the router to do it. The DNS role in Windows Server 2008 R2 (the foundation for Windows Home Server 2011), and the DNS role in any Windows Server operating system for that matter allows you to create multiple zones for multiple domains to which the server will respond with DNS resolutions, and this is where the fix derives from.

The fix, or trick as the case may be, is to use DNS to reroute the client computer by resolving the homeserver.com domain name to the internal IP address of the Home Server, and away from the Internet side of the network, which ultimately will improve the performance of the Remote Web Access interface too.

On the Home Server, launch the DNS Manager console from Administrative Tools.

image

In the console, right-click on Forward Lookup Zones, and select New Zone.

In the New Zone Wizard on the Zone Type panel, select the Primary Zone option,

On the Zone Name panel, enter the full domain name that you specified in the Domain Name Setup Wizard from the Home Server Dashboard (in this example, I’m using server.homeserver.com).

On the Zone File panel, you can leave the default option to Create a New DNS Zone File.

On the Dynamic Updates panel, leave the option set to Do Not allow Dynamic Updates. This will help to prevent any rogue clients on the network from poisoning the DNS zone and directing your clients to the wrong IP address.

imageimageimageimageimage

On the Completing the New Zone Wizard panel, verify that you can specified the homeserver.com domain correctly. and then select Finish to complete the wizard.

Back in the DNS Console, your new zone will be visible. In the new zone, right-click and select New Host (A or AAAA).

image

In the New Host dialog, leave the Name field blank and in the IP Address field, specify the IP Address of your Home Server. This IP Address should either be statically assigned to the Home Server, or it should be configured as a DHCP Reservation on whatever device is running your DHCP Server on the network (although if the Home Server is your DHCP Server, then this should obviously be static).

Congratulations. Your internal clients will now be able to access the Home Server Remote the Web Access site, using the Client Connector user interface as Microsoft had intended, without a single packet touching the outside interface of your server.

If in your home network, you are using the router to perform DNS queries on your behalf, but your router prevents connections through the same interface that the connection was initiated as the PIX does, you could also implement this trick using the DNS HOSTS file, however this would need to be performed on a per client basis editing the HOSTS file. Using this example, the HOSTS file line item would be configured as follows:

192.168.1.100   server.homeserver.com   # Windows Home Server

Remember to flush your DNS cache on the clients using ipconfig /flushdns before testing your work regardless of whether you used the DNS or the HOSTS file methods to implement it.

App-V Client Management via GPO

Deploying the App-V Client to end-user machines can be headache. Microsoft provide ADM files for managing the configuration of the App-V Client via Group Policy in AD DS, however if you are trying to deploy the client yourself, you will soon discover that the Microsoft ADM files don’t allow you to configure an App-V Publishing Server. The only options you have with the ADM files are to override the sequenced application package and icon source roots.

Using this method, you install string for silent installation will look something like this:

setup.exe /s /v” /qn SWIPUBSVRDISPLAY=”App-V Server” SWIPUBSVRTYPE=”RTSP /secure” SWIPUBSVRHOST=”SERVERNAME” SWIPUBSVRPORT=”322” SWIPUBSVRREFRESH=”on” SWIFSDRIVE=”Q””

As anyone can see this isn’t exactly elegant, and if you are using SCCM to deploy the App-V Client as I am, you will soon discover SCCM has a character limit for the installer path which means you may have to turn to building a batch file to execute the installation and then call the file in the SCCM Program.

The other problem you will have are that you are then hardcoded to use the server name and port specified in the install. Yes, you could use a DNS CNAME to direct your clients to the App-V servers, and sure you can use a GPO to edit the registry keys on the end-user machines after the fact, however none of this is elegant as properly managing the deployment.

Introducing Login Consultants, a Netherlands based virtualization specialist company. This company provide a third-party ADM file for you to import into AD DS for extending the management options for App-V from the Microsoft ADM file, and best of all, you can register and download the ADM file for free from http://www.loginconsultants.com/index.php?option=com_docman&task=cat_view&gid=20&Itemid=149.

Using the Microsoft ADM file and the Login Consultants ADM file in conjunction, your install string turns into this:

setup.exe /s /v” /qn”

Much cleaner, easier to setup in Configuration Manager and then it gives you the ability to manage all of your App-V server configuration, including server name, ports, protocol, SFT_SOFTGRIDSERVER environment variable and all the other settings you need via Group Policy.

For centralising and streamlining management, this is a huge boon, as it means you have a one size fits all deployment of the App-V Client and then allowing you to manage everything else from either AD DS or from the App-V Management Server.

Certificate Store Permissions and Windows Live Block App-V RTSPS Protocol

Last week, when converting our existing ICT internal dogfood trial of App-V to a highly available production capable App-V solution, we came to a decision to utilize the RTSPS (Real Time Streaming Protocol Secure) protocol for streaming our applications.

Using some my own and another colleagues laptops for testing the RTSPS protocol, we ran into an issue whereby the client received the following error:

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

We initially discovered from an App-V blog article (http://blogs.technet.com/b/appv/archive/2010/03/09/troubleshooting-common-rtsps-issues-with-app-v.aspx) that this issue occurs when the server lacks permissions for the NETWORK SERVICE account to access the certificate store machine keys.

Following the advise of the article for Windows Server 2008 R2 systems, this was quickly resolved by using a Certificate Management based Microsoft Management Console to grant Read permission for the NETWORK SERVICE account to the certificate which is being used to sign the RTSPS protocol in App-V.

Thinking the issue was resolved, we proceeded to initiate a Refresh on the App-V client and tried to stream an application that we had previously sequenced, however we now received a new error:

The Application Virtualization Client could not update publishing information from the server App-V Server. The server will not allow a connection without valid NTLM credentials. Report the following error code to your System Administrator.

Error code: 4615186-1690900A-00002002

Leaving us puzzled. We were unable to find a solution initially, so we turned to Bing for some assistance, unearthing an interesting but niche blog post.

According to the source of our findings (http://blogs.ethz.ch/jlaville/2011/08/25/app-v-error-00002002/) machines with components from the Windows Live Essentials suite of applications cannot run the RTSPS protocol due to a registry key added to the LSA Security Packages key.

AppV Regedit LSA No LIVESSP

After removing the livessp value from the multi-value string in the registry and restarting the system we were successfully able to refresh the server and also stream the applications.