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.
Using Virtual PC with Windows 7: Be sure to use Integration Features when the Narrator Accessibility Feature is Enabled
There is an important item to be aware of if you are using Windows Virtual PC (VPC7) and you are also using the Windows Narrator Accessibility feature. The Narrator is an excellent aid for the visually impaired as it reads screen text and echoes verbally various actions. In addition, it will echo verbally what you are typing to ensure accuracy.
If you are running Windows 7using Virtual PC for legacy applications and are incorporating the narration feature, you will need to be aware of an important security item. Normally, when there is a secure field (such as password prompts) instead of echoing the keystroke, the narrator feature will say “hidden” instead. In the case of Windows Virtual PC, this will also be in effect when you type in the password for the guest operating system – IF – and this is a big IF – integration features are enabled. If you are using MED-V to provision these virtual PC’s you will automatically be engaging integration features.
If you are not using MED-V or VPC integration features, you may run into a situation where the Windows 7 narrator will read the contents of the password upon entry into the guest. The Windows Narrator monitors the keyboard to read keystrokes. It also communicates with Windows to check if the field is a secure field or not. In case it is a password field, narrator will not read the keystrokes. Normally, when the password is typed in the password dialog, the response from the narrator will always be “Hidden.” With integration features disabled, this translates to the Windows Narrator in the host as a simple sending of keys to a pane control.
The purpose of Virtual PC for Windows 7 was to provide a seamless integration experience through RemoteApp whether it be through simple Windows XP Mode – or through the MED-V enterprise provisioning solution. If you have users who will still need the Narrator Accessibility feature for their legacy applications, please ensure that integration features are enabled even if they are using VPC in full screen mode.
Just about a year ago, I moved all new posts over to Technet.com. 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.)
When you configure App-V’s desktop configuration refresh feature (i.e. DC Refresh, Publishing/Refresh) you have the option of setting this to occur “on login” and/or using a periodic interval. This configuration can be controlled at the client end or, in the case of an environment using the traditional App-V management server environment, can also be controlled via the provider policy.
The “On-Login” option is partially facilitated by registering the desktop configuration controller (SFTDCC.exe) into USERINIT under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon key. A default installation of both the desktop and RDS App-V clients will do this and start SFTDCC on login. This option is always generally recommended for startup if the publishing configuration for applications is coming from an App-V management server. If you want to remove the on-login behavior, it is best recommended to do this through the client user interface or through a provider policy. Removing the SFTDCC entry from the USERINIT registry entry will simply result in the entry getting re-registered the next time the App-V client service restarts.
The “on login” behavior is a good thing because it ensures all of the user initialization, application asset caching, publishing (Icons, OSDs) and other setup is facilitated around the same time the user’s desktop becomes available. It also corrects potential problems. For example, if another user had previous logged onto that desktop and for some reason deleted an application while you were logged out, this will re-provision your application.
In addition, if your access to an application was revoked while you were logged out, this is the process that hides your shortcuts, and essentially hides the application from you. This occurs even if the
applications assets were previously fully cached. If the SFTDCC component were not configured to start on login, or worse yet, the SFT Listener process were not engaged (most common if the App-V Client services is set to manual) the
shortcuts and assets would still be there, but they would not work.
A common misconception is that sometimes this “on-login” feature causes slow startups in Windows 7. While true, there have been issues where the presence of the App-V client has been a factor in slow startups, there is more to the story than that simple statement. Common troubleshooting steps that have been employed have involved setting the App-V Client service to manual (and thus devising some workflow to start the service post user login) or even removal of SFTDCC from USERINIT. I would advise against either of the above steps as this issue could be one of a few known bugs that have been fixed on both the App-V side as well as the Windows 7 side.
First and foremost, all of the major App-V startup bugs have been isolated and fixed as of App-V 4.6 Service Pack 1 hotfix 3. If you do not have hotfix 3 installed, please install it. You can download this via (http://support.microsoft.com/kb/2571168.) Of course, I would always recommend installing the latest hotfixes for App-V 4.6 SP1 but this one is essential for clearing up a lot of the slow startup problems.
In addition, I would also advise ensuring the following hotfixes have been installed for Windows 7 or Windows Server 2008 R2 to alleviate slow startup problems:
Unexpectedly slow startup or logon process in Windows Server 2008 R2 or in Windows 7
The desktop does not load and only displays a black or blue background after you log on to a computer that is running Windows 7 or Windows Server 2008 R2
And of course, don’t forget, it could be other software causing the slow startup and App-V may just be an innocent victim. Remember this? – https://madvirtualizer.wordpress.com/2011/08/18/yes-trusteer-rapport-does-break-app-v/
MED-V V1 SP1 running on either Vista or Windows 7:
If a workspace configured by policy to use the host machine’s optical drive starts without Optical Media injected (in either full desktop mode or seamless mode) the following may happen:
When you insert an optical disk post workspace start, the drive in Explorer will show the proper-media injected however when you try to open the workspace while the workspace is running you will get the error:
“Please Insert a disk into <TYPE> Drive (n:).”
Likewise – the same also happens inside the guest operating system as well.
After restarting the workspace, it is, however available to the host and guest.
This is caused by a combination of the process for VirtualPC not being elevated and the drive is captured only at startup for a standard user process.
There are four ways to work around this:
1.) Simply restart the workspace with the disk in the drive.
2.) Start the MED-V Client elevated (run as admin.)
3.) Disable UAC.
4.) Disable the feature in the workspace policy.
If required for guest OS’es use a drive mapping to the shared optical drive.
When you install Virtual PC 2007 Service Pack 1 on a computer running Windows Vista or Windows 7 x64 edition, the installation appears in a subdirectory of the “Program Files (x86)” directory. Additionally, the VirtualPC.exe process displays in Task Manager as a 32-bit process.
When Virtual PC 2007 is installed on a 64-bit host Operating System it installs to the 32-bit program files directory. This is because unlike Virtual Server, Virtual PC 2007 is a 32-bit application which uses 64-bit drivers when necessary.
In order to run on a 64-bit host Operating System the drivers must be 64-bit themselves, but the only benefits of making the application 64-bit is the ability to access larger amounts of memory and to run more virtual machines at the same time. While both of these things are very important for Virtual Server, they are not as important for Virtual PC.
This works as designed for hosting 32-bit operating systems as guests on x64 hosts.