We know how to bring Internet Explorer into the App-V bubble. It’s as simple as creating a special shortcut that points to an OSD file that allows the local instance of Internet Explorer to interact inside the virtual bubble of an App-V package (http://support.microsoft.com/kb/931986) - But there has always been the issue of ensuring the user is clicking on the correct shortcut. This is essential to proper functionality when leveraging App-V to virtualize plugins and add-ons for customized webapps. So, one of the most common question I get from customers that I have always assumed the answer was readily out there is:

How do I launch Internet Explorer configured to run inside the Virtual Environment from a simple URL Shortcut?

This is a great question because placing a direct shortcut to the website/webapp provides a direct point of access for end-users. You can create a shortcut that will launch the IE shortcut configured ot run inside the bubble. There are several ways to create the shortcut but the easiest way I have found to do this is to:

1.) Launch the Application Virtualization Client management console.
2.) From the Applications node, look for your published instance of Internet Explorer. For example, you may have customized it i.e. “Internet Explorer inside Office 2020 package.”
3.) Right-click the application and select “New Shortcut.”
4.) In the next screen customize your shortcut name. Click Next.
5.) Place the shortcut in your desired location. I usually place it on the desktop.

Once you have placed the shortcut on the desktop, then right-click the shortcut and select properties. In the target field you will want to add the argument for the website URL you will want to use for this customized shortcut. The syntax you will use will vary depending on platform and management methodology:

32-bit clients using SFTTRAY as Launcher (Traditional App-V Infrastructure, Stand-Alone implementation)
C:\Program Files\Microsoft Application Virtualization Client\SFTTRAY.EXE /launch “<APPNAME>” <URL>

64-bit clients using SFTTRAY as Launcher (Traditional App-V Infrastructure, Stand-Alone implementation)
C:\Program Files (x86)\Microsoft Application Virtualization Client\ SFTTRAY.EXE /launch “<APPNAME>” <URL>

32-bit clients using VAPPLAUNCHER as Launcher (Config Manager 2007 Integration)
C:\Windows\CCM\VAppLauncher.exe /launch “<APPNAME>” <URL>

64-bit clients using VAPPLAUNCHER as Launcher (Config Manager 2007 Integration)
C:\Windows\CCM\VAppLauncher.exe /launch “<APPNAME>” <URL>

- Where <APPNAME> is the name of the application published (Internet Explorer) and <URL> is the URL to the website.

To take this further, if you have Internet Explorer configured to launch via an App-V application (i.e. with Office, or running a virtual web application) you can modify the registry to point the shell-open shortcut function for the http object to the OSD instead of the local instance of Internet Explorer.
To make this modification:

1.) Navigate to the following Registry Key:

 HKEY_LOCAL_MACHINE\Software\Classes\http\shell\open\command

The default value is normally the path to iexplore.exe, like “C:\Program Files\Internet Explorer\iexplore.exe”.

2.)    Modify the value to have the sftdde.exe process launch the virtual version of IE, using the syntax:

<PATH TO APPV DDE LAUNCHER>  “<APPNAME>”  IExplore –nohome

for example:

"C:\Program Files\Microsoft Application Virtualization Client\sftdde.exe" "IE in Microsoft Office 2010" IExplore –nohome

- Would work on 32-App-V clients running with SFTDDE.EXE as the DDE launcher. You can find this out by looking at the DDELaunchCommand in the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface

(or HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\UserInterface if 32-bit clients.)

NOTE: IExplore is the DDE name for Internet Explorer (if you don’t get that right, when you try to launch a URL you get an error from the shell about being unable to pass the parameter to the app). -nohome is the same parameter I found on the original IE command line.

This will require the user to log off and log back on. A full reboot will be better especially on terminal services clients.
One final note: The registry change will have to be pushed out and I have found that customers find the fact that it (the shell modification) cannot be turned on or off with app availability via refresh/publishing frustrating. It’s a good work-around in my opinion though if you are planning to continue to use App-V 4.6 for time being.

Here is another interesting one-off issue that was happening on a few machines in one of my customer’s environments. They were using App-V 4.6 with Configuration Manager 2012 managing the packages. The virtual applications were distributed fully cached to the clients (download and execute.) The problem was that the download to the cache would never be able to progress beyond 99% thus the application would never become available to the client.  This was happening on all virtual applications for the affected clients. The Configuration Manager CAS.LOG showed the following:
 
