App-V: Current Recommended Practices for using App-V with Azure RemoteApp

In recent blogs posts, I’ve been discussing the topics of how to leverage App-V for software delivery and management to custom Azure RemoteApp images joined to a hybrid collection. I’ve discussed what is supported and demonstrated a few walk-throughs regarding image setup and targeting. While there are many particular variances for each facet of configuration, I would like to shed some light on some recommended practices that we have found in the early stages of testing and implementing these scenarios.

Isolate ARA App-V Publishing Servers to ARA OU

Azure RemoteApp is a PaaS (Platform as a Solution) in the Azure cloud for non-persistent session-based applications. Like any other implementation of non-persistent session and VDI solutions, there will be provisioning and de-provisioning of Azure VMs depending on the amount of connected users combined with the particular subscription plan. Since the collection number will vary in size (as well as potential App-V client configuration changes) it is recommended that you create a specific OU (organizational unit) for the ARA images as it will allow you to control targeting and configuration more easily through GPO (Group Policy Objects) and GPP (Group Policy Preferences.)

When Possible, Leverage GPO’s for App-V Client Configuration

The App-V 5.1 client can have the vast majority of the client configuration controlled and modified through group policy. Controlling images via GPO allows for the extra insurance that newly provisioned ARA images will inherit the same client configuration the existing images also have. Group policy also ensures that changes in Publishing servers or Reporting servers will also properly propagate to the images.

Path Publishing Gives More Flexibility – Path Publishing Requires Integration Path

If the applications are not pre-published within the image, then advanced knowledge of the App-V integrated path to the application executable must be known in advance. This also means package information (Package GUID) must be known prior to targeting.

• User Paths (%LOCALAPPDATA%MicrosoftAppVClientIntegration<GUID>Root<EXE>)

• Machine Paths (%SYSTEMDRIVE%ProgramDataMicrosoftAppVClientIntegration<GUID>Root<EXE>)

As with other VDI scenarios, you could consider devising a custom launcher and pre-install that within the image.

Preserve Package Lineage (Sequencing) to Prevent OS Image Updates

One of the primary use cases for App-V streaming with ARA (be it pre-publishing or management server targeting) is the capabilities of streaming package updates for applications. This prevents the need to re-upload custom OS images when the application is updated. In order to take advantage of this feature, it is necessary to preserve the package lineage where the base package GUID always remains constant as packages are updated. In order to do this, you must always open the package for editing or upgrade in the App-V Sequencer as oppose to just simply re-sequencing a new version or “saving as new package.”

Use an App-V Reporting Server with Frequent Agent Upload Intervals

One of the most convenient features of the App-V infrastructure is the capability of configuring the client’s reporting agent to upload application usage data per user to a reporting service. This has been especially helpful for tracking package and application usage history in on-premises non-persistent environments and is just as valuable with Azure RemoteApp. It is recommended to customize reporting configuration on the images via GPO.

Have an RSDH Host in Azure IaaS for Testing Publishing and Targeting prior to ARA deployment

Prior to joining your ARA images to the existing VNET and domain, it is a great idea to have an RSH VM within Azure on the same VNET in order to test publishing and targeting in advance. That way you can confirm things are working right with regard to the entitlement and publishing of applications – especially if the App-V infrastructure is based in Azure IaaS.

 

As mentioned, these are CURRENT recommended practices. As App-V and ARA evolve (and they have,) so may these.

 

App-V: On Targeting Azure RemoteApp Images with the App-V Management & Publishing Server

There are two types of Collections with Azure RemoteApp: A Cloud Collection and a Hybrid Collection. App-V requires that the client must exist on domain-joined machines in order to be supported. Azure RemoteApp Custom Images can be part of a Hybrid RemoteApp collection where the images are joined to the local domain. This now entails App-V and Azure RemoteApp the possibility of integration with the App-V Management & Publishing Server using a cloud-based or on-premises App-V Infrastructure scenario:

