Forum Discussion

cam_farineau's avatar
8 years ago

Start TestExecute from TeamCity



To test our desktop application we have a Master project that runs the Slave project on different VMs. The Master project is started on a Management machine.

We are currently moving our Build process to TeamCity. On this Management machine we have a Build Agent from TeamCity. The Build Agent is running as service with a System Account (not the Local System Account).

We are not using the Local System Account (that can interact to the Desktop) because we need a domain account to access domain resources. And we don't want to start the Agent as a process, we want to keep it at a service. 


Right now, we can't start TestExecute directly from TeamCity because TestExecute requires an interactive session and the Account of the Build Agent can't interact with Desktop.

We tried with a script (executed from TeamCity) to create a PSSession with a normal user that have access to Desktop and start TestExecute from this PSSession. But this is not working either.


Here is the exception that we had:


Start-Process : This command cannot be run due to the error: This operation requires an interactive window station.
 At line:3 char:9
+         Start-Process "D:\SmartBear\TestExecute 12\Bin\TestExecute.ex ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
         + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Does anyone have a solution to start tests with TestExecute from TeamCity (with the Agent running as service with a particular system account and not the local one) ? Is it possible for a domain system account (like the one we are using) to interact with the Desktop ?


Thank you for your answers,



  • I figured it out.
    My problem was that I didn't disable "uiAccess" in the "TestExecute.exe.manifest".


                <requestedExecutionLevel level="asInvoker" uiAccess="false"/>

    So the Desktop interaction was needed according to the Manifest of the app.


    With this attribute to false, TE doesn't require a Desktop / UI Access. So I can start my test directly from TeamCity and this domain system account without interaction with the Desktop.


    Thank you all for your help !! 


14 Replies

  • AlexKaras's avatar
    Champion Level 3



    As is said on the pages that Marsha provided references to and have been discussed here a lot of times:

    -- GUI application in the Windows environment *must* have active interactive session in order to be able to display its UI. This is required by OS, but not by TestComplete. Note, that active interactive session is not the same as allowance to the service application to interact with the desktop.


    In order to test GUI application with any tool (Selenium/QTP-UFT/Ranorex/CodedUI/TestComplete/etc.) you *must*:

    -- Provide active interactive session for your application;

    -- Start your tested application in this session;

    -- Start your test tool in the same session and start tests;

    -- Keep session open and not locked until tests finish.


    One more link that might help:

    • cam_farineau's avatar

      Thank you for your answer,


      But we are not running any tests on this machine. 
      We want to run our Master project from TeamCity running as a service on this machine. This Master project doesn't require interaction with the Desktop, it is not testing our App.

      This project will start the Slave remote project (actual UI tests of our app that require Desktop Interaction) on different VMs through TestExecute directly.


      So we juste need a way to start the Master from TeamCity, in the background or any other way... Thereby it can launch our actual UI automation tests on VMs using TestExecute.



      • AlexKaras's avatar
        Champion Level 3



        Actually, TestExecute does not require interactive user session and can execute test code without any problem if interaction with GUI is not required. So your scenario should work.

        My guess is that the error from your initial post caused not by TestExecute itself, but, maybe, by the failed command (PSSession) that was executed previously.