Download completed for content Content_74cfa5bd-d3981-21fc-2316-4c3e8659f7a690.1 under context System      ContentAccess   12/5/2012 11:15:35 AM   4460 (0x116C)
CreateFileW failed for c:\windows\ccmcache\11\xxxxxxxx.sft      ContentAccess   12/5/2012 11:15:35 AM   4460 (0x116C)
楆敬灏湥 failed; 0x80070020 ContentAccess   12/5/2012 11:15:35 AM   4460 (0x116C)
慈桳潃瑮湥t failed; 0x80070020       ContentAccess   12/5/2012 11:15:35 AM   4460 (0x116C)
潃灭瑵䍥湯整瑮慈桳 failed; 0x80070020    ContentAccess   12/5/2012 11:15:35 AM   4460 (0x116C)

The specific HREF error code 80070020 translates to “The process cannot access the file because it is being used by another process.”

Process Explorer to the Rescue

Using Process Explorer (found here: http://technet.microsoft.com/en-us/sysinternals/bb896653) we found that the “System” process had an open handle to all of the various SFT files in the CCM cache (C:\Windows\ccmcache\11\xxxxxxxx.sft.) Using MSConfig and disabling all 3rd-party services and startup items (as well as the Configuration Manager client service (SMS Agent Host) we still found that the system STILL had an open handle to all of these SFT files in the CCM cache. Further investigation of the stack revealed there was a mini-filter driver attaching to the SFT files. The filter was identified in Process Explorer as AppVFltrPort. This corresponded to the SFTVIEW.SYS file. This file was part of the Microsoft Application Virtualization SFT View application (that is available from http://www.microsoft.com/en-us/download/details.aspx?id=8897).  It has a mini-filter driver that attaches to SFT files even when you are not using the program.  The problem shows up as soon as something uses the file system near (one level down) to a SFT file on a client computer. 

Uninstall SFTVIEW from Clients

In the above case, the solution was to simply uninstall SFTVIEW or disengage the AppVFltrPort driver. The SFTVIEW tool was meant to be installed outside of production until you are ready for deployment onto content stores. The purpose of having this application on content stores is to provide read-only access to on-access anti-virus scanners so they can scan the contents of the SFT files. If you are looking to view content information or extract meta-data from SFT files, use the SFT Parser instead when working on clients. You can get that here: http://www.microsoft.com/en-us/download/details.aspx?id=12350. If you want anti-virus scanners to be able to scan the App-V client cache, use Service Inclusions instead. More information on Service Inclusions can be found here: http://blogs.technet.com/b/gladiatormsft/archive/2012/08/01/app-v-4-6-using-service-and-process-inclusions.aspx

Microsoft Application Virtualization 4.6 Service Pack 2 is now available via Microsoft Update. This also means that you can leverage WSUS as well as the software updates feature of Configuration Manager to deliver this update to your RDS and desktop clients. This is the third service pack that App-V has delivered via
Microsoft Update.  You can view all the Microsoft Application Virtualization updates available via Microsoft Update from the following link: http://catalog.update.microsoft.com/v7/site/search.aspx?q=application%20virtualization

Back in 4.x, we pretty much had one of two ways to launch an application inside the virtual environment or “bubble” as it is often called. One way was through the use of a pre-launch script. This was cumbersome in that you had to either modify the cached OSD or even worse, modify the original OSD file and re-deploy/refresh. Since I always used this for troubleshooting purposes, I found it easier to modify the cached copy of the OSD file. Starting in version 4.5, we also had a way of launching an alternative native executable inside the virtual environment by simply adding parameters to the SFTTRAY.EXE command:

C:\Program Files (x86)\Microsoft Application Virtualization Client\sfttray.exe" /exe cmd.exe /launch "DefaultApp MFC Application 1.0.0.1

App-V 5 offers us even more flexibility in this regard. To start off, do not use the scripting elements in the dynamic configuration XML. It is completely unnecessary and a waste of time. APP-V 5 offers many ways of getting inside "the bubble."

Powershell

You can use the Start-AppVVirtualProcess cmdlet such as the following example to retrieve the package name and start a local process within the specified package's virtual environment:

$AppVName = Get-AppvClientPackage *name*

Start-AppvVirtualProcess -AppvClientObject $AppVName cmd.exe

This way allows you to do something similar to the previous variant of SFTTRAY in which you can initialize an App-V virtual environment substituting a local command as the process running within that virtual process.

The Command Line Hook Switch “/appvpid”

This allows you to apply the /appvpid switch to any command which will allow the command to run within the virtual process of the virtual process you selected by its PID (Process ID) as in the example below:

cmd.exe /appvpid:8108


The Command Line Hook Switch “/appve”

Where the /appvpid switch requires the virtual process to already be running, this switch allows you to start a local command and allow it to run within the virtual environment of an App-V package and will initialize it. The syntax is as follows:

cmd.exe /appvve:<PACKAGEGUID_VERSION_GUID>

The syntax is a but cumbersome as it requires both the package GUID and the version GUID:

cmd.exe /appvve:bcfdbe1b-8bff-4502-b4e2-5a773e82d86c_2ef3aaf9-9864-44a3-85dd-bf99a6b4d8f2


Run Virtual

If you are working within RDS environments, and have a package that is published globally, you can also take advantage of the “Run Virtual” feature. You basically add process executable names as subkeys of the following key:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual

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> or such as in the figure below:

 
Each native process that needs to run locally will require its own subkey beneath the Run Virtual key. As long as there is one version of the EXE on the system, placing the package\version GUID combination in the default key value will suffice. If there is more than one version of the EXE installed on the machine, you will need to create a new REG_SZ value beneath the subkey and specify the value name by using the full path to the EXE.

Flexibility

The above options give you much flexibility in how you merge native processes with virtual environments. With App-V 5, these not only add interoperability options, but they enhance our troubleshooting toolkits.  There will not be any reason to go into dynamic configuration XML in order to do this.

PS: Yes, I know I have not been blogging enough on APP-V 5. I promise to change that. I do have customers to tend to, you know! ;)

