Google Offboarding Steps - Troubleshooting – CloudM

Generic errors

An error could occur if the user being offboarded has already been deleted within the source platform.
If the Microsoft / Google APIs that we use to perform the operations are down, then we will receive errors.
If a step fails, it will automatically retry up to a maximum of 5 times.
- Please note that there may be exceptions where a "NON_RETRYABLE" message will be displayed.

Google Specific errors

Google - Rate Limit Exceeded - The APIs that we use in Google have limits within them, meaning that we can only perform a certain amount of calls to them within a certain period. We try to work around this so that we do not hit this limit. Sometimes, however, we do hit the rate limit, especially in the steps where we are transferring large amounts of information. Please retry the step after a few minutes or if it keeps on happening, please contact Support.

Expected behavior

Steps that unsuspend a user - Any step that requires a suspended user to be unsuspended (to allow the action to take place on the user account) now has a 1 hour delay to allow for full data propagation. You can manually trigger the action, but this could result in errors as some data might not be propagated.

Request Approval

Overview

The executor of the workflow will be prompted to approve the offboarding.

The notification will be sent in both Manage, within the Notifications section, and by email. When approving via email, the executor will be taken to the “Offboard User” view and allow them to approve the Offboarding there.

The email will be re-sent every 24 hours asking for approval.

Once approved the offboarding will then continue onto the next step in the workflow.

Expected Outcome

After approval of the offboarding the next step in the workflow should begin processing.

Possible Errors

An error could occur if the user that is meant to approve the offboarding has been deleted.
If a group is set as the executor, a “user” won't be able to approve.

Prompt for Resource Allocation

Overview

A prompt will be sent to the executor to set the target destination for the steps selected in the Offboarding Step. These destinations are then used to override the original destinations set at an overall offboarding workflow level. This will allow the user to set up a target for that specific user’s offboarding that will override the workflow settings.

Before the allocations are confirmed, the user can “check” whether the targets are valid users. A target can be an external user or a group mail address, but this could cause errors when performing the migrations, so the “check” will validate whether the targets set are valid user profiles. If not, then the step can still proceed but errors may occur due to the targets chosen.

The Offboarding process will not proceed until all resources have been allocated.

Expected Outcome

After approval of the resource allocation the next step in the workflow should begin processing.

The targets for the steps specified for approval should then be the set up for those steps.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the Source platform.
For the steps specified, as stated above, if the target is not a User account registered within CloudM Manage, this could cause an error during the processing of those steps.
If the target user doesn’t have drive or mail enabled or have the correct licences this could also cause issues.

Wipe Mobile Devices

Overview

Any devices that are registered for that user account will have the user’s Google Workspace account removed off those devices.

In order for us to be able to wipe the devices, the following scope must have been approved: https://www.googleapis.com/auth/admin.directory.device.mobile.action. In the vast majority of cases, this scope will have already been approved by the admins when logging into CloudM Manage.

An audit log entry is created for each of the devices wiped.

If we do not have the authorization to wipe the device, then this device is skipped but we will not mark the workflow as failed. However, there will be an audit log entry for that device to record that it was skipped.

Expected Outcome

The Google Workspace profile for the user on all mobile devices should have been removed and any devices that we have skipped will be logged in the CloudM Manage audit log.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the Source platform.
We will be unable to wipe the mobile devices if the following scope has not been granted and will result in an error:https://www.googleapis.com/auth/admin.directory.device.mobile.action

Wipe Chrome OS Devices

Overview

This step wipes all user profiles off the device.

In order for us to be able to wipe the devices, the following scope must have been approved: https://www.googleapis.com/auth/admin.directory.device.chromeos. In the vast majority of cases, this scope will have already been approved by the admins when logging into CloudM Manage.

An audit log entry is created for each of the devices wiped.

Expected Outcome

The user’s profile is removed from any Chrome OS devices that they have been logged into and any devices that we have skipped will be logged in the CloudM Manage audit log.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
We will be unable to wipe the Chrome OS devices if the following scope has not been granted and will result in an error:https://www.googleapis.com/auth/admin.directory.device.chromeos

Change Password

Overview

Changes the password to a random 16 digit alphanumeric code for the user.

Expected Outcome

The user is unable to login with their old password and the new password is not made visible to anyone once the change has been applied.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Revoke 2-Step Verification

Overview

Any backup codes for the offboarded user are invalidated and then will turn off 2 step authentication for that user.

The following scope is required for us to perform these operations:
https://www.googleapis.com/auth/admin.directory.user.security.

