Category Archives: Uncategorized

What next, MDOP?

Microsoft Desktop Optimization Pack (MDOP) is a subscription add-on used by many enterprises with Microsoft Enterprise Agreements (EA) that provides a number of software benefits. The software has recently been released on a twice-a-year basis, making the next version due sometime soon. Microsoft typically does not pre-announce release dates, so we can only guess that, based on the last release being November 1, we should be due for a release around May 1.

In addition to providing upgrade benefits, meaning you can upgrade PCs to the latest version of windows as long as the MDOP subscription is in place, MDOP provides additional software to help with enterprise deployments of Windows Desktops. In each release of MDOP, Microsoft typically updates a subset of these applications, and sometimes adds new ones. The last released version of MDOP (2013 R2) included updates to support Windows 8.1, plus a few extra things. The biggest was a major update to the Application Virtualization product (App-V 5.0 SP2 and 4.6 SP3) and smaller updates to Microsoft BitLocker Administration and Monitoring (MBAM 2.0 SP1), Advanced Group Policy Management (AGPM 4.0 SP2), and Diagnostics and Recovery Toolset (DaRT 8.1). Other components in MDOP include the User Environment product (UEV 2.0), and Med-V and were apparently unchanged from the previous MDOP release.

Given that Windows XP is no longer under support, I am guessing that the next version of MDOP will drop MED-V. MED-V is the managed version of Windows 7 “XP Mode”, in which a copy of Windows XP is virtualized on top of Windows 7 using the older “Virtual Computer” hypervisor. If XP goes away, I can’t see Microsoft continuing to support MED-V as a product. Probably more important than the virtualization piece of that product, what Microsoft should find a way to re-use is the innovative user interface integration that came with the acquisition that created MED-V. In a world where people are using virtual machines, whether local or remote, integration of the user experience on a per-application basis remains interesting. Citrix has long had such capabilities, and other than RemoteApp, Microsoft does not. The value of having a single user interface experience, start menu, file associations, and “seamless application windows” on a single desktop is the end-user’s nirvana. This might or might not be an MDOP thing, but I hope they don’t forget about it if MED-V is dropped.

But if MED-V is removed from MDOP in the next release, Microsoft will feel a little pressure from customers to add something more into MDOP. Which opens up the fun guessing game of what Microsoft could or should add!

I think that everyone’s top item, a license allowing you to for host VDI images on a shared hosting provider infrastructure, ain’t gonna happen. MDOP might not be the right vehicle for that anyway, but anyway we can get it would be better than the current situation.

Next on my list would be things to improve image management. Something like the capabilities of the Microsoft Deployment Toolkit (MDT) but with a better user interface would be great. I love MDT, but the UI is something out of the 1980′s. It can be a pain to do things like make a copy of a task sequence to tweak it.

Or maybe attack image management from the other end. Something along the lines of FsLogix is doing. I like their idea of a single image tweaked at runtime by policy, in essence enabling apps on the fly, so much that last year I joined their advisory board. You still need App-V to handle application conflict, but a combination of something like FsLogix, App-V, and a better User Environment product would be a solid combination. Microsoft might be better to buy the company and add it to MDOP rather than develop on their own, but one way or another the capability would be a great addition to MDOP.

Further down my list is something to help the user and IT organize all of their remote “stuff”. A single interface where remote machines, remote apps, storage repositories, and even website credentials are managed. This could be simply a UI that accesses things, or more of a secure repository that also holds the credentials (safely) with centralized backup. This would require Microsoft to move their thinking beyond “just buy Office 365″, which might be too much to ask, however.

Given the lack of noise, I doubt any of this is happening soon. What would be on your list for MDOP?

Disclaimer: Although I am a Microsoft MVP, this article contains no “inside knowledge” or NDA material. My contacts at Microsoft are not talking about this and clam up if asked.

Request for new VDI Term: “Semi-Persistent”

VDI is often categorized as either Non-Persistent or Persistent.

