Archive for the ‘Virtualization’ Category

The Case of the Ever-Expanding, Dynamically-Expanding VHD

December 11, 2013 Leave a comment

I recently had an issue where I encountered something quite bizarre. In an effort to reduce size on disk of dynamically expanding virtual hard disks (VHDs) I found myself feeling like I needed to take medication. After sysprepping an operating system image on the disk, the current file consumption on the disk was approximately 12 GB and the size of the dynamically expanding virtual hard disk was 15 GB (with a capability of growing to 127 GB as that was the size designated when creating the VHD.)

I then mounted the disk as a drive in Windows 7 using diskpart.exe in order to perform some offline defragmentation, pre-compaction, and compaction. I found that after disk defragmentation was completed in Windows 7, the total size of the disk grew to the full 127 GB although the total file consumption the disk was still at 12 GB. I had never encountered this before. I have, in the past, seen defragmentation cause some gain in VHD size but only ever at a maximum of 10-20%. To top that off, pre-compaction and compaction did nothing to reduce the size.

Now, just to give some background, the Windows 7 virtual stack used to mount VHDs did not understand the TRIM command (which is what the file system started sending down in Win7 to let the storage stack know an area was no longer in use).  Anytime defragmentation is run on a dynamically expanding VHD where the stack doesn’t understand TRIM will in fact result in a larger VHD than you started with.  BUT NOT THIS MUCH! I even verified that volume snapshots were disabled on the volume as that can also explain a large increase in the size of the VHD.

Realizing this was done on a host machine using a customer’s corporate operating system image, I took a copy of the original VHD and mounted and defragmented the disk on one of my plain vanilla operating system images and found the behavior I expected – only a nominal increase in size. At this point, I realized something outside the norm of the operating system was causing this growth. I could have easily done the tedious approach of removing individual 3rd-party filters on the image (using the divide-and-conquer method) while running defragmentation but I wanted to see if what was doing this was even related to defragmentation. I decided to simply just mount the drive again and monitor the disk size while doing absolutely nothing interactively to affect the drive.

I went to lunch. I came back, the disk was already at 32 GB. By the end of the afternoon, it was back to 127 GB. There was obviously some file-system based software performing this. It turns out, there is a McAfee Encryption policy in place (they were running 3rd-party disk encryption software) that silently encrypts new logical drives as they are added. When I mounted the VHD through Windows 7’s Disk again while this software had been disengaged, the issue did not occur.

I hadn’t been taking crazy pills after all.

Running a MED-V application that depends on presence may not properly show presence when hovering over it in the System Tray

February 26, 2013 1 comment

Let’s review some basic information about how MED-V: The way MED-V V2 works is the Windows 7 host machine connects to the Guest Virtual PC through an RDP-style connection. This basically turns the Windows XP Virtual PC into a mini-RDP server. This must always be in the back of your mind while you test your applications under a MED-V solution. Leveraging RDP removes the need for a hooking DLL to be injected into the guest OS and cuts down on the overhead of the MED-V Guest Agent.

Since applications that run under MED-V are basically the same to the Windows 7 host as applications running remotely on an RDS or Terminal server, you will encounter specific limitations in cosmetic desktop features. For example, the AeroPeek style thumbnail preview of the remote application will not be visible. Window titles will show an appended (Remote) to differentiate it from the local applications.

In addition to what comes through the remote connections, MED-V will republish (pass along) critical messages that appear in the Windows XP system tray. For example, password expiry notices and update notices from WSUS (or Configuration Manager) will also appear on the local desktop. Applications that publish to the Windows XP System tray in the guest will also appear in the host (with an appended “Remote.”)

One item that is not simply a cosmetic issue that you will need to be aware of when considering MED-V for application remediation are applications that have presence indicators in the system tray. Changes in presence often cause a change in icon or icon color as well as their pop-out status message. While these status icons will appear in the Host system tray, there will be potential issues with changes in user presence updating icons properly.  Applications such as Communicator, Windows Messenger, and Lotus SameTime may not always update/change presence notifications properly when running in a MED-V workspace.

Let’s use the example of a user being signed in initially as “available.” When the use steps away and becomes idle, the system tray icon may not initially reset the icon appearing in the host to “Away” even though the user is away from their desk.

