Chat now with support
Chat with Support

Migrator Pro for Exchange 20.11.2 - User Guide

Appendix H:  Mailbox Permissions Migrated

When a mailbox is submitted for migration, the Submit Pending Jobs activity will read the following mailbox permissions:

Exchange Permissions:

ChangePermission

DeleteItem

ReadPermission

ChangeOwner

FullAccess

Send On Behalf

NT Permissions:

Send-As

Receive-As

Mailbox Folder Permissions:

All mailbox folders

All trustees, except Default and Anonymous

All rights including: Owner, PublishingEditor, PublishingAuthor, Editor, Author, NoneditingAuthor, Contributor, Reviewer, CreateItems, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderContact, FolderOwner, FolderVisible and ReadItems

Mailbox folder permissions are automatically migrated by Exchange. However, to enable Exchange to do so successfully, the following must be done prior to moving the mailbox:

  • For Resource Folder migrations the msExchMasterAccountSID must be set on each target trustee before moving the user.

  • For non-Resource Forest migrations an X500 address must be added to each source trustee that points to the target trustee before moving the user.

Once the mailbox migration has completed, the permissions found in the CMTEUP_UserMailboxPermissions table are processed.  For each permission, the trustee is opened in the Source AD and a matching Target trustee is located using:

Mailbox GUID

E-Mail

Primary SMTP

Common Name

SAM Account Name

If no match is found, the MCP waits and retries applying the permission. This retry process can be configured in the Mailbox Settings with the Mailbox Permissions Retries setting.

 

 

 

Appendix I:  How to Process GDPR Requests

What is a GDPR Request?

The General Data Protection Regulations (GDPR) is the new European Union (EU) data protection regulations which go into effect May 25th, 2018. Under the GDPR individuals have certain rights to their personal data. They can make requests to exercise those rights to the data controller, and the controller must respond within 1 month.  It is expected that the controller will verify the identity of the requestor.

There are four primary types of GDPR requests:

 

  • Export – Request for a copy of all personal data about an individual held by this controller and any related processors.  Must be in a commonly accepted portable data format.

  • Update – Request to rectify inaccurate personal data.

  • Delete – Request to remove all personal data about an individual from our systems. Can be initiated by an individual or by a revocation of consent process. Includes burden of proof.  (Ideally follow a delete with an export to show no remaining data)

  • Hold – Request to halt processing of personal data but not delete that data. 

How to handle GDPR Requests for Migrator Pro for Exchange

When Migrator Pro for Exchange is installed, the data associated with the application is hosted locally within the client’s environment. The client has full control over this data. By default, the user and configuration data is stored in the SQL database called, “ExchangePro_<date>”. It is assumed the operator has the proper administrative SQL Permissions to execute the following methods outlined.

 