Cloud-based App-V Infrastructure: This is where the App-V Management, Publishing, and Content Sources are based in Azure IaaS (with the content being also available with extended Azure PaaS services as well.) In this scenario the Hybrid Collection must be associated with an existing VNET that also contains the App-V back-end resources. This scenario also requires that the Azure RemoteApp clients and the App-V infrastructure are joined to the same local domain either hosted in Azure IaaS or via the forthcoming Azure AD Domain Services (In preview – https://azure.microsoft.com/en-us/services/active-directory-ds/) The Azure RemoteApp images are pre-configured for the Publishing Server or controlled via GPO (group policy.)

The Cloud-based App-V Infrastructure can easily service both cloud-based resources (RDSH in Azure IaaS, Azure RemoteApp) as well as traditional on-premises clients (via the web, through Site-to-Site VPN’s, or ExpressRoute.)

On-Premises App-V Infrastructure: This is where the App-V Management and Publishing Servers are based in an on-premises network servicing primarily on-premises clients. In this scenario the Hybrid Collection must be associated with a VNET attached and routed to the on-premises App-V infrastructure through a site-to-site VPN or ExpressRoute. The Azure RemoteApp images are joined to the local domain and pointed to the Publishing Servers via pre-configuration or GPO. In this scenario, it is recommended to still leverage Azure-based content sources for content even though streaming over the on-premises connection would be possible – but not recommended.

Walking Through the Process:

For the sake of this conversation, we will assume that an existing App-V 5.1 infrastructure has already been provisioned, be it cloud-based or on-premises. Obviously, before you would start the process of setting up a custom image, you will want to make sure you have this in place.

1.)    Create a custom operating system image that has the App-V RDS 5.1 Client installed –  then import image into Azure RemoteApp. This is an oversimplification of a process that is further outlined in a previous blog post on configuring and preparing an image for use with App-V and Azure RemoteApp: http://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) You can pre-configure the client and even pre-publish some applications prior to upload. I would advise skipping the client pre-configuration and instead, leverage AD GPO’s to configure the client.

2.)    Create an Azure RemoteApp domain-joined (hybrid) collection and leverage the OS image as the template image for the collection. When you go to join the domain, you will want to join the domain to a specific OU (organizational unit) within your local domain. It will be much easier to administer and control the configuration of your ARA images if they are contained within a specific OU. NOTE: This step is massively simplified here in the explanation. More specific ARA information on joining Hybrid Collections can also be found here (https://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-hybrid-deployment/)
 

3.)    The image upload may take a while to provision. Once the image has been provisioned, the status will show as ready.

     

4.)    Once the images have been provisioned, you will start to see computer objects appearing in the OU you specified for the domain join.

      

5.)    At this point you can begin to configure a Group Policy Object and link it to the OU for the ARA images.

      

Within the GPO, you can leverage the ADMX templates for App-V via the MDOP ADMX template download package (available here: https://www.microsoft.com/en-us/download/details.aspx?id=41183) to control the App-V 5 client settings including App-V Publishing server targets, shared content store mode, scripting configuration, etc.

6.)    Now the interesting part begins: The App-V management console allows you to target packages to user AD (Active Directory) groups or machine AD groups.  When it comes to targeting groups, GPO’s only allow you to control local group membership. As a result, the targeting options available for machine groups that affect ARA machines is pretty much the Domain Computers Group. However, if you wanted to target the ARA images for machine groups (global publishing) you can effectively use the Domain Computers group coupled with the OU configuration for the specialized publishing server. User Targeting is a more flexible option as there are no restrictions with regards to the non-persistent provisioning of the ARA images.

   

In this example, I have targeted both the Domain Computers machine group as well as a custom user group within the App-V Management Console.

   

7.)    Publish App-V apps in ARA (using path option or pre-published discovery.) Within ARA, you can publish applications by querying the Start Menu of the image or by using Path Publishing. App-V applications will not show up via a Start Menu query unless they have been pre-published globally in the image. For this reason, it is better recommended to Path Publish the App-V applications. This requires juuuuuuust a bit of a workaround. If you plan on publishing an App-V application by path, you will need to be able to know the actual integration path to the executable in advance.

For machine-targeted (globally published) packages, they will begin with:

%SYSTEMDRIVE%ProgramDataMicrosoftApp-VClientIntegration<Package_GUID>Root

For user targeted (user published) packages, they will begin with:

%LOCALAPPDATA%MicrosoftApp-VClientIntegration<Package_GUID>Root

If you do not know the package GUID from sequencing, you can easily retrieve it from the package details within the App-V management console.

Any additional path information beyond the root folder must also be obtained in order to complete the path. Since the APPV format is a ZIP format, you can easily view this information within the APPV package file itself.

8.)    Once you have this information, you can proceed to publish the App-V applications n the Azure RemoteApp publishing console.

  

