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:
You can download it as separate .ISO files or as part of MDOP 2014 R2:
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.
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.
You might notice this new setting available on the App-V 5.0 SP3 client when running a Get-AppvClientConfiguration
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:
If this non-admin user tries to publish this package they will get the following message warning them they need admin rights:
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.
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:
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:
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:
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.
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!
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:
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:
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”:
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:
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:
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:
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:
Our connection group would now not be delivered as users will have lost access to version 1 and only have access to version 2:
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:
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.
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:
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.
Notice the * values next to VersionId on certain packages and the IsOptional values:
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.
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:
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…
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.
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.
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:
- Plugin 1
- 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.
- Plugin 1
- 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!
Lately I have had a lot of people ask me about securing the App-V 5.0 infrastructure by utilising the HTTPS protocol so I thought I would share a step by step guide on how you can go about implementing it. There are three main areas you can utilise HTTPS in an App-V Full Infrastructure environment:
– Content Streaming
– Client to Publishing Server
– Publishing Server to Management Server
This blog post will cover all three, however much of the same steps around certificates will apply in all scenarios, infact it might seem less like steps and more like hurdles depending on how much patience you have to get this working! Hopefully if you follow the steps below you should have largely stress free experience!
1. Create Virtual Directory
Assuming you already have a folder holding your content you need to create a virtual directory in your IIS console as shown:
You need to create a mapping to the physical folder you wish to provision:
Test the connection to the content and take note of any warnings, you may need to revisit this if you hit issues later down the line:
2. Add MIME Types
The next step is to add a MIME type for .appv file extensions, .xml files will already be covered by default:
The file name extension should be for .appv of MIME type application/appv
3. Check Directory and Tweak Permissions
Next, before you look to use HTTPS its best to check everything is in order with standard HTTP streaming, hit the Browse Virtual Directory link in IIS:
If it goes through fine then great, however if you get a screen like this saying “Cannot read configuration file due to insufficient permissions” then we need to tweak the permissions so the web.config in the content folder is accessible.
First thing to check is your application pool, typically it should be running as Network service but if it isn’t you can change it as shown:
Once you access the advanced settings of the application pool you change the Application Pool Identity account:
Next thing is to make sure the permissions on the security of your content folder itself are correct, give the following objects read & execute, list folder contents and read permissions if they are not already listed:
– NETWORK SERVICE
– COMPUTER ACCOUNT
Hit Browse again:
If you hit a page like this which says “The web server is configured not to list the contents of this directory” then it is actually a good sign! Your permissions are correct!
4. Enable Directory Browsing (Optional)
If you prefer not to hit the HTTP error above from a browser you can enable directory browsing to list contents. This can be useful for troubleshooting and general inspection of the HTTP(S) content structure but will be accessible to all users with permissions. You can find this setting in the Virtual Directory panel, just hit enable.
You should then find you can browse the content directory:
5. Check HTTP Import and Delivery
At this stage my opinion is you should check that a basic HTTP delivery of an application works by importing a package into the management server and publishing it to a client machine:
Aslong as it imports successfully and is successfully delivered to the client you can be satisfied that everything is setup correctly:
For some great information about optimising your IIS deployment for better performance check out this great blog post by Ingmar.
6. Import a Certificate
Now before we can start using HTTPS we require a certificate to allow us to start utilising SSL, this certificate will verify the identity of the machine and our URL for content. You have three options for obtaining a certificate:
1. Self Signed
2. Domain PKI
3. Third Party CA
Now I highly recommended avoiding using a self signed cert, not only because it is bad practice for a production environment but also as the Management Server itself is likely to reject it and throw a error at import which details that “Content decoding has failed”:
Another time you may see error message is when trying to load balance services with a wildcard certificate, more details on how to resolve that here.
As you can see below my machine already has a self signed certificate which has been created by IIS, but as mentioned instead of using this I would recommend either purchasing and importing a certificate from a third party CA or if you have a PKI infrastructure setup you can request a certificate from your internal CA using the Certificates snap in for MMC :
Once you have your certificate in place you should see it appear in the MMC console:
7. Create Binding
Now to enable SSL on your content you need to create a binding for the HTTPS protocol by clicking bindings and adding an entry. You should select the certificate you have just imported:
8. Require SSL (Optional)
It is very possible that as part of securing your content you will want it to only be accessed over HTTPS and not HTTP in which case you can tick the box that says “Require SSL” on the virtual directory settings:
9. Test HTTPS Access
You will notice you now have the option to browse via https since creating the binding, I have not required SSL as above so I also have the option for HTTP:
Clicking the browse HTTPS link however will appear to take you to a untrusted site:
This is because the URL does not match the URL in the certificate, if you enter the exact naming as specified in the certificate you should find it passes through without any warnings, in this case I am required to use the full FQDN in my URL as my certificate does not have any aliases for other URLs:
10. Import and Deliver the Package
Nearly there! Now all that is left to do is import and deliver the package to test it works:
Notice we need to use the full path as we specified in our certificate to ensure there are no challenges to authenticity.
And there we go all published, streamed and delivered over HTTPS!:
Client to Publishing Server
Now next up is configuring the Publishing Server to enable refreshes over HTTPS to the client. As this will be on a different server you will need to repeat the steps 6 to 8 above relating to certificates. After that the remaining steps are pretty simple:
1. Create Binding
Exactly as we did on our content store, we create a binding for HTTPS, this time on the Publishing Service site:
2. Require SSL (Optional)
If you want your publishing server to only ever function over HTTPS then you can tick the “Require SSL” option on the SSL settings of the site. WARNING: This will stop any clients that are already configured to use the publishing server for standard HTTP performing a successful refresh.
3. Configure the Client
The next task is to configure client with the new publishing server URL:
and finally test that a refresh completes successfully!:
Publishing Server to Management Server
The final task is configuring the Management Server to operate over HTTPS and to allow the Publishing Server to communicate securely . As this will be on a different server to the Management Server you will need to repeat the steps 6 to 8 in the Content Streaming section relating to certificates. After that the steps are again pretty simple:
1. Create Binding
Exactly as we did on our content store and Publishing Server, we create a binding for HTTPS, this time on the Management Service site:
2. Test Console
The next step is to test the console, you will likely get prompted for your credentials when connecting:
But it should look and function as normal once you are in:
3. Change Settings on Publishing Server
Next you need to change the PUBLISHING_MGT_SERVER setting on your Publishing Server which relates to the Management Server URL, this can be found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Server\PublishingService and should be amended with the new URL of your Management Server with URL matching your certificate:
4. Restart Publishing Site
The last thing to do is to restart the Publish Service in IIS so it picks up the new setting:
Finally all you need to do is test that a new package imported into the Management Server is picked up by the Publishing Server, you can do this by checking the PublishingMetaData.xml in C:\ProgramData\Microsoft\AppV\Server\Publishing\ by looking to see if it is being updated according to your refresh interval (default 10 minutes). After following all of the above, any newly published packages should get successfully delivered to the client end to end over HTTPS.