SQL Tables containing User data:

  • [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

    Unique Key Look-up Columns:

    [sAMAccountName]

    [userPrincipalName]

  • [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

    Unique Key Look-up Columns:

    [DistinguishedName]

    [Email]

     

Where does the Migrator Pro for Exchange get its user data?

All user data within Migrator Pro for Exchange is derived from the source Active Directory Forest configured in the product. Therefore, the authoritative source of any user related data stored in Migrator Pro for Exchange is Active Directory. Any remediation required from a GDPR request should first be remediated in Active Directory or the source feeding Active Directory. Once that user data is updated in the source directory, running a new discovery within the product will update those values as well.

 

The following sections will provide guidance on fulfilling the 4 primary GDPR request types.

 

  1. Exports – Request for a copy of all personal data about an individual held by this controller and any related processors.  Must be in a commonly accepted portable data format.

 

Migrator Pro for Exchange user data can be exported in many ways. The product interface provides export options for any discovered mailbox user. For more information, search the product help for “Exporting data to a CSV file”. There are also methods of exporting data using SQL Server Management Studio wizard. 

 

For the purposes of this document, using PowerShell with the SQLPS Module is the recommended method to refine the results of the output. One may export any SQL Query result to a CSV file. Below is an example script to do so. Replace the variables to conform to your environment.

 

Import-Module sqlps

$SQLquery='SELECT * FROM [ExchangePro_<Date>].[dbo].[CMTEUP_Person]'

$result=invoke-sqlcmd -query $SQLquery -serverinstance <servername> -database <dbname>

$result |export-csv c:\temp\ExportQueryResults.csv -notypeinformation

 

  1. Updates – Request to rectify inaccurate personal data.

 

As previously stated, all user data within Migrator Pro for Exchange is derived from the source Active Directory Forest configured in the product. Therefore, the authoritative source of user data is Active Directory. Any remediation required from a GDPR request should first be remediated in Active Directory or the source feeding Active Directory.

 

If editing the user data within SQL is still required, using any SQL editor such as SQL Server Management Studio, run an update command against one or more columns for one or more records. Below are examples to accomplish this. Note however, that any new discovery will update the values based on the source Active Directory.

 

Update multiple columns for a single record:

UPDATE [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName='<Unique ID>'

 

UPDATE [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName='<Unique ID>'

 

Update multiple columns for multiple records:

UPDATE [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE DistinguishedName='<Unique ID>' OR DistinguishedName='<Unique ID>'

 

UPDATE [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName='<Unique ID>' OR userPrincipalName='<Unique ID>'

 

Update multiple columns for multiple records using a list:

UPDATE [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE DistinguishedName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

UPDATE [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

  1. Deletes – Request to remove all personal data about an individual from our systems. Can be initiated by an individual or by a revocation of consent process. Includes burden of proof.  (Ideally follow a delete with an export to show no remaining data.)

 

Using any SQL editor such as SQL Server Management Studio, run a Delete command against one or more records. Below are examples to accomplish this. However, as previously stated, if the user is not deleted in the source Active Directory during any subsequent new discovery the user will be re-populated into SQL. The only way to truly remove the data is to delete the source user or delete the entire SQL database when it is no longer required.

 

Delete a single record then verify:

DELETE FROM [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

WHERE DistinguishedName='<Unique ID1>'

 

SELECT * FROM [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

WHERE DistinguishedName='<Unique ID1>'

 

DELETE FROM [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

WHERE userPrincipalName='<Unique ID1>'

 

SELECT * FROM [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

WHERE userPrincipalName='<Unique ID1>'

 

Delete multiple records then verify:

DELETE FROM [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

WHERE DistinguishedName='<Unique ID1>' OR DistinguishedName='<Unique ID2>'

 

SELECT * FROM [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

WHERE DistinguishedName='<Unique ID1>' OR DistinguishedName='<Unique ID2>'

 

DELETE FROM [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

WHERE userPrincipalName='<Unique ID1>' OR userPrincipalName='<Unique ID2>'

 

SELECT * FROM [ExchangePro_<Date>].[dbo].[CMTEUP_PersonADData]

WHERE userPrincipalName='<Unique ID1>' OR userPrincipalName='<Unique ID2>'

 

Delete multiple records then verify:

DELETE FROM [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

WHERE DistinguishedName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

SELECT * FROM [ExchangePro_<Date>].[dbo].[CMTEUP_Person]

WHERE DistinguishedName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

DELETE FROM [ExchangePro_<Date>].[dbo].[ CMTEUP_PersonADData]

WHERE userPrincipalName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

SELECT * FROM [ExchangePro_<Date>].[dbo].[ CMTEUP_PersonADData]

WHERE userPrincipalName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

 

  1. Holds – Request to halt processing of personal data but not delete that data.

As with exporting user data, this can also be accomplished using the product interface. Halting a user from processing within Migrator Pro for Exchange can be achieved using the Blackout Times feature. The process has two steps.

 

  1. Create a New Blackout Profile

  2. Assign the Profile to the User(s)

 

Create a New Blackout Profile

To set blackout times spanning every day, all day:

  1. Launch Migrator Pro for Exchange.

  2. Click Blackout Times in the main toolbar.

  3. Click Add Profile to create additional blackout profiles.

  4. Name the Profile “User GDPR Hold” or equivalent. Click OK.

  5. Within the Calendar view, double-click on today.

  6. An appointment will open. Click the “All day event” checkbox.

  7. Populate the Subject and Description Fields.

  8. Click the “Edit Recurrence” button.

  9. Select the “Daily” recurrence pattern.

  10. Select the “No End Date” range of recurrence.

  11. Click OK.

  12. Click Save & Close.

 

Assign the Profile to the User(s)

The “default” blackout profile is initially applied to all user mailboxes. To set user mailboxes to a different blackout profile, select one or more mailboxes in the Mailboxes or Mailbox Jobs view and edit the “Properties” in the right-click menu.

 

To assign the new blackout profile to the desired user, follow these steps.

  1. Launch Migrator Pro for Exchange.

  2. Select the Forest where the user is located.

  3. Locate the user(s).

  4. Right-Click on the selected user(s).

  5. Select Properties.

  6. Place a check in the Blackout Times checkbox.

  7. From the drop-down menu, select the new Blackout Profile created previously. The instructions above called it, “User GDPR Hold”.

  8. Click OK.

  9. The User record will update to display the new Blackout profile assigned.

 

Please note, manually suspended migrations ignore blackout periods if they are manually resumed, and will begin migrating immediately. For more information, search the product help for “Applying Blackout Times to the Forest”.

    

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating