Archive for February, 2014

Channel 9 Interview: Life as an MCS Consultant

February 25, 2014 Leave a comment

A few years back, I was interviewed while in my previous role:

I will tell you this, it is much easier to do an interview in print than in person.

You can see and hear me talk about my current role on Channel 9:

Categories: Uncategorized

Connection Group Case Study #2: Paint.NET

February 24, 2014 Leave a comment

To continue my current obsession with App-V connection groups, I want to use another case study to go examine how to implement connection groups for applications that use plug-ins or add-ins. Sometimes you may encounter applications which have no actual registration of configuration storage of plug-ins. The plug-in is simply loaded and dynamically integrated simply because it happens to be in a specific directory.

Paint.NET has yielded some interesting discussions out there regarding the challenges people are having with getting connection groups to work with Paint.NET plug-in DLLs. I looked at one of those problematic scenarios where Paint.NET was sequenced as a primary application and a few DLL’s were placed into a separate package. The packages were then brought together using a connection group. I took a look at the procmon trace of the failed load. As you can see in the trace below, Paint.NET loads plug-ins by simply making a query for *.DLL files located in the effects subdirectory using a QueryDirectory Operation:

The filter response in Procmon will show null. The thing is, the plug-ins are actually there – but not in the main packages directory. In fact, if you open a command prompt inside the converged connection group, you will see everything correctly (the plug-ins beneath the effects) subdirectory. Even though the directories converged, the method used by Paint.NET is only going to receive filter responses from the primary package.

So we need a filter return of the plug-ins, which means we want a single directories to converge in the virtual environment. This will require a modification to the sequencing process. I will walk through the process of sequencing Paint.NET for use with plug-in packages in a connection group first – and then I will dive into the plug-in sequencing and how to bring them together through a connection group.

In this example, I am using version 3.5.11. I will also be using the following plug-ins for demonstration purposes only: MosaicManiac, TRsFilmStock, Shape3D, and Fill_Gaps.

The Primary Paint.NET Package

Before you start sequencing Paint.NET, you will need to first create an exclusion. You can do this by going to the “Tools” menu and then select “Options.”


You will need to add in a VFS exclusion of the plug-in path in the tokenized format – [{ProgramFilesx86}]Paint.NETeffects. Once you have done this, you can proceed to sequence Paint.NET as a standard application. Sine we will be using Paint.NET with connection groups and we want the VFS directories to converge, you will need to select a fake PVAD that is different from the normal Paint.NET installation directory. We will still install Paint.NET to its normal directory, but we want it to be different from the PVAD.


Aside from the PVAD configuration, you will want to run a custom installation of the Paint.NET installer.

On the options page with the Paint.NET installer, I usually leave all of these blank especially the updating option as I would normally service this application the same way I would service other application updates – through App-V.

I then select the C:Program FilesPaint.NET directory to ensure that the installation goes to a VFS tokenized path.

Then complete the sequence as normal.

You will note that if the VC runtimes are not already installed on the machine, the App-V Service pack 2 sequencer will detect these runtimes and include them in the package.



Once you have finished, save the package and copy it off the sequencer. Revert the sequencer to a clean state and either copy back the Paint.NET package or install the Paint.NET application natively.


Sequencing the Plug-ins

Like any other add-in or plug-in, you will want to follow the “add-in or plug-in” workflow.


Be sure to select “Custom Installation” as you will be using the command prompt to copy the DLLs for the plug-ins into the effects subdirectory. On the next screen, you will need to either have Paint.NET installed or expand the existing Paint.NET package to disk (Devirtualize.)

On the “Package Name” screen, you will need to ensure that you select a fake PVAD (one different from the actual installation path of Paint.NET) to ensure that the files will be copied into a VFS folder.

During Monitoring – open up a command prompt and copy the DLLS to the Effects subdirectory.


After you have finished copying, navigate to the directory and launch Paint.NET from a command prompt to verify the plugin DLLs load. Then close the command prompt and select “I am finished installing” and click “Next.”

Verify the package contains these files and the directories are set to merge (Grey.)

Remember, if it is grey it overlays.


Then save the Plug-in package and move it to a staging area with the parent application. You can now being testing. First add and publish both packages. Target should not matter so long as the connection group you create and enable matches the target of the packages it contains. Once the packages are published you can create the CG XML document. The order in which you do this does not matter. If you wanted to create the document in advance of publishing, that is fine. I just use the published GUID paths in explorer easier for copying and pasting when I test. But your methods may differ according to your preferences.

