App Compat Toolkit
The application compatibility toolkit (ACT) is a great tool for analyzing compatibility of apps when doing a migration of Windows. However, the available “reports” are limited in what they display out-of-box. Fortunately since the tool is a SQL database, we can write our own queries to get what we need. The below procedure/query will identify business specific apps and the detected compatibility issues.
- Create and customize an ACT query (within the compatibility manager) which identifies your specific business software
- Select all of the apps listed
- Create a new custom category “Priority Business Apps”
- Run the following query against the ACT database
Select distinct CAQ.subCategory, AR.AppName, LI.issueID, AIQ.severity, LI.title, LI.Details from Applications AR join AppReport_Issues_Query AIQ on AIQ.appID=AR.identity_hash join Categorized_Applications_Query CAQ on CAQ.objectID=AR.identity_hash join Localized_Issue LI on LI.issueID=AIQ.issueID where CAQ.category='Priority Business Apps'
- Copy the results into Excel
Recently came across a situation where my ACT 5.6 server suddenly ceased processing log files and the directory had filled up with .cab files. As I had previously learned, the first quick thing to check is that the log processing [Windows] service is started. In this case it was started, but the .cab files were stuck. In turning to the event logs, I there was a warning message for ACT-LPS code 1017 with message “listener.exe verification for directory \\server\share fails”.
As it turns out, the fix was simple. Somehow ACT had accidentally become configured to just use the \\ServerName\ and it did not have the logs directory. By resetting it to include the correct path, the service began processing all the logs again!
Ran into a problem where ACT was deployed to many computers, their data was successfully being created on the file share, but the computers were not showing up in the App Compatibility Manager. What I discovered (as it’s been awhile since I last used ACT) was that there is a log processing service which imports the logs from the share into the database.
In troubleshooting the issue, I came across and excellent guide by Microsoft for troubleshooting the log processing service. I went through every step and in nearing the end of the guide, the computers were still not imported. Ironically, the very last step was my fix and it was the easiest step – check that the Windows service “Act Log Processing Service” is running. Really? That couldn’t have been listed as one of the first thing to check?