The Basic Mechanics of a Publishing Refresh with App-V

With App-V we have something called “Full Infrastructure”, this is used to refer to an App-V Management Server based method of delivery for App-V packages.

App-V 4.x

In App-V 4.x we had the App-V Management Server role which was responsible for not only managing the packages but also servicing client requests to refresh and publish App-V applications. This meant the Management Server bore the brunt of every single publishing refresh request from every client whether the client was local or in a branch location.

App-V 5.0

In App-V 5.0 the roles of management and publishing have been separated out. We have a Management Server which is responsible for managing our packages. We also have a Publishing Server which as the name suggests is responsible for handling refresh requests from client machines.

Separating out these roles has pushed App-V Full Infrastructure towards a more scalable hub and spoke model:

How does it work?

The way it works is very simple, let’s start from the beginning.

Management Server

Our Management Server is essentially a web service, every time a new package is added, a subsequent record in the database is created alongwith an increment to a sequence number. Our Management Server also keeps a local .xml file containing all the information around what apps are available and to who they are published.

Every time we change what is available to our users or computers in the Management Console this file will get updated with the latest information alongwith a reference to the new sequence number.

Publishing Server

Our Publishing Server which is also a web based role utilising http gets registered with our Management Server in the console:

 

This is all you need to do to connect a spoke to the hub! Now our Publishing Server will be able to poll into our Management Server at set intervals. This interval is set to 10 minutes by default (set in seconds) and can be influenced in registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Server\PublishingService

Our Publishing Server will then periodically retrieve the .xml hosted by the Management Server when the sequence number is newer than what it already has. It too, like the Management Server stores the .xml file locally, it has a raw file which is a container to onboard new changes and an active .xml which the changes get committed to when possible.

 

Client

The final piece of the puzzle is the client. Once a Publishing Server has been registered with the client the next refresh will trigger a communication into the publishing server, again via http. The publishing server will return a filtered view of the .xml file it holds and publish the relevant packages. You can see a user based filtered view of this file by simply hitting the publishing server URL from a web browser:

The client refresh itself is handled via scheduled tasks:

Again depending on whether we are using global or user based refresh, these tasks will run accordingly by running a .vbs script which will trigger the process.

So that explains the basic mechanics of a publishing refresh in App-V 5.0, it really is simple!

Thamim Karim