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.

0 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!

2 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

1 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

2 Comments
December 2, 2014

SSL and HTTPS with App-V 5.0

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!

 

 Content Streaming

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:

virtuldirectory

You need to create a mapping to the physical folder you wish to provision:

virtuldirectory2

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:

virtuldirectory3

 

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:

virtuldirectory4

The file name extension should be for .appv of MIME type application/appv

virtuldirectory5

 

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:

virtuldirectory6

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.

virtuldirectory7

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:

virtuldirectory8

Once you access the advanced settings of the application pool you change the Application Pool Identity account:

virtuldirectory9

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:

– IUSR

– SYSTEM

– NETWORK SERVICE

– COMPUTER ACCOUNT

virtuldirectory10

Hit Browse again:

virtuldirectory6

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!

virtuldirectory11

 

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.

virtuldirectory12

You should then find you can browse the content directory:

virtuldirectory13

 

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:

virtuldirectory13.1

Aslong as it imports successfully and is successfully delivered to the client you can be satisfied that everything is setup correctly:

virtuldirectory13.2

virtuldirectory245

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”:

virtuldirectory17

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 :

virtuldirectory18]

virtuldirectory19

virtuldirectory20

Once you have your certificate in place you should see it appear in the MMC console:

virtuldirectory21

 

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:

virtuldirectory22

 

 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:

virtuldirectory16

 

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:

virtuldirectory244

Clicking the browse HTTPS link however will appear to take you to a untrusted site:

virtuldirectory246

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:

virtuldirectory247

 

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:

virtuldirectory248

Notice we need to use the full path as we specified in our certificate to ensure there are no challenges to authenticity.

virtuldirectory13.2

And there we go all published, streamed and delivered over HTTPS!:

virtuldirectory249

 

 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:

virtuldirectory250

 

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.

virtuldirectory251

 

3. Configure the Client

The next task is to configure client with the new publishing server URL:

virtuldirectory252

and finally test that a refresh completes successfully!:

virtuldirectory253

 

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:

virtuldirectory254

 

2. Test Console

The next step is to test the console, you will likely get prompted for your credentials when connecting:

virtuldirectory255

But it should look and function as normal once you are in:

virtuldirectory256

 

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:

virtuldirectory257

 

4. Restart Publishing Site

The last thing to do is to restart the Publish Service in IIS so it picks up the new setting:

virtuldirectory258

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.

 

Summary

summary

 

2 Comments
November 17, 2014