It is almost easier to pretend you know nothing about App-V 4.x scripting when looking at scripting in 5.0. That is often my first response to many rumblings about difficulty getting scripting set up in 5.0. These rumblings come mostly from users of App-V 4.x. Change is hard, I know, but we have a better set of options and frankly, in my opinion, it’s much better this way in the long run. It is just a paradigm shift that does require somewhat of a translation process for bringing older scripts from 4.x over to 5.0.

No More SCRIPTBODY (Embed in the Package, not the XML)

First of all, there are no more <SCRIPTBODY> elements. Instead of embedding the script inside the XML, the intent is to have the script embedded inside the package in the .\Scripts folder. This is the ideal place for it as it will be one of the default search paths when calling a script. If you have already sequenced a package (or converted a package) and want to add a SCRIPT element into the dynamic configuration, you will need to specify the path to the script interpreter and script file. So in essence you have as the command and argument the script interpreter as the command and the script (and options) as the argument.

Not Enabled by Default

Before you even begin to start testing scripts, you will have to make sure the client is set up to allow for package scripts. The quickest way to do this is through PowerShell using the following

Set-AppvClientConfiguration -EnablePackageScripts $true

You can also do it by GPO or manually in the registry. Always verify this before testing scripts.

Security Context

Some scripts will run in the SYSTEM context or the currently logged on user depending on the scripts package event. Later I’ll discuss workflows that will also help you determine the context (Machine or User) for running the script (which is another new concept in 5.0.) The following table outlines how the security context relates to the package event.

Package Events?*

You need to forget the concept of PRE and POST events. Scripts can be called based on specific events in the lifecycle of the package. You will need to know at what point you want the script to be triggered. If your script needs to run in a specific context, this will help determine your event. If you decide your script needs to be triggered during application initialization (at the start of the virtual environment, the start of the process, when a process exits) you will need to also specify the specific application, rollback options, and whether you want to run it inside or outside the virtual environment.

*I so want to call this “event trigger” but it would be confusing.

To explain how the PRE and POST Options of before evolved into Package Event Elements – but not directly – look at the table below:

The key is to know what package/app event you want to trigger execution: (AddPackage, PublishPackage, StartVirtualEnvironment, StartProcess, ExitProcess, TerminateVirtualEnvironment, UnPublishPackage, RemovePackage)

Wait Options

In addition to the command <Path> and <Arguments> you have your “Wait” options (Wait, RollbackOnError, Timeout.) If you have a <Wait> element with nothing else, it will default to RollbackOnFailure=”True” and Timeout=0.

Element Flow

When we put it all together, you will see the element flow follows this basic process:

    [MACHINE OR USER CONTEXT?]

      [EVENT TO TRIGGER EXECUTION?] [IF VE or Process Event – Also the option of running inside the VE]

        [MY Command Path]

        [MY Command’s arguments]

        [My Wait Options]

          [Optional AppID EXE w/ tokenized path if this is a Process event]

Where an example of a machine targeted script looks like this:

    <MachineScripts>

      <PublishPackage>

        <Path>PowerShell.exe</Path>

        <Arguments>-f file.ps1 </Arguments>

        <Wait RollbackOnError="true" Timeout="30"/>

      </PublishPackage>

As another example, if a script was targeted for a user, set for PRE LAUNCH/ABORTRESULT=1/PROTECTED=TRUE in 4.x, and was only needed for one app, you could call it this way in 5.0 

    <UserScripts>

      <StartProcess RunInVirtualEnvironment="true">

        <Path>cscript</Path>

        <Arguments>myscript.vbs</Arguments>

        <Wait RollbackOnError="true"/>

        <ApplicationId>[{AppVPackageRoot}]\Directory\Subdirectory\App.EXE</ApplicationId>

      </StartProcess>

