Troubleshooting an App-V and SCCM integrated solution

This is an easy to use pictorial representation of troubleshooting App-V in an environment where App-V is integrated with SCCM.


Don’t let App-V 5.0 derail your migration project: A strategic assessment of the impact of App-V 5.0 on your migration project

Since the unexpected release of the App-V 5.0 (Beta) by Microsoft on 04 April (see announcement by Karri Alexion-Tiernan), I have not stopped receiving emails from ex-employers where I have worked as Lead Architect on App-V implementations.

The common questions running through the emails are:

  1. What is the impact of the new product on their migration project?
  2. When is the product likely to go RTM?
  3. Is it worth suspending any further work on the current releases of App-V whilst awaiting the RTM of App-V 5.0.

My one answer to the questions has consistently been:

  “App-V 5.0 (beta) should not derail your application migration project.”

Over the last couple of days, I have thought through the various questions that I am being asked and also done a strategic analysis of the impact of App-V 5.0 (beta) on inflight Windows 7 / application migration projects and the analysis is presented in a series of questions and answers.

Question: Should we postpone / delay / suspend our App-V roll out?

Answer: It is ok to be concerned about the impact of the new release on your current efforts to virtualise your applications. I agree that this is quite frustrating because the changes in the new product are drastic and there has been a clear lack of visibility in the roadmap for the product.

However, it is only a beta product and an RTM version may not reach the market for up to 12 months, which I believe will be a long wait especially when there are instantly realisable benefits to virtualising some of your applications using App-V.

Furthermore, you would have already assessed products in the market place and chosen App-V 4.x because it met your requirements. In addition, support for App-V 4.6 is not being stopped by Microsoft , so there is no reason to be fretful about an impending loss of product support.

Question: Is there an available roadmap for App-V?

Answer: I have not seen one formally but you can discuss this directly with your customer representative / liaison officer (I have used the wrong titles here) at Microsoft.  Product roadmaps are important and Microsoft needs to make this publicly available, similar to the “System Centre Roadmap” published some years ago. I have just looked at various incarnations of the “System Centre Roadmap” again and there is nothing listed in the year 2012 for the Microsoft Desktop Optimization Pack.

Question: What is the significance of the change in the package format from .SFT to .APPV?

Answer: From my perspective, the change in the package format is the most drastic and significant since the acquisition of Softricity by Microsoft.

The change from .PKG to .APPV implies your existing App-V packages will not work on the new client and they have to be converted. The good news is that the new sequencer includes an “Package Converter” referred to as AppVPkgConverter. The AppVPkgConverter can be used to automate the conversion of the packages created using the 4.x sequencers into the .APPV format.

Question: Is there an estimated product release date?

Answer: This is another one that has to be posed to your representatives at Microsoft, but you should expect a 12 – 18 months before the RTM.

Question: Will packages created in App-V 4.x work on App-V 5.0?

Answer: No. Packages have to be converted into the new format.

Question: Will packages created in App-V 5.0 sequencer work on the App-V 4.x client?

Answer: No. You would have to upgrade your client to App-V 5.0 client.

In the past, you would have been able to use an earlier version of the sequencer to create packages for the newer version of the client. However, with the change in the package format (a very fundamental change), this is no longer the case.

Question: Will my application compatibility assessment tools e.g. AppTitude and AOK be capable of assessing my applications for App-V compatibility? How will I assess my applications for App-V 5.0 compatibility?

Answer: In fact, App-V virtualised applications now work almost similar to traditionally installed applications, implying you have a greater probability of being able to virtualise applications that you would have had difficulty with in the past.

The AppTitudes and AOKs will need to be updated by their respective vendors to include new rule sets and algorithms that take into consideration the deeper platform integration between App-V and the operating system.

You would hope by the time App-V 5.0 becomes RTM, these vendors would have upgraded their products.

However, note that if an application can be virtualised using App-V 4.x, then it is virtualisable using App-V 5.0

Question: How should I approach my application virtualisation? Should I continue in an aggressive manner or should I take a more cautious approach?

Answer:  First and foremost, the questions you need to ask yourself are:

I.     Will I be happy to convert all my existing App-V 4.x applications to App-V 5.0 format when App-V 5.0 is released?

II.     Will my client base be happy to conduct a series of user acceptance testing for applications that are converted from App-V 4.x format to App-V 5.0 format?

III.     Will I have resources –financial and personnel to undertake the task of package conversion from App-V 4.x format to App-V 5.0 format?

The answers you provide to those questions should determine how you approach application virtualisation.