In the vast majority of cases, this scope will have already been approved by the admins when logging into CloudM Manage.

If the User being Offboarded is already suspended, then we will skip the Disable 2FA step and any backup codes will not be removed.

Expected Outcome

The user has had their backup codes invalidated and the 2 step authentication for that user has been removed.

If a user is suspended and this step is triggered, the user is unsuspended and an hour wait is triggered before the step is done. Then the user will be suspended again.

If the user's 2-step verification is managed by a Google policy, such as at OU level, then the step will not error but CloudM will be unable to disable their 2-step verification.

If a user is suspended when the step begins, the user will be unsuspended for the duration of the step.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
We will be unable to invalidate the backup codes and revoke the 2 factor authentication if the following scope has not been granted and will result in an error: https://www.googleapis.com/auth/admin.directory.user.security

Remove Recovery Methods

Overview

The recovery phone number and email address for the offboarded user will be removed.

Expected Outcome

The user’s recovery phone number and email address no longer exist on the user’s account.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Remove Application Specific Passwords

Overview

Any application specific passwords that the user might have set up are removed.

We require the following scope to perform the operation:
https://www.googleapis.com/auth/admin.directory.user.security.

In the vast majority of cases, this scope will have already been approved by the admins when logging into CloudM Manage.

Expected Outcome

Any application specific passwords that have been setup will be removed and the user should have none in the user account.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
We will be unable to remove the application specific passwords if the following scope has not been granted and will result in an error: https://www.googleapis.com/auth/admin.directory.user.security

Revoke Application User's Accounts

Overview

For this step to be selectable for a workflow, at least 1 Integration must be installed within CloudM Manage.

Any accounts the user has on any of the installed integrations configured in the workflow step will be locked down so the user can no longer access them and the integrations will not be able to act on the users behalf.

In some cases, depending on the third party application and how it has been configured within CloudM Manage, this could mean suspending the user account in the application, revoking their license or deleting the user account.

Expected Outcome

The user will not be able to log in to any of the accounts in the configured applications that have been integrated with CloudM Manage. The user accounts should have had any action performed on them too as set up in the Offboarding and / or Integrations.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
If the Integration has been removed since setting up the Offboarding or the authorization for the application is no longer valid, this could cause an error while trying to perform any operations in that application.
If the API we use for the 3rd party application is down, then this will return errors when trying to perform this step.

Revoke OAuth Tokens

Overview

Any OAuth tokens that have been issued for the user’s account will be revoked. This will stop any applications accessing the user’s account on their behalf.

The scope required to perform this operation is:
https://www.googleapis.com/auth/admin.directory.user.security.

In the vast majority of cases, this scope will have already been approved by the admins when logging into CloudM Manage.

Expected Outcome

All OAuth tokens removed for the user and applications can no longer perform operations on behalf of the user or access their information.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
We will be unable to revoke the tokens if the following scope has not been granted and will result in an error:https://www.googleapis.com/auth/admin.directory.user.security

Set Out of Office Message

Overview

The user will have the specified Out of Office settings applied to them. A subject and message can be provided for the email, which is returned to anyone trying to contact this user. An executor can be selected and used in the subject or message as an alternative person to contact.

The settings that are used are as follows:

Start Date - the date and time the step was processed
End Date - 1 year from when the step was processed
Active for all people contacting the user, not just people within their domain or on their contacts list

Expected Outcome

The Out of Office settings are set for the user and any emails sent to them will be automatically replied to with the configured subject and message.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
An error will occur if the user does not have a valid workspace license as we will be unable to access their Mailbox.

Delegate Access

Overview

The user’s mailbox will be delegated to the executor defined on the workflow level so that they can access the users emails and send them on their behalf.

We perform a check to see if the user has mail services enabled or not, which might be the case for a Cloud Identity User. If the user does not have mail services then we skip the step.

Expected Outcome

The executor now has access to the offboarded user’s mailbox.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
If the executor does not have mail services enabled or is suspended, then an error is returned when trying to perform the delegation.

Move User

Overview

The user will be moved to the specified OU.

If the user is already within that OU, then this step will be skipped.

This can be useful for setting up global offboarding policies in combination with the “Offboard suspended users” setting. You can set users that have been suspended to be moved to a specific OU that has specific offboarding policies setup.

Expected Outcome

The user has been moved to the specified OU.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform or the OU no longer exists.

Hide User

Overview

The user is hidden from the Global Address List (GAL).

Expected Outcome

The user does not appear on the Global Address List.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Rename User

Overview

The user is renamed in both CloudM Manage and the source platform, giving them an email address in the format specified in the step. By default this is a random ID.

