Issue with RequirePublishAsAdmin with SCCM 2012 and User Targeting

SP3 for App-V 5.0 introduced a new feature called RequirePublishAsAdmin which allows Administrators to restrict non-admins publishing packages to themselves if they are already added to the machine. For a full run down of this feature read here, it was on this post a commenter brought up the question of whether or not this feature would work with SCCM delivery (Thanks IV!), assuming it would work I thought I would test just to confirm however what I found is the commenters concerns were indeed justified….

The Error

Once RequirePublishAsAdmin is enabled and a non-admin user tries to take delivery of a user targeted App-V application the delivery fails and the following error occurs:

failed2

failed3.1

The Cause

The cause of this error is exactly as suspected by the commenter on my previous post, the PowerShell process running the publish command runs as th user and therefore is automatically blocked from running.

If we dig into the AppEnforce.log we find evidence of this:

failed4

failed3

Above you can see the first App-V command which is the Add operation runs with a PID 2916 and completes successfully with a return code of 0.

However the second command which is the Publish operation runs with a PID of 1572 and fails with a return code of 1.

failed4.2

A quick ProcMon shows us that as suspected PID 2916 (Add) runs as system and PID 1572 (Publish) runs as the user and therefore fails.

Summary

In summary the RequirePublishAsAdmin feature is not fully compatible with SCCM 2012 user targeted deliveries. I have tested the same scenario with App-V Server with no issues.

0 Comments
January 13, 2015

Running App-V 5.0 Commands on a Remote Machine with or without PSRemoting

Since the introduction of App-V 5.0 and the PowerShell commands which we have come to know and love there has always been the question around ways we can execute these commands remotely. As more and more organisations start to look at how they go about supporting their App-V environments and build up their own tooling, whether it be for desktop support activities or cache maintenance, the question about remote management arises.

Now the obvious answer for running PowerShell commands on a remote endpoint is enabling and leveraging PSRemoting however I have found certain organisations tend not to allow this feature to be enabled over security concerns. Lets take a look at the options either way:

With PSRemoting

PSRemoting is very powerful allowing us to run PowerShell commands on a remote machine as if it was being run locally. First thing to do is enable PSRemoting:

1. Enable PSRemoting

There are various ways to enable PSRemoting which basically needs the WinRM service, the easiest way to do it across multiple machines is via Group Policy:

Just open: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service 

Enable the Allow Remote Server management through WinRM policy setting.

winrm1

Alternatively if you are just testing you can enable it on a particular machine using the Enable-PSRemoting cmdlet.

enablepsr2

Click here to read more on TechNet about the Enable-PSRemoting cmdlet.

You can test connectivity from a remote machine using Test-WsMan COMPUTERNAME

testpsr

Now all you need to do is run your commands!

2. Use PSRemoting

There are two main ways you can run your commands, either by issuing a single command or via an interactive PowerShell session.

To issue a command use the following syntax:

Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { COMMAND} -credential USERNAME

For example here I have remotely removed a package from cache:

psr1

We can do the same thing from an interactive console if we wanted to run more than one command:

Enter-PSSession -ComputerName COMPUTERNAME -Credential USERNAME

psr2

Above you can see how I am using an interactive session to interact with my remote client by querying a package and then removing it. To be honest this is just the tip of the iceberg, there is so much more you can do. I have seen some organisations write their own custom tools which use PSRemoting to enable them to support and maintain their environment. If your in the same position hopefully you can leverage the same techniques, better yet why not check out some of the toolsets already out there, my favourite is Bram Wolfs App-V Scheduler - which amongst other features includes much more user friendly way to query remote endpoints using its Central View console.

Without PSRemoting

So what if PSRemoting is disabled in your environment and restricted due to organisational policies? Well all is not lost! Recently someone from a large insurance company contacted me about this scenario and was kind of enough to share how they worked around not having PSRemoting enabled (Thanks Gyan!).

The workaround involves invoking PowerShell via WMI using the Create method of Win32_Process:

1. Assign to Variable

First thing we need to do is assign the WMI Class Win32_Process of the remote machine to a variable from our local machine:

$Process = [WMICLASS]”\\COMPUTERNAME\root\cimv2:Win32_Process”

wmiclass

2. Invoke Process

So now all we need to do is utilise the Create method of Win32_Process to invoke whatever we want. In this case we want to use PowerShell to remove a package from cache on a remote machine:

$Process.Create(“PowerShell.exe Remove-AppvClientPackage PACKAGENAME”)

wmiclass2

What the above will go and do is go invoke PowerShell on the remote machine and run my specified command, so one minute I have my package and next minute it’s gone! The great thing about all this is it doesn’t need PSRemoting enabled as its all done over WMI. The not so great thing is the feedback, as you can see from above the returned information once issuing the command isn’t that meaningful.

We can however query WMI to find out if the package is there:

Get-Wmiobject -ComputerName COMPUTERNAME -NameSpace Root\APPV -Class AppvClientPackage | where-object {$_.Name -eq “PACKAGENAME”}

wmiclass4

Above is the output you can expect when the package is present, you will get a null return if the package isn’t there. There is a lot more you can do with the WMI provider for App-V to query and execute commands however it probably just needs a bit more investment of time compared to using remote PowerShell.

So in summary if PSRemoting is enabled in your environment you can very easily begin to put together your remote support solutions or even look at some of the third party tools out there already. If PSRemoting is restricted in your environment then WMI is your answer, it may be a little harder to get familiar with but it does offer a lot of potential to act remotely.

0 Comments
January 8, 2015

Everything you need to know about App-V 5.0 SP3

App-V 5.0 SP3 is now available on MSDN as part of MDOP 2014 R2, there are some great features that you need to check out! Here are detailed posts detailing the key features of this release:

- Connection Groups 2.0 – More Manageable & More Flexible

- User RunVirtual Key

- Merged Roots and PVAD changes

- Require Admin for Publishing

You can download it as separate .ISO files or as part of MDOP 2014 R2:

downloads

Don’t get thrown off by the “Application Virtualization Hosting” – its just the desktop client, server and sequencer!

Check out Microsoft’s TechNet documentation on the release here.

Also check out Tim’s great breakdown of all the new features here.

Enjoy!

5 Comments
December 4, 2014

RequirePublishAsAdmin in App-V 5.0 SP3

Right so pre SP3 for App-V 5.0, aslong as a package was added into the client cache, any user (admin or non admin) could go ahead and publish the application to themselves with a quick and easy line or PowerShell. There weren’t really many ways to negate this apart from custom ACLs on the package store or using a feature called PackageStoreAccessControl, a feature which has now been deprecated and is no longer supported.

Enter RequirePublishAsAdmin…

You might notice this new setting available on the App-V 5.0 SP3 client when running a Get-AppvClientConfiguration

setting

You enable this setting with a simple Set-AppvClientConfiguration -RequirePublishAsAdmin 1

Once enabled exactly what you expect takes effect, the next time a non admin user logs on, even if a package has already been added to the client they lose the ability to publish packages to themselves. To understand more about the difference between adding and publishing read here.

Here we can see a standard user has visibility of the fact a package is in cache but not currently published to them:

getdash

If this non-admin user tries to publish this package they will get the following message warning them they need admin rights:

publishdash

This is well welcomed feature, however there is no thing to note, unlike PackageStoreAccessControl, RequirePublishAsAdmin does not prevent a non admin user browsing the package store cache and reading the contents or even copying contents out. It does however stop a non admin gaining access to a package that has not been authorised to them.

2 Comments
December 4, 2014

Merged Roots in App-V 5.0 SP3 – Free from the PVAD

Before I say too much lets play a game of spot the difference! Below are two screenshots of me sequencing Paint.NET in both pre-SP3 and SP3 for App-V 5.0:

Pre-SP3

preSP3PVAD

SP3

SP3noPVAD

Spotted it?! Of course you have. You will notice that the SP3 sequencer no longer requires the entering of a Primary Virtual Application Directory or PVAD prior to sequencing. Now to say the PVAD has been the subject of a lot of discussion since the release of App-V 5.0 RTM would be a massive understatement! I can recall countless conversations/debates about what the standard should be, most people had strong feelings that the best way forward was to avoid the PVAD and go VFS all the way! Well check out how this package looks when sequenced as default now:

SP3VFSMerge

That’s right, everything is now put into VFS. Cutting down the confusion and making things much clearer! Another massive benefit of this and one of the reasons people used to specify “dummy PVADs” is now the roots of packages inside a connection group will merge. Not to be confused with the Merge with Local Directory setting, even as standard without tweaking the behaviour if I were to the sequence another package which shared the same root, the packages will automatically merge. For example I have sequenced the following plugin for Paint.NET:

SP3VFSMerge1

As you can see the plugin package shares the same root as the parent package, no worries however, with merged roots the default, without any extra tweaks once these packages are deployed in a connection group, the roots will merge seamlessly allowing Paint.NET to see and load in the plugin package.

But I really want to use the PVAD!

Really? Well there are ways to bring it back:

1. Launch the Sequencer from a command prompt and specify: Sequencer.exe -EnablePVADControl

2. Populate a DWORD value called EnablePVADControl in registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Sequencer\Compatibility. Setting the value to 1 will enable the PVAD field next time you launch the Sequencer and 0 will turn it back off.

enablepvad

3. Use the command line sequencer and specify the -PrimaryVirtualApplicationDirectory argument against New-AppvSequencerPackage.

So is the PVAD debate well and truly over? More or less I’d say as the default to approach of VFS is now inherently part of the sequencer GUI. However there is the option to use PVAD via the methods above so we cannot say goodbye to the concept just yet!

Read more about the improvements of App-V SP3 here!

0 Comments
December 4, 2014

Connection Groups 2.0 in App-V 5.0 SP3 – More Manageable & More Flexible

Connection groups have been given a lot of attention in the latest SP3 release of App-V 5.0 in what is now a more flexible and more dynamic overall picture of how we can manage these groups. There are two main improvements that have been brought into the fold:

Optional Packages

Pre-SP3 for App-V 5.0 every package in a connection group had to be published to the user/machine where the connection group was being deployed otherwise it would fail to be registered. For example if I had Paint.NET with a selection of plugins all held inside a connection group published to my users:

CG

But one of these packages was no longer published to my users for whatever reason, for example the license expired so it had to be decommissioned, in this example the plugin “Donut”:

packages1

Because all packages in the connection group are not present or available the user the connection group would fail to be delivered on the client:

error

This presented a bit of a manageability challenge as administrators would need to constantly check that consistency between packages published and connection groups published was in sync. A user would need access to every package in a connection group to receive it, if a package was published then the administrator would need to ensure it was also removed from the connection group. This challenge was further expounding when managing different sets of users. Imagine we had different users who were licensed for and used different combinations of these plugins with Paint.NET, we would essentially need to create multiple connection groups for each desired combination of packages.

Now things are much more simple with the optional parameter we have with the App-V Server:

optional

By simply ticking the box next to indicate that the Donut plugin is optional it will mean even if my user does not have it, the connection group will still go ahead and publish the connection group with the other packages:

published

Use Any Version

Another new improvement to connection groups is the use any version option which does exactly what you would expect! It allows makes a connection group flexible to the version of a particular package that needs to be present. This again addresses some of the manageability challenges we may of had previously with connection groups.

For example say pre-SP3 we decided to upgrade Paint.NET to a new version, publish it to our users and unpublish the older version:

updated

Our connection group would now not be delivered as users will have lost access to version 1 and only have access to version 2:

error

This version sensitivity again could potentially add a big overhead to management of connections groups as every update to a package would need to be checked against connection groups it may affect. This is again further expounded when we have different users using different versions of a package that require connection groups as we would need to create separate groups for the different combinations of package.

Luckily this is all in the past as we can now simply check the box that says Use Any Version:

anyversion

Ticking this box against the Paint.NET package means we can now deploy new versions without worrying about the sensitivity of connection groups it may reside in. Aslong as the user/machine has any version of the package, the connection group will go ahead and publish.

New Schema

So how does this all work I hear you ask? Simple, its all made possible by the new 2014 schema which evaluates the group metadata held on the publishing server. Notice the true and false values against our new PackageOptional and VersionOptional values in this connection group:

metadata2

Off the back of this the client publishes a new connection group PackageGroupDescriptorTemplate.xml which leverages the new settings in a brand new 2014 schema.

templatefile

Notice the * values next to VersionId on certain packages and the IsOptional values:

templatefile2

This all the gets parsed into a traditional PackageGroupDescriptor.xml that we are used which contains the packages we should have the connection group in this particular instance based on the template above.

Priority Settings

I’ve talked about connection group priorities in depth here and how priorities can be used to overcome these. Pre-SP3 has to be down via PowerShell on the App-V Management Server however this has now been brought into the console as a configurable:

priority

And as if that wasn’t enough check out Merged Roots in App-V 5.0 SP3 for another reason why connection groups are even easier to manage in App-V 5.0 SP3…

services banner1

5 Comments
December 4, 2014

RunVirtual comes to the user in App-V 5.0 SP3

That’s right people! The RunVirtual feature that was limited to machine targeted packages affecting all users has now been enhanced to allow user specific deliveries. If your not familiar with RunVirtual then read here first for a quick run down.

Machine RunVirtual

First of all its worth mentioning nothing has changed with machine based RunVirtual, the key still exists in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual, it still affects all users on the machine and it still requires that a single globally published package is referenced.

User RunVirtual

This new key lives in the equivalent you would expect in HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\RunVirtual, it will not already be there so you can go ahead and create it. It too has certain conditions in that the default key must contain reference to a single package which is published to the user. Of course the ability to now use RunVirtual on a user basis means we have much more flexibility, especially when we consider shared platforms such as RDS environment where different users will have different packages and publishing to the machine is not always an option.

Conflicts between User and Machine RunVirtual

There are a few scenarios whereby we may end up with conflicting or overlapping RunVirtual between machine and user keys, here is a breakdown of how they will be handled:

- If the same local process is used in both machine and user RunVirtual for different packages the user key will take precedence and the user targeted package will be loaded. For example:

- HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\RunVirtual\winword.exe

- Plugin 1

- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual\winword.exe

- Plugin 2

When winword.exe is launched plugin 1 will be loaded. To get around this deploy the two packages in a connection group and both plugins will be loaded regardless of whether they are published to the machine or user.

- If different local processes are specified in both machine and user RunVirtual for the same package (published to both user and computer) only the machine key will work.

- HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\RunVirtual\winword.exe

- Plugin 1

- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual\excel.exe

- Plugin 1

When winword.exe is launched plugin 1 will not be loaded. When excel.exe is launched plugin 1 will be loaded.

 Read more about the improvements of App-V SP3 here!

services banner1

0 Comments
December 2, 2014