The ApplianceID can be found in the Appliances.csv in a Support Bundle to determine the ApplianceIDs currently in use. To create a support bundle please review the Knowledge Base (KB) article How to create a Support Bundle in TPAM 2.5 (102903)
https://support.quest.com/tpam-appliance/kb/102903
In this example Request ID “1-2212"
1 = is the Internal ID number used by TPAM to identify the Primary and Replica. Normally this will be 1 for the Primary appliance and 2 for the Replica, but this will change if multiple enrollments are performed or if there are multiple replica's for example. The 1 indicates the request was generated on the Primary appliance. If it was 2-2212, the request would have been generated on the replica.
2122 = This is a unique number starting at 1 and increasing for every request.
The number would only be that high if the TPAM Admin user has been adding and removing appliances to the cluster, or actually have over 100 appliances in that cluster. The ApplianceIDs are specific to their respective clusters. Each cluster initially starts off with ApplianceID 1 and ApplianceID 2, and there are instances where ApplianceID 2 could be a DPA IF it were the first cluster member added to a cluster.
Requests prefaced with:
2- would be a request generated when the first replica was failed over (in their instance).
13- would be the thirteenth appliance added to this cluster.
101- the 101st appliance added to this cluster.
The ApplianceID increments each time an appliance "new to the cluster" is added, whether it be a TPAM console or a DPA. If the TPAM Admin user removed appliances and then added them back then they'd get new ApplianceIDs each time they're readded.
For these requests, X (the ApplianceID) only indicates the appliance the request was created on, any subsequent activity for that request may take place on a different appliance.
Also, unless the TPAM Admin user has done a bunch of "transfer/seize author. primary" then the primary ApplianceID should remain constant in any given cluster. If they have moved the auth. primary around though, then that wouldn't be the case.