Deployment Configuration and Dynamic User Configuration

Many of the problems with testing scripts come with proper placement in deployment and dynamic configuration files and how they are targeting. Scripts that need to be called during package add and global publishing events should be part of the DeploymentConfig.XML file. These scripts will also run in the context of the local system account so scripts that map drives, for example, should not go here. Those need to be called as a <UserScript> element. I use the following visual workflow to help me determine targeting and publishing.

In the case of global publishing, the deployment configuration also has a UserConfiguration element in addition to MachineConfiguration which means that scripts appearing during these events will apply to all users when the package is published globally. This would be the appropriate place to have scripts which map network drives.

For those enterprises using 3^rd-party ESD (Electronic Software Distribution) products to deploy and manage software, use of the MSI-wrapper makes it easy to incorporate these types of applications into their environments. In App-V, when you “install” a virtual application using the MSI wrapper, all that is being done are custom actions that add and publish the package globally to all users on that machine. In addition, it will place an entry in the “Program and Features” list (formerly Add/Remove Programs.) This entry in the programs list is pretty much the difference between using the MSI to publish the application instead of manually using the PowerShell AppV cmdlets. Because of this entry, it is also advised to always use the programs list (or the msiexec /uninstall command) to remove the application instead of the manual PowerShell commands in order to prevent an orphaned entry from remaining.

It is also important to note that the MSI checks are more resilient in v5, where if you try to uninstall an application that is currently in use, it will echo a 0200000508 error:  

Following the warning, the uninstallation stops, the package will remain and the entry will remain in the programs list. This is different from 4.6 where the entry would get removed while the virtual application would remain published and you would have to manually remove the application using SFTMIME cleanup commands. The specific error in 4.6 would be:

The Application Virtualization Client could not complete the operation.

The operation failed to complete because the package is still in use. Report the following error code to your System Administrator

Error code: xxxxxx-xxxxxx04-00001808

In 4.6, once you got the 1808 error, at this point you had to remove the application using the manual SFTMIME command (SFTMIME DELETE PACKAGE) http://technet.microsoft.com/en-us/library/cc843829.aspx

If you are using a 3^rd-party ESD (Electronic Software Distribution) product to manage applications, you can query the WMI namespace for App-V to determine if a package is still in use in order to prevent this from happening.

If the package is indeed in use, you can then use the Stop-AppVClientPackage and/or Stop-AppVClientConnectionGroup cmdlet although the standard caveats apply with regards to open documents and unsaved information.

Speaking of WMI

In V5, the WMI classes are now located in a different namespace (\root\appv) and the classes have been expanded to align with PowerShell objects. The classes are:

• AppVClientPackage
• AppVClientApplication
• AppVClientConnectionGroup

You can use PowerShell, VBScript, WMIC, or native/managed code to query WMI to get information about virtual applications, packages, and connection groups. For example, you can inventory packages using these PowerShell commands:

$VPackages = Get-WmiObject -Class AppvClientPackage -Namespace root\appv

$VPackages | Format-List -Property Name, InUse, PercentLoaded

What is really great about App-V 5.0’s WMI is the inclusion of Connection groups which allows extensibility for management of not only applications, but super-bubbles (especially with Configuration Manager 2012 SP1 - which actually refers to them as virtual environments.)

"Where are these 0xc0000142 errors coming from in App-V 5.0?"

There has been some chatter revolving around this generic application error that is happening with many LOB (Line of Business applications) running virtualized with App-V 5.0. You will also note that for a lot of these applications, this issue did not occur in previous versions of App-V. The error is as follows:

The application was unable to start correctly (0xc0000142). Click OK to close the application.

First of all, this is not an App-V error but rather a generic application error. Does this mean that App-V did not play some role in it? No. Obviously that would not be the case if the application behaved fine prior to virtualization. So in order to isolate what App-V’s role is, we need to understand first what the error means.

This error (0xc0000142) technically resolves to STATUS_DLL_INIT_FAILED in the native API – which simply means that it was unable to load or initialize a critical DLL, etc. If there is a DLL mismatch or some other type of subsystem failure, you will get this error. If the DLL can be found and loads but fails to initialize, you will also get this error.

I know of one type of application where you may find this most prevalent. In one specific type of use case, there may be applications that are written with client-side “bootstrap” executables. These executables then load server-side modules over the network. These applications were written to allow for ease of updating on the back end. In App-V 4.x, when these applications loaded these modules, they would be impersonated on behalf of the user so the user just needed to have read and execute permissions to access these modules over the network. Even under App-V 4.x, these modules would be brought into the bubble under the context of the current user account.

In App-V 5.0, the App-V Client is running as system, which means file operations will operate under the AppVClient.exe process which will be running under the context of the local system account and not the user account. Even though the executable is loaded into the context of the user running the program, the file operation will be spearheaded by the AppVClient.exe process and the access will not be impersonated. So in the case of these 0xc0000142 errors, it is likely because there is a file operation that is occurring under the system account. It will fail authentication, thus preventing the loading of the DLL causing this error.

How do I know if this is the case?

Once again Process Monitor will be your friend. It will involve a very simple procedure to isolate this. First reproduce the issue while capturing the events with Process Monitor. Once you have done that all you need to do is apply a quick filter to see if, in fact, the AppVClient.exe is getting a logon error when trying to access the share where the DLLs are located. The events you need to filter for are:

• Process Name: AppVClient.exe
• Operation: Create File
• Result: LOGON FAILURE

 So what do I do now?

You can resolve these errors by granting access (RX) to the directory for the computers accessing the shares as SYSTEM. Bear in mind they will need that at both the share level and the NTFS level. As of now, that appears to be the best point of remediation.

One touchy feature that has frustrated packagers has been the issues arising when the ODK (Office Deployment Kit) proxies are not configured properly. When this happens, search will not properly work, MAPI configuration will not work properly, and even headaches with “Mail” Control Panel. The erro displayed is very quick and very terse.

The Application Virtualization Client could not launch the application you requested.

The specified application does not exist. Check the name you specified, and then try again.

Error code: xxxxxxx-xxxxxx04-00000A09

The error is pretty straight-forward. The App-V client went to launch an application using the SFTTRAY command, and it does not match anything published on the client – but you know it’s there, right? You checked. The OSD matches. Even launching the OSD manually with the SFTTRAY works. So what in the heck is going on?

4.6 Proxies – Trail of Consistency

By design, what you specify during the deployment of the ODK (Office Deployment Kit) is extremely important in the automation and integration of these proxies, or virtualization handlers as they are more appropriately called. When you are sequencing Office 2010 and deploying via App-V, you have to also deploy the virtualization handlers using the Office Deployment Kit. As you can see from the diagram above, the command to call the virtual application (in this case – the mail search) will be constructed based upon two options specified when deploying the Office Deployment Kit - PACKAGEVERSION and the name of the Proxy (i.e. MAPIPROXY, MLCFG32CPL, etc.) In the case of the mail search, it is VIRTUALSEARCHHOST. This information is mentioned deep inside the Prescriptive Guidance document, but is often overlooked. What is not mentioned is that these will be registered locally in the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\CVH

In the case of the Virtual Search Host, a subkey called Click2runWDSProxy should exist with an entry for the Package GUID in {GUID} format followed by the SFTTRAY command to launch the application.

So let’s say you install the Office Deployment Kit using the following parameters:

ADDDEFAULT=Click2runMapi,Click2runWDSProxy,Click2runWDS,Click2runOutlookProxies,OSpp,OSpp_Core,Click2runOWSSuppProxies PROPLUS=1 OUTLOOK=1 KMSSERVICENAME=booger.contoso.com OUTLOOKNAME="Microsoft Outlook 2010" PACKAGEVERSION="14.0.6025.1000" PACKAGEGUID="{GUID}” MAPISERVER="Microsoft Virtual Office Simple Mapi Proxy Server" VIRTUALSEARCHHOST="Search MAPI Protocol Handler Host" MLCFG32CPL="Mail" OWSSUPPServer="Microsoft SharePoint Client Support Manager" 

The Office Deployment Kit will have the expectation that the following will be configured during sequencing:

If you leave out the PACKAGEVERSION option, that’s bad. That will add an additional trailing space to the constructed SFTTRAY command. Even if you include the version in the name, leaving out the PACKAGEVERSION option still causes this. This means you will need to make sure all of the versions specified in the application names (created during sequencing) are identical so the right virtual application will then be launched and you can avoid those A09 errors.

Before Upgrading to App-V 4.5 SP2 on the management server, it is recommended to first review the release notes for added features such as SQL mirroring support.

App-V 4.5 SP2 Release Notes

http://technet.microsoft.com/en-us/library/ff699130.aspx

Also, you can download the installation for SP2 here:

http://www.microsoft.com/download/en/details.aspx?id=25291

The following are recommendations for preserving information and critical data to ensure a proper rollback is available in the event of an upgrade failure or a desired rollback to a previous version of the App-V server.

1.)    Backup a copy of the App-V management SQL datastore. In SQL this is the APPVIRT database by default.

2.)    If .NET 4.0 is installed and you are using Windows Server 2003, The current work around is to:

a. Remove the .NET 4.0 (temporarily as it will be re-added later.)
b. Restart the server.
c. Perform the Upgrade. Restart the server.
d. Reinstall the .NET 4.0 Framework.

The following are recommended options for rollback should an error occur during upgrade.

In the event of a 25109 error, please use Rollback Option #1 for rolling back the server to its previous state.

In the event of a 25119 error (or any error not otherwise mentioned), please use Rollback Option #2 for rolling back the server and data store to its previous state.

In the event of a 2512* error, please use rollback option #3 for rolling back the AppVirt management Service (ASP.NET Web Management Service) to its previous state.

In the event that the installation completes successfully and you decide for reasons otherwise not mentioned here to roll back the server to its previous state, please refer to Rollback Option #2 for rolling back the server to its previous state.

A 25109 error indicates failure to connect to the database. In the event of this error, all that needs to be rolled back are the binaries on the App-V Management Server.

1.)    After the installation rolls back, very connectivity to the App-V Management server.

2.)    If the binaries list version numbers at SP2 (4.5.3.XXX) uninstall the App-V Management server and reinstall your previous version.

A 25119 error or a successful completion of the upgrade means that both the App-V Management server binaries and the SQL data store have been upgraded. The rollback procedure requires both the server binaries and the data store to be reverted back to its previous version.

1.)    Restore the previously backed up version of the App-V data store on the SQL server back to its previous version.

2.)    The App-V Management Server will likely be rolled back to its previous version during the installation. If this as a rollback following a successful installation then the existing version will need to be uninstalled and the previous version will need to be reinstalled.

1. Manually uninstall ONLY the AppVirt Management Service (Service – not server.)

2. Restart the server.

3. Reinstall AppVirt Management Service component from SP2 media.

Symptoms:

If you open a Visual Studio 2008 package for upgrade (or simply upgrade in the 4.6 SP1 sequencer) and upgrade the package to Visual Studio Service pack 1, it may fail to function properly on the App-V Client.

Cause:

This is caused by the Visual Studio SP1 installer setting a reparse point for key SxS (side-by-side) assemblies. The Visual Studio  2008 Service Pack 1 installer sets a reparse point from

<%SFT_MNT%>\<root>\VFS\CSIDL_WINDOWS\assembly\GAC_MSIL\WcfSvcHost\0.0.0.0__31bf3856ad364e35

to

<%SFT_MNT%>\<root>\VFS\CSIDL_WINDOWS\WinSxS\MSIL_WcfSvcHost_31bf3856ad364e35_9.0.0.0_x-ww_e0abf5ea

This means that if the application on the client looks for the files in the first location, they won't be found because they are actually only located in the latter.  When running virtualized on the client, the VFS does not reflect to the application the fact this is a reparse point. The application thinks the files will be located here but they are not actually found here.

Resolution

During the monitor phase, when the upgrade application has completed, you will need to open a  command prompt and copy the files from:

Q:\<root>\VFS\CSIDL_WINDOWS\WinSxS\MSIL_WcfSvcHost_31bf3856ad364e35_9.0.0.0_x-ww_e0abf5ea

to

Q:\<root>\VFS\CSIDL_WINDOWS\assembly\GAC_MSIL\WcfSvcHost\0.0.0.0__31bf3856ad364e35

so they are located in both locations.

For example, If the drive used for the SFT_MNT volume is Q:, then the syntax for copying via XCOPY would be:

XCOPY /S /E Q:\<root>\VFS\CSIDL_WINDOWS\WinSxS\MSIL_WcfSvcHost_31bf3856ad364e35_9.0.0.0_x-ww_e0abf5ea Q:\<root>\VFS\CSIDL_WINDOWS\assembly\GAC_MSIL\WcfSvcHost\0.0.0.0__31bf3856ad364e35

Administrators can use the System Utilization Report to graph the total daily system usage. You can use this report to determine the load on your App-V Server.

This report tracks the usage over time during the reporting period for the specified server or for the server group.

The System Utilization Report also graphs the following system usage:

• Usage by day of the week
• Usage by hour of the day

The System Utilization Report also includes a summary of the total system usage for specific users and total session counts.

There is an issue, however that you may run into when you try to run a System Utilization Report by session count where you may get the following error:

Error: 0000B065

The SFTMMC.LOG (Management Console log) will also show the following:

2011-10-14 04:35:31                  https://steveth-appv/
ManagementConsole.MCException: Arithmetic overflow error converting expression to data type int. ---> SoftGrid.Management.GetReportDataFailedException: Arithmetic overflow error converting expression to data type int. ---> System.Data.OleDb.OleDbException: Arithmetic overflow error converting expression to data type int.
   at System.Data.OleDb.OleDbDataReader.ProcessResults(OleDbHResult hr)
   at System.Data.OleDb.OleDbDataReader.NextResult()
   at SoftGrid.Management.DataAccess.ReportDataAccess.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
   at SoftGrid.Management.Reports.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
   --- End of inner exception stack trace ---