9.)    Upon logon using the ARA RDP client, you should then see your App-V applications appearing just like any other normal application.

      

App-V: More on App-V with Azure RemoteApp

Last April, we gave a little bit of information on the limited use of App-V applications with Azure RemoteApp (http://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) This piqued the curiosity of many and over the past several months, we have been validating several scenarios involving the integration of App-V with Azure RemoteApp images within hybrid collections. 

As you might have heard, Eric Orman – the Program Manager for Azure RemoteApp, announced at Ignite Australia that App-V *IS* supported with Azure RemoteApp within specific scopes. (https://channel9.msdn.com/Events/Ignite/Australia-2015/WIN336.)   This is a significant development for companies that want more options for bringing their desktop applications to Azure as well as the birth of another chapter in the story of App-V in Azure. In the three months since that announcement, one of the most common question I have been getting is “Why? How is this significant?”

Why App-V for Azure RemoteApp?

I would say the three most important aspects about being able to use App-V with Azure RemoteApp are the following:

Keeps Custom Images Thin: Custom Images with Azure Remote App have to remain beneath the 127GB maximum for VHDs. In addition, the more applications pre-installed to ARA images translates to a longer upload time. Customers embracing App-V will have the ability to quickly bake an image for upload with minimal pre-publishing (or NO pre-publishing if leveraging path publishing the with the App-V Publishing Server or Configuration Manager.) In addition, App-V clients baked into Azure RemoteApp images can have those applications stream to memory using the App-V Shared Content Store rather than to disk also preserving permanent storage consumption on the ARA images. It is important to note that Premium Plus subscriptions coupled with a high-end storage back end (Azure Files) would be recommended for Shared Content Store use in ARA.

Allows for Streamed Application Updates: When a company decides they would like to move a LOB application to the Azure cloud using ARA, it involves an image upload. Periodically, the application may require maintenance and patching. Without a demand technology such as App-V, this would require re-uploading and re-provisioning of ARA images. With App-V, applications that have been sequenced for streaming can be dynamically updated to the ARA images without the need to re-upload any new custom images.

On-Premises, Azure IaaS, and Azure RemoteApp resources can share application Content Sources: If your organization is currently leveraging App-V and streaming content from content stores – be it on-premises or in Azure IaaS, these same resources can also be leveraged by your ARA-provisioned images as well.

Scenarios for App-V with Azure Remote App

When designing a strategy for delivering App-V applications with Azure RemoteApp, you will pretty much follow along the same lines as you would when you are designing App-V for any other target. The exceptions in the world of App-V involve the current existing gaps between the App-V IaaS (Infrastructure as a Service) and the Azure RemoteApp PaaS (Platform as a Service.)

The following table outlines the pros and cons of the different options for App-V delivery, application storage, and publishing and targeting with Azure Remote App:

 

Configuration options		Pros		Cons
Delivery method	Streaming (on demand from content server)	Application is always the latest and fresh		Possible first time latency upon initial application launch
	Mounted (Pre-cached into the ARA image.)	Fastest 1st launch – all of the application assets are already present on the ARA virtual machine.		Potential Image Bloat – applications take up additional image space (remember the 127gb limit)
Primary Application location storage	Shared Content (Stream-to-memory)	App runs in memory of Azure RemoteApp instance		Eats memory and requires good connection to streaming (file) server where the app resides. Affects baseline.
	Disk (Cached)	Fast execution App not dependent on availability of Content Source		Bloat – takes up image space (127gb limit)
Targeting	User*	*Requires full standalone App-V infrastructure or Configuration Manager 2012 R2 or later
	Global (machine)	Pre-publish or target using Publishing server	Need to update your Azure image if you want to update the app.  (huge) Takes up some space on image

* In addition, User targeting also requires that the App-V application be pre-published via a path Publishing rule for the Azure RemoteApp collection.

 

More to come . . . 🙂

App-V 5 and Citrix Integration Resources

Whether it is integration with XenApp, XenDesktop, PVS, or UPM, App-V 5 is the recommended application virtualization and streaming model for Citrix Session and VDI environments. I work with a lot of customers who leverage App-V in this capacity and they have been asking me to maintain a “living post” that contains links and references to Citrix and App-V 5 integration resources.

So with help of App-V 5 SEE John Behneman, (you may recognize him from the official App-V support blog) below is a collection of Citrix KB and documentation links related to App-V 5.0 when integrated with Citrix technologies:

(Page will be updated)

Citrix-Hosted

Citrix Official App-V 5 Version Support Matrix for XenDesktop or XenApp and App-V 5.0
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-hosted-apps-intro.html

Choosing an application and desktop delivery method
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-apps-compare-delivery-methods.html

XenDesktop 7.5 and XenApp 7.5 Features and Entitlements
https://www.citrix.com/go/products/xendesktop/feature-matrix

Reviewer’s Guide XenDesktop 7.5
http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/xendesktop-reviewers-guide.pdf

Citrix App-V 5 Integration: Internals
http://blogs.citrix.com/2013/12/23/citrix-app-v-integration-internals/

User Profile Management and App-V 5  – Required UPM exclusions for App-V
http://support.citrix.com/proddocs/topic/user-profile-manager-5-x/upm-using-with-app-v.html

Random Application Fails When Using Standard Image Mode with the “Write Cache on Target Hard Disk” Option
http://support.citrix.com/article/CTX139627

Troubleshooting App-V 5
http://support.citrix.com/proddocs/topic/xendesktop-71/app-v-troubleshooting.html

Citrix EDocs on App-V XenApp 6.5 Publishing: Note that they redirect you to how to publish App-V 5 apps with Server 2012 RDS:
http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-pub-app-v.html

Citrix EDocs on App-V 5 XenDesktop 7.1 Studio Publishing Integration:
http://support.citrix.com/proddocs/topic/xendesktop-71/cds-get-started-current-configure-app-v.html#cds-get-started-current-configure-app-v

 

Microsoft-Hosted

App-V 5 and Citrix Integration
http://www.microsoft.com/en-us/download/details.aspx?id=40885

Microsoft-Citrix Virtual Desktop Infrastructure Technical Whitepaper
http://download.microsoft.com/download/1/7/C/17C16807-317A-4EFE-8197-16E76CB04D18/MS-Citrix%20VDI%20Whitepaper.docx 

 

Community Resources

App-V: A Configuration Template for Deploying to Stateless RDS Clients on Citrix Published Desktops with Citrix UPM for Profile Management

http://social.technet.microsoft.com/wiki/contents/articles/25318.app-v-a-configuration-template-for-deploying-to-stateless-rds-clients-on-citrix-published-desktops-with-citrix-upm-for-profile-management.aspx

App-V 5: On Run Virtual, RDS Run Virtual, Virtualizable Extensions, and Dynamic Virtualization

Update 12/6/2014: With the release of App-V 5 Service Pack 3, there is a change that allows the RunVirtual key to be added to the user's profile (HKEY_CURRENT_USER) to affect user-targeted applications. More information on this improvement can be found here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_runvirtual_reg_key

If you think that title is a handful, it simply a summary of most of the ways we allow local processes to interact with virtual environments in App-V 5. Whether or not you need to use these features will depend on factors such as targeting or if you want to take advantage of features introduced in App-V 5 SP2. Last year, I gave a primer in a blog on how to run a native process inside an App-V 5 package’s virtual environment. Well, recent question regarding internals as well as product developments have warranted a further discussion on the functionality of “running virtual: in App-V 5.

Run Virtual (RDS Run Virtual)

Designed really for RDS, I prefer to call this RDS Run Virtual as it was designed for RDSXenAppTerminal Servers. Why do I say that? Often application servers will be siloes for specific applications therefore they will likely be published globally. Through a simple registry key, you can have a local process interact with a specific virtual environment. As I mentioned in that blog from last year. You basically add process executable names as subkeys of the following key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientRunVirtual

For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID>)

If the package is also in a connection group, the native process will be launched into the virtual environment (connection group) where that package belongs. NOTE: The connection group obviously has to be published globally as well. If the GUID pair is invalid or not found, the application will launch natively.

Run Virtual on Demand (using switches /appvve)

I have received feedback on the fact that only global publishing is supported with the RunVirtual registry key. If the application is user targeted and you want a “Run Virtual” equivalent for a native process, you can use the /appvve switch. This is a nice option because it allows an application be brought into the virtual environment regardless of publishing target type. Unlike the RunVirtual key in the registry, you will have to manage this on a per-application basis. Thanks to the VirtualizableExtensions option in the registry, if you simply call the native process through a shortcut extension in the package’s dynamic deployment configuration file, it will run virtual automatically.

Virtualizable Extensions

Speaking of Virtualizable Extensions: This is a special registry value which determines which application extensions will be treated with “Run Virtual” if configured as an application extension point within an App-V application. The extensions are registered under the following registry key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientIntegration

The value is VirtualizableExtensions and it consist of a REG_SZ data type where all of the supported extensions are listed separated by commas. For example, when you sequence an application like the IBM DB2 client, you may notice that some of the shortcuts are .BAT and .CMD files. In order for those applications to be treated as App-V applications that register properly as extension points, those extensions need to be registered under VirtualizableExtensions. The defaults are: exe, com, bat, cmd, vbs, ps1, cpl, jar, wsf, and wsh. You could add a .TXT extension, but given that a TXT file is not executable by FTA design in Windows, it would be pointless as the most it would do is open up Notepad in the bubble with this extension. But let's say your script interpreter of choice was something like Visual Cobol and you wanted to process a script using a .CBL file. You would have to add in this extension. If a Visual Cobol is locally installed when a CBL script is called through an extension point, it will run it virtually.

Dynamic Virtualization

This was introduced in App-V 5 SP2 in order to give us shell extension support and native interaction with virtualized ActiveX controls. The registry value that toggles this on or off is EnableDynamicVirtualization and it is located in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientVirtualization

In addition, those processes that are specified for this feature are listed in the ProcessesUsingVirtualComponents registry value located in the same key. By default, Explorer.exe and Internet Explorer are listed there. You can see this in action by using a tool from SysInternals called LISTDLLS.EXE. For example, let’s say I’m on a client configured with the virtualization defaults for App-V 5 SP2 and I currently have one program launched: Notepad++ (yes, I admit it – I use it.)

When I run Get-AppVClientPackage from PowerShell, it shows I only have one application in use:

However, when I run the LISTDLLS.EXE command to find out which processes have the AppVEntSubsystems32.dll injected (or AppVEntSubsystems64.dll for 64-bit processes) you will see both notepad++ and Explorer have been hooked.

And if I were to launch Internet Explorer, I would see the same thing. Do not confuse this interaction with RunVirtual. Dynamic Virtualization has a limited scope of interaction designed for features introduced in App-V Service Pack 2.

 

Update: 2/7/2014

While I rarely update my blog posts (except for resource pages) it appears that I need to expand further based upon the feedback and comments I have received. When you are virtualizing an application that uses shortcuts that point to BAT or CMD files, you configure these shortcuts just as you would any other application. I’ll use the example of the DB2 client. It sets up a perfect example.

Notice in the figure below we have captured some applications that are executables and some that are scripts.

 

The shortcut to Command Line Processor Plus (CLPPLUS.BAT) appears as it normally does in the shortcut dialog box.

 

And the Command Line Processor (which calls a batch file as an argument) appears as normal as well.

Now both of these will be captured into the manifest and dynamic configuration as such:

 Upon the publishing/configuring of the package the shortcuts will then get applied as shortcuts that run inside the virtual bubble. The EXE’s are published with the respective scripts as arguments:

 

But while EXE’s launch from the integration path and get directly hooked, you will notice that script extensions (BAT, CMD’s) get /appvve applied to it to ensure it launches in the correct bubble:

 

 The publishing components knew to do this because the extension was listed under the VirtualizableExtensions value inside the App-V registry.

Update 12/6/2014: With the release of App-V 5 Service Pack 3, there is a change that allows the RunVirtual key to be added to the user's profile (HKEY_CURRENT_USER) to affect user-targeted applications. More information on this improvement can be found here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_runvirtual_reg_key

App-V 5: Why are all of these Different Language Shortcuts Displaying in my Start Menu?

If you have been using App-V 5 SP1 with RDS (Remote Desktop Services) or Citrix XenApp servers, you may have noticed that when you installed the App-V 5.0 Service Pack 1 RDS Client using the EXE installer (no extraction) – this creates shortcuts for all 24 language packs on the start menu for Windows Server 2008 R2 machines. This was indeed a mistake which has been corrected with the SP2 EXE installer.

However, you may have noticed the SP2 version of the EXE installer still installs all of the 24 language packs. You will not notice this in any shortcuts but it will be visible in the Programs Control Panel as well as the App-V client installation folder. This is by design as the RDS EXE installer installs all the language packs so as to be able to service users from multiple locales by default. If you only want to install a certain language pack, I would advise for you to extract the MSI for the client and subsequent language packs by using the /LAYOUT and /layoutdir switches to extract the MSI files out.

More information on these switches can be found here: http://technet.microsoft.com/en-US/library/jj713460.aspx

Then you can install the MSI separately and will also allow you to suppress reboots for silent deployments using the /norestart switch. Bear in mind the EXE installer also detects (and applies if not found) some (but not all) prerequisites. Remember these will have to be deployed in advance when installing the App-V Client using the MSI installer.

App-V 5 and Citrix Integration: New Whitepaper

Ever since the summer (TechEd) I have been promising customers we would have a white paper coming on this. Well, we have just published a new App-V 5.0 and Citrix
integration overview white paper.

Whitepaper Title:  App-V 5.0 and Citrix Integration overview

 

Abstract: This whitepaper is designed to provide administrators with guidance for combining Microsoft’s App-V 5.0 and Citrix solutions. It discusses the benefits of an App-V 5.0 and Citrix combined solution, and includes recommendations for Citrix images, App-V cache management, App-V management with Citrix, and other factors that impact user experience and administrative effort. Whether you are using XenApp or XenDesktop, this paper will be a must read!

 

It is available to download here

(Direct Link – http://download.microsoft.com/download/C/4/1/C416F9FD-1B51-4E1D-9DBE-87C12AB329A2/App-V5_and_Citrix_Integration_Overview.docx)

App-V 4.6: Are you using the Latest Version of the Client and Sequencer? You should be.

When many organizations move to Windows 7, they also take on the task of discovering, inventorying, testing, and remediating all of their current applications currently used in production. Often part of that process includes a decision to deliver those applications with App-V. The App-V 4.6 SP1 Sequencer and client offers a streamlined workflow to virtualize, package, and deliver those applications to the desktop or RDS server providing a simplified, centralized approach to application delivery and management. It also, at the same time, resolves many application interference issues through isolation and state separation.

When a product such as App-V undergoes a significant maintenance release, there are always the possible regressions. With 4.6 SP1, there were a few, and the App-V team was able to quickly isolate many of them and provide fixes in a timely manner. Servicing is always an important process in the support of production software.

App-V service releases (a.k.a hotfixes) are released in a manner that allows for the simplification of the deployment of fixes. Hotfixes are based on major release points (i.e 4.6, 4.6 SP1) and are designed to be cumulative. This way, if you deploy the recent hotfix pack, you can rest assured you are getting all of the cumulative patches released since the last major revision. In the case of App-V 4.6 SP1, the most recent release is 4.6 Hotfix Package 6 (build 4.6.1.30121.) if you are not currently running your 4.6 clients at this build you can leverage the hotfix download link found with the associated KB article here:
http://support.microsoft.com/kb/2693779

The hotfix packages are made available in MSP format. This allows for flexibility in enterprise deployment of the patch.  Remember, since the patches often affect revision changes of the App-V filter drivers, a reboot is necessary when deploying the patch.

But What about the Sequencer?

As many client changes involve patching the App-V System Guard (the component that facilitates the virtualization engine) it requires making revision to the App-V 4.6 SP Sequencer as well. I always advise all of my customers to ensure that they are always using the most recently released build of the App-V Sequencer.
The relase process for the sequencer is slightly different. Not every cumulative patch, involves a change to the sequencer. With this, you will not always see inclusion of the sequencer with every cumulative hotfix release. In the case of the most recent release of App-V as of this writing, the most recent service release of the App-V 4.6 SP1 sequencer is the refresh build that came with 4. SP1 Hotfix 3. You can download the release via the KB article for the hotfix here:

Hotfix Package 3 for Microsoft Application Virtualization 4.6 SP1: August 2011
http://support.microsoft.com/kb/2571168

Instead of an MSP file, when a sequencer is patched, an entirely new installation is made available. This makes sense because sequencer machines are often never “upgraded.” They are often cleanly reverted. This allows sequencing engineers to refresh their machines images used for sequencing in a clean manner without having to worry about patching.

App-V: Refresh “On-login” and Slow Startups in Windows 7

When you configure App-V’s desktop configuration refresh feature (i.e. DC Refresh, Publishing/Refresh) you have the option of setting this to occur “on login” and/or using a periodic interval. This configuration can be controlled at the client end or, in the case of an environment using the traditional App-V management server environment, can also be controlled via the provider policy.

The “On-Login” option is partially facilitated by registering the desktop configuration controller (SFTDCC.exe) into USERINIT under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon key.  A default installation of both the desktop and RDS App-V clients will do this and start SFTDCC on login. This option is always generally recommended for startup if the publishing configuration for applications is coming from an App-V management server. If you want to remove the on-login behavior, it is best recommended to do this through the client user interface or through a provider policy. Removing the SFTDCC entry from the USERINIT registry entry will simply result in the entry getting re-registered the next time the App-V client service restarts.

The “on login” behavior is a good thing because it ensures all of the user initialization, application asset caching, publishing (Icons, OSDs) and other setup is facilitated around the same time the user’s desktop becomes available. It also corrects potential problems.  For example, if another user had previous logged onto that desktop and for some reason deleted an application while you were logged out, this will re-provision your application.

In addition, if your access to an application was revoked while you were logged out, this is the process that hides your shortcuts, and essentially hides the application from you. This occurs even if the
applications assets were previously fully cached. If the SFTDCC component were not configured to start on login, or worse yet, the SFT Listener process were not engaged (most common if the App-V Client services is set to manual) the
shortcuts and assets would still be there, but they would not work. 

Slow Startups

A common misconception is that sometimes this “on-login” feature causes slow startups in Windows 7. While true, there have been issues where the presence of the App-V client has been a factor in slow startups, there is more to the story than that simple statement. Common troubleshooting steps that have been employed have involved setting the App-V Client service to manual (and thus devising some workflow to start the service post user login) or even removal of SFTDCC from USERINIT. I would advise against either of the above steps as this issue could be one of a few known bugs that have been fixed on both the App-V side as well as the Windows 7 side.

First and foremost, all of the major App-V startup bugs have been isolated and fixed as of App-V 4.6 Service Pack 1 hotfix 3. If you do not have hotfix 3 installed, please install it. You can download this via (http://support.microsoft.com/kb/2571168.) Of course, I would always recommend installing the latest hotfixes for App-V 4.6 SP1 but this one is essential for clearing up a lot of the slow startup problems.

In addition, I would also advise ensuring the following hotfixes have been installed for Windows 7 or Windows Server 2008 R2 to alleviate slow startup problems:

Unexpectedly slow startup or logon process in Windows Server 2008 R2 or in Windows 7

http://support.microsoft.com/kb/2617858

The desktop does not load and only displays a black or blue background after you log on to a computer that is running Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2590550

And of course, don’t forget, it could be other software causing the slow startup and App-V may just be an innocent victim. Remember this? – https://madvirtualizer.wordpress.com/2011/08/18/yes-trusteer-rapport-does-break-app-v/

 

App-V: Why would new users on RDS/Terminal Servers not get any App-V Applications?

App-V: Why would new users on RDS/Terminal Servers not get any App-V Applications?

I recently came across a situation where a customer was in a panic because newly provisioned users were unable to receive any applications on their RDS Servers. Existing users were actually able to launch applications just fine and they appeared to be pre-cached properly. The scenario always seem to be tied to specific users as all of the users leveraged roaming profiles to maintain consistency across the farm.

The first thing to always do in this situation is verify connectivity to the App-V management server. This was quickly done. In addition verification of user group/provider policy configuration was also very quick as all users were part of the same global group tied to the server’s provider policy.

The next test quickly confirmed the issue. From both a user experiencing this issue and a user not experiencing this issue, a simple SFTTRAY /refreshall was performed and it was quickly revealed that the RDS servers running the App-V client had been specifically placed in offline mode.

The Virtual Application Client could not refresh your publishing information.

The Application Virtualization Client is operating in offline mode and cannot perform the operation requested. Disable offline mode, ensure that you have a network connection, and then retry the operation. If the problem persists, report the following error code to your System Administrator.

Error Code: 4615186-19101601-0003100F

The interesting aspect is this was done only after the first batch of users had logged on and initially refreshed against the server. Then the “Online” value beneath the following registry key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5ClientNetwork
Was set to 0. Setting the key back to 1 allowed the new users to refresh and get applications upon login.

The administrator wanted to “cut down on excessive traffic” as he had read on a web site where this would be a good trick. As you can see from the example above, there are ramifications of doing this. In addition, this is the exact reason Microsoft offers Stand-alone mode as an option.