The Duplicate Site Security action lets you to copy the security settings (users, groups, and permissions) of a SharePoint site to one or more other sites within the same farm. This may be useful, for example, if you have created one or more new SharePoint sites and want them to have the same users, groups, and permissions as an existing site.
You also have the option of backing up destination site permissions before the Duplicate Site Security action is carried out.
In a multi-farm environment, site security can be duplicated within a single farm; either the home farm or a remote farm.
Factors to Consider before Duplicating Site Security
·Duplicate Site Security is a one-time action. Any ongoing changes to permissions on the source site will not be replicated to the destination site(s). You can, however, schedule the action to run on a recurring basis.
·The action will replace the list of users with direct permissions on a destination site with that of the source site.
·Any permissions level referenced in the source site that does not exist in the destination site collection will be created there as a custom permissions level (even if it exists as a SharePoint default permission level in the source site collection). If custom permissions levels with the same name but different definitions exist in both locations, you can choose whether or not to overwrite the definitions in the destination site collection.
·If you duplicate security to a site that inherits permissions from its parent, that inheritance will be broken and it will become a site with unique permissions that have been copied from the source. Conversely, if you duplicate security to a parent site, child objects with inherited permissions will inherit the new permissions that have been copied from the source.
·You have the option of duplicating permissions (and breaking any existing inheritance) to target lists with identical names (for example, Calendar to Calendar; Shared Documents to Shared Documents). You cannot, however, duplicate permissions of list items.
·Any list with unique permissions on the destination site that does not exist in the source site will remain intact.
How "Matching" Groups Are Handled
SharePoint groups that include the name of the source site (such as Owners, Members, and Visitors) will be matched to equivalent groups on the destination site, using the destination site name. (For example, Source Owners will be matched to Target Owners and so on.) Whenever a "matching" group already exists on the destination site, the action can:
·add members of the source group to the target group, if they are not already there
·replace members of the target group with members of the source group
·leave the target group membership unchanged.
If a group on the destination site has a matching name but the permissions level is different, ControlPoint will replace the permissions level of the destination group with that of the source group.
Other group settings, including Group Owner, will not be changed.
If a matching group is not found at the destination:
It will be createdusing the name of the destination siteand the membership will be copied from the source. Additional settings will be handled as described in the following table.
Action That Will be Taken
ControlPoint will attempt to use the group ownerwhich may be either an individual or another SharePoint groupfrom the source site (provided that owner already exists on the destination site). If the owner does not exist at the definition, the ControlPoint user who is performing the action will become the group owner.
Other group settings
the SharePoint default values will be used (regardless of whether they match the settings for the source group).
To duplicate site security:
1In the SharePoint Hierarchy, select the site whose security you want to duplicate.
NOTE: This action is only available at the site level.
2Right-click and choose Users and Security > Duplicate Site Security.
3If you want to back up permissions on the destination site(s) before performing the duplicate action, check the Backup site permissions before duplicating box.
NOTE: If you check this box and encounter issues with the operation, you can restore permissions from the backup using the procedure for Restoring Site Permissions from a Backup.
4If you want custom permissions level definitions from the source to replace any in the destination site collection that have the same name, leave the Replace custom permission level definition if it is not the same in the target box checked.
NOTE: If you uncheck this box, existing custom permissions level definitions will not be changed.
5If you want permissions of source site lists to be carried over to destination site lists of the same name, leave the Duplicate permissions on lists with matching names checked.
NOTE: If you uncheck this box, permissions for lists with matching names will not be changed.
6Specify how you want the action to proceed When a matching group name is encountered:
§Add members from source site if they are not already in target site
§Replace members with members from source site
§Leave existing group membership as is
7From the Available Items list, select the site(s) to which you want permissions duplicated and move them to the Selected Items list.
8When you have finished selecting sites, click [Apply]
Now you can:
·run the operation immediately (by clicking the [Run Now] button)
If you chose the Run Now, option, after the operation has been processed:
·a confirmation message displays at the top of the page, and
·a ControlPoint Task Audit is generated for the operation and displays in the Results section.
If you schedule the operation, a link to the Task Audit is included in the scheduled action notification email.
See also The ControlPoint Task Audit.
The Migrate Users action lets you update user accounts in SharePoint 2010 farms when:
·Active Directory accounts have been moved from one domain to another
·a user's Active Directory login name has changed.
You can also
·duplicate Active Directory group permissions, and
·if the account was moved in a way that preserved the SID history, verify the SID history to ensure that the old and new accounts correspond.
§In order to use the "Preserve SID History" flag, the ControlPoint Service Account must have dbowner rights to the User Profile Service Application Profile Database.
§For a simple account rename, the same SID is used and a SID history is not generated, so the verification of SID history cannot be performed.
In a multi-farm environment, users can be migrated for a single farm; either the home farm or a remote farm.
NOTE: This action is not available for SharePoint 2013 or later farms.
Migrating Multiple Users
You can migrate only one individual user at a time using the ControlPoint application interface. If you want to migrate multiple users, you can:
·use a wildcard (for example domain_name\*)
NOTE: If you use a wildcard, you also have the option of excluding specified users from the migration.
· save the operation as xml, add users to the xml file, then run the xml instructions.
For the sake of performance, when a wildcard is used users are collected from the ControlPoint cache, which is updated whenever the ControlPoint Discovery process. This information is current as of the date and time of the last Discovery.
IMPORTANT: Permissions of Old and New Accounts
ControlPoint gives you the option not to remove any existing permissions of target users. If you select this option, ControlPoint will check for the existence of permissions granted to the target account of an individual user using permissions information collected during the last Discovery, and if found, will skip the migration for that account and will continue on to the next account. For Active Directory groups, permissions from the source account will be appended to the target account without deleting existing permissions. Individual user accounts that have been skipped will be reported in the ControlPoint Task Audit.
If you choose to remove existing permissions for the target user:
·The default stsadm -o migrateuser behavior will apply for individual Active Directory users. That is, if a user has given permissions in SharePoint using the new account name prior to the Migrate Users action, those permissions will, by default, be deleted as part of the migration. The permissions originally granted to the old account are transferred to the new account after deleting the permissions for the new account. Note that this means:
§You should not run the function two times, as the second run will remove the permissions transferred to the new account by the first run.
§After running this function, the old account will still exist in Active Directory, but will no longer have permissions in SharePoint.
·In the case of Active Directory groups, permissions of the new group will replace existing permissions of the old group.
NOTE: If your ultimate goal is to copy permissions to users in a target domain while retaining all existing permissions in both domains, you can do so using the ControlPoint Duplicate User Permissions action.
Before Migrating Users in ControlPoint
Before using the ControlPoint Migrate Users action, make sure that the changes have been made in Active Directory (that is, new accounts have been created or renamed accounts have been renamed).
How Names Appear After Migration
SharePoint's handling of display names after rename in Active Directory and/or a run of Migrate Users depends on many factors, including which versions of SharePoint you are running, whether and how several Profile Synchronization jobs are configured. In SharePoint Foundation, no shared profile exists. Display names are stored only in each individual site collection and must be modified directly there. By default, there is no automated process to update the display names.
In SharePoint Server, a shared profile is available. This should normally be updated using whatever methods are in place in your environment.
In general, if your environment is configured to have SharePoint Profile Synchronization jobs run on a regular basis, until it runs, SharePoint and ControlPoint will show:
·the new account name, and
·the old display name.
After the Profile Synchronization jobs have run, the new display name normally will show in both SharePoint and ControlPoint, with the following exceptions:
·Activity by User, Activity by Document, and Change Log Analyses will continue to show the old display name.
·Any ControlPoint analysis using cached data will show the old display name until the next time Discovery runs.
REMINDER: The Migrate Users action is not available for SharePoint 2013 or later farms.
Before carrying out the ControlPoint Migrate Users actions, it is recommended that you review Factors to Consider Before Using the ControlPoint Migrate Users Action.
To migrate users:
1From SharePoint Hierarchy farm node, choose Users and Security > Migrate Users.
2Check the appropriate option(s) using the information in the following table for guidance.
·you have migrated users from one domain to another in a way that preserves SID history, and
·you want to verify the SID history to ensure that the old and new accounts correspond.
check Verify SID history.
·For a simple account rename, leave this box unchecked because the same SID is used and a SID history is not generated. If this box is checked and a SID history does not exist, the operation will fail.
·In order to use the "Preserve SID History" flag, the ControlPoint Service Account must have dbowner rights to the User Profile Service Application Profile Database.
you have migrated Active Directory groups from one domain to another and you want to update permissions granted to Active Directory groups
check Process Active Directory groups.
NOTE: if you leave this box unchecked, Active Directory group names will not be updated
·you want to remove any permissions that have been granted to individual Active Directory user accounts at the target and replace them with the permissions from the source account (which is default stsadm -o migrateuser behavior)
·replace the permissions of Active Directory groups at the target with the permissions of corresponding source groups
check Remove existing permissions for target accounts.
NOTE: If you leave this box unchecked, the Migrate action will skip any individual Active Directory accounts that already have permissions. (Skipped accounts will be recorded in the ControlPoint Task Audit.) For Active Directory groups, the action will append permissions from the source group to any permissions that exist for the target group.
The Migrate User operation only evaluates permissions collected during the last Discovery run.
3For User to migrate, enter a single user name or wildcard.
Note that you can only enter one wildcard, anywhere within the entry.
REMINDER: When a wildcard is used, users are collected from the ControlPoint data cache, which is current as of the date and time of the last Discovery run.
§In the following, we want all instances of the login name axcelertest\marktwain in our SharePoint farm to be changed to the new login name axcelertest\sammuelclemens. Note that Process Active Directory groups option is not relevant for this operation.
§In the following example, we want to change the domain for all users in our SharePoint farm from the old Active Directory domain (axcelertest) to the new domain (metalogixtest). We want to exclude axcelertest\marysmith from the process, because she was assigned a different account name in the new domain. The Process Active Directory groups option is checked, so that permissions of all Active Directory groups in the old domain will be transferred to corresponding Active Directory groups in the new domain. Remove existing permissions for target accounts is also checked, to ensure that any existing permissions for a target account will be replaced with those from the matching source account.
REMINDER: Once the operation is run, the old account will still exist in Active Directory, but will no longer have permissions in SharePoint.
Now you can:
·run the operation immediately (by clicking the [Run Now] button)
If you chose to Save XML Instructions and want to specify additional users to migrate, enter each user as a separate item with:
·the old login name as a string between the <key></key> tags
·the new login name as a string between the <value></value> tags.