SharePoint Account Management using SPUserUtil - Part 2 - Adding Accounts

SharePoint Account Management using SPUserUtil - Part 2 - Adding Accounts

 

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 is the second of a few posts in regards to Adding accounts via SPUserUtil.

See the first post in this series SharePoint Account Management using SPUserUtil - Part 1 - Cloning Accounts

Adding Users

Someone has just joined your team, and you want to give them access using a mix of rights to the same sites as someone else. Cloning doesn’t work here, because you may not want them having the exact same rights as the source account

In this scenario, We’ll add a user and security group to sites/webs that the source account is already an Administrator of. The Security group will be given Contributor rights, and the user will be given Web Designer rights

If you needed to do this for tons of sites and webs, it can be very time consuming if you have to manually visit every single site and web to perform this change.

SPUserUtil to the rescue.

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

Adding Users using SPUserUtil

Using the add operation in SPUserUtil, it's extremely simple to add account resource rights to a series of sites and webs, 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 and a Webs Manifest file showing the location of the single user across your virtual server, or create one from scratch (See SharePoint Account Management using SPUserUtil - Part 0 - Removing Accounts for more information)

WSSUserUtil –o analyze –url https://server -usermap singleuser.xml –r –ac -usermask "*krichie*"

Note: Unlike the cloning example in my previous post, we don’t want to use the –asuonly switch. We want to use the –r <recursive> and –ac <all site collections> switch so that the webs manifest file will have the location of the user.

This will generate the file singleuser.xml. An additional file, singleuser-webs.xml, will be generated that contains the webs manifest file which shows you the location and rights of all users found in the scan. You could of course, just create this file from scratch in notepad if you wanted to.

Here is a version showing this scan on my test environment from a scan on a single user account.

<?xml version="1.0" encoding="utf-8" standalone="no"?>

<!DOCTYPE SPUserUtilWebFile>

<!--This file represents the web information generated and used by SPUserUtil-->

<webs>

  <web url="https://dev.tailspintoys.com" title="Team Web Site" description="" lcid="1033" template="STS" uniqueperms="True" acecount="1">

    <user loginname="tailspintoys\krichie" displayname="Keith Richie" email="krichie@tailspintoys.com" notes="" sid="S-X-X-XX-XXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-XXXXX">

      <crosssitegroups />

      <sitegroups>

        <group name="Administrator" />

      </sitegroups>

      <listpermissions />

    </user>

    <web url="https://dev.tailspintoys.com/subweb1" title="Subweb1" description="" lcid="1033" template="STS" uniqueperms="True" acecount="1">

      <user loginname="tailspintoys\krichie" displayname="Keith Richie" email="krichie@tailspintoys.com" notes="" sid="S-X-X-XX-XXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-XXXXX">

        <crosssitegroups />

        <sitegroups>

          <group name="Administrator" />

        </sitegroups>

        <listpermissions />

      </user>

    </web>

    <web url="https://dev.tailspintoys.com/subweb2" title="subweb2" description="" lcid="1033" template="STS" uniqueperms="True" acecount="1">

      <user loginname="tailspintoys\krichie" displayname="Keith Richie" email="krichie@tailspintoys.com" notes="" sid="S-X-X-XX-XXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-XXXXX">

        <crosssitegroups />

        <sitegroups>

          <group name="Administrator" />

        </sitegroups>

        <listpermissions />

      </user>

    </web>

  </web>

</webs>

Following the analyze operation, I performed the following steps to prepare for my add operation.

  1. Copied the singleuser-webs.xml file to addusers.xml
  2. Edited the addusers.xml file to change the loginname attribute to the loginname of the target user
    1. I also changed the group name attribute from “Administrator” to “Web Designer”
  3. Added a <user> element at each web to add a reference to the new Security Group, and give it a <sitesgroups> and <group> element to add this group to the “Contributor” site group in each web.

<?xml version="1.0" encoding="utf-8" standalone="no"?>

<!DOCTYPE SPUserUtilWebFile>

<!--This file represents the web information generated and used by SPUserUtil-->

<webs>

  <web url="https://dev.tailspintoys.com" title="Team Web Site" description="" lcid="1033" template="STS" uniqueperms="True" acecount="1">

    <user loginname="tailspintoys\cgideon" displayname="Chris Gideon" email="cgideon@tailspintoys.com" notes="" sid="S-X-X-XX-XXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-XXXXX">

      <crosssitegroups />

      <sitegroups>

        <group name="Web Designer" />

      </sitegroups>

      <listpermissions />

    </user>

      <user loginname="NT AUTHORITY\authenticated users" displayname="Everyone in the company!" >

      <sitegroups>

       <group name="Contributor" />

      </sitegroups>

      </user>

    <web url="https://dev.tailspintoys.com/subweb1" title="Subweb1" description="" lcid="1033" template="STS" uniqueperms="True" acecount="1">

      <user loginname="tailspintoys\cgideon" displayname="Chris Gideon" email="cgideon@tailspintoys.com" notes="" sid="S-X-X-XX-XXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-XXXXX">

        <crosssitegroups />

        <sitegroups>

          <group name="Web Designer" />

        </sitegroups>

        <listpermissions />

      </user>

      <user loginname="NT AUTHORITY\authenticated users" displayname="Everyone in the company!" >

      <sitegroups>

       <group name="Contributor" />

      </sitegroups>

      </user>

    </web>

    <web url="https://dev.tailspintoys.com/subweb2" title="subweb2" description="" lcid="1033" template="STS" uniqueperms="True" acecount="1">

      <user loginname="tailspintoys\cgideon" displayname="Chris Gideon" email="cgideon@tailspintoys.com" notes="" sid="S-X-X-XX-XXXXXXXXX-XXXXXXXXX-XXXXXXXXXX-XXXXX">

        <crosssitegroups />

        <sitegroups>

          <group name="Web Designer" />

        </sitegroups>

        <listpermissions />

      </user>

      <user loginname="NT AUTHORITY\authenticated users" displayname="Everyone in the company!" >

      <sitegroups>

       <group name="Reader" />

      </sitegroups>

      </user>

    </web>

  </web>

</webs>

Notice that on subweb2 “NT Authority\Authenticated users” is NOT given the “Contributor” right. The purpose here is to show you that you can change the rights at any point. You can use a mix and match of additional <group> elements within the <sitegroups> and <crosssitegroups> containers if you wanted to add a user to multiple site groups. This minimal example is just to show you that it can be done.

Note: I would NOT recommend using NT Authority\Authenticated Users as a NT Security Group to use. It’s purpose of use in this post is for example purposes ONLY.

5. Use the add operation to add these users with their prescribed rights to SharePoint.

WSSUserUtil –o add –usermap singleuser.xml –webfile c:\addusers.xml -verbose

Note: The usermap operation is a required parameter even though is NOT used in the add operation. This is a small inconsistency that will be corrected at a later date.


In a future post I'll cover Auditing Rights with SPUserUtil to cover more on the analysis features.

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

 - Keith


For more information in regards to the Schema of the Various SharePoint Tables, see the Databases section in the SharePoint Products and Technologies SDK at:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/SPPTWSSDatabases_SV01072208.asp

For more information in regards to Managing Users and Cross Site Groups in SharePoint
https://office.microsoft.com/en-us/assistance/HA011608091033.aspx

SPUserUtil is contained in the The SharePoint Utility Suite at:
https://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724

For More information on the Windows SharePoint Services MigrateUserAccount() API:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsamSPGlobalAdminMigrateUserAccount_SV01234066.asp

For More information on the SharePoint Portal Server MigrateAccount() API:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/mPortalAccountMigManagerMigrateAccount2_SV01187841.asp

For more information on Windows SharePoint Services and SharePoint Portal Server 2003:
https://www.microsoft.com/sharepoint