My recommendation to my clients is to virtualise only applications that require constant patching , changes and upgrades, and continue delivering the more static ones as MSIs /EXEs. Using this approach implies that when App-V 5.0 is finally released, such applications might be in need of an upgrade and such applications can then be converted to the new 5.0 format and upgraded at the same time.

Please share your wisdom with the community by participating in the poll:

The case of the “ghost” SID in the App-V Management Console (Error code: 0000B004)

There seems to be many reasons why you might come across the error message presented below when using the App-V Management Console:

However, this discussion is focused on the one described by Microsoft in  Microsoft’s description of this error is: “When you try to use the Microsoft Application Virtualization Server Management Console to remove group assignments for an Active Directory group that has already been deleted, the removal fails together with the 0000B004 error code.”  Microsoft provides a hotfix for this error if you are running 4.5 Sp1.

If your question is what do I do if I am currently running the latest version of the App-V Management Server i.e. 4.5 SP2? Well, again this version includes the hotfix (KB980850) and this issue should not be seen. If you  still have issues despite running App-V 4.5 SP2 or you are unwilling to go through the change management hoops involved when deploying a hotfix  (assuming you are running 4.5 SP1) to a critical application in your enterprise,  go to the Application Assignment Table in your App-V DB (data store) and delete the “ghost” entry.

