KB2447513: The number of concurrent licenses are not reset when the Application Virtualization Management Server service restarts

KBSymptoms

The Microsoft Application Virtualization (App-V) 4.5 Management Server may appear to run out of available licenses and clients may receive the following error:

You are not authorized to access this resource.

Error code: 0A-20000193

Cause

The stored procedure sp_SFTclosesessions in the management server database is used to close orphaned sessions, license sessions, application usage and licenses assignments that are stale. An example of when this occurs is when the management server or the client crashes/restarts and did not close the appropriate sessions. 

There is an issue with this stored procedure that may prevent it from working properly in certain situations.

Resolution

First, here is an overview of what the stored procedure does:

  1. Determines which servers should be cleaned up.
  2. Retrieve the startup times of the servers from MESSAGE_LOG table.
  3. Determine the latest date of startup for each server using the results from #2.
  4. Find stale sessions by looking in the MESSAGE_LOG table where the entry date < last startup date AND where it has no corresponding teardown entries (specified by pre-defined transaction codes).
  5. For each stale session found, clean up the entries in the appropriate tables.

In order for the stored procedure to work properly, modification needs to be made at step 2 as follows:

  1. Connect to the SQL Server where the App-V database is located (make sure the account you are using has the right permissions to modify the stored procedure).
  2. Expand SQL_Server_Instance\APPVIRT\Programmability\Stored Procedures.
  3. Right click on dbo.sp_SFTclosesessions and select “Modify”.
  4. Go to line 212 and change 41217 to 44951.
  5. Now hit Execute to save the changes.

For example, here is the relevant part of dbo.sp_SFTclosesessions prior to modification:

SELECT s.server_id,

           s.hostname,

           m.msg_time

INTO #temp_startups

FROM message_log m INNER JOIN

           vw_softgrid_servers s ON (m.server_hostname = s.hostname)

WHERE s.server_id = ISNULL(@server_id, s.server_id)

AND s.hostname = ISNULL(@server_hostname, s.hostname)

AND m.fn_module LIKE N'SW_SystemDispatcher%'

AND m.severity = 0

AND m.msg_id = 41217 --

Here is the relevant part of dbo.sp_SFTclosesessions after modification:

SELECT s.server_id,

           s.hostname,

           m.msg_time

INTO #temp_startups

FROM message_log m INNER JOIN

           vw_softgrid_servers s ON (m.server_hostname = s.hostname)

WHERE s.server_id = ISNULL(@server_id, s.server_id)

AND s.hostname = ISNULL(@server_hostname, s.hostname)

AND m.fn_module LIKE N'SW_SystemDispatcher%'

AND m.severity = 0

AND m.msg_id = 44951

More Information

What can happen is that the stored procedure does not find any entries in MESSAGE_LOG for server start up that matches "41217." As such, the stored procedure may not work as expected.  One can observe that when the App-V 4.5  server service is restarted, the only entries added to MESSAGE_LOG table are:

44952 - Successfully shutdown Microsoft System Center Application Virtualization Management Server...

44951 - Successfully started Microsoft System Center Application Virtualization Management Server...

Whereas in the past with the 4.1 server, when it starts up, an entry with msd_id == 41217 does exist. 

Once the transaction code has been changed to 44951, the stored procedure is able to determine the cutoff date from the new startup message and cleans up the sessions. The number of available licenses will  be up to date and users will able to launch applications again.

You can find the latest version of this new Knowledge Base article at the link below:

KB2447513: The number of concurrent licenses are not reset when the Application Virtualization Management Server service restarts

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: https://blogs.technet.com/appv/
The WSUS Support Team blog: https://blogs.technet.com/sus/
The SCMDM Support Team blog: https://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: https://blogs.technet.com/configurationmgr/
The OpsMgr Support Team blog: https://blogs.technet.com/operationsmgr/
The SCVMM Team blog: https://blogs.technet.com/scvmm/
The MED-V Team blog: https://blogs.technet.com/medv/
The DPM Team blog: https://blogs.technet.com/dpm/
The OOB Support Team blog: https://blogs.technet.com/oob/
The Opalis Team blog: https://blogs.technet.com/opalis

clip_image001 clip_image002