MED-V V1 Disaster Recovery

Disaster recovery in MED-V v1 is a very straight-forward and seamless process. Offline access is available for those clients who have already cached their MED-V client authentications. One of the first steps in ensuring a good disaster recovery plan for this version of MED-V is to establish continuity through offline access. This will assume all images that the users need will have been downloaded. Information on MED-V v1 credentials and offline access can be found here:

For the MED-V server, since the configuration is all XML-based, the process for backing up crucial data is very easy and does not even require a system state backup. In my MED-V v1 environments, I simply backup the XML configuration, the reporting database, and the server-side images. This process is outlined in the following article:

The article is pretty straightforward on the key locations for images and configuration:

\Med-V\Med-V Server Images

\Program Files\Microsoft Enterprise Desktop\Servers\ConfigurationServer

It also goes through the restoration process which is just as straight forward. The article does not mention the reporting database. While true, reporting is an option in MED-V V1 and is not required for the server to be operational, most organizations still using MED-V v1 are making use of the reporting database. If the database is locally available on the MED-V server (i.e. though SQL Server Express) please ensure that you are backing up the database (defaults to “medv”) manually using SQL Management Studio Express or through whatever means your database administrators backup databases.

– Steve Thomas

Categories: MED-V, Virtualization, VPC Tags: , , ,

Bringing Legacy Blog Back to Cover Legacy Products

Just about a year ago, I moved all new posts over to In spite of that, this blog still continues to get much attention due to a lot of the existing content proving to be very useful for users. For that I am extremely happy to help and it recently gave me an idea. I have been mulling over how I should focus my current blog over at Technet with regards to information, guidance, and support tips. While I have a lot of great information coming (a lot of new products/product versions in the pipeline) I also have a wealth of information I’ve been needing to post tat was related to existing products and legacy products (Softgrid/App-V 4.x/MED-V V1, etc.) I also realize there is a strong user community and install base still present who may not be moving off until the products get closer to end of life.

– Steve Thomas

With this said, I decided that I would use this blog on WordPress in the future for legacy product information (App-V 4.x/Softgrid/MED-V V1/VMM 2008/VPC) while keeping my blog over at Technet more related to current and forward technologies (App-V 5.0/UE-V/Hyper-V 2012/Win8/Win2012.)

SCVMM: Service Principal Names (SPNs) Required for Proper SCVMM 2008 Functionality

April 30, 2011 8 comments

SCVMM 2008, 2008 R2, as well as future versions of SCVMM rely on kerberos and kerberos delegation functionality for its security and authentication model. You may encounter various problems with SCVMM related to authentication and authorization if the underlying platform service principal names (SPNs) are not properly set.

There are all sorts of problems ranging from console authentication, to SQL access, or even host access for the purposes of accessing virtual machines managed by SCVMM. All of these problems cann be caused when delegation is failing possibly due to incorrect or missing SPNs (Service Principal Names.)
The resolution is to verify and correct any configuration issues with kerberos delegation, often correcting problems related to SPNs not being registered – or even duplicate SPNs.
You can use the SETSPN command to check for duplicate SPNs and to create missing ones if needed. Please note not all SPNs may be required as that will vary based on what server roles are installed. SETSPN is a default external command in both Windows Server 2008 and 2008 R2. For Windows Server 2003, I would recommend downloading the SETSPN update for Windows Server 2003. More information and download links are found here:
The following list below lists all of the SPNs that may be required relating to their corresponding components. Since SCVMM is a management interface that sits on top of so many different platform components, incomplete or improper delegation at these component layers will cause problems in SCVMM functionality.
Hyper-V Virtual Consoles:

For Virtual Console Support for Hyper-V Hosts (VMCONNECT.EXE) – This will be required on Hyper-V Hosts. Use the following command to set and verify SPNs.

setspn -s "Microsoft Virtual Console Service/HOSTNAME" computername 
setspn -s "Microsoft Virtual Console Service/hostname.fqdn.etc" computername 

For P2V Support.

Use the following command to set and verify SPNs.