In the CG XML document, you will notice that I have my plug-in package at the top of the package order. I then add and enable the connection group.

You will notice that the connection groups work when you launch Paint.NET, navigate to the “Effects” menu, then select the submenus then you notice the plug-ins have loaded.

You’ll observe the difference in behavior using ProcMon – where the query for DLLs is met with success and the subsequent ones found will then be loaded:





Connection Group Case Study: Notepad++

February 22, 2014 Leave a comment

Notepad++ uses plug-ins that register through a configuration file. This is one of the most common methods used by applications. Too often people run into problems because they order the primary application too high in the packages list inside the connection group. As a result, the configurations conflict with the one from the main package were overriding the one from the plug-in package. So to avoid this problem, and to allow more flexibility of deployment and connection group interaction, I will show you how I recommend you sequence these types of applications. I will be using Notepad++ as an example as it can fall into this same problem. My hope is that you can avoid this problem in the future with Notepad++ (and subsequently those applications that load plug-ins in the same style.)

For this example, I will be using Notepad ++ version 6.5.3 downloaded (from Please bear in mind that Notepad updates very frequently although I do not think there will be drastic changes forthcoming in how the application manages its plug-ins. For the plug-ins, I will be using the following examples:

These plug-ins differ as one of them actually requires overlays to the Notepad++ program files.

The Sequencing Process

Notepad++ uses a normal installation procedure. The installation is almost straight forward so the only adjustments I will make are:

1.)    Sequence to a fake PVAD.

2.)    I will then install Notepad to the %PROGRAMFILES% directory to get a tokenized VFS installation (using the VFSProgramFilesx86 directory.

3.)    When I get to the “Components” dialog page, I disable updaters and for demonstration purposes, I do not select any plugins except the plug-in manager as I want to do all of this through connection groups.

4.)    On the next page, I leave everything blank. If you check the box to “Don’t use %APPDATA%” you will run into problems with Notepad as it will try to open immutable assets for modification once virtualized. I will also be converging the main program directories for the plug-ins and I do not want to be loading plug-ins from the %AppData% folder.

5.)    I will then sequence the application as normal opting to provide advanced customization so I can get to the tabbed, advanced package editor. Here, I will verify that the paths in the registry for Notepad are properly tokenized.

6.)    Then I will go to the “Package Files” tab to perform two very important tasks.

7.)    I will be changing the convergence settings for the ProgramFilesx86Notepad++plugins directory from “Override Local Directory” to “Merge with Local Directory.” This will change the color to grey.

8.)    I will then save the package, copy it off, and then revert my sequencing machine. (PLEASE NOTE – I only mentioned particulars here that go outside the norm of sequencing. I am making an assumption that the reader is familiar with the basics of sequencing.)

Sequencing the Plug-in Package

Now that the primary application has been virtualized, I will need to reuse this package on the sequencer when it comes time to virtualize the plugins for Notepad++. I will copy the parent package to the reverted clean sequencer. In the case of these plug-ins – since they are DLL’s I have downloaded and extracted them into a staging directory on the sequencer as well.

Sequence as an Add-In

You will need to use the “Add-in or Plug-in” workflow as it will give you the opportunity to expand the virtualized package (Devirtualize) to the local machine so you can launch the parent application during sequencing to ensure that the plug-ins load and that the configuration will get registered properly and then stored inside the plug-in package.

In this example, I am pointing to my previous package I just sequenced and will be selecting this package as the primary parent application.

I then ensure that I do a custom installation so I can name my plugin package properly AND I will also use a fake PVAD to ensure that everything that gets captured goes to a VFS or tokenized path.

Once all of that is completed, I can proceed to install my plugins while the sequencer is monitoring. When I click the “run” button to proceed with the installation, I choose a command prompt (C:WindowsSystem32cmd.exe.)


Since these plug-ins are DLL’s I use xcopy to copy them over to the C:Program FilesNotepad++ directory.



Since I am still in the monitoring phase, I now want to ensure that the plug-ins get loaded and registered to automatically load through Notepad++’s plug-in manager. From that same command prompt, I launch the NOTEPAD++ application and verify the plug-ins are there from the plug-in manager. I see they are there:


I can now close Notepad, stop the command prompt and stop monitoring by checking that I have finished installing and clicking next. I will then click through and select the customize screens until I get to the final editing tabbed mode. You will notice that this way when you view the advanced editing Files tab the files are already set to merge and they are in the tokenized path. If they are not set to merge, you will want to make that adjustment.

Then save the Plug-in package and move it to a staging area with the parent application. You can now being testing. First add and publish both packages. Target should not matter so long as the connection group you create and enable matches the target of the packages it contains.

