One of the frustrations that I have in working with App-V 5 virtual apps is remembering to forget everything that I know about how application virtualization worked before version 5. Quite often, the same concept is implemented just so slightly differently that I make assumptions about an app problem that is incorrect, simply because I “know” more than I should. Even worse is when things act differently in some cases but not others due to test cases that I had not considered being important distinctions.
Lately I have been digging into issues we have seen with Connection Groups. I had hoped to have an article that would look at some problems and solve them, but it seems I just keep getting deeper and deeper into side issues that distract me when I discover that at the detail level things don’t work exactly like I thought. Even worse is when they sometimes act differently due to those additional conditions that I had not considered.
Ultimately, I think that my research papers on Pellucidity, Deletion Objects, and Connection Groups in App-V 5 as well as Connection Group Fun with App-V 5 may turn out to be rather naïve for the file system and only really cover certain situations. Eventually I’ll have to update those, but for now let me document one of the side issues that have come up and slowing me down in getting the complete picture of how things work now.
Scripts and Error 534 (hex)
Last year Microsoft’s Josh Davis wrote on adding scripts into Dynamic Config files. But it doesn’t mean that I still don’t struggle with them. Here is an example.
One side issue that came up recently was in attempting to run a simple script as a Publishing Script in the UserConfigusation section of the DynamicConfig.xml file. I simply wanted to create a folder, external to the virtual application, at publishing time.
Here is an example of that script:
Let’s not worry about why I wanted to do this, because it turns out that it doesn’t matter what you try to do in the script. When you add the package with that config file, and then publish to the user, you get this neat little error:
And there is little information about error 534 out there other to state was is already displayed in the error above. Some sort of context error. I had previously considered the wording in point #3 of the “gotchas” section of the Davis blog to be a typo of some kind.
“User scripts cannot be placed in the UserConfiguration section of the deployment policy. User scripts run in a user context and will only be invoked for user Publish and Unpublish as well as the corresponding runtime events (Start/Stop Process/VirtualEnvironment). If you do this, the package add will fail as this will invalidate the deployment config schema.”
I mean, why would Microsoft add a plublishing script sample in the UserConfiguration section, but not an add sample, if you could never use it? I had interpreted that paragraph to mean that AddPackage scripts could not be placed in the UserConfiguration section. But maybe not? But I swear that I have done this in the past.
The exact same PublishPackage script placed in the MachineConfiguration section works great (assuming you publish to the machine using -global). I also tried it using Powershell instead of cmd, and even just gave it a benign command. All fail with the same error.
We believe that the scripts, including a UserConfiguration PublishPackage script, that are indicated as running in the user context in the Davis blog should be executed by a system process that impersonates the user (which is why user profile environment variables are not available to the script). So it looks like some kind of SID issue. Enabling all of the App-V debug logs also provide no new insights.
After a bit of testing, I learned a new small detail that affects scripts. What kind of account you are logged in as makes a huge difference!
Here is a summary of some test cases that I ran on 5.0 SP2:
| Log In As | File Section | |||
| UserConfiguration | MachineConfiguration | |||
| PublishPackage | StartVE | AddPackage | PublishPackage | |
| Administrator | Error 534 | Error 534 | OK | OK |
| Standard User | OK | OK | OK | OK |
The 534 error appears differently when it occurs in a Start of VE script (and I assume also StartofProcess script):
I usually test first logged in as an Admin, and when it looks OK I then test as a standard user, so that was the issue, unless of course you have users that normally log in with Admin rights. It looks like they will need either AddPackage or global publishing if they need scripts.
Side note for those using my AppV_Manage tool: Log in as a standard user. You need to launch AppV_Manage using the RunAsAdministrator in order to perform actions such as AddPackage. But you need to launch the tool without RunAsAdministrator if you want to perform other actions, like publishing to the user instead of the machine. This advise is based on the AppVClient powershell requirements and is unrelated to the permission issue in the use of scripts documented above, but necessary to know if you want to test as a standard user.
For extra credit
Ultimately, I realized that although I want the script to run when the app is published to a user account, in reality it would be equally reasonable to run it at AddPackage time. So moving the script to the MachineConfiguration section and changing it to an AddPackage script made this script work for all users. But, of course, this is not going to help if I need to perform an act that is user specific, such as drop in a license key, and the user is an admin.
An additional issue I noticed is that the script must return 0 when RollBack is set. I want it to rollback if the directory creation fails, but not if it fails for the reason that the directory already exists. This is easily handled by a modification of the script to first check for the existence of the directory, and to keep it simple without adding a multiline file I modified the AddPackage script to use powershell:
<AddPackage>
<Path>powershell.exe</Path>
<Arguments>-NonInteractive -Command “if (test-path -path C:\BaseVFS) {return 0} else {mkdir C:\BaseVFS}”</Arguments>
<Wait RollbackOnError=”true” Timeout=”30″/>
</AddPackage>
