Overcoming WMI Deployment Conflicts in Microsoft Server App-V

Article
12/01/2011

Introduction

You have just gone through the process of sequencing a package, you go to deploy it in your test environment and you get an error message that says “The operation could not be completed successfully because a WMI class or provider in the package is already registered on the machine.” What do we do now? In this post, we will see how to identify WMI conflicts and methods for overcoming these conflicts without re-sequencing.

Identifying the problem

At the time of deployment, Server App-V performs a series of conflict detection checks to ensure that the package’s components and the machine’s components can coexist. If one of these checks fails, the package cannot be deployed to the target machine. For WMI components, this means that one or more of the classes or providers detected during sequencing is already present on the deployment machine. This often occurs when a non-essential process is accidentally left running during sequencing.

So how can we know that the add package failure is due to a WMI conflict? The error code for a WMI conflict is 1D-00003007 as shown in the Powershell screenshot below. A similar error is produced when deploying via Virtual Machine Manager.

Now that we know there was a WMI conflict, we need to determine which items in the package are actually conflicting with the native system. To do this, we open the Application event log and locate events with an Event ID of 13318 from the “App-V Services” event source. If more than one conflict was found, there will be an event log entry for each conflict.

From this event log message, we can determine which class or provider conflicted and in which namespace it resides. With this information we can begin the process of fixing the package.

Addressing the Conflict

The first thing that we need to determine is if the conflicting WMI classes and providers are part of the application itself. This is the most difficult part of this process and requires some knowledge of the application itself. Many applications publish information about their WMI classes and providers as part of their documentation. In other cases, it may be obvious that the class or provider captured belongs to another application. For the rest of this post, we will assume that the conflicting components are not part of the application (i.e. they shouldn’t be in the package).

There are two techniques for removing these components from the package, both of which leverage the package update functionality on the sequencer. The first technique is called “namespace exclusion” and provides the capability to remove entire WMI namespaces from the package. The second technique is a more targeted approach for removing individual entities within a namespace you need to keep.

NOTE Both of these techniques change the content of the package in a non-recoverable way. Backup your package before starting this process.

Namespace Exclusion

Namespace exclusion removes entire WMI namespaces from the package. This feature is not exposed in the user interface and must be configured through the registry.

From the previous section, we identified a conflict in the root\cimv2 namespace for the serverappv_collision_sample. After looking at the application’s documentation, we confirmed that the application does not put any WMI content in this namespace, so we can simply exclude it.

To do this, we open regedit on the sequencing machine and navigate to the HKEY_LOCAL_MACHINE\Software[\Wow6432Node]\Microsoft\Softgrid\4.5\ServerAppV key and edit the WmiNamespaceExclusions multistring value. This value consists of one namespace per line and is blank by default. We add “root\cimv2” to the value and close regedit.

Now, we start the Sequencer and open the existing package for update. We follow the Sequencing Wizard, selecting “Perform a custom installation” on the Select Installer step, and simply complete the wizard without installing anything. Once the wizard is completed, we are back in the main Sequencer window and can save the package. This package contains all of the previous content except the WMI components in the root\cimv2 namespace. When we deploy this package on the Agent machine, we no longer receive a WMI conflict (notice the ssrs2008_2.sft in the second Add-ServerAppVPackage call).

Targeted Removal

In some cases, an application may place classes or providers in the same namespace as other applications. If this occurs and we need to remove a specific set of WMI entities, we can use the package upgrade process as described above (without the registry change) and simply remove the problematic items from the WMI repository during the Installation phase. These components can be removed through Powershell. Below is an example of removing the serverappv_collision_sample class:

# WMI Connection Parameters
$savHost = "localhost"
$namespace = "root\cimv2"
$authLevel = "PacketPrivacy"

Remove-WmiObject -Authentication $authLevel -Namespace $namespace -Class "serverappv_collision_sample" -ComputerName $savHost

We can then complete the wizard, save the package and deploy the new version in the test environment.

Secondary Problems

During package upgrade, the same registration process that occurs on the Agent occurs on the Sequencer. This could result in a WMI class or provider that was captured in the package preventing the upgrade from succeeding. When this occurs, an error is received during the Installation phase of the Update wizard.

In this case, the sequencer log will contain an entry with the same message that was seen in the event log on the Agent. At this point, you can either find a machine that does not have the WMI entity causing the conflict or remove the conflicting component from the native system.

NOTE Removing the native component may result in a negative impact on the system’s function. This should only be done within a non-production virtual machine that you are willing to lose.

To remove a native component, follow the same process described in the Targeted Removal section above.

Conclusion

WMI conflicts can cause an otherwise usable package to fail deployment. By leveraging the package update process on the Sequencer, we can correct some of these issues without needing to completely re-sequence the application. The techniques described here can save a significant amount of time when trying to correct a minor sequencing issue.

Jeremy Dunker | Senior Software Design Engineer | Server App-V