App-V Reporting - Start to Finish and Back Again

Technet has this to say about the App-V 5 Reporting flow

1. After the reporting server receives the data from the computer running the App-V 5.0 client, it sends the data to the reporting database.
2. When the database has received and processed the data, a successful reply is returned to the reporting server.
3. After the reporting server receives the successful reply from the database, a notification is sent to the computer running App-V 5.0 client that the data was successfully received.
4. After the computer running the App-V 5.0 client receives the notification that the data was successfully stored in the database, the client empties the current data cache. This ensures that the cache on the client does not contain previously reported data.

Pasted from <http://technet.microsoft.com/en-us/library/jj692560.aspx>

 

Well, yeah that's pretty high level.  And while there are a few nuggets in there that could be useful for troubleshooting, frankly it has the resolution of a 80's video game.

 

 

If we run into problems, we're going to need seriously more detail than this.

What client properties should I be concerned about?

Where are these client cache files?

Where along the path did it fail?

 

A significant place is missing from the overview above.  It's called  the beginning, and to me it seems like a very fine place to start, at the App-V 5.0 Client.

 

 

At the App-V 5.0 Client:

 

What happens here?

 

It's pretty simple really.   In the case of application usage tracking, the user launches a virtualized application, and if configured to do so, the App-V client creates an .xml file with some details about the launch.  The client then reaches out to the reporting server and attempts to pass the .xml data to it.  If the .xml file appears to be annoyingly persistent (over 24 hours), that's a good indicator that something within the overarching process is not working correctly.  It is important to note that regardless of the thorough description above, the .xml file does not immediately go away after the data makes it to the database server.

 

Things to check on the client

The App-V Client must be setup with reporting turned on.

·         Is the .xml file getting created?Get-AppvClientConfiguration

o    ReportingEnabled should equal 1

o    ReportingServerURL must be valid

·         App-V Client creates .xml files when a virtualized application is launched

o    Referenced .xml file is stored in \ProgramData\Microsoft\AppV\Client\Reporting on the client workstation.    Remember you need your admin account to get into that folder, and the file is hidden by default; so if you're command lining it, you may need to whip out that attrib command.

o    The ReportingInterval property reported from the Get-AppvClientConfiguration command

·         Send-AppvClientReport -<url:port>    (manually sends data collected in workstation cache to the reporting server.  You may want to omit the -DeleteOnSuccess parameter  while testing, but remember even if you do not use this parameter the file will not immediately disappear.)

 

At the App-V 5.0 Reporting Server:

 

What happens here
 

The web service hosting your reporting url now picks up the process.  You can tell the web server is doing its job by checking IIS logs.  The default location will be a subfolder of <drive>\inetpub\logs\LogFiles.    In my case, the file name for the log was u_ex<DATE>.log.  You'll find  an entry with a date/time stamp, your workstation IP address POST - <port#> followed by the account used to authenticate with the server (which will probably be a workstation account.)

 

Things to check on the Reporting server
• World Wide Web Publishing Service is started.
• Any services set to start automatically are running (note that the Microsoft .NET Framework NGEN v.xxxxx services are designed such that they will stop if they have nothing to do at the time.)
• Dig through server event logs for any errors.

 

At the App-V 5.0 SQL Server:

 

What happens here

 

The SQL Server takes the data delivered from the reporting server, and stores it in a kind of temporary table for future processing.  In the case of application usage tracking, two of those table names are dbo.UnprocessedCurrentApplicationUsage and dbo.UnprocessedCompletedApplicationUsage.  As the name indicates, application usage data remains in this table until something else happens.

 

That something else, is the execution of the ProcessAppVReportingDataJob, which can be found under SQL Server Agent\Jobs if you are looking at the SQL Server Management Studio.  It is only after successful completion of this job will the actual application usage tables be updated and the workstation .xml file be removed.

 

Things to check on the SQL Server

• Check the application event log on the SQL server for authentication errors.  They should show as coming from the MSSQL SERVICE source.
• Check your SQL server error logs.  Full transaction logs and disk drives are a tragically common source of database outages.
• Check the ProcessAppVReportingDataJob properties.
• Is the job scheduled?
• Are there any alerts or failures?
• Does it run if you kick it off manually?

 

But where are my reports?

 For me, that remains a mystery.  All I have been able to find is that you should be using SQL Reporting Services.  I don't know if that means there are pre-canned reports out there somewhere, or if that means you Reporting Services to gin up your own shiny graphs and charts.