setspn -s "Microsoft Virtual System Migration Service/hostname.fqdn.etc" computername 
setspn -s "Microsoft Virtual System Migration Service/hostname" computername 

 For VS2005 Hosts and the VMRC utility

– This will be required on Virtual Server 2005 Hosts. Use the following command to set and verify SPNs.

setspn -s vmrc/hostname.fqdn.etc:5900 computername 
setspn -s vmrc/hostname:5900 computername 
setspn -s vssrvc/hostname.fqdn.etc computername 
setspn -s vssrvc/hostname computername 

For RDP Support.

Use the following command to set and verify SPNs.

setspn -s TERMSRV/hostname.fqdn.etc computername 
setspn -s TERMSRV/hostname computername 

 For all Hosts.

Use the following command to set and verify SPNs.

 setspn -s HOST/hostname computername 
setspn -s HOST/hostname.fqdn.etc computername 

 HTTP (may needed for authentication on SSP if VMM server is using Remote SQL.)

Use the following command to set and verify SPNs.

setspn -s HTTP/hostname.fqdn.etc computername 
setspn -s HTTP/hostname computername 

 SQL VMM Database

Depends on port and instance type: 

Named Instance.

Use the following command to set and verify SPNs.

 setspn -s MSSQLSvc/hostname.fqdn.etc:Port computername

setspn -s MSSQLSvc/hostname.fqdn.etc:InstanceName computername 

 Default Instance.

Use the following command to set and verify SPNs.

setspn -s MSSQLSvc/hostname:1433 computername 
setspn -s MSSQLSvc/hostname.fqdn.etc:1433 computername 

Here are some links to some excellent articles:

Microsoft Virtualization Engine and Management Updates

Here are a listing of significant Microsoft management and Virtualization engine downloads and updates at all levels of the stack:

Storage Virtualization:

Microsoft iSCSI Target Software:

iSCSI Software Target is an optional Windows Server component that provides centralized, software-based and hardware-independent iSCSI disk subsystems in storage area networks (SANs).


Microsoft App-V 4.6 Service Pack 1


Windows Server 2008 R2 SP1:

Hyper-V Server 2008 R2 SP1:

Updated Hyper-V Management Tools for Windows 7 SP1 now available

Update to the Hyper Best Practices Analyzer:


SCVMM 2008 R2 SP1:

Updated Configuration Analyzer for SCVMM to include 2008, 2008 R2, and 2008 R2 SP1

Remote Desktop Services Connector for System Center Virtual Machine Manager

Important notice for those of you building C++ projects with App-V virtualized Visual Studio 2008 . . .

March 31, 2011 1 comment

. . . if you build it with debugging enabled it will not complete and will throw an error in the console window.

When using a virtualized instance of Visual Studio (sequenced following the instructions at

When users build a C++ project in Visual Studio 2008 with debugging enabled the compiled program will not run and gives an error in the console window and/or the interface.

ERROR in Visual Studio Interface:

 “Unable to start program ‘path_to_program\program_name.exe’.”

“This application has failed to start because the application configuration is incorrect. Review the manifest file for possible errors. Reinstalling the application may fix this problem. For more details, please see the application event log.”

ERROR in console window:

“The system cannot execute the specified program.”

[To reproduce this specifically:

Create a new empty C++ project in Visual Studio. Write any compilable and runable code. Build the project (F7). Run the project without debugging (CTRL+F5) ]

 This problem does not occur when the project is set to release mode – only in debug mode.

This is caused by the debug run-time modules not being captured inside the virtual application package because of how the Application Virtualization side-by-side process works during sequencing. The debug runtimes are not used, so they are left out.

In order to work around this, the developer will need to install the debug runtimes on the local machine. They can be built out of Visual Studio 2008 pretty easily as follows:

 1. From Visual Studio, navigate to “File” – “New” – “Project.”

2. Select and expand “Other Project Types,” then “Setup and Deployment.”

3. In the Visual Studio Templates area, select “Setup Project.” Click “OK.”

4. In the Project window, Right-click “Setup1” and select “Add” – “Merge Module.”

5. Select all debug runtimes desired from the list.

6. Click Open

7. Right-click Setup1 and select “Build.”

8. Execute the project. It will install the modules you selected.