Control Room & Scheduler

Expand all | Collapse all

Control Room suddenly useless - Can start any process on any machine whether it's logged in or not - obvious error and swiftly terminates

  • 1.  Control Room suddenly useless - Can start any process on any machine whether it's logged in or not - obvious error and swiftly terminates

    Posted 04-06-2019 00:07
    Hi, In BP Control room, whole system became suddenly useless today. We have 10 resources, have multiple schedules that run and occaisionally kick off process manually when required. Suddenly today, control room stopped workign normally.  Now all process permanently show as logged out. -Using LoginAgent I can login to any resource however, while the session marks itself as a success and completes.  The machine is NOT logged into. -Can do this over and over, always a success but the machines status never changes. -Likewise I can manually kick off processes on any machine.  Normally, if the machine is not logged into, the process will always terminate immeadiately as it's not on the windows home screen.  However now, all process will allow the process to "start".  This morning I could not run a process on a machine that wasn't logged into.  Then process fails because obviously the machine is not logged into. Have tried - Rebooting all the machines, problem persists - With IT, remoting into resources.  This allows the BP listern to start workign normally so i can run processes.  But as soon as the machine logs out.  The same behavior outlined abvoe resumed. - With the machine remoted into, terminating the BP Listener service and restartign it, then logging out.  Does not work. Only way we can currently run our BAU is to have a PC remote int othe Run Time Resource so that the Listener starts working, run processes manually while moving the mouse. Naturally this is completely unacceptable and cannot continue. Been trying to solve the problem all day and have gotten nowhere. Open to any and all suggestions. Thanks in advance.

  • 2.  In reality all the login…

    Posted 04-08-2019 19:11
    In reality all the login process does is pass the credentials to Windows, it does not wait for Windows to complete the user log in. So it would be worth double checking that 1) the Windows user/password are valid, 2) the user/password in the BP credential store are OK, 3) after logging into Windows the resource PC starts automatically, 4) the event log on the resource machine.

  • 3.  I'm curious about your usage…

    Posted 04-08-2019 21:41
    I'm curious about your usage of wording when you say ""the machine logs out"". Do you actually mean that the user account is logged out, or that the workstation simply goes to the lock screen? If the former, try setting up to just lock instead of logging the account out entirely. (Though if these are VMs, it seems silly to require it to lock to begin with.) Theoretically, you should only need to use Login Agent to enter the credentials while the VM is locked, rather than entirely logged out. This should save time and create additional stability. Just make sure that the VM is configured through Windows to automatically login the proper account on reboot (hint: check out netplwiz ). Likewise, how are you remoting into the system? If it's RDP, that's known to break Login Agent. Try using something like TeamViewer.  

  • 4.  If you absolutely have to…

    Posted 04-08-2019 21:49
    If you absolutely have to use RDP to connect, I'm attaching a batch script as a txt file that'll unlock the system from an RDP disconnect (Assuming the forum will play nicely - if not, I'll have to make another post). Set this up as a scheduled task to kick off on remote disconnect from the resource, and make sure it runs with elevated privileges.   I know it may seem excessive to have this many tscon lines - but sometimes there are more sessions than you may be aware of. We had a resource reach 15 once. (Not at all a pretty sight.) Please note that there is a known bug with this particular scheduled task trigger that may cause the script to kick off on RDP connection, rather than just disconnection. The attached file has some logic included to check for this. In case of failure, you should be able to RDP in as any other account and disable the task.

  • 5.  RE: If you absolutely have to…

    Posted 06-17-2019 15:32
      |   view attached
    Had a request earlier to re-attach the script. (Also, fun fact: Edit won't allow you to attach anything after the fact. :P )

    Ami Barrett
    Lead RPA Software Developer
    Solai & Cameron


    unlockMe.txt   1K 1 version

  • 6.  Thanks @John & @AmiBarrett…

    Posted 04-09-2019 15:36
    Thanks @John & @AmiBarrett for your input. Issue was resolved yesterday afternoon. It was a perfect storm of several small human errors which were not caught in time.  - Two environments were not in sync when a developer edited a VBO in our QA environment  (all edits should have been done in Dev) (mistake #1) - The edit broke the object - The QA object was imported back to our Dev environment which is against our protocols (mistake #2) - A package was created which included the overwritten object which was then imported into PROD, it should not have included the object (mistake #3) - The object is used in a few custom VBOs including a modified LoginAgent. - Package was imported into Production on Friday - The modified VBO causes LoginAgent to essentially do nothing and always report a success. - No changes were made at a process level so it took us longer to diagnose the issue (i ll call this mistake #4, i should noticed this sooner) It was a face palm moment when we figured it out. @Amibarett When I said ""the machine logs out"", I meant that when we remoted into the resource, it reported to the control that it was available to run processes so long as the remote desktop session is dispalyed on a monitor. So everything works normally from then.  But when we ran a 'LogOut' or a 'MachineRestart' process.  We could still not use the LoginAgent's 'Login' function. The thing that was throwing me off was that when we ran the Login, the it reported successful completion and the Log showed all steps completed successfully. But once we synced up our environments with the correct version everything returned to normal.