Server stack trace:
   at SoftGrid.Management.Reports.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at SoftGrid.Management.IReports.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
   at ManagementConsole.ManagementSession.GetSystemUtilizationBySessionData(DateTime startTime, DateTime endTime, Int32 serverGroupID, Int32 serverID, RptSystemDailySessions[]& dailySessions, RptSystemDayOfWeekSessions[]& dayOfWeekSessions, RptSystemHourOfDaySessions[]& hourOfDaySessions, RptSystemSessionUsageSummary& usageSummary)
   --- End of inner exception stack trace ---

This is caused by the system exceeding a limit of calculation. When running the system utilization report the system calculates the total session duration in seconds for all users for all of the applications that have been used during the specified time period. This total must not exceed the current limit of 2,147 million seconds.

Reduce the time period used to generate the system utilization report so it falls within the current allowed limit. 30 Days will usually be a safe maximum.

DC Refreshes and Application Launches may fail intermittently in the case of an unstable SQL Server connection. This can happen when the threshold for connectivity to overall service connectivity to SQL has not been reached but the authentication and/or authorization of a user actually timed out on the back end connection to SQL.
In essence, overall connections to the App-V server may still be maintained and the clients will not go into DO (Disconnected Operations Mode.) Authentications may fail due to intermittent availability of a remote SQL server.

While some have recommended modifying connection timeouts to the SQL datastore, but in my opinion, this would not be addressing the underlying issue. If connectivity is problematic to SQL, first find the root cause of the connectivity.

The error that commonly appears in this scenario is:

"A Network operation did not Complete in Time"
Error: xxxxxxxx-xxxxxxx0a-10000005

I have also seen this issue pop up when the back end SQL Server’s CPU Utilization was maxed out at 100% making the service temporarily unavailable.

Starting with the 4.6 sequencer, the default block size for sequenced packages was changed to 64K. In addition, the option to adjust this was removed from the sequencer. The block size used to be an issue when the network bandwidth was limited and large blocks could not be transferred. Now with more robust networks in place, this is not a problem anymore.

With certain 4.6 client configurations (using packages sequenced on 4.6 sequencers and later) involving RTSP streaming from management servers or streaming servers, users may notice significantly longer RTSP streaming times.

If you want to set the block size lower than 64K with the App-V 4.6 sequencer, you can still do this via the command-line sequencer. This will require an installation program, script, and/or batch file that will run completely unattended. The command line parameters are found here:

http://technet.microsoft.com/en-us/library/cc843675.aspx

You can use the /BLOCKSIZE option to specify a block size parameter of less than 64 (i.e. 32.)

To rectify this issue post-sequencing, you will need to make the following adjustments on the App-V Management server and/or streaming servers when using RTSP:

1.)    If using Windows Server 2003 for your App-V Management server, you can modify the TCP/IP settings on the Windows Server 2003 App-V Management server to immediately acknowledge incoming TCP segments per the following KB article: “Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program” (http://support.microsoft.com/kb/823764).

2.)    Use an alternative protocol for streaming (HTTP or SMB.)

3.)    Use a third-party sequencer/packager/encoder to adjust the block size.

4.)    Some of our customers have had success with adjusting TCP optimizations. For example, on servers running Windows Server 2003 Service Pack 2, you can turn on the TCP optimization feature "Receive-Side-Scaling" on by enabling the following registry parameter:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data Type: DWORD

Value: 1

NOTE: This is only one part of the SNP (Scalable Network Pack features) that needs to be turned on. Other features such as offloading or TCP chimney do not need to be enabled. Please be aware of the fact that other applications that may be running on that server may not be tuned well for TCP optimizations. You will also need to reboot the server for this to take effect.

5.)    For servers running Windows Server 2008 and later, it is recommended to also have the receive window auto-tuning level set to either normal or experimental in addition to RSS being enabled.

To enable TCP Auto-Tuning and RSS:

• From an elevated command prompt, run the following command:

                netsh interface tcp set global rss=enabled autotuninglevel=normal

• Reboot the server.

Here is the scenario: You are leveraging an App-V Management Server that will be assigning groups from trusted domains to applications and/or provider policies. Often there are organizational changes (mergers, spin-offs, domain flattening, etc.) that will warrant domains going offline or trust removals with the current domain for which the App-V management Server belongs.

How does that affect the App-V management server in the event that these domains are no longer reachable? What will happen is those groups will not be able to resolve and “ghost” SIDs will display where the groups formerly displayed.