Once the packages are published you can create the CG XML document. The order in which you do this does not matter. If you wanted to create the document in advance of publishing, that is fine. I just use the published GUID paths in explorer easier for copying and pasting when I test. But your methods may differ according to your preferences.

In the CG XML document, you will notice that I have my plug-in package at the top of the package order. I then add and enable the connection group.

Once the connection group is enabled, I then launch Notepad++ and navigate to the plug-in manager where I find my plug-ins loaded properly.

More case studies to come.

On the Design of (and Sequencing for) Connection Groups

February 21, 2014 1 comment

Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: after reading this article for the updates.

I constantly stress to my customers that significant assessment and planning revolving around the design and implementation of connection groups is essential to a successful lifecycle for virtual environments. One of the primary challenges with connection groups is that while understanding the mechanics of setting them up is quite easy; it is the sequencing thereof (as well as the understanding of how applications are affected by them) that is challenging.

I approach connection groups from a packaging and integration perspective. With that approach, I must plan out my strategy PRIOR to sequencing as retrofitting previous sequenced applications for connection groups can be quite risky and I recommend avoiding it.

Connection Group Architecture

I am not going to do too much diving into this point because there is already good information available. But a connection group is a virtual environment that contains more than one virtual package. All of the packages share the same virtual environment where the VFS and tokenized paths merge and the registries are converged. This gives sequencing engineers the flexibility to maintain packages independently and removes the redundancy of adding the same application several times onto a machine. Simple Concept. How about Execution?


The first thing you need to reconcile will be targeting. Connection groups, like packages, can be targeted to users or to machines (globally published.) But targeting cannot overlap. All packages within a connection group must align. If a connection group target is per user, member packages must be published per user. If a connection group target is machine, member packages must be published to the machine.

Test Strategy

A connection group needs to be tested operationally and functionally by incorporating the connection group and package publishing life cycle into your QAUAT application testing. Creating Connection groups in stand-alone mode allows for more seamless testing. It can also be automated using PowerShell. The general flow for this is as follows:

  • Add and Publish packages
  • If possible, test the functionality of the individual applications.
  • Manually create the connection group XML descriptor document (to be used in stand-alone testing to verify functionality independent of delivery system.)
  • Add and Enable connection group
  • Test applications
  • Disable and Remove connection group
  • Unpublish and Remove packages


The Easy Part – the CG Descriptor

Creating connection group descriptor documents is a pretty easy process. All you need to do is supply a unique GUID for the connection groups VersionID and AppConnectionGroupId. The packages PackageId and VersionId fields come from the packages themselves. You then list the individual packages under the <appv:Packages> element in order of convergence priority. When you create connection groups using the management server or through SCCM, you are simply automating this very process. For more detail on this descriptor document and the format, please refer to the following Technet article:

The Hard Part: Actual Sequencing for Connection Groups

The Technet article above also mentions supported scenarios for using connection groups. Connection Groups are great in that they facilitate the use of primary applications virtualized separately from plug-in or add-in applications to be brought together. You can also use connection groups to leverage run-times or middleware without having to package everything together creating a servicing nightmare. The use of converging primary applications with add-ins and plug-ins is one of the most desired use cases of connection groups – HOWEVER, they can be the most difficult to implement if you do not understand how the add-in is loaded and used by the application. This is important information because it will govern how you sequence the application.

Not Every Application Loads an Add-in the same way.

Each type of load method will govern how we sequence. In earlier blog posts, we even learned that Office Add-ins are even registered or loaded differently depending on the addin.

(See the following: )

Most add-ins load because they are registered to load. Some add-ins load because there’s a variable or a search path. In some cases, they load because the add-in simply exists in a special directory. Understanding how the plug-in or add-in loads (and it’s format) will affect how you engineer your connection groups.

File Convergence

Only VFS Folders and tokenized paths merge. Pure and simple. If you suspect you will use an application or a plug-in within a connection group, you will need to sequence your application a specific way when it comes to selecting a PVAD (Primary Virtual Application Directory) and an installation directory. Unlike the former DSC (Dynamic Suite Composition) where the opposite was true, non-VFS folders do NOT merge. You will need to fully VFS the packages, that is, provide incorrect ‘Primary Virtual Application Path’ (PVAD) while sequencing the packages. This puts all the files of the package under VFS folder and nothing ends up in the root folder.  For example, use C:<PACKAGE_NAME> as the PVAD and install to its regular tokenized path (i.e. C:Program Files, etc.) If the application does not normally install to a tokenized path, make sure you install to a different folder then the PVAD.

Registry Behavior across Connection Groups

Registry keys will merge across connection groups however the data and value overlap will be ruled by order within the connection group. To clear up potential issues with conflicts due to registry opacity configuration where key information may not resolve properly, I would consider placing virtualized plug-in/add-in information (where the add-ins were registered) ahead in the list inside the connection group descriptor document to ensure the right configuration wins out. This is especially important not only when it comes to add-ins but when it comes to VFS file convergence where you may have duplicate directories across multiple packages.

In the next few posts, I will discuss case studies on different types of applications.

Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: after reading this article for the updates.

Online Event: Virtualizing Your Data Center with Hyper-V and System Center

February 15, 2014 Leave a comment

Wednesday, February 19th from 9am – 5pm PST

If you're new to virtualization, or if you have some experience and want to see the latest R2 features of Windows Server 2012 Hyper-V or Virtual Machine Manager, join us for a day of free online training with live Q&A to get all your questions answered. Learn how to build your infrastructure from the ground up on the Microsoft stack, using System Center to provide powerful management capabilities. Microsoft virtualization experts Symon Perriman and Matt McSpirit (who are also VMware Certified Professionals) demonstrate how you can help your business consolidate workloads and improve server utilization, while reducing costs. Learn the differences between the platforms, and explore how System Center can be used to manage a multi-hypervisor environment, looking at VMware vSphere 5.5 management, monitoring, automation, and migration. Even if you cannot attend the live event, register today anyway and you will get an email once we release the videos for on-demand replay!  

Topics include:

•    Introduction to Microsoft Virtualization
•    Host Configuration
•    Virtual Machine Clustering and Resiliency
•    Virtual Machine Configuration
•    Virtual Machine Mobility
•    Virtual Machine Replication and Protection
•    Network Virtualization
•    Virtual Machine and Service Templates
•    Private Clouds and User Roles
•    System Center 2012 R2 Data Center
•    Virtualization with the Hybrid Cloud
•    VMware Management, Integration, and Migration

Register here:

App-V 5: The Case of the RunVirtual Collision

February 11, 2014 3 comments

I've discussed running native applications within virtual environments and the many ways we can bring applications like Internet Explorer into the bubble. One of the many reasons we would need to bring IE into the virtual environment is for web applications that use different versions of Java. When you virtualize different versions of Java, the shortcuts that are created will launch inside the bubble (and also through the /appvve switch.) For example, in the figure below, I have two specific Java packages deployed – each with its own Internet Explorer shortcut configured to run inside a separate Java bubble. I use the URL to verify the version.

I can also view the java processes from the sysinternals utility Process Explorer running successfully launched from their own respective immutable package directory locations.

I can use another Sysinternals utility ListDLLS.exe to show that the App-V hook DLL has been injected into the Internet Explorer and Java processes.

You will also notice that if you configure RDS RunVirtual (where you use the AppV RunVirtual registry key to allow Internet Explorer to run inside a virtual package) to load Java into Internet Explorer, that you can see the Java application spawned by the IEXPLORE.EXE process inside of Process Explorer.

Differences from Dynamic Virtualization in SP2

You may notice in SP2 (as I believed I also mentioned in my last blog post) that when you launch Explorer and Internet Explorer, you will find that these also contain the injected AppVEntSubsystems32.dll due to the default dynamic virtualization configuration – however – just because you see EXPLORER.EXE and IEXPLORE.EXE hooked with LISTDLLS does not mean they will automatically behave the same way as if the application where configured for Run Virtual. App-V 5.0 SP2 introduced this feature as response to the historical desire for the virtualization of shell extensions. Actually shell extension virtualization is just one of the side benefits of JITV (Just-in-Time Virtualization – or “Dynamic Virtualization” as it is officially called.) Beginning with Office 2013, there was the capability of virtualization within a process being dynamically activated and de-activated on a per-thread process.

With SP2, this feature was extended to shell extensions AND ActiveX controls implemented as an in-proc COM object. This is why you will see injections of the App-V Hook DLL into Explorer or Internet Explorer even when no virtualized package is in use. This leads to an important statement: Just because the application is hooked, doesn’t always mean it is running virtualized if it appears as a process under the ProcessesUsingVirtualComponents registry value. This will be done at the thread level.

When an ActiveX OCX or a DLL that implements a shell extension is loaded from a native process or a process from another virtual application, App-V generates an additional virtual environment on demand linking the package containing the OCX or DLL with the process. Then dynamic virtualization is turned on for that particular thread. Once the thread exits, dynamic virtualization is turned off. If the said thread with dynamic virtualization spawns another thread, that thread too will be virtualized. This also helps to prevent RunVirtual collisions.

RunVirtual Collisions

When a single native process attempts to launch within more than one primary virtual environment without connection groups, you have colliding virtual environments – and it is not pretty.

In the context of Internet Explorer, they look like this:

Often this will be accompanied by the illustrious “spinning donut!”

How to tell if you have a RunVirtual Collision:

  1. The native application is immediately unresponsive upon launch and it remains unresponsive.

  2. The launch of the native applications spawns multiple packages in use when no connection groups are configured. These are the collisions.

  3. The CPU will be completely pegged:

And the battle waging will be the native processes – usually at least one per package involved in the collision.


Finally, the smoking gun will be running LISTDLLS or Process Explorer against it looking for the actual executable for the virtual package. You will notice that while the native app is hooked, no virtual processes are able to start and get hooked (in this particular example, Java)

The Cause

The cause will most likely be launching the application through a run virtual command (ie Process.exe /appve:<GUID>_<GUID>) configured to run inside one particular virtual environment – while at the same time – that same native application is configured to run virtual inside another virtual application environment using the RDS RunVirtual registry key.

In the case of the above example, that was the exact cause. Internet Explorer was added as a process in the RunVirtual registry key and was configured to run in the Java 1.4 package. If you ran a normal instance of Internet Explorer, everything behaved properly. However, if you ran a shortcut to Internet Explorer configured to run inside a separate instance of Java using the /appvve switch, then the collision occurs.

Are you *sure* you need to rebuild the WMI Repository?

February 5, 2014 1 comment

To continue the subject of WMI troubleshooting: I am always frustrated at the quick, shotgun method of rebuilding the WMI repository as a rote, rudimentary troubleshooting step. This is very dangerous and risky. Rebuilding the WMI repository manually has resulted in some 3rd party products not working until reinstallation – IN SOME CASES – even this does not work. This is especially a shame since it may not always be necessary and even if it were – if there is severe WMI corruption, it may almost be better to “in-place” upgrade the OS or do a complete reinstallation of the operating system and software as incomplete repositories can yield lingering problems.

Before you go down that road, ask yourself the following:

1.) Have I properly troubleshot the error to the point that the only possible source could be corruption?

2.) Have I researched and installed all of the latest service packs and hotfixes related to WMI? (Hint: Go to and search WMI, hotfix, and <OS>)

3.) Have I gone through the rudimentary WMI checklist so I don’t get burned by simple things such as firewall rules? (Hint –

4.) Have I ran WMIDiag (

and received really bizarre errors like 0x80041010 WBEM_E_INVALID_CLASS or does it fail to connect at all?

5.) Do you fail to connect to WMI Control from Computer Management?

If you answered “yes” to 4 out of the 5 above, here are some steps you can do to safely troubleshoot the WMI repository using “soft” actions:

Instructions for Operating Systems Prior to Windows Vista (XP/2003)

1. Open the Services MSC console and stop the Windows Management Instrumentation service.

2. You will be prompted to stop dependent services. Click “Yes” on the prompt.

3. Once the service is stopped, browse to %SystemRoot%\System32\wbem. Rename the Repository folder to Repository.old.

4. Once the folder has been renamed, restart the WMI and dependent services in the following order:

Windows Management Instrumentation

SMS Agent Host (If SCCM/SMS is installed)

Windows Firewall / Internet Connection Sharing (ICS)

Any other services that were detected as dependencies

5. Once services have restarted, verify the Repository folder has been recreated. Now bear in mind, it could take up to one hour for WMI to fully rebuild.

Instructions for Windows Vista and Later (2008/Win7/2008 R2/Win8)

1.  Open an elevated command prompt.

2.    Verify the WMI repository is not corrupt by running the following command:

winmgmt /verifyrepository

If the repository is not corrupted, a “WMI Repository is consistent” message will be returned. If you get something else, go to step 3. If the repository is consistent, you need to troubleshoot more granularly. The repository is not the problem.

3. Run the following commands to repair WMI:

winmgmt /salvagerepository

If the repository salvage fails to work, then run the following command to see if it resolves the issue:

winmgmt /resetrepository

After the last command, there should be a “WMI Repository has been reset” message returned that verifies the command was successful.

Even the above commands should be a last resort if you are getting an error related to “Access Denied” or “RPC Server unavailable.”

Categories: Management, WMI Tags: , , , ,