Forum Discussion

lambdaburst's avatar
lambdaburst
New Contributor
2 months ago
Solved

On-premises Azure build agents running TestExecute with ID-based licensing

We recently migrated our self-hosted Azure DevOps Build agents from HASP based licensing to the ID based licensing.  We use a test adapter via the COM integration to execute and pull test data back into Azure Pipelines.  Through the sales and renewal teams, we were instructed that exporting the licenses to the On-Premises License Server was the appropriate mechanism.

Now, we are seeing that the access token expires regularly and we have to manually access every build agent in the pool and open either TestComplete or TestExecute, log-out, and then generate the auth code again.

This article says however, that an access key should be generated and provided via CLI execution. https://support.smartbear.com/testcomplete/docs/licensing/id-based/automated-builds.html
This doesn't work with the COM integration, or in any way that I can find in the interface.  It also doesn't seem to be possible to create an access key with the On-Premises server, as it always states "Failed to generate an Access Key".

Years after releasing ID-based licensing, there still seem to be major disconnects in the implementation.  The HASP system was simpler and more reliable.

What is the proper solution to using ID-based licensing with Azure DevOps build agents?

integrations
  • lambdaburst's avatar
    lambdaburst
    2 months ago

    Opened a support ticket and Support was able to tell me about an undocumented method of generating an Access Key for anonymous.user and manually substituting this in the local auth files for TestComplete/TestExecute.

    I'm not sure they want the details in the public so if you encounter the same hang up, just contact them.

5 Replies

  • lambdaburst's avatar
    lambdaburst
    New Contributor
    2 months ago

    Opened a support ticket and Support was able to tell me about an undocumented method of generating an Access Key for anonymous.user and manually substituting this in the local auth files for TestComplete/TestExecute.

    I'm not sure they want the details in the public so if you encounter the same hang up, just contact them.

    • rraghvani's avatar
      rraghvani
      Icon for Champion Level 3 rankChampion Level 3
      2 months ago

      Are you referring to?

      /AccessKey:access_key

      This parameter is for those who use SmartBear ID-based licenses of TestComplete. It specifies the access key associated with your SmartBear account and is used to license the product in automated runs that don’t require user interaction. For more information on this and on how to get the key, see Activate TestComplete in CI/CD build runs.

      • lambdaburst's avatar
        lambdaburst
        New Contributor
        2 months ago

        Yes but no.  An ID-based access key is required for this situation, but as I alluded to initially, when using the COM integration you aren't launching TestComplete/TestExecute via command line and cannot specify the AccessKey parameter.

        There is a way to generate an AccessKey for the On-Premises License Server using anonymous.user, and then substitute that key for the normal ID-based token.

        Since that is not documented publicly, I won't elaborate on it here, but those that need it can discuss the process with the support team.

  • scot1967's avatar
    scot1967
    Icon for Champion Level 2 rankChampion Level 2
    2 months ago

    Hi lambdaburst,

    This is a guess.  I have not seen this type of behavior but, could there be a connection issue between the agents and the license server?

    It looks like you have done your homework here and may need to open a support issue.

    https://support.smartbear.com/testcomplete/message/


    ... If you find my posts helpful drop me a like! 👍 Be sure to mark or post the solution to help others out and/or to credit the one who helped you. 😎

    • lambdaburst's avatar
      lambdaburst
      New Contributor
      2 months ago

      Thanks for the reply.  I did check uptime across the server pool.  All of the servers were up at the time it was first detected and all of them could reach the URL for the on-premise license server.  We don't have any indication that the local network switch had an outage either, which should be exceedingly rare.

      TestExecute/TestComplete checks against the license server on every launch, so the error in the attached to this thread was easy to reproduce.

      We also have enough floating TestExecute licenses on the on-premise license server to handle the maximum concurrency of our interactive agents for UI tests.  There should never be a collision.

      If the community has no suggestions, then we'll definitely reach out to support.