Non-persistent VDI is where you use a shared common image. Only one image to maintain. When the user logs off, the image is destroyed and the next time the user logs on they get the original image.

Persistent VDi is where the complete image is retained upon logout and the next time the user logs on they get the exact same image they had when they logged off.

The reality is that usually Non-persistent VDI implementation brings along some user data from the prior session. This is handled by Roaming Profiles at a minimum, but may also have folder redirection or a user environment add-on product to manage the user-related-data, either app related (UEV, AppSense, RES, TriCerat, Norskale, etc) or layering (Unidesk, Citrix PVD, 2012R2 “User Layer”).

I think we need a different term for this, segregating it from Non-persistent. I’m going to start calling this “Semi-Persistent”. What do you think?

Microsoft blogs about AppV_Manage

Maybe there is something to AppV_Manage you’ll find useful. This free tool from the App-V 5 Tools section of the TMurgent website was recently covered as a great source for troubleshooting App-V in a Microsoft support blogpost on TechNet by Microsoft’s own John Behneman!

Check it out here:

Scripting Restriction in App-V 5: error 0x8AD

In our training class on App-V 5 SP2 two weeks ago (yes, I did do the class using the Service pack less than a week after the release), we had a problem in one of the labs and saw a new client error 0x8AD. I won’t name names, but the student causing all the chaos is visible in the photo below.

Photo from App-V December 2013 Training Class
Or at least the error seemed new to me. Maybe it was in the earlier versions and I hadn’t run into it, or maybe a different error return from an otherwise known (but easily forgotten) problem.

The problem threw us for a loop, and with multiple people all trying different things it got a little crazy to where I thought perhaps we had a situation where sometimes it worked and sometimes not. In the end, being able to test in a calmer environment with my own hands on the keyboard, I was able to see it for what it was. Here is the story.

We wanted to use DeploymentConfig File scripting to modify the way an application acts after sequencing was complete. Often, this is something you might do if something small is found in UAT and you don’t want to crack the package back open. In our case, we wanted to add the ability for the end user to select the default FTA for a number of graphical file FTAs used by the application. The vendor did not register these capabilities (Application Capabilities publishing) but we can add them ourselves. Normally, I would perform this action inside the package, but we wanted to work with the scripting in the Config files.

The registration of Application Capabilities includes adding some registry items, and we created a set of reg import files to use when publishing and unpublishing the package. But some students got an error, 0x8ad when publishing at the client. Others did not. It took some time to figure out what happened and we jumped to a number of wrong conclusions and issues along the way.

PS C:\Users\Admin> Publish-AppvClientPackage -PackageId 7cf15471-58b2-4753-a5d4-79c4e7446a0d -VersionId 691357a2-96c2-4278-86c5-8bb418b8a0a2

Publish-AppvClientPackage : Application Virtualization Service failed to complete requested operation.
Operation attempted: Publish AppV Package.
Windows Error: 0x8AD – The user name could not be found
Error module: Shared Component. Internal error detail: 0DF02625000008AD.
Please consult AppV Client Event Log for more details.

Issue #1: Disabled scripting at the client (Result=error 0x0D)
This is not enabled by default when you install the client. I leave this off in the class VMs I provide so that students run into this problem in the lab. When scripting is disabled, the error occurs only when the script is run, not when you perform an action using a Config file that includes scripting. So if you Add-AppVClientPackage with a DeploymentConfig file that has scripts, the cmdlet will complete without error as long as you didn’t have an AddPackage script. If it contains a PublishPackage script, you would see the error at Publish time, StartVirtualEnvironment or StartApplication would occur when you later launch the app.

Issue#2: Wrong place in the file. (Result=script didn’t run)
The PublishPackage script has two locations inside the DeploymentConfig file, in the MachineConfiguration section and in the UserConfiguration section.
If you intend to publish using the -global flag, you must place the PublishPackage script in the MachineConfigion section of the file, if you intent to publish to the current user, you must place the PublishPackage script in the UserConfiguration section of the file.

If you put only a script under one section and publish using the other mode, the script never runs.

Issue #3: Testing with a cmd prompt to “see the script”. (Result=Nothing, then Rollback with error 0x0A)
Because of the above, people often want to replace the script with a cmd prompt, so that they can try to run the action themselves. So they replace the script command and parameters with “cmd.exe” and “/k”.

This might work great on a StartVirtualEnvironment or StartApplication script that is running under the user context, but not for those running under the system context. If you do anything in the script that causes a user-interface interaction on a script running under the system context (add, remove, publish, unpublish, for example), these scripts will get stuck since there isn’t a valid desktop to display/prompt on. They seem to just get stuck waiting for input. Eventually, the script timeout (default 300 seconds) kicks in and kills the script. If you kept the default rollback action of true on the add/publish scripts, you’ll get an error, but only if you wait around 5 minutes to see it.

Some students also hit this problem not with a cmd prompt, but because they forgot the “/s” option on the regedit command to silently perform the import. By the way, regedit and regedt32 both accept either “/s” or “-s”.

Issue #4: Understanding what you can/cannot do in each section.
You can, and probably should, put the publish script (or a version of the script) in each section. The reason for potentially two versions of the script is that you might have different script versions depending on if the publish is to all users or only the current user being published. For example, our scripts should affect HKLM locations when publishing globally and HKCU locations when publishing to a specific user since the app it is related to has the rest of the extensions published that way..

One piece of overly-simplified advice from Microsoft that you might here is that if you want to change HKLM locations, this must be placed in the MachineConfiguration section and if you want to change HKCU locations these must be placed in the UserConfiguration section. But it turns out that this is true only if you are placing entries in the “Registry” element of the xml file. A script is allowed to modify either registry hive. You might not want to affect locations affecting all users in a user publishing action, but it will work. Not understanding this can cause confusion when troubleshooting also as you can jump to wrong conclusions about the results you just saw.

Issue #5: Failing to remove and re-add the package when changing the DeploymentConfig file.
Typically, the script command is to run a command against a file. While Microsoft recommends putting the file inside the package, often we prefer to put the file in an external location, such as the folder that holds the AppV package itself.

If your first test didn’t produce the results you wanted, you might be able to just edit the external file. Then, all you have to do is unpublish/publish to get the updated script to run. But if you had to edit the DeploymentConfig file itself, then you must also remove the package, and then re-add it with the updated config file first. There are at least three ways to mess that up and in a room of 10 students at least 2 will do it.

And if it had been an Add-Package script you always have to remove and re-add with the DeploymentConfig file, whether you edited the DeploymentConfig file or the external script file.

Issue #6: Clients never forget
The theory that you can just unpublish and remove the package and re-test is invalid. Sometimes it will work, but sometimes not. Our mystery 0x8AD error made this painfully clear. The client does not clear everything out. And if you had any unbalanced bad scripting, it gets worse.

When I add something in a Publish time, I always add a script to remove it at unpublish. Same with Add and Remove. But if one of those scripts has an error, you are now out of balance. (Often unnoticed when it is the undo script as the default is Rollback=false). And this will affect subsequent tests. So remember to revert the client VM now and then to get rid of ghosts of the past.

Issue #7: Always edit a copy
To the best of my knowledge, the 0x8AD error we had in the class happened due to an editing mishap that placed something in the XML that the client didn’t like when we published. What that was, I don’t know. We looked and looked. We copy and pasted. Sometimes we saw the error, sometimes we didn’t. We left believing that the new release probably contained a new scripting bug that only appeared at random.

In the calm of my own lab, I found that wasn’t true. I still don’t now exactly what was wrong with the DeploymentConfig file. But the student followed my advice and made a backup copy of the original file before starting the edit. I was able to wipe out the badly edited version causing the problem with a pristine copy of the original, edit it, and get everything to work perfectly.