Expected Outcome

The user is renamed in the correct format.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
If this step is used with other offboarding steps, there is a chance an error is shown that the profile can not be located. However, the offboarding process will continue without issues.

Assign Alias

Overview

The user’s old email address is added as an alias to the person specified in the workflow step.

A label can be set so that any incoming emails under that alias are automatically labelled within Google.

Expected Outcome

An alias is on the specified user for the offboarded user’s old email address. If a label is applied, a rule is set up in Google for these emails.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Archive Vault

Overview

The Archive Vault step is used to archive deleted data for a user that has been retained in Vault due to a customer's configured Vault retention policies. The user's deleted data is archived, in a similar way as to how we archive their active data, to long term storage which can be restored to another user account at a later date. The bucket where the information is to be archived can also be configured.

When archiving emails and documents a query can be provided to only archive certain items or all of them.

CloudM Archive can only access and save historic user chat messages that are available on the Google Hangouts API.

Expected Outcome

The items that were selected and matched any queries were archived to the storage bucket.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Known Errors

If there are not any available Vault licenses to assign then this step will fail, more licenses can be purchased from the portal.
Invalid License Key - This will show if the license key is invalid from the portal key. A newly generated portal key will push it to the Manage instance and they should be in sync again.

Transfer Ownership of Documents

Overview

Any documents that are owned by the offboarded user will be transferred to the specified account under the specified folder name. These are configured in the workflow step.

We ensure any document’s shares are maintained.

We will try to retain the file structure where possible, however, some files may become “Orphaned”. This means that Google informs us the user the document is being transferred to cannot see the parent of this file. If this is the case, then the file is moved into the root of the folder that was created for the workflow step.

The existing file structure is generally most at risk of being disrupted when there is a complicated folder structure and the offboarded user owns multiple files / folders within the folder hierarchy.

Any items that are of the type “Shortcut” are skipped.

Any items that have not had their ownership transferred will be lost when the user is removed.

A count of Successful, Skipped and Failed items are recorded in the CloudM Manage audit logs.

We perform a check to see if the offboarded user and the target user have mail services enabled or not, which might be the case for a Cloud Identity User. If the users do not have mail services then we skip the step.

Expected Outcome

The items that were owned by the user have been transferred to have the new owner that was specified in the workflow step.

The majority of the existing file structure has been preserved. Any shares that were present will remain. Shortcuts were not migrated.

Possible Errors

On the Offboarding Status panel (which will be displayed if you select the user in the Offboarding Status table), you will see a table of all errors that occurred during the step. You can also select Export Errors to export the error messages to a CSV or Google Sheet, allowing you to quickly troubleshoot any issues.

An error could occur if the user being offboarded has already been deleted within the source platform.
Google will sometimes throw an error for no apparent reason when trying to transfer the ownership of a document. The step can be retried to resolve this but there is no guarantee that the error will not reoccur.
The file structure can be disrupted if the new owner is not able to see the parent folder of where a file is located, in this case it will go to the root of the folder specified in the workflow step.
If Drive has been disabled for the offboarded user, the target user or the OUs either of the users are in then the step may fail.

Known Errors

Invalid Credentials - If this error is reported this is most likely due to Drive being disabled. To resolve, try enabling Drive for both users and then retry the step.

Migrate Calendar Events

Overview

The offboarded user’s primary calendar, as well as any calendars that they have created, are transferred to the user specified in the workflow step.

The ownership of the non-primary calendars are directly transferred to the user.

The events in the primary calendar are cloned and created in the target user’s calendar with the naming format specified in the workflow. The events created are new and independent of the old ones, so any changes by attendees to the original events will not be shown in the new calendar.
Any recurring events are not linked to the original, they are just copies of the meetings in the offboarded user’s original calendar.

We perform a check to see if the offboarded user has mail services enabled or not, which might be the case for a Cloud Identity User. If the user does not have mail services then we skip the step.

Expected Outcome

The primary calendar items have been cloned into the target user’s calendar with the given name.

The target user is the owner of the non-primary calendars.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
Google will sometimes throw an error for no apparent reason when trying to transfer the ownership of a calendar. The step can be retried to resolve this but there is no guarantee that the error will not reoccur.
If calendar services are not enabled for the user but mail services are, then this could cause the error processing the steps.

Transfer Ownership of Groups

Overview

The ownership of any groups that the offboarded user is the owner of are transferred to the specified user. The new owner can be specified in the workflow step.

Any existing members or admins of the groups will not be changed.

Expected Outcome

