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.
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. |
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.
Conclusions
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.
