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.
If you have not already heard, today MDOP (Microsoft Desktop Optimization Pack) 2013 R2 became generally available for download to our MDOP customers. More information can be found here:
This latest incarnation of MDOP includes the release of:
- Application Virtualization (App-V) 5.0 SP2 and the virtualization of Office 2013
- Application Virtualization (App-V) 4.6 SP3
- User Experience Virtualization (UE-V) 2.0
- Microsoft BitLocker Administration and Monitoring (MBAM) 2.0 SP1, which also offers multi-language support.
- Diagnostics and Recovery Toolset (DaRT) 8.1
- Advanced Policy Group Management (APGM) 4.0 SP2
Primary release pillars for MDOP 2013 R2 revolve around support for Windows 8.1.
If you are still using App-V 4.6 on Windows 7 (either 4.6 SP1 or SP2) or Windows 8 (4.6 SP2) you may also be aware that the installation of Windows 8.1 will be blocked if it detects the presence of any version of App-V 4.x. This will also include 4.6 SP3 if you decide to go ahead and pre-install SP3 prior to the upgrade to 8.1. This relates to the
operating-specific drivers that are used by App-V 4.6. If you are planning to use Windows 8.1 with App-V 4.6 SP3, you will need to first remove any installations of App-V 4.6. Then you can upgrade/install Windows 8.1. Once Windows 8.1 is installed, you can install App-V 4.6 SP3. Please note this approach only applies to App-V 4.6 and not App-V 5.0.
While the App-V Client settings and user application settings will be retained with the uninstallation/reinstallation approach, the App-V 4.6 cache will be reset so applications will have to be re-delivered (re-streamed, pre-cached, re-advertised, etc.) Normally to avoid having to do this in the past, administrators would simply do in-place upgrades. This one-time exception does not allow for this and will require likely adjustments if you have users currently using virtual applications with 4.6 and will be upgrading to Windows 8.1 from Windows 7 or Windows 8.