Syncplicity Support

Search our knowledgebase to get the help you need, today

Follow

User drive - user account mapping

Map user accounts on one connection to those on another. Individual jobs will be generated to transfer items between mapped accounts

User account mapping jobs are ideal for migrations where you wish to control the transfer at a granular level without the effort of creating individual jobs. DataHub will automatically create a unique job for each user account that can be matched between the source and destination connections.

Users on the destination are matched to either users on the source, folder names on the source, or LDAP records on the source.

Important! User account mapping jobs require connections with the ability to impersonate other users.

Related: Create New Job | Transfer Direction

User-Interface - Create a User Account Mapping Job

User account mapping job supports the following:

Impersonation

All job features defined while creating the parent job will be applied to the child jobs it create.

Important! User Account mapping jobs require connections with the ability to impersonate other users.

User-Interface - Define your Source and Destination Paths

If you are an administrator using Impersonation, enable Run as user..., and choose the user you wish to access.

Source / Destination Path: If you wish to transfer all content, leave the source path blank. A child job will be created for every user account. If a directory is selected for the source path, a child job will be created for every user account within the parent directory. 

Child Job Source / Destination Path: This directory within each user account will be used as the source. If the directory does not exist on the destination, DataHub will create it.

Target the root of each user account: The child job will be created for the first level folder/account relative to the source path.

Target a specific directory within each user account: If there is a folder that exists in every user account, you can define it with this option.

User-Interface - Save and Configure Mappings for the User Account Mapping Job

After configuring policies, behaviors, and advanced features, select the option to save and configure the parent job. You will be prompted to schedule the job. This schedule will be applied to the child jobs.

User-Interface - Configure User Account Mapping Job - Settings

Configure the settings that determine the general rules for how the child jobs are generated. The user mappings and filter tabs allow you to override automatic user mapping rules and filter out users by explicitly including or excluding them.

User Account Job Generation: Which connection should be used to determine user accounts?

Source: Use the source connection as the source of user accounts when generating user account jobs.
Destination: Use the destination connection as the source of user accounts when generating user account jobs.

Remove user account jobs that are no longer valid: This is an on/off setting that deletes jobs that are no longer valid.

Email Domain: Specify an email domain to limit the generation of user account mapping child jobs to only users with this email domain. For example, enter 'example.com' to create a job for the user 'test@example.com' but not for the user 'test@something.com'.

Mapping policy: Users can be automatically mapped from one platform to another. Select the rules to be used for attempting a match

Unmapped User Policy: What should be done if the user source account is not found on the destination?

User-Interface - Configure User Account Mapping Job - User Mappings

On the settings tab, you are able to create rules to automatically map users from one platform to the other for child job generation. Here, you can override those general rules by specifically mapping one user to another.

Import mappings: Upload a CSV file to create explicit user mappings.

User Account Mappings - CSV Import Sample

Create User Mapping: Manually match each user through the DataHub user-interface.

User-Interface - Configure User Account Mapping Job - Filters

Here, you can specify a list of users to include or exclude from child job generation by importing filters defined in a CSV. The configuration defined on the other tabs will determine how matching is done from one connection to another, but these filters will remove some of the matches from generating jobs.

User Filter Policy: Child jobs are generated from the users within the path. You can explicitly include or exclude users when creating child jobs.

Inclusion: Specify users to include when generating child jobs. When matched, only include users in this list. All other users will be excluded.
Exclusion: Specify users to exclude when generating child jobs. When matched, exclude users in this list. All other users will be included.

User Account Mappings - Filter Import Sample

User-Interface - Run User Account Mapping Job

After configuring your user account mapping job, run the job. This will execute the parent job, which will create the child jobs.

  • After the child jobs are created, the default schedule is set to run every 6 hours so it can review the source for any new content.
  • The parent and child job schedules can be changed at any time.

DataHub API - Creating a User-Drive Mapping Job

Account would match users on source to destination – User Account Mapping

Container would match folder name on source to users on destination – Network Home Drive Mapping

POST /jobs

{
    "name": "personal_drive box to o365",
    "kind": "personal_drive",
    "transfer": {
        "transfer_type": "copy",
        "source": {
            "connection": {
                "id": "{{cloud_connection_source}}"
            }
        },
        "destination": {
            "connection": {
                "id": "{{cloud_connection_destination}}"
            }
        },
        "schedule": {
            "mode": "auto"
        }
    },
    "schedule": {
        "mode": "manual"
    },
    "convention": {
        "match": "account",
        "map_by": {
            "email": true
        },
        "users": "source",
        "remove_invalid": true,
        "unmapped_policy": "warn",
        "type": "personal_drive"
    }
}

