One of the biggest concerns when users are leaving the business is the retaining of data that could be sensitive or crucial to upcoming events.
CloudManager provides a customisable deprovisioning policy and process which can be applied to your entire domain and using Smart Teams individual groups of users to match your business structure.
The workflow is a total of 15 steps that can be enabled or disabled as you require.
- Request Approval
- Prompt for Resource Allocation
- Change Password
- Delegate Access
- Hide User
- Rename User
- Assign Alias
- Transfer Ownership of Documents
- Transfer Ownership of Calendars
- Transfer Ownership of Groups
- Transfer Contacts
- Remove from Groups
- Migrate Emails
- Suspend User
- Delete User
In this guide, we're going to go over each step and discuss the use and impact of each.
Set Root OU
To edit the Deprovisioning Policy for the Main OU
- Click on the Deprovisioning left-hand menu
- Click on the subcategory Deprovisioning Policy
This will open up the Edit view for the Main OU Deprovisioning Policy.
Set Smart Team
To edit the Deprovisioning Policy for a Smart Team
- Under User Lifecycle Mangement, select Smart Team
- Select the Smart Team you wish to edit the policy for.
- Click on the sub category Deprovisioning Policy
This will open up the Edit view for the Main OU Deprovisioning Policy.
When configuring your deprovisioning policy the first option you have available for selection is the ability to 'Automatically Deprovision Suspended Accounts'. If this option is selected, as stated, any account within the OU where this option is active that is set to a 'suspended' state will be automatically deprovisioned in line with the rest of the defined policy steps. Accounts currently in a suspended state when this setting is enabled will not be deprovisioned. You will be required to deprovision these manually using the normal steps.
During the deprovisioning process we are required to remove the suspended state from an account to allow the system to process documents (e.g. transfer ownership of documents), when these steps are complete we will automatically re-apply the suspended status to any account deprovisioned using this method. However, it is important to remember that if you have a large account the period of time when the account is unsuspended maybe lengthy whilst documents and email are transferred, you must take steps to secure the account to ensure no unauthorised use.
It is important to remember that when this option is a selected account set to 'suspended' by any method will be deprovisioned. This included accounts set via an external system e.g. via Office 365 Admin or an other HR system, accounts set to suspended via CSV import or accounts set via CloudManager itself.
The Deprovisioning Policy must have the following set:
- Executor = This is the person/account that will be required to make decisions during the deprovisioning process
The Executor can be set to one of the following:
- User's Manager or Domain Admin
- User's Manager or Specified
- User's Manager or Error
- Domain Admin
Remember the user's manager is the one specified on the CloudManager user profile. If this is not set and you select this option the process may error.
In any setting of "Specified" you'll be presented with a text box beneath the drop down allowing you to pick the email of the user you want to use. In cases where there are more than 1 potential executor (the top 2 settings), then a workflow is sent to both however as soon as one starts the workflow it is assigned to them.
After the executor you'll have several text fields that can be edited, these fields are the subject line that will be received when a user goes through the deprovision process, you can alter these so you can more easily setup a Gmail filter, or ensure the language is tailored to your organisation. It doesn't have any impact on the deprovision itself.
User Profile Fields
You can use Profile Fields - First name, Last Name, Title etc. within the email notification Subject
At this point, you'll then be able to specify which steps you want on your OU's policy:
- Request Approval => This is a basic Yes/No request of the Executor, the purpose being to make sure approval is given before the process begins.
Prompt for Resource Allocation => Since we allow you to reallocate items to default values (which can be changed in this workflow from the Executor), we also allow you to change who this is going to be at the last second without having to go into the workflow and altering the policy for everyone. This is useful is a colleagues files or alias could be better suited to someone elses account such as a team member or an archive account.
It's important to note that there are sub-components that can be disabled if you don't want to give the option to reassign items, i.e. you could have it so that only drive could be re-assigned but all other items will always abide by the workflow.
- Change Password => Changes the user's password to a random 16 character alphanumeric one to prevent log-in and clears their password reset question answers.
- Delegate Access => The executor will be given delegation access so they can read/send/delete messages on behalf of the suer.
- Hide User => This moves the user to a specific OU, and also hides them from the global address list so no other user can find them.
- Rename User => This renames the primary email address of the user, meaning it can be reused by another user (see step 7), by default the new email address is a random guid, but it can be changed to something as simple as "old.$mailPrimary" so that you can still identify the user should you need to intervene or stop the workflow later.
Assign Alias =>
This option is only available if 'Rename user' is enabled
Reassign the leaving users primary email to the new owner. A label can then be specified and this will be applied to all emails coming into the new owners mailbox but when using the old users primary email as it's now an alias. This helps avoid disruption of the new owners workflow within Gmail and means they can easily find and update any and all clients emailing an invalid address.
- Transfer Ownership of Documents => This moves over all documents from the leaving user to the new owner and puts it all under a root level folder in their MyDrive as specified under the new owner setting. This means your MyDrive structure is unaffected but can now find all files of the leaving user easily.
Ownership of Calendars => This moves all calendars over to the new owner.
If Calendar is not selected they will be lost when the user account is deleted.
Transfer Ownership of Groups => This moves all groups over to the new owner. Ownership or any Sharepoint Sites associated with this group will also be transfer as part of this step.
If Groups is not selected they will be lost when the user account is deleted.
Transfer Contacts => This will move all contacts over to the new owner and place them under a name you can specify under the new owner setting
If Contacts is not selected they will be lost when the user account is deleted.
- Remove From Groups =>This will remove the user from any groups they're a member of, but it's important to note with any smart groups they may be re-added if they still fall under the search query the group is based on. That is why it can be useful to move the user to another OU (under Hide user step).
- Migrate Emails => Migrates the user's emails to the specified user. The migrated emails will be given a label based on the template below which can include profile attribute placeholders just like email signatures. The original labels of the migrated emails will be re-created under this new label.
- Suspend User => This prevents the user from logging in and accessing any services in GSuite.
- Delete User => This finally deletes the profile in full, you can provide a delay and also reminder email delay values.
Email notifications you can customise for step 16:
- Scheduled Delete Email Notification Subject
- Deleted User Email Notification Subject