FAQs
- Updated: 2020/05/07
FAQs
While every effort is made to address all possible questions, please contact us if you have additional questions that must be included.
- Is there one RDP session per Bot Runner?
- Yes.
- Do I need to ramp up the Control Room RAM for RDP Based Deployment?
- You might ramp it up depending on the bot deployment scenarios. A typical RDP session takes around 150MB of RAM. So, if you are deploying onto 10 Bot Runner, 1.5GB RAM is consumed. It is recommended that you increase the RAM to 16 GB if extensive bot deployment is required. Refer the Hardware Requirements section for Control Room in the AAE - Installation Guide that is shipped with the product.
- Will the RDP sessions terminate when the bot is executed?
- Yes.
- Can a Control Room user see the active RDP Session?
- No. User cannot see the active RDP Session as it is a background process. However, the user can see it under the Task Manager > Processes tab.
- While the bot is executed in a RDP session on the Control Room, if the Bot Runner user logs in to the Bot Runner, does it impact the bot execution?
- As soon as the user logs in to the Bot Runner, the RDP session on the Control Room terminates. The bot continues to run, and is visible to the user on the Bot Runner.
- In the above scenario, if the user locks/logs off/disconnects the RDP session on the machine, what happens to the current executing bot?
- If a user locks/disconnects the RDP session, the bot continues to run in the background. However, the screen based commands might display errors. If a user logs off the RDP session, the bot execution is terminated.
- While selecting Remote based bot deployment, the AA player is taking more time to come up. Is the performance affected by new functionality?
- No, there is some delay in the AA player to come up as first the RDP connection must be made. And in environment where there is high latency, the RDP connection itself can be slow.
- What is the impact if RDP connection is very slow?
- Let us assume that the Control Room takes about 30 seconds to RDP. The bot execution start-up is delayed by 30 seconds for that Bot Runner. Beyond that, if RDP session does not get connected, then the Control Room deploys the bot through the legacy route (auto-login).
- If there is already active RDP (manually done by the user) and if the bot starts, will the existing RDP session be taken from user?
- Older RDP session is disconnected and the task is executed on new RDP Session, which is created by Control Room.
- If RDP Session crashes in between bot execution, does the Control Room restart the session without impacting bot execution?
- Yes, RDP has an inbuilt capability to reconnect. But that works only for certain duration. So, if Bot Runner gets disconnect for longer time, then it impacts the execution of the bot.
- Further to the above scenario, there is possibility of bot displaying errors due to RDP disconnection. How would a developer/Control Room User differentiate a failure between RDP and Actual bot error? If not, a developer might spend long time (impacting production execution) analyzing the code while the actual impact was due to RDP session, which might not require any code change.
- If bot displays errors, then it is automatically audited in the Control Room. For RDP disconnect case, we have kept the list of reasons for disconnection and we are storing this in a log file. See IMsTscAxEvents.
- If RDP Session crashes, is the occurance and status of bot captured in the Audit log even though the RDP crashed?
- Yes, the bot continues to run on Bot Runner and the required audit of success or failure is logged.
- We have occasional RDP session timeouts. Will Control Room RDP be impacted by it?
- Ideally, there cannot be any RDP TIMEOUT as it can impact the execution of the bot.
- Does the RDP based Bot Deployment work with Bot Schedules as well?
- Yes, there is an option to select the RDP based Bot Deployment while scheduling the bot from Control Room.
- Can it be configured with other RPD tools like VMware clients?
- It cannot be configured currently, but might be in one of the future updates.
- If a user's Active Directory (AD) password has changed when the Control Room tries to RDP, will it update the new password by syncing with the AD?
- No. Control Room will only fetch the password which is set in Automation Anywhere Enterprise Credential Vault.
- If a bot is scheduled to deploy onto a 100 Bot Runner, will the Control Room invoke RDP onto all 100 Bot Runners asynchronously or sequentially?
- RDP sessions is created on the Control Room box and deploys the bot asynchronously on these Bot Runners.
- Consider a scenario where a bot is deployed onto 10 Bot Runners. If Control Room is unable to RDP onto the fifth Bot Runner, will it move onto the sixth Bot Runner, or the entire process is canceled?
- As it is happening in parallel, RDP failure of one Bot Runner does not impact the other. The Control Room moves onto the next Bot Runner.
- If Bot Runner is unable to terminate the RDP session, is the Control Room admin notified or is it logged in the Audit trail?
- The Control Room admin must manually terminate the Bot Runner's RDP session.
- Will this work if the Control Room is hosted in load-balanced high-availability disaster recovery (HA-DR) mode; where multiple Control Room Application Servers are installed? If yes, on which Control Room machine will the RDP sessions run?
- Yes, this works in the HA-DR mode. In that case, the RDP sessions are deployed on the Control Room Server that deploys the bots.