A Story of a Publishing Refresh Request

  • Article

Publishing Refresh Request is one of the main reasons why we have an App-V Management Server.  Since clients send these requests many times (especially on Monday mornings :-) ), you may interested in learning what is going on at the server side during Publishing Refresh Request!

In this post, we are going to see the underlying technology behind the publishing refresh implementation in server side. 

First of all, keep in mind that you can do Publishing Refresh only if you have a configured App-V Management Server in your client.  When you click “Refresh Server” from the client management console or login to your account or a prescheduled publishing refresh arrives, your client sends a publishing refresh request to the network which now contains a RTSP(S) packet whose IP address is the IP address of the management server…

What happens then? If server needs to authenticate the client (most of the time it needs), your request will be declined.  We don’t want unauthorized packages to be processed in server so after you take the response from management server, client will repeat the request with your credentials this time.

Now the story begins… After server accepts the request, it starts processing your Publishing Refresh Request. Here is how:

DCPublish

1) Your Publishing Refresh Request to Management Server: We already covered this step.  You need to send a Publishing Refresh Request either by manually or automatically (login to your desktop or schedule it!).  Also note that along with the request, the client will send a service ticket, which is a part of Kerberos transaction and which contains all the security groups (SIDs) the user is a member of.  These SID values will be then used to determine which applications that user is authorized to use.

2) Internal Processing: At this step, RTSP request is evaluated as a Publishing Refresh Request.  The thread which is responsible from processing Publishing Refresh Request picks up the request and checks the management server cache, if there is a valid XML cache which represents all of deployed applications together with their shortcuts (where to publish applications), file type associations etc.. XML cache is a very important feature of Publishing Refresh Request processing. It comes with AppV 4.5 to increase the throughput of total Publishing Refresh Requests that can be processed at one time.

3) Get XML Cache: If your request isn’t the first request to management server during a timeout period (DCRefreshTimeout ), this step will be skipped.  Purpose of this step is; if management server doesn’t have a valid cache, it renews the cache by getting the latest data from database. So you may wonder what a valid cache is. When a cache becomes invalidated? Cache simply an XML data which contains applications metadata.  Well, if there is a cache which is got by Get XML Cache request before, it will be dirty after publishing refresh timeout, or a new application is added and a new request arrives to server which requests this application too.  After this step, you have a valid cache which contains applications metadata such as OSD paths, ICON paths, shortcuts and file type associations.

4) Get Policy Parameters: The next step in the journey is getting some policy parameters. This parameters are used to manage client desktop configuration such as publishing shortcuts is turned on in the system or not etc. This is a stored procedure which is management server specific.

5) Get Allowed Application IDs: This is the next important step in processing the request. Indeed the answer of “you may wonder why you have different applications in your desktop than your colleges have” lies behind this step. Remember that we earlier mentioned about the SID values which are sent to server along with the request.  Management Server queries the database with these SID values to get the applications lists of a specific user. Each application in the system may belong to different user groups. As an example, application X may be only used by Domain A whereas application Y may be used by Domain A and Domain B. Your SID values simply represent the groups you belong to and we are using these values to get your very specific application list.

6) Internal Processing: Once we have a valid XML Cache, Policy Parameters and Application IDs, the next step is creating an XML document which is specific to you.  By processing this information, a user specific XML is created in management server cache which contains user specific applications along with shortcuts and file type associations (if policy for managing desktop is turned on).

7) Return Applications XML: This is the happy end. Server is sending back the XML to client for further processing in client. Once you get the XML, client starts processing the XML to create everything you want!

In this post we tried to cover the underlying technology behind a Publishing Refresh request. I hope you now have a better understanding about what is going on at the server side when a request arrives!

Enjoy!

Emre Kanlikilicer
Software Development Engineer
Microsoft App-V Team