The only problem with making a copy is where to put it. If you deploy using SCCM, you definitely don’t want it in the same folder as the App-V package. So I’d recommend dropping it in a subfolder in that case, otherwise, I just copy paste directly in the same folder.

When scripting, make the backup of the Config file before editing. If you have a problem, don’t try to quick-fix-it. Be methodical and try to not jump to conclusions, of you just make things worse. When in doubt, revert everything and start over.

Maybe someday the App-V team will give us a real editor for scripting and prevent this nonsense. I know a dozen people that agree with me on this now.

Is App-V 5.0 SP2 the release to use?

Yesterday, Microsoft released App-V 5.0 SP2 as part of MDOP 2013 R2. (The photo on the left is from the MVP summit two weeks ago with myself, Nicke Kallen, Aaron Parker, and Adam Kiu of the App-V Dev team. He couldn’t tell us when the release would come down, but clearly his work had been completed and he was one happy cookie). Rather than talk about the cool stuff (you can read that elsewhere) I am going to talk about some realities. The biggest competitor to App-V 5.0 is App-V 4.6, not the going-away Citrix Streaming and not ThinApp. I have been cautious about upgrading in the last year, so let’s update where I think we are with what version you should use.

For companies new to App-V, 5.0 SP2 is definitely the way to go.

But for companies on 4.*, I have been more cautious. Unless they had a specific need to upgrade, I said that they should be working with 5.0/SP1 in the lab but that SP1 was not necessarily the release we wanted.

5.0 SP2 adds significant advantages, and I believe that now is the time for most customers to move on. I might even say something nice about virtualizing office once I see companies happy with it for about 6 months. There will be some gotchas along the way, but so many of the things you work-around today with 4.* go away so it will be worth it in the long run. However, there is no need to rush it…

  • 4.6 SP3 was also released yesterday. This supports your need to handle the newer operating systems, 8.1 and 2012R2 without removing support for those older client OSs. If you can’t handle Win 7 SP1 as the lower end of client OS support, you’ll need to keep this around.
  • We need to do some performance testing on the release. Chances are that we have some improvements over the Beta, but maybe not everything. I wouldn’t want to commit RDS/VDI workloads company-wide to 5.0 without doing some pilot testing including performance testing.
  • We need to think about the automatic silent deployment of the VC runtime/msxml components a little more. I love that it solves the problem automatically, but in highly secure deployment scenarios you really don’t want older versions with known security flaws being dropped on the system. We can handle this — but not if you take the attitude that you can just ignore VC Runtimes from now on.
  • XenApp customers that don’t give any users access to the full desktop probably want to disable the new shell extension support at the client, since it will slow things down at inappropriate times without giving the user the functionality. I think this can be disabled at the client level using the new EnableDynamicVirtualization configuration setting, but I’ll need to play with the actual release bits to be sure what the side effects are.

So go get the bits and start having at it. Be cautious, but move on!

AppV 5 Connection Group “Pellucidity” and Deletion Objects

I have written a new “white paper” on App-V 5. This one looks at package “pellucidity” (the layering effect caused by the settings “override local” or “merge with local”), and package deletion objects and how these are implemented at the client when you use Connection Groups.

As it was in 4.6 with DSC, all is not as simple as you might think. The paper makes a nice reference with charts showing you what happens in each of the possible combinations. Fortunately, most of the time the client is doing the reasonable thing. But when you hit those other cases you need a reference like this to figure out what is going on. It’s full of charts like this…

…as well as explanations. You might think the virtual file system and virtual registry would behave the same way, but you’d be wrong!

White Paper at Pellucidity and Deletion Objects: Connection Group Layering in App-V 5

Training my VDI Desktop Images for Quick Boot

I am constantly building new VM desktop images for my lab, here are some tips on how I am doing it.