For example, in the example below, there are groups from two domains (SECUREPKI and CONTOSO) assigned to a default provider policy on an App-V 4.5 management server.

Once the domain CONTOSO becomes offline and no longer reachable, the Provider Policy will simply show ghosted SIDS as in the example below. Provider functionality will not be affected.

The same will also occur for application access permission assignments. The groups from the offline domain will simply display as “ghost SIDs” and the other user’s access will not be affected.

This allows for the App-V management server to remain functional while administrators clean up the decommissioned data.

How this was different with the Softgrid 4.1 Virtual Application Server

The process for previous releases of the Softgrid Virtual Application Server (what the App-V management server used to be called) resolving and accessing Active Directory was different. A special browsing account was required to access Active Directory. Account Authorities had to be configured as well. The group references were also stored in a different format within the database (see below.)

 4.5 and later

Pre 4.5

Using the same example with a 4.1 server, we will see the difference in the example below:

Like with the 4.5 server, the groups are unable to resolve their SIDs. However, we have found that unresolved groups within provider policy group assignment as well as application access permissions, may cause delays.

This delay can lead to “A Network Operation did not Complete in Time" error  (xxxxxx-xxxxxx0a-10000005)

 With 4.1, if you have a series of applications that have many groups assigned to the application that are no longer resolvable, then you may want to provide temporary remediation for your existing users while you clean up the ghost SIDs. You can simply de-select “Enforce Application Permission Settings” in the Provider Pipeline tab in the Provider Policy dialog box.

What to look for in the SFT-SERVER.LOG file

When this issue is happening, you will likely see entries similar to below upon service start in the SFT-SERVER.LOG

[2011-11-09 19:41:13.599] APP-V-SRV1 4512 4932 SW_ADSDataConnection::FillGroupRefToSIDMap - - - - 5 - Caching(LDAP://contoso.com/<GUID=f80b836b317f7f45afb437ff7db8e741>)->(S-1-5-21-6776287-1952083785-2110791508-36630)

[2011-11-09 19:41:18.161] APP-V-SRV1 4512 4932 SW_ADSDataConnection::DomainNameToType - - - - 5 - "Domain (CONTOSO.COM) error (1355)"

 When a client tries to launch an application, you will also see entries similar to below:

 [2011-11-9 19:44:24.685] APP-V-SRV1 3836 4436 SW_ADSDataConnection::DomainNameToType - - - - 5 - "Domain (CONTOSO.COM) error (1355)"

[2011-11-9 19:44:42.762] APP-V-SRV1 1984 4272 SW_ADSDataConnection::FillGroupRefToSIDMap - - - - 5 - "Could Not Get Group(LDAP://CONTOSO.COM/<GUID=857fed02a9a42b4d89b7879066f327fd>)"

 A slew of these entries may be present if there are a slew of unresolved groups for many applications.

Management Console Issues in Softgrid 4.1

You may also encounter the following error " A referral was returned from the server" when trying to add groups to the Provider Policy in the Softgrid 4.1 management console. You can resolve this by changing the ASP.NET configuration of the Softgrid Management Web Service. You can change the ADReferralChasingOption to "None.” Per the following KB article:

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

Microsoft App-V is the only application virtualization product capable of virtualizing Visual Studio 2010. However, you may receive the following error message when attempting to launch the primary development environment (DEVENV.EXE) within a Visual Studio 2010 package virtualized with Microsoft App-V:

The 'Environment Package Window Management' package did not load correctly.

The problem may have been caused by a configuration change or by the installation of another extension. You can get more information by running the application together with the /log parameter on the command line, and then examining the file 'C:\users\<USERNAME>\AppData\Roaming\Microsoft\VisualStudio\10.0\ActivityLog.xml'.

Continue to show this error message?

 This is nothing to be alramed about. This can happen if one or more of the following is missing/configured incorrectly on the App-V Client where the Visual Studio package is being deployed:

- The Microsoft .NET Framework 4 Full Profile
- The KB 2468871 Update
- Interference from the Windows Presentation Foundation Font Cache Service.

To resolve this issue, be sure to complete the following steps on all App-V Clients to which the virtualized package of Visual Studio 2010 will be deployed.

1. Install Microsoft .NET Framework 4 Full Profile.  Using Microsoft Update, install all updates for Windows and .NET Framework.  The full download for the .NET Framework 4 Full Profile can be found here:

http://www.microsoft.com/download/en/details.aspx?id=17718

2. Make sure that the following update was installed by Microsoft Update.  If not, install it manually from the following location: http://www.microsoft.com/download/en/details.aspx?id=3556

3. Run services.msc and disable the Windows Presentation Foundation Font Cache service.

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_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon 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/