Skip to main content

Hello,

One of our customers recently transitioned from their old domain (Ex. abc.com) to a new domain (Ex. abc). These domains are being used as a prefix with the Botrunner machine device names (Ex. abc.com\mfdaabr2 or abc\mfdaabr2, where mfdaabr2 is the Botrunner machine/device name).

After this transition, we are facing an issue where the File: print multiple files action is NOT working at all in the new domain (Ex. abc) but it is working fine in the old domain (Ex. abc.com). Please find below the error that the bot encounters.

"ExceptionMessage: Error occurred in printing file '<Shared Drive File Path>\<FileName>.pdf”

We already discussed this issue with the customer’s Infrastructure team and they did set up the required printer as a default printer in the new domain Botrunner machine (Ex. abc\mfdaabr2) but it still gives this error when we try to print the files using the File: print multiple files action.

We are able to print the test page from the same printer manually from the new domain Botrunner machine (Ex. abc\mfdaabr2).

Please let me know if anyone has faced a similar issue or need more details from my end to help resolve this issue.

Hi ​@ganesh.bhat ​@Shreya.Kumar ​@Aaron.Gleason,

Could any of you please help me out with this issue?

​@Vatsy Hey Vatsal, thanks for the tag

This could be an issue with the AD tree, but a few things that could help troubleshoot:

  • Have the printers been moved to the new domain?
  • Have the printers been reinstalled after the switch?
  • Is manual printing to the said printers from the device working from the affected device?
  • Has the computer’s DNS cache been cleared?

Would be good to rule these out - let us know what you find!

Hey ​@Shreya.Kumar,

Thanks a lot for your response. Really appreciate it!

I will check the questions that you sent with the customer’s infrastructure team and get back to you.

Hi ​@Vatsy ,

I think you can update the user profile with the help of the IT team. When we connect the device for the first time there would be new user profile will be created in the VM/Server. Server/VM admin can able to create a user profile without domain name. It all about system configuration changes.

 

Eg: Corp/mfdaabr2 can be mapped as mfdaabr2. 

Thanks for your response ​@DK 964!

We have already mapped the related AA Prod Control Room with the new domain under Device Settings (Ex. abc\mfdaabr2). If you are talking about any other mapping or configuration then please share the steps with me to do that.

Hi ​@Vatsy 

I’m refering to check user profile under C:\Users

The user should not have mfdaabr2.Corp it should be mfdaabr2

​@Vatsy 

DK is referring to Windows user file mapping.  The line of questions from Shreya is line with my thoughts as well. This sounds like a Windows issue and its impact the Automation Anywhere packages.

When a user logs in for the first time, Windows creates a folder for them under C:\Users.  If they are logging in from a specific domain, it often appends the domain somewhere in the profile name, as DK showed.

Assure the profile names you are logging in with have a profile that’s connecting to the right and current domain.  If you aren’t you are likely just logging in with locally cached credentials and wouldn’t be able to connect to the printers.

Thanks for your responses ​@DK 964 and ​@Matt.Stewart! Really appreciate it!

As per your suggestions, I checked the C:\Users folder in the mfdaabr2 botrunner machine and I found two users (Ex. srvc_botrunner2.abc.com and srvc_botrunner2.abc).

The srvc_botrunner2 is the user account which we use to log into the mfdaabr2 machine.

The Bot is working fine when we use abc.com\srvc_botrunner2 user account but the same bot fails when we use abc\srvc_botrunner2 user account.

Since the Bot is working fine for the srvc_botrunner2.abc.com user profile, should we still change the srvc_botrunner2.abc user profile to srvc_botrunner2?

Hi ​@Vatsy ,

This issue can arise when you retrieve the bot runner's user name using the AA system variable during the bot's runtime.

Hi ​@DK 964, ​@Matt.Stewart, and ​@Shreya.Kumar,

I had also created a support ticket to resolve this ongoing issue and I am happy to share the good news with you guys that this issue is resolved. I had a hunch that the solution would be something very simple and easy which came to be true! :D

Below are the details:

  1. We were asked to share the below details from our end by the AA support team member which we did after running the same Bot in both abc.com and abc domains on the same mfdaabr2 machine.
    - Enable logs (steps mentioned below)
    - Run the bot (in both the old and the new domains)
    - Collect logs (steps mentioned below)
    - Share the time stamp, Deployment URL (AA Control Room > Activity > Historical > open the test/failed run > Copy link from browser) and the Bot Name for the test run in step 2

    => Steps to enable ALL level logs in any Runner device:
    1.Go to path: C:\Program Files\Automation Anywhere\Bot Agent\config
    2. Open file: "botlauncher-logging.xml"
    3. Find Line <Property name="ArchiveSize">10 MB</Property>
    3.1. Change the value to 30 MB
    4. Find Line: <DefaultRolloverStrategy max="10">
    4.1. Change the value to 15
    5. Find Lines <Root level="INFO"> and <Logger level="INFO" name="com.automationanywhere"/>
    5.1. Change "info" to "all"
    6. Perform same steps for files "C:\Program Files\Automation Anywhere\Bot Agent\config\nodemanager-logging.xml"
     
    => Steps to collect logs via Diagnostic Utility:
    1. open command prompt (run as admin)
    2. navigate to the path of Bot agent installation (for ex: cd C:\Program Files\Automation Anywhere\Bot Agent)
    3. run command: .\AADiagnosticUtility.exe -collectLogs
    The zip file generated by the utility will be named like "bot_agent_logs__datetimestamp]". Path of the file: C:\ProgramData\AutomationAnywhere\BotRunner\Logs
  1. After we shared the logs the analysis showed a discrepancy in the ShellExecute return code in the logs. For the successful run (in the abc.com domain), the ShellExecute return code was “42” (anything above “32” means successful). For the unsuccessful run (in the abc domain) the ShellExecute return code was “31” which means “There is no application associated with the given file name extension. This error will also be returned if you attempt to print a file that is not printable”.
  1. Based on the above analysis we were asked to ensure that the Bot runner machine (abc\mfdaabr2) has an application to read and print PDF files. It was also suggested to compare the domains and ensure that both the domains have identical application installations.
  1. As suggested, we checked in the abc\mfdaabr2 machine and found that the Adobe PDF Reader app was installed in it but even after that if we tried to open any PDF file, it opened in the MS Edge browser. We made the Adobe PDF Reader as the default app to open PDF files in the abc\mfdaabr2 machine and then reran the Bot in it. Voila! This time the Bot successfully printed the files!!! The issue is now resolved! :D

Thanks a lot ​@DK 964, ​@Matt.Stewart , and ​@Shreya.Kumar for all your help and support! I really appreciate it!

Cheers! :D

Terms & ConditionsCookie settings