I use MTD to make life easier. If unfamiliar, MDT (Microsoft Deployment Toolkit) is free, simple, and has a lot in common with SCCM task Sequence deployment, but will less overhead. I have a lot of standard stuff I put into builds, with just a small change here or there. MDT creates a bootable ISO that automates as much as you want. My ISOs only prompt for which task sequence to run and the OS name. Everything else is automated, including the domain join, timezone, and other out-of-box OS customizations. To get my resultant VMs to boot quickly, I do two important things before I take a snapshot.

First, is that I have a group of commands at the end of every task sequence. (Making it a group makes it easy to copy the entire group to a new task sequence). The group consists of 5 sets of two actions. The first action is an application “install” with the command “powershell.exe Sleep 240″. This command sleeps for 240 seconds and will be run after the automatic login completes. The second action is a reboot. The purpose of this is to train Microsoft ReadyBoot. It makes the OS boot much faster. About 180 seconds after logon completes, the system stops recording logon activity and updates the ready boot data. This data is used in the next boot to speed up boot time by pre-reading boot files during the boot process. I find about five times is great for speeding up the boot and more does not help. This training should be done after all installs have been completed. You can usually reduce a 45 second boot down to below 20 seconds with this.

Second, I remove the virtual CD used for booting before taking the snapshot. Under Hyper-V, this mount setting is saved with the snapshot and delays booting by about 10 seconds.

So what is in my standard App-V Client task sequence?

  • Sysinternals BGInfo
  • Sysinternals ProcessExplorer
  • Sysinternals Process Monitor
  • Disable Network Logon Password Change
  • Enable Remote Desktop
  • App-V 5 Prerequisites
  • Restart Computer
  • AppV 5 Client
  • Disable Windows Updates
  • Copy App-V Client Console Shortcut to desktop
  • Set Powershell Execution Policy
  • Copy PowerShell Shortcut to Desktop
  • AppV_Manage 2.2
  • Copy AppV_Manage shortcut to desktop
  • Set of 5 sleep/restarts

App-V 5 and App Related Data

One of the big benefits of App-V has always been that applications that needed certain kinds of remediation to work today were automatically dealt with.

I’m talking about apps that were developed without complete support for multiple users (or multiple tenants), or for apps that assumed systems that have no security protection to write to common locations.

We just sequenced them, and App-V automatically redirected any writes by the user to a safe location isolated to only that app. And it all roamed with the user.

Until version 5.0, where Microsoft decided that virtualized apps should behave more like non-virtualized apps. For the most part, the changes in 5.0 are welcome and make the job of preparing and distributing apps easier. But not for a log of older apps.

Primarily we are talking apps that were originally developed before UAC in Windows Vista, but also apps originally developed before people understood multi-user in Windows XP. These categories, unfortunately, include a whole lot of business apps developed by enterprises themselves. And in most cases the enterprise cannot update the app. Reasons for being unable include:

  • No longer knowing where the source code is
  • Developer is no longer at the company
  • Don’t have the tools to even rebuild that old code
  • Nobody wants to take ownership of it

In App-V 5, we really have a couple of big problems with these apps:

  • The virtual app doesn’t roam all of the changes made by the user (the ARD).
  • The app won’t work because of file or registry writes that now fail

You would still have those problems with a natively installed version, so App-V 5 isn’t breaking anything that way, but usually these apps worked great in App-V before.

A while back, I created a tool (AppRemediation) to take care of much of the first issue. I continue to find more things and need to update that tool at some point; it doesn’t get 100%.

So to better understand the problem, I performed some new testing. The accompanying chart shows the results of all of that testing.

Click for a larger image

Testing was done using a new version of my home-built AppVPersonalization tool that allows you to write to specific places and see if it works, or where the data is being written.

The testing consisted of making a package with files, registry items, and environment variables of different kinds inside the package. I tested both cases of having the program be located inside the PVAD folder and not (VFS’d). I also tested as an admin or standard user, and with the program elevated to a different admin user using RunAsAdministrator. The chart above shows what happens in the different scenarios.

I am hoping that Microsoft will continue to adapt the App-V product to improve it’s ability to make virtual applications easier for these older applications. If not, at least you know a little more about what to look out for.