Thanks to Vijay ( for sharing the error and also testing this approach.

Configuring your App-V Management Server for dynamic database ports

In order to configure your App-V Management Server and App-V Management Service for MSSQL dynamic ports, the following changes have to be made:

  • The registry value  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Server\SQLServerPort should be 0, and
  • The Network Address settings in C:\Program Files (x86)\Microsoft System Center App Virt Management Server\App Virt Management Service\sftmgt.udl should not contain any port. This will normally contain the port number used when the service was installed.

Note: The aforementioned changes are only applicable if your App-V datastore has been reconfigured to use dynamic data ports after installation of the App-V Management Server and Service. The locations of the registry value and the sftmgt.udl will be dependent on your platform i.e. 32 bit or 64 bit and the installation directory for the application.




Building a case for upgrading to App-V 4.6 SP1

Microsoft released the Service Pack 1 upgrade to the App-V 4.6 Sequencer and Client in March 2011 as part of the Microsoft Desktop Optimization Pack (MDOP) for Software Assurance 2011.  This release did not affect the Management and Streaming Server components of App-V; therefore the latest release of both products is still 4.5 SP2.

There is no significant impact of SP1 on the App-V Client. Most of the changes are reflected in the App-V Sequencer which includes newer features to mainly simplify the sequencing process. The features of the SP1 are:

  • Improved User Interface: The user interface has been further simplified with a step-by-step guide during all phases of the sequencing, thereby reducing the know-how required to sequence non-complex applications. In addition, the sequencer also informs you of processes that might be running that may likely interfere with the sequencing operation.
  • Installation Report: The feature provides reporting on potential compatibility issues that might prevent successful App-V virtualization. This is similar to using the virtualization modules in  AppTitude by AppDNA and ChangeBase AOK, but with one application at a time.
  • Package Accelerators: They allow you to convert traditional applications into App-V packages without manually sequencing the application. Microsoft has released package accelerators and other vendors are following suit. This will reduce the level of know-how required to sequence applications.
  • Settings Templates: They let you re-use of commonly used settings which can reduce the time period for the completion of sequencing.
  • Command Line Sequencer: The command line sequencer has been enhanced to better support applications that may not allow for the execution of the sequencer graphical user interface (GUI).
  • Auto Preparation of the Sequencing Environment: The creation of the dummy ODBC connection and the sequencing drive are both automated, thereby reducing the time required to setup a sequencing machine.
  • 8.3 Limitation: The 8.3 limitation on the App-V Asset Directory (Primary Virtual Application Directory) no longer applies.

These aforementioned features offer tremendous benefits. Some of these benefits are:

  • Reduction in Sequencing Efforts: The Improved User Interface, Built-in Diagnostics, Package Accelerators and Setting Templates do significantly reduce the amount of time taken to sequence applications.
  • Better Diagnostics for difficult to sequence applications: Although, tools like Dependency Walker, Process Monitor and Process Explorer will still be useful to diagnose issues when sequenced applications malfunction, the diagnostics provides an insight into potential problems when sequencing specific applications, in places where tools like AppTitude and AOK do not exist
  • Cost of Sequencing: A reduction in the time taken to sequence applications will reduce the cost of application provisioning as packaging (sequencing) contributes to a significant chunk of the application provisioning process.
  • Supportability: Having the latest version of the components helps with support by Microsoft.
  • Security: The service pack includes all released hotfixes thereby increasing your protection from security vulnerabilities.

 Despite the numerous benefits provided by the upgraded components, there are impacts of upgrading and these are described below:

  • Training Cost & Time: Support personnel and application packagers may need to be re-trained in order to get them acquainted with this new version. This is not expected to be significant. Those already familiar with sequencing should be able to become proficient in using App-V 4.6 SP1 Sequencer in 3 hours.
  • Change to Sequencing Standards: Sequencing (Packaging) standards may need to be redefined in organizations willing to benefit from the removal of the 8.3 limitation on the Asset Directory naming.
  • Change to Sequencing Processes: The auto-preparation of the Sequencing Environment during the installation of the App-V 4.6 SP1 Sequencer may change the way the sequencing machines are prepared.

 Every change does introduce some level of risk. Some of the risks associated with this change are presented in the Table below:

Description Impact Assessment Probability Countermeasures
Packages created in earlier versions of the App-V Sequencer may malfunction on the new client Small.Applications created in versions of the sequencer pre-dating version will be the main risks. These applications may have to be opened up in the Sequencer and saved, or completely re-sequenced. Low Test applications created in earlier versions of the Sequencer pre-dating version 4.5
The Client cannot be deployed to computers with more than 64 processors Small.Most desktop systems do not have up to 64 processors Low Perform a hardware inventory of your enterprise and provide applications using other application provisioning systems e.g. RDS to users of workstations with more than 64 processors
User folder names do not correspond to the package names on the App-V Client when the Asset Directory is longer than the 8.3 format Small Low Stick with the 8.3 limitation for the Asset Directory naming
Sequencing a plug-in with side by side components may fail when expanding the parent package Small Low Some registry keys should be deleted after expanding the package.
Path from package template may be lost if it does not end in a forward slash (/) Small Low Use a trailing forward slash (/) in the HREF path.

                                                                                Table 1: Risks

Although a detailed investment appraisal with a payback calculation cannot be done as each environment will be different, the following factors should be taken into consideration: cost of re-training, cost of testing virtual packages created in earlier version of the App-V Sequencer pre-dating 4.5, cost of re-sequencing some virtual packages, cost of updating processes and sequencing standards, cost of upgrading the App-V Client etc.

Overall, there are significant benefits and very little risk to upgrading to App-V 4.6 Service Pack 1.

Logging SFTMIME Commands

SFTMIME commands for repairing an application and deleting a package may not generate entries in the App-V Client log file, despite setting the log level to verbose.

In order to see the cause of failures when using enterprise software delivery toolsets to deploy App-V packages to an App-V stand-alone client, always use the logging option of the SFTMIME command.

For a package delete operation, use the following command:

  • SFTMIME DELETE PACKAGE:{PKG GUID} /LOG %WINDIR%\TEMP\Whateveryouwantittobe.txt

For an application repair operation, use the following command:

  • SFTMIME REPAIR APP:”Application Name & Version” /LOG %WINDIR%\TEMP\Whateveryouwantittobe.txt

Note: There is also the sftmsi.log which contains error details logged during the MSI installation and removal for MSI based deployments to App-V stand-alone clients.

The conundrum of the unload least recently used in an App-V Stand-alone mode implementation

During a recent engagement at  a client, one of the complaints I heard from System Administrators and App-V Administrators was that App-V packages were being removed from the App-V cache when new applications are deployed to App-V clients in an App-V stand-alone mode implementation. This environment had a mixture of App-V clients streaming packages and stand-alone clients, and no one with the App-V client in streaming mode had complained about this arbitrary removal of App-V packages.

The things that jumped out from this explanation were the “MinPackageAge”, the “UnloadLeastRecentlyUnused” and the size of the App-V cache. Although, it was glaring that this behaviour was due to the limited size of the App-V cache, the removal of previous applications automatically was still unacceptable. In a full infrastructure mode, the App-V client would have had the capability of re-streaming the package and users may not have noticed the removal of the application.

My recommendation for a stand-alone implementation will be to change the default behaviour of the App-V client “UnloadLeastRecentlyUsed” policy as below:

  • UnloadLeastRecentlyUsed=0.

The removal of deployed applications should be a conscious decision and not an automatically configured option, as the automatic removal of software could lead to customer dissatisfaction, increased helpdesk calls and administrative burdens.Some school of thought, do advocate increasing the “MinPackageAge” to a very high value. The  argument for this is based on the fact that if an application has perhaps not been launched in a long time, the probability of it being used again will be low.

On a side note,  the price of hard disk drives have crashed in recent times, so you can also increase the capacity of the disk and also prevent your business from saving files locally.

%d bloggers like this: