SPUserUtil will mean either WSSUserUtil or SPSUserUtil respectively (WSSUserUtil is used to administer Windows SharePoint Sites on a standalone WSS Farm/Virtual server OR Windows SharePoint sites in the same virtual server of a SharePoint Portal Server 2003 site.)  SPSUserUtil is a superset of WSSUserUtil, designed for working on SharePoint Portal Server Areas.

You don't need a separate tool to just add an account resource to SharePoint sites and webs, but when it comes to scenarios where you need to "Replicate" someone's rights to another account, it can be an extremely difficult and time consuming process to do this manually.

This will be the first (Really the second, as we're now going 0 based :)) of a few posts in regards to Adding accounts via SPUserUtil.

Replicating Rights/Cloning.

Someone has just joined your team, and you want to replicate, or more precisely clone,  your rights on webs/sites to his account.    If you didn't use an NT Security Group to manage common rights, you would have to do the following to note all your rights so that you can then add the new team member to sites/webs with the same rights:

1. Figure out exactly what you have access to across the farms you have access to :)
2. Note your individual user Role/Rights where you have an individual ACE entry on a a site/web/
3. Note the groups you are a member of and that groups Role/Rights on every single web, etc.
4. Visit each site/web through the UI and and add the user.

If you have permissions spread across many webs and site collections (And across farms too) it can be a daunting task.

With SPUserUtil, you can automate all the above processes easily to help relieve the headache of managing users in SharePoint.

Note: Pay special attention to the new -asuonly and -usermask switches noted below

Replicating Rights using SPUserUtil

Using the clone operation in SPUserUtil, it's extremely simple to replicate account resource rights from one account to another, whether it be a user account or NT Security Group using the following steps:

1. Perform an quick single user analysis to get a proper UserMap file, or create one from scratch (See SharePoint Account Management using SPUserUtil - Part 0 - Removing Accounts for more information)

WSSUserUtil –o analyze –url http://server -usermap singleuser.xml -asuonly -usermask "*margie.richie*"

Note: The –asuonly switch means Give me All Site Users associated on the site collection, regardless if they have any direct ACE entries on any webs, and prevents normal web scanning for the user. It implicitly includes the default -asu logic as noted above,

This will generate the file singleuser.xml.  An additional file, singleuser-webs.xml, will be generated but it will be completely empty, because we're bypassing the normal web scanning that occurs in an analyze operation.  It's a crude but effective way to generate a proper user map file for a single user (or multiple users based on the -usermask).  All we're concerned about is getting one <user> element created for the user.  You could of course, just create this file from scratch in notepad if you wanted to.

Note: A future version of this tool will eliminate the need to generate a UserMap file for single user operations.  In other words, you'll be able to specify -userlogin to target a specific user without the need to generate the UserMap.

Here is a version prepared to work on a single user account.

<?xml version="1.0" standalone="no"?> <!DOCTYPE SPUserUtilUserMapFile> <!--This file represents the user information generated and used by SPUserUtil--> <users>   <user loginname="MYDOMAIN\margie.richie" newloginname="" /> </users>

2. Edit the singleuser.xml file to add the newloginname attribute.  For example:

   <?xml version="1.0" standalone="no"?> <!DOCTYPE SPUserUtilUserMapFile> <!--This file represents the user information generated and used by SPUserUtil--> <users>   <user loginname="MYDOMAIN\margie.richie" newloginname="MYDOMAIN\SomeSecurityGroup/> </users>

   
   
3. Pass this file back into SPUserUtil to replicate the rights for MYDOMAIN\margie.richie to the security group MYDOMAIN\SomeSecurityGroup using the clone operation

   WSSUserUtil –o clone –url http://server -usermap singleuser.xml -r -ac

   This will enumerate over every single web (via the -r <recursive> switch) on every single site collection (via the -ac <all collections> switch) and replicate/clone the rights for MYDOMAIN\margie.richie to the security group MYDOMAIN\SomeSecurityGroup. 

   You could of course use a user account as the source or target, as well as a Security Group, or mix and match between them.  Also, by using the UserMap, it allows you to batch up a series of cloning operations. 
   
   Note: A future version of this tool will eliminate the need to generate a UserMap file for single user operations.  In other words, you'll be able to specify -userlogin to target a specific user without the need to generate the UserMap.

If you were to then do an analysis of the site collection now, you'll see where MYDOMAIN\SomeSecurityGroup matches the rights of MYDOMAIN\margie.richie.

Of course, it's always best to use NT Security groups for common rights so you don't have to perform this process all the time.

In a future post I'll cover Altering Rights using SPUserUtil as well as Auditing Rights.

I hope this helps, and let me know if you have any questions!

 - Keith