Ivanti’s Endpoint Manager (formerly LANDesk) is heavily reliant upon IIS, Application Pools, and Worker processes. This page contains my own diagnostic methods for tracking down performance related issues specific to this product. These methods can easily be adapted to help you diagnose and track down issues relating to IIS or integration with IIS. This document is not intended to be a full how to, but simply a reference.

NOTE: Always be sure to reference Ivanti’s documentation before making any changes. See: Recommendations for tuning EPM (LDMS) and MS SQL for large enterprise Core Servers

Ivanti also provides some additional details about IIS specific error codes here: https://community.ivanti.com/docs/DOC-1086

Tools required:

The “Query Names” below are the names I have saved theses queries as under Log Parser Studio. Name them whatever works for you.

Query Name: IIS – 404 Distinct Client Policies [CSV]
Log Type: IISW3CLOG
Use Case: A common problem I see, especially when doing a side by side migration, is that client policies are missing. In the EPM console, everything ‘looks’ good, however local clients see nothing in the portal manager. The root cause is that the underlying XML files are missing, EPM does not self heal if a client policy is found to be missing. This will export a list of the missing client policies. Each policy (failed URL) will have the task ID in the name. To regenerate the XML file, go into the EPM console and restart the task. Keep in mind the type of task you are starting to avoid accidentally re-pushing something that should not be pushed. 

SELECT DISTINCT cs-uri-stem 
INTO '[OUTFILEPATH]\404_Distinct_ClientPolicies.csv'
FROM '[LOGFILEPATH]'
Where sc-status = 404
AND cs-uri-stem like '/landesk/files/ClientPolicies/CP.%'
ORDER BY cs-uri-stem

Query Name: IIS – 404 Distinct Client Policies [CSV]
Log Type: IISW3CLOG
Use Case: Pull in the distinct 404 error paths for analysis. In theory, there should never be a 404 entry… in theory. If you are seeing 404 errors that you cannot explain. For example, I recently identified 404 errors pointing to the location ‘ldlogon\LenovoPackage.dll’. After investigating further the .dll was located in ‘ldlogon\LenovoClientDrivers\LenovoPackage.dll’. This could be a problem with a bad security definition pointing to the wrong location, or maybe the file somehow moved itself into the wrong folder. Either way, question every 404 error and investigate it. I export this to a CSV since I often send the report to Ivanti.

SELECT DISTINCT cs-uri-stem 
INTO '[OUTFILEPATH]\404_Distinct.csv'
FROM '[LOGFILEPATH]'
Where sc-status = 404
ORDER BY cs-uri-stem

Query Name: IIS – Requests per Hour in Local Time
Log Type: IISW3CLOG
Use Case: Monitoring the requests per hour, but in local time as opposed to GTM, which is the IIS Log default. *I do not suggest changing the IIS log date\time format.

SELECT	QUANTIZE(TO_LOCALTIME(TO_TIMESTAMP(date, time)), 3600) AS Hour, 
	COUNT(*) AS Total
FROM '[LOGFILEPATH]'
GROUP BY Hour 
ORDER BY Hour

Query Name: IIS – HTTP 503 Errors
Log Type: IISW3CLOG
Use Case: Monitoring the 503 errors to identify which ones IIS Application pools might need the queue length increased or other process workflow adjustments made. When analyzing the data, you need to validate which application pool the cs-uri-stem belongs to. Some EPM installations have modified or broken out the application pools to increase performance. For example the cs-uri-stem might show “/ApmService/PolicyRequest.asmx”. By viewing an unfiltered list of the applications, a default instance will show that the virtual path “/ApmService” belongs to the “LDAppAPM” application pool. The EPM default install sets the queue length to 4000. You may want to increase the queue length if you are finding a lot of 503 errors. Refer to the Ivanti community article above.

SELECT cs-uri-stem,
   COUNT(*)
FROM '[LOGFILEPATH]'
WHERE sc-status=503
GROUP BY cs-uri-stem
ORDER BY COUNT(*) DESC