This would create a convention job. Convention jobs can be controlled and manipulated just like transfer jobs, but convention job's execution does not transfer any data. Instead, each execution of a convention job results in the creation, modification, or deletion of its child jobs.

Notes:
  • Schedule in the transfer block is for child jobs. In this case, all child jobs would be on auto schedule.
  • Schedule outside transfer block is for convention job itself. In this case, the convention job would be on manual schedule.
  • Destination path is relative to the root of matched user's account. In this example, if we found that user1@example.com exists on source and destination, we would create a child job that transfers from user1's '/my docs' on box to user1's 'Documents' on o365.
  • If matching to source accounts, source path is relative to that user's root. If matching to source folder names, source path is path to where user folders are located.

Additional Settings

Match

convention.match controls how to match source and destination. Possible values are container, account, or ldap.

Container would match folder name on source to users on destination – Network Home Drive Mapping

Account would match users on source to destination – User Account Mapping

Ldap 

If this setting is omitted, DataHub will default to account if account querying is supported by source connection; otherwise, it will default to container.

Map_by

convention.map_by refines how to match source to destinations.

"convention:" {
    ...
    "map_by": {
        "id": true,
        "name": true,
        "email": true,
        "fuzzy": true
    }
}

Option

Values

Description

default

true/false

Optional. Enables default mapping by all fields.

Equivalent to setting all the the following to true: id, name, username, caption and email 

id true/false Optional. Match accounts by id.
name true/false Optional. Match accounts by name.

username

true/false Optional. Match accounts by username.
caption true/false Optional. Match accounts by caption / display name.
email true/false Optional. Match accounts by email.
fuzzy true/false Optional. Allows for partial match on supported platforms. This would apply to all selected fields.
built_in true/false Optional. Allows to use built_in accounts on supported platforms.
passthrough true/false Optional. Allows to create child jobs for folders for which DataHub couldn't match an account (FS or NFS; both sides only)
external_passthrough true/false

Optional. Allows external emails that have never been associated as a guest account to get passed through

Note: External email already associated as a guest account in OfB/O365 will work regardless of whether external_passthrough is on

ldap true/false Not fully supported 

Search Domain

convention.search_domain allows to specify domain name when matching folders without domain to email address.

For example, the following setting would match folder with name 'test' to email 'test@example.com'.

"convention:" {
    ...
    "map_by": {
        "email": true
    },
    "search_domain": "example.com"
}

Users

convention.users is an optional setting that defines the source the user conventions use to create the map. Valid values include sourcedestination, and ldap. Example:

"convention:" {
    ...
    "users": "source"
}

Value

Description

source Use the source platform as the source of user accounts when generating the personal drive jobs.
destination Use the destination platform as the source of user accounts when generating the personal drive jobs.
ldap Use an ldap server as the source of the user accounts when generating the personal drive jobs.

Inclusions / Exclusions

convention.inclusions is an optional setting that limits user mapping to this list only.

"convention:" {
    ...
    "inclusions": [{
        "sid": {
            "email": "include_me_only@example.com",
            "type": "account"
        }
    }]
}

convention.exclusions is optional setting that excludes user mappings specified in this list.

"convention:" {
    ...
    "exclusions": [{
        "sid": {
            "email": "exclude_me@example.com",
            "type": "account"
        }
    }]
}

By default, inclusions and exclusions are applied to source users. This can by changed to use destination users.

"convention:" {
    ...
    "users": "destination"
}

Inclusion/Exclusions can be imported via CSV.

"inclusions": {
        "text": {
            "connection": { "id": "{nfs_connection_id}"},
            "target":{
              "path":"/pdm.csv"
            }
        }
    }

CSV Format:

id,username,name,caption,category,source_uri,destination_convention
"skymash\\spuser","skymash\\spuser","","","Category1","/Documents","/Documents"

Inclusions for Personal Drive Matches include 3 optional fields that allow user-specific Categories, Source, and Destination Paths. When specified (via JSON or CSV), these values will override the convention values.

"inclusions": [{
      "sid": {
          "username": "skymash\\spuser",
          "type": "account"
      },
      "category": "TestCategory",
      "source_uri": "/SourceUri",
      "destination_convention": "/DestinationConvention"
  }]

Inclusions and exclusions are mutually exclusive, meaning that either inclusions or exclusions will be used during the matching process of the job.  If both are defined during job creation, whichever is defined last is the the one that will be honored.

Exceptions

convention.exceptions is an optional setting that defines a map of source to destination users. This is useful where a match cannot be done automatically.

"convention:" {
    ...
    "exceptions": [{
        "source": {
            "email": "m_smith@example.com",
            "type": "account"
        },
        "destination": {
            "email": "smith.michael@example.com",
            "type": "account"
        }
    }]
}

Path Conventions

convention.path_conventions is an optional setting that defines the source and destination paths for the account match jobs (child jobs).

"path_conventions":[{
   "source":"/Documents",
   "destination":"/Documents/Test"
 }]

Unmapped Policy

convention.unmapped_policy is an optional setting that determines what to do when an account cannot be mapped to a destination account. Example:

"convention:" {
    ...
    "unmapped_policy": "warn"
}

Value

Description

ignore Do not create a job for the unmapped convention.
warn Do not create a job for the unmapped convention and log a warning in the audit log.
default Not applicable
add Provision the account on the destination and create the job for the mapped convention.

Remove Invalid

convention.remove_invalid is an optional flag that specifies whether to remove existing jobs that no longer have a valid convention at the source. Example:

"convention": {
    ...
    "remove_invalid": true
}

Filter by Pattern

convention.filter.pattern  is an optional setting for filtering user drive accounts by pattern. The convention.policy property specifies whether this is an inclusion or exclusion filter. If a filter policy is not specified, it defaults to exclude. Example:

"convention": {
    ...
    "filter": {
        "policy": "include"
        "pattern": {
            "text": "user*"
        }
    }
}

includes all users named user1, user2, user3, etc.

Filter by Metadata

convention.filter.metadata is an optional setting for filtering user-drive folders (the root folder anyway) by their metadata properties. Example:

Simple Metadata Filter

"convention": {
    ...
    "filter": {
        "policy": "include"
        "metadata": {
            "source": {
                "text": "[Author]=\"Angus Young\""
            }
        }
    }
}

includes all items and containers whose Author metadata property equals "Angus Young".

More Complex Metadata Filter

"convention": {
    ...
    "filter": {
        "policy": "exclude"
        "metadata": {
            "source": {
                "text": "string"
                "filter": {
                    "name": "Author",
                    "op": "empty",
                    "value": ""
                }
            }
        }
    }
}  

excludes all items whose Author metadata property is empty.

For more examples of simple and complex filters, see Job Filters

Folder Metadata

NFS and FS folders have special metadata provided by their underlying operating systems (e.g., Windows).  The property values of this metadata can be used in the metadata filters above.  Here is a description of these metadata properties:

Property Name

Property Type

Description

ID string internal ID of the folder.  may not be useful
Name string name of the folder
Owner string full name of the folder's owner
CreatedBy string full name of the folder's creator
CreatedOn DateTime time of folder's creation
ModifiedBy string full name of the last user to modify the folder
ModifiedOn DateTime time of last folder modification
IsShared boolean indicates whether folder is shared or not
IsHidden boolean indicates whether the folder is hidden or not

Viewing the details of a user-drive mapping job

Inclusions / Exclusions

GET

/transfers/{{jobId}}/personal_drives/matches

There is currently no flag returned indicating whether the matches list returned is used for inclusions or exclusions.

Exceptions

GET

/transfers/{{jobId}}/personal_drives/exceptions

Updating a user-drive mapping job

Inclusions / Exclusions

New inclusions / exclusions can be added to the list by posting the following:

POST /transfers/jobId/personal_drives/matches

[
        {
          "sid": {
            "email": "include_me_too@example.com",
            "type": "account"
          }
        },
        {
          "sid": {
            "email": "include_me_also@example.com",
            "type": "account"
          }
        }
]

The following REST API call provides the ability to remove an inclusion/exclusion from the matches list.

DELETE

/transfers/{{jobId}}/personal_drives/matches/{{matchId}}

Exceptions

New exceptions can be added to the list by posting the following:

POST /transfers/jobId/personal_drives/exceptions

[{
    "source": {
        "email": "m_smith2@example.com",
        "type": "account"
    },
    "destination": {
        "email": "smith.michael2@example.com",
        "type": "account"
    }
}]

The following REST API call provides the ability to remove an exception from the list.

DELETE

/transfers/{{jobId}}/personal_drives/exceptions/{{exceptionId}}

Powered by Zendesk