Microsoft Office 365 - General Troubleshooting Guide

News Knowledge Base
1

How to troubleshoot Office 365 Activities?

Table of Contents:

  1. Ensure that the Microsoft Office 365 activity package version is compatible with the Studio version
  2. Double check the Graph API required permissions
  3. Upgrade/Downgrade the activity package version and test the behavior
  4. How to get additional details regarding the error
  5. Ensure the Office 365 scope is properly configured
  6. Double check the activity inputs
  7. Beware of "Code: generalException"
  8. Test different authentication types
  9. Use the Azure Sign-In logs
  10. Contact us

############################################################################

  1. Ensure that the Microsoft Office 365 activity package version is compatible with the Studio version

Starting with Microsoft Office 365 1.11.1, each version has a "UiPath.Platform" dependency. When this package is installed, make sure that the Studio version matches the "UiPath.Platform" dependency version.

If this requirement is not met, an unexpected error might be encountered during design or run.

E.g. Microsoft Office 365 1.11.1 requires UiPath.Platform 21.10.0, indicating that at least Studio / Robot 21.10.0 is required.

  1. Double check the Graph API required permissions

Each Microsoft Office 365 activity requires a different set of permissions to be added to the Azure App Registration. To check those permissions, use the "Help" option from the context menu (right click on the activity).

This option will take to the activity documentation that contains links to the underlying Graph API queries.

In the Microsoft Graph API reference, find a table with the required permissions based on the permissions type: Delegated or Application.

Ensure that the permissions from all references are added and consented by an Admin for the App Registration.

Note: Both Delegated and Application permissions require Admin consent.

  1. Upgrade / Downgrade the activity package version and test the behavior

Microsoft Office 365 activity package has been improved and some bugs were fixed along the way. Some version might contain a bug, while other will not. It is a good practice to upgrade or downgrade the activity package to check if the behavior changes.

Note: If the activity package is upgraded, take into account the point 1, about compatibility. Also check for Known Issues and Bug Fixed on the activity package release notes.

  1. How to get additional details regarding the error?

The best way to get a full stack error message is by Running (not Debugging) the workflow that contains the problematic activity package. Additional details sent by Graph API, contains specific error codes or even Microsoft's documentation on how to resolve those issues. This logs can later be found in the "UiPath.Studio.logs" file.

E.g.

This example contains more information and a link to documentation. Observe that before this error there was only a "generalException" code. This will show on debugging and unless continued to the end or simply run the file, the additional details will not be seen.

  1. Ensure the Office 365 scope is properly configured

A considerable amount of error is caused by a misconfiguration on the Office 365 Scope authentication or missing settings on the App Registration from Azure.

For the App Registration setting follow the UiPath Activities - Setup guide and check point 2 of this article.

For the Office 365 Scope, there are different authentication types that can be allowed / blocked / set / not set on the Organization. Follow the Office 365 Scope documentation regarding authentication and discuss with an Azure Admin which one is implementable on your environment based on the necessary requirements.

A recommended to troubleshoot the authentication is to use the "InteractiveToken" authentication while running / debugging the project. This authentication type will require an interactive log-in be performed. If this log-in is successful, it can rule out / in other causes. (e.g. other authentication types are affected or the activities inside the scope might be misconfigured/not properly working)

There are a few notable settings that must be configured in Azure App Registration, based on the authentication type you want to use:

InteractiveToken: The following redirect URI must be set: 'urn:ietf:wg:oauth:2.0:oob'
From the App Registration -> Authentication -> Add Platform -> Mobile and desktop application

Integrated Windows Authentication: Go through the Integrated Windows Authentication article to ensure that the IWA is properly configured on the Organization.

Username and Password: Enable the feature "Allow client public flows" from the App Registration -> Authentication -> Advanced Settings (bottom of the page)

Note: Those 3 authentication types require 'Delegated' permission on your App Registration, while the Application ID and Secret/Certificate requires 'Application' permission.

  1. Double check the activity inputs

Depending on what authentication scenario you are using (Delegated or Application authentication), the properties marked as "Optional" may become mandatory.

E.g. on "Send mail" the "Account" property tooltip shows it as "Optional", because the scope will assume the current authenticated user's mailbox, however in an Application authentication scenario (App ID and Secret/Certificate) you have to input the account so the Azure App Registration knows what mailbox to use. So you will have to input both Account and From field.

Failing to do so will result in the following error message:

  1. Beware of "Code: generalException"

Even if point 4 is followed, sometimes the only error thrown is "Code: generalException". This usually happens because the inputs on the Office 365 scope are not correct (most commonly the App ID).

Most of this situations are happening when they are inputted as variable or arguments and are generated by config files or GetAsset activities.

To rule out this possibility, hardcode the inputs for tests: App ID, App Secret, Tenant ID, Username, Password (whichever apply to your situation).

  1. Test different authentication types

Sometimes the issue is caused by a specific authentication type. Try switching to InteractiveToken authentication for tests, to ensure that at least one authentication type works and there is no networking issue.

To be sure that the test is valid, delete the Studio activities authentication cache from '%appdata%\UiPath\authentication' before testing. Otherwise, the Office 365 authentication might be already cached and the activity might fail due to other reasons. Post deleting the cache, a prompt will be displayed to sign in interactively.

Return to point 5 for more info and troubleshooting on authentication types.

  1. Use the Azure Sign-In logs

Another way to check if the Authentication is causing the issue is by using the Azure Sign - In Logs.

Go to https://portal.azure.com/ -> Azure Active Directory -> Sign-in Logs, filter them to show only the logs for the User or Application used in the Scope and look for any failure.

To be sure, check all the following tabs: User sign-ins (interactive), User sign-ins (non-interactive), Service principal sign-ins, Managed identity sign-ins

If there is a failure, use the option to "Launch the Sign-in Diagnostic".

Results usually contain more details, documentation or even steps to fix the issue.

Note:

  • It might take a while for the sign-in logs to be populated.
  • If the sign-in is successful, then the issue might be related to the activity, the service itself (e.g. Exchange Online, SharePoint policies), networking (VPN, proxy, firewall).


  1. Contact us

If after following all the suggestions above, the issue persists, open a support ticket with UiPath Technical Support and let know the findings so far.