The ownerships of the groups are transferred to the specified user and all existing access remains.

Possible Errors

We transfer the group ownerships acting as the registered domain admin in CloudM Manage on behalf of the user. This will mean that if the domain admin does not have permission to change the ownerships then this step may fail.
Due to the above circumstance, errors reported may be caused by the domain admin account performing the transfers and not necessarily the offboarded user or the specified user.
An error could occur if the user being offboarded has already been deleted within the source platform.

Transfer Contacts

Overview

The contacts in the offboarded user’s “My Contacts” are transferred to the specified user’s contact list with a group name matching that of what has been configured in the workflow step.

We perform a check to see if the offboarded user has mail services enabled or not, which might be the case for a Cloud Identity User. If the user does not have mail services then we skip the step.

Expected Outcome

A contact group matching the name specified in the workflow containing the contacts from the offboarded user’s “My Contacts”.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Transfer Shared Drives

Overview

The management of any Shared Drives that the offboarded user is a manager of are transferred to the specified user.

The specified user must have the "Drive and Docs Settings" Google Workspace privilege which can be assigned via the "Services Admin" role.

We perform a check to see if the offboarded user has mail services enabled or not, which might be the case for a Cloud Identity User. If the user does not have mail services then we skip the step.

Expected Outcome

The specified user can manage the Shared Drives that the offboarded user was managing.
The offboarded user is no longer a manager of those Drives.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
We transfer the shared drive ownerships acting as the registered domain admin in CloudM Manage on behalf of the user. This will mean that if the domain admin does not have permission to change the ownerships then this step may fail.
Due to the above circumstance, errors reported may be caused by the domain admin account performing the transfers and not necessarily the offboarded user or the specified user.
If the specified user does not have the “Drive and Docs Settings” privilege in Google Workspace then the transfer will fail.
If Drive has been disabled for the offboarded user, the target user or the OUs either of the users are in then the step may fail.

Known Errors

Invalid Credentials - If this error is reported this is most likely due to Drive being disabled. To resolve, try enabling Drive for both users and then retry the step.

Remove From Groups

Overview

The offboarded user is removed from any groups that they are a member of.

If the user is included in any Groups or Smart Teams that have dynamic memberships based on search queries, they could be re-added to the group depending on the query.

Expected Outcome

The user is removed from any groups.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Migrate Emails

Overview

The offboarded user’s emails are migrated to the specified user.

The emails will be given a label matching the label specified in the workflow settings. Any original labels on the emails are then re-created under this label, preserving the label structure.

A query can also be used to only migrate emails matching the query. This query uses the Gmail search syntax.

A tolerance level can also be entered. This will mean that if the total failure rate of the transferred emails is above the threshold then the step is marked as “Failed”.

A target for the email migration can only have one active migration at a time. This will mean that if 5 offboarded users all have the same target they will be processed one at a time.
If the 5 offboarded users have different targets, they will be done in parallel.

We feedback statistics on the migration periodically into CloudM Manage that can be viewed when looking at the user’s offboarding.

We perform a check to see if the offboarded user has mail services enabled or not, which might be the case for a Cloud Identity User. If the user does not have mail services then we skip the step.

If the step is aborted within CloudM Manage, the migration will actually continue to proceed. This will mean that if the step is aborted and then restarted, it may carry on with the existing migration since it was not stopped.

Expected Outcome

The emails matching the query are migrated to the specified user, under the label provided and have the same structure of labels when in the offboarded user’s mailbox.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
Emails can fail to migrate if we cannot recreate the label in the target’s mailbox. This can be caused by a nested label structure causing the length of the label to be over the Google limit.

Unassign Licenses

Overview

Any licenses that CloudM Manage has visibility over will be unassigned from the user.

The licenses CloudM Manage has visibility over are: Google Workspace, Drive, Education and Vault.

These licenses are then returned to the pool.

Expected Outcome

Any licenses CloudM Manage has visibility over are removed from the user.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
If the user has auto-licensing setup then we may be unable to remove the licenses that are managed in this way.

Suspend User

Overview

The user’s account will be suspended so that they cannot login or use any services.

Expected Outcome

The user is suspended and cannot login.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.

Apply Google Archived User (AU) License

Overview

The user is archived in Google, giving them an Archived User License.

Expected Outcome

The user will become archived in Google.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.
If there is not an Archived User License available to assign, this step will fail.

Delete User

Overview

The user is deleted from the domain, both within CloudM Manage and Google.

Expected Outcome

The user is deleted.

Possible Errors

An error could occur if the user being offboarded has already been deleted within the source platform.