SOLVED - MS Outlook VBO - The operation failed

[osmandvci]

Hi all,

We have a process running in PRD that checks 10 shared mailboxes and needs to categorize and move emails to a subfolder. The robot treats around 400 emails per day, sometimes without any issues.

However, almost every day, the robot crashes after treating 50-60 emails due to the following exception when trying to move the email to a subfolder: "Could not execute code stage because exception thrown by code stage: The operation failed." Also: every other case that comes after that case that failed, also fails with the same exception until you reboot the VDI.
Restarting Outlook does unfortunately not solve the issue, but a reboot of the VDI does solve the problem temporarily. But of course this a problematic since we cannot reboot the VDI each time it crashes. 
--> So the same email/case that initially failed, can be moved after rebooting the VDI.

The Cached Exchange Mode Settings are turned off and also the download shared folders setting are off. I wanted to try it with turning it on, but it takes very long (+10 minutes) to load all emails (since there are a lot of emails across the different shared mailboxes) and therefore this is not an option I think.

Blue Prism Version: v6.10.4
Outlook VBO version: v6.10.5


Does anyone have a solution please?

Thank you!

Kind regards,
Osman Deveci

[ewilson]

@Osman Deveci,

There was a change made to the Outlook VBO in the 6.10.6 release that addressed an issue with Shared Mailboxes. It may help with your issue.

https://digitalexchange.blueprism.com/dx/entry/3439/solution/ms-outlook-vbo​

One other question. Do any of the shared mailbox folders include spaces in their names? @HarikrishnaMura noticed that if folder names do include spaces (ex. 01 - Processing) then the folder name should be input in single quotes (ex. '01 - Processing').

Cheers,
Eric​

[osmandvci]

Hi @ewilson,

Thank you for your reply. I will import the new version and try with that one.

And indeed, the mailboxes contain spaces. The strange thing is that it always works when started, but crashes after 20-30 minutes​. So I am not sure of it is related to single quotes but will check it if the new version also does not help.

Kind regards,
Osman

[osmandvci]

Hi,

Unfortunately, the Move Email still fails after updating to Outlook VBO 6.10.7

ERROR: Internal : Could not execute code stage because exception thrown by code stage: The operation failed.

Yesterday treated 400 cases without issues. Today crashed twice after treating a dozen of cases. 

Is there any other solution please?

Thank you!

Kind regards,
Osman

[ewilson]

Hi @Osman Deveci,

Is this the same destination folder across all of those cases?

Cheers,
Eric​

[osmandvci]

Hi Eric,

The naming of the subfolders is the same for each mailbox. If an email is received by account "ABC", the mail will be moved to a subfolder (e.g. "Urgent") of email account "ABC".

And this perfectly works for all mailboxes, like yesterday it treated 400 cases in a row. But just sometimes he suddenly crashes without reason. If you reboot the VDI, Force retry the case, it gets completed.
So I cannot find any logical explanation why it crashes the first time. It feels like the connection with Outlook suddenly disappears and only gets back after rebooting the entire VDI.

Kind regards,
Osman

[ewilson]

Definitely strange behavior. I really don't have a good answer for why it would work for so long and then just stop. Is the Outlook UI running as your Digital Worker processes email, or is all of the work performed headless via just the VBO (no Outlook UI shown)?

Since these are Shared mailboxes, technically Use Cached Exchange Mode should be enabled as should the option for Download shared folders. I understand that's pretty slow for you though. Typically that slowness should only occur the first time the VBO is run as the mailbox is sync'd with Exchange once Outlook is started. To account for that, you could add a single call to your process to simply get the count of items in the folder or something like that. That should trigger the sync and then you could process the messages in the folders.

Cheers,
Eric

[RogerThat1]

Hi!

One thought that came to mind.

When it crashes, did you check if the Outlook.exe hangs or uses excessive resources on the RDP User session?

Could it be that the user session runs out of memory after many outlook API tasks? Just a thought.

Another thought, try to kill the Outlook.exe application/Process tree and retry without a reboot. I believe the reboot cleans up hanged tasks/prosesses, so by killing the faulty one, should give the same result without a reboot. Not good on an RDP server, for sure.

Take a look here in Task manager on the RDP session.

Please keep us updated! 🙂

Kind regards RogerThat

[osmandvci]

Hi Eric, Hi Roger,

We are a bit closer to the root cause of the issue. We have 5 shared runtime resources and robots run on them randomly. Scheduling is arranged by customer and they cannot pick which resource to use. So there is no dedicated machine for a specific process.
By checking the logs, I found out that the robot only crashes when it runs on 2 out of the 5 VDI's. Although all 5 machines are identical and have the same capacity. 
IT informed me that these 2 machines had indeed a different host than the other 3 and moved the 2 VDI's that caused the problem to the other host where the other 3 run.

However, it did not solve the problem yet. The process keeps crashing on the 2 VDI's.
I've checked task manager while it was crashing but nothing special to see. We will continue investigating with IT.

But what I did see is the following: while the robot was generating system exceptions due to "the operation failed", I logged in to the machine through the viewer and unfolded all shared mailboxes so that the subfolders (e.g Inbox, Drafts, Sent Items, Archive,...) were visible and suddenly the robot started treating cases successfully for another 20-30 minutes. Very strange issue to be honest.

Kind regards,
Osman

[osmandvci]

Hi,

The issue has been solved.

IT has exported the user registry settings in Outlook from a VDI that had no problems and imported it on the 2 VDI's that caused trouble.
After doing so, the 2 problematic VDI's stopped throwing errors and the issue is fixed.

Thanks again.

Kind regards,
Osman