TN - LicMgr250926001 Using the AVEVA Checkout Utility to manually check out licenses
Last updated: March 24th, 2026Description
- Author: Jamie Jackson
- Published: March 24th, 2026
Details:
Description
This article from InSource shows how to use the AVEVA Checkout utility to check out licenses. Sometimes if a license shows that it is checked out on a license server, that computer still fails to acquire a license. In those cases you can use the AVEVA checkout utility to see if the computer trying to acquire a license agrees that it is checked out and if not, manually check out the license.
- Author: Jamie Jackson
- Published: 09/26/2025
- Applies to: AVEVA License Manager
Details
- Navigate to the computer that your are trying to license.
- Run the command prompt as administrator
- Using the command prompt, navigate to the following file path (if you're installation is on another drive, replace C with the correct drive) C:\Program Files (x86)\Common Files\ArchestrA\Licensing Framework\License API2
- If you need help with navigation in the command prompt, this documentation may help: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/cd
- From here, run AELicCheckout.exe checkedoutlist to see if any licenses are marked as checked out on this computer.
- If you see the license you are trying to checkout in this list and you cannot acquire a license, there is some other issue at play. Assuming you do not see your license, you can run the following command to check out your license: AELicCheckout.exe checkout -pn <your license part number>
- For examples of this and for additional commands you can check the following AVEVA documentation: https://docs.aveva.com/bundle/enterprise-licensing/page/680534.html
Give feedback about this article
Recommended articles
[ISS Support Case] AVEVA WSP Configuration Assistance
I am a bit confused with the installation of the Aveva suite. Our implementation is so miniscule compared to the vast capabilities of the Aveva 2023 platform. We have one instance of InTouch 10.0 running one instance of FSGateway/DAServer, connecting to one instance of Opto22 OPC server. And thats it. When I start the Aveva 2023 installation, I am completely uncertain as to the components that I need to install that will resemble and function as the current implementation does, without adding additional complexity. I know there will be some additional inherent capabilities, and complexity with the new version so I just want to avoid anything that would be completely unnecessary. I have run through the first install selecting the following components: System Platform (PCS Runtime, and PCS Service Repository) This seems to be a default selection that cannot be omitted InTouch and all of its components Historian with all of its components Application Server (just the bootstrap), also one which wont let me omit Enterprise Licensing Communications Driver Packs (Internal-SIM, and Standards-Gateway) System Monitor (Agent Install Manager) Running through the post-install configuration was a bit challenging. When looking at the System Management Server configuration choices, I selected No System Management Server, although it is indicated in BOLD as not recommended. I chose this as there are no other Aveva nodes, or platforms in our topology.
Read More[ISS Support Case] Migration from 2014 R2 to 2023 R2 Sp1 Undetermined
Objective migrate an application from 2014 R2 - 2023 R2 Sp1 Performed transitional upgrade - 2020 Trying to migrate to 2023 R2 SP1 Gets to a certain point sees aaGR started (no more activity 73% in) found a TN - suggested applying a registry update. Applied with no impact. previously had an issue with batch objects (none of those objects were available) Fixed the problem got batch objects working. Migration process question: Does it need communication with batch server during the migration process or is the migration just about converting code and objects? I ask be cause I tested on 3 separate systems and had similar but varying results). At Client site ; experienced migration issues (lots of RED) the batch server is on separate machine. Tried internally with the difference being the batch server was installed locally) the migration 'worked' there (less RED). It was the best progress thus far. Plant: All Servers are running Microsoft Server 2022 and will be using: System Platform 2023 R2 SP1 Batch 2023 R2 Historian 2023 R2 Servers: Galaxy Server Batch Server Historian Server RDP Server The original Plant used System Platform 2014 R2 and InBatch 2014 R2.
Read More[ISS Support Case] Platform Deployment Failure
Client reached out as when user was attempting to deploy WinPlatform user was receiving the following error: "Cannot find the target PC on the network OR target PC can not communicate back to the Galaxy Repository using the NIC that is top in the binding order."
Read More