Keith Richie : SPUserUtil

Thanks All! - The #1 download from the SharePoint Products and Technologies Web Component Directory is now The SharePoint Utility Suite

krichie — Fri, 25 Aug 2006 14:22:00 GMT

Thanks to everyone for helping make this happen by your suggestions and requests!

Sometime over the last couple of days, the SharePoint Utility Suite moved to the top of the Top Five Downloads (http://www.microsoft.com/sharepoint/downloads/components/results.asp?s=5 )

Thanks John Kozell for your contribution with the .Net Protocol Handler

Thanks Larry Kuhn for your contribution with the SharePoint Portal Server Search Property config

Thanks Dan Winter for your Refresh List contribution.

Thanks to Joel Oleson for recommending it as the #1 Must Have tool set!

Thanks to Chris Gideon and Raymond Hung for their contributions to making SPSiteManager even more powerful and useful than before!!!

SPSiteManager 2.2 is already proving great value with our customers with its new features (http://blogs.msdn.com/krichie/archive/2006/07/28/681634.aspx ), and I could not have done it without you. The updated Analysis and remedial features are helping our customers by identifying growth and usage trends; exceptions to Capacity Planning Guidelines, and improving Search Performance via its site directory and Deep Crawl list cleanup tools.

Not only are customers finding great value out of these tools for their existing Windows SharePoint Services and SharePoint Portal Server 2003 deployments, but they are also

using these tools for preparation for MOSS 2007 Upgrades

http://blogs.msdn.com/krichie/archive/2006/07/12/663278.aspx

Thanks again!

Keith Richie

Try the SharePoint Utility Suite at http://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724

"After Microsoft, I hope I'm remembered for more than just making one fine cup of coffee..."

SharePoint Account Management using SPUserUtil - Part 6 - Synchronizing Display Names and Email Addresses with Active Directory

krichie — Tue, 08 Aug 2006 01:27:00 GMT

SharePoint Account Management using SPUserUtil - Part 6 - Synchronizing Display Names and Email Addresses with Active Directory

Originally Posted as: Using SPUserUtil to synchronize SharePoint user Display Names and Email addresses with the information in Active Directory. Because of a ton of recent queries on this exact subject, I'm re-posting it but also re-titling it to include it in the "SharePoint Account Management using SPUserUtil series.

Note: 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.

Consider the following:

We have an account named MYDOMAIN\margie.murphy.
This account has permissions on various SharePoint sites.
This accounts NT Login Name changes to MYDOMAIN\margie.richie for one of many different reasons (In our scenario, Margie married a really cool guy with the last name of Richie :))
The NT Login Name for this account was synchronized with Active Directory using the steps provided in my previous post :) SharePoint Account Management using SPUserUtil - Part 6 - Handling NT Login Name Changes

SharePoint provides a feature for users to use different Display Names and Email addresses across the site collections they are members of. This information is cached in the tp_Title and tp_Email columns in the UserInfo table for every site collection in which the user has permissions. The individual user can update their information or the administrator can do it by visiting the siteusrs.aspx page for every site collection. This allows a user to utilize say, different email addresses for alerts on the same SharePoint Virtual Server but in different site collections. One scenario is where I may want to alert myself of changes to content on one site collection using my work email address, while content from another site collection should send alerts to my personal email address.

The problem with this, is that most enterprise customers I have worked with find this feature really annoying :). They prefer the users account display name and email address to be consistent to what the have established in their corporate environment, and it is an administrative nightmare to to update this information across literally 10's of 1000's of site collections. It also confuses users of SharePoint when their information changes (Say a contractor becomes a full time employee, etc). It can also cause administrative headache for administrators when they try to change security information on their sites (in some places we try to look up the account with the old NT Login Name). You can however, re-sync SharePoint with the current information in active directory by using SPUserUtil.

To perform this action, there are actually two different ways of accomplishing this.

Using the displayname= and email= attributes in the UserMap file

See my previous post (SharePoint Account Management using SPUserUtil - Part 5 - Handling NT Login Name Changes) to familiarize yourself with creating a proper UserMap file.

Set the displayname= and email= attributes appropriately, similar to the following example.

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilUserMapFile>

<users>

</users>

Run WSSUserUtil to update the information:

WSSUserUtil –o update –url http://myserver -usermap users.xml –ac

This will find the user on the site collections, and update the displayname and email address to what is defined in the XML file for the user.

Note: The –ac switch tells SPUserUtil to perform the operation on “ALL” site collections on the SharePoint Virtual Server. If you only wanted to perform it on the http://server/sites/thesite then remove the -ac switch and specify the site using the –url option.

Using the -adu switch to query AD for the current values

See my previous post (SharePoint Account Management using SPUserUtil - Part 5 - Handling NT Login Name Changes) to familiarize yourself with creating a proper UserMap file.

It is not necessary to specify or even include the displayname= and email= attributes using this method. All we need is the loginname= attribute as in the following example.

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilUserMapFile>

<users>

</users>

Run WSSUserUtil to update the accounts in the UserMap file with information from Active Directory:

WSSUserUtil –o update –url http://myserver -usermap users.xml –ac -adu

This will find the user on the site collections, and update the displayname and email address to what is currently set in Active Directory.
Note: In this example, I’m using the –adu switch. This tells SPUserUtil to lookup the displayname and email address from Active Directory, and bypass what is in the usermap file if it is defined. Again the –ac switch will perform the operation on all site collections.

It may seem silly to just go through all those steps for a single user, but if you need to do a batch of users, I personally think WSSUserUtil and SPSUserUtil is the way to go.

Try this out for fun, do it Wicked Kung Fu style

If you want to just update all the users across your entire SharePoint Virtual Server in one whopping swoop try the following (But be sure you have a backup first in case you don't like the results!!!)"

WSSUserUtil –o analyze –url http://myserver -usermap users.xml –asu -ac

Note: In this example, I’m using the –asu and -ac switch. This tells SPuserUtil to enumerate over All site collections and just dump what we find for all site collection users into the usermap. You don't need to specify the -r swtich (Recursive web dive) as we don't care where and what web they are actually on. The end result, is that we will get a unique record for every user found in the usermap across all site collections.

Then just issue the following command:

WSSUserUtil –o update –url http://myserver -usermap users.xml –ac -adu

And every single user defined in the users.xml file will be updated in SharePoint

Hope this helps!!!!

Keith Richie

Previous posts in this series:

Additional Reference Material:

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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/SPPTWSSDatabases_SV01072208.asp

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

For More information on the Windows SharePoint Services MigrateUserAccount() API:
http://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:
http://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:
http://www.microsoft.com/sharepoint

SharePoint Account Management using SPUserUtil - Part 5 - Handling NT Login Name Changes

krichie — Fri, 04 Aug 2006 17:36:00 GMT

SharePoint Account Management using SPUserUtil - Part 5 - Handling NT Login Name Changes

Originally Posted as: Using SPUserUtil to update accounts when the NT Login Name changes.Because of a ton of recent queries on this exact subject, I'm re-posting it but also re-titling it to include it in the "SharePoint Account Management using SPUserUtil..." series.

Consider the following:

We have an account named MYDOMAIN\margie.murphy.
This account has permissions on various SharePoint sites.
This accounts NT Login Name changes to MYDOMAIN\margie.richie for one of many different reasons (In our scenario, Margie married a really cool guy with the last name of Richie :))

The problem with this, is that the tp_Login column in the UserInfo table for every site collection in which Margie has permissions, is cached with her previous NT Login Name. There is also no way to update this information with a SPUser object from the SharePoint object model, and SharePoint does not synchronize this from Active Directory once the users is added to a web in the Site Collection.

The only time that SharePoint will automatically update the tp_Login column, is if the users is completely removed from the site collection. The tp_Deleted column is then set for the user in that site collection. On the next occurrence of the user being added to a web, we gather the current information from the domain. You can however, re-sync SharePoint with the current information without removing them completely from the site collection by using SPUserUtil

To perform this action, following these steps:

Prepare a SPUserUtil usermap file with a user element which has the loginname= and newloginname= attributes set accordingly.
loginname= should be the old NT Login Name as reflected in sharepoint. newloginname= should be the new user NT Login Name.
I actually recommend running a analyze of the site to get a complete list of all users. You can then use this file as a template.

For example:

WSSUserUtil –o analyze –url http://server/sites/site -usermap users.xml –asu

Note: The –asu switch means Give me All Site Users associated on the site collection, regardless if they have any direct ACE entries on any webs.

This will produce a listing of all users and generate the file users.xml. An additional file, users-webs.xml, will be generated that contains the web hierarchies and the location of user permissions on each web.

Here is an example of the output (Of course, your results will be different :)).

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilUserMapFile>

<users>

<user loginname="MYDOMAIN\margie.murphy" newloginname=""

displayname="Margie Murphy" email="margie.murphy@MYDOMAIN.com"

sid="S-1-5-21-5555555555-555555555-5555555555-1111" />

<user loginname="MYDOMAIN\Administrator" newloginname=""

displayname="" email=""

sid="S-1-5-21-4444444444-555555555-5555555555-500" />

<user loginname="MYPORTALSVR\administrator" newloginname=""

displayname="MYPORTALSVR\administrator" email="administrator@MYDOMAIN.com"

sid="S-1-5-21-3333333333-555555555-5555555555-500" />

</users>

Here is a version prepared to work on the user account in question.

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilUserMapFile>

<users>

</users>

With this file prepared, we can utilize the -o migrate operation of SPUserUtil to update the users NT Login Name.

Note: You are not truly migrating the user, but the MigrateUserAccount() functionality provided in Windows SharePoint Services SP2 and in the Post SP1 hotfix has a great side effect of being able to use it for NT Login Name updates. The LoginName field in the object model and in the SharePoint administration pages, is readonly. Using the MigrateUserAccount() api is the only supported way to update it.

When running the -o migrate operation using WSSUserUtil, it will read in and process all the user elements found in the xml file.

Note: You also have to specify the –ignoresidhistory option, otherwise the Migrate functionality will attempt to look at the target accounts SIDHistory attribute for the “source” accounts SID. This is a safety check when doing “Actual” user migrations. Since this is not a true User Migration, you'll want to specify -ignoresidhistory so this check is not performed.

For Example:

WSSUserUtil –o migrate –url http://myportalsvr/sites/site -usermap users.xml –ignoresidhistory

The users NT Login Name is now updated.

Using STSADM to update accounts when the NT Login Name changes

You can also perform this same process for a SINGLE user at a time using STSADM. For SharePoint Portal Server 2003 sites, you will have to use SPSUserUtil or your own custom code, as Portal does not provide an executable to perform this feature. The Post SP1 hotfix nor the SharePoint Portal Server 2003 SP2 provide an executable to provide this functionality.

For Example:

STSADM –o migrateuser –oldlogin MYDOMAIN\margie.murphy –newlogin MYDOMAIN\margie.richie –ignoresidhistory

Now that you have the NT Login Name changed, you might want to consider updating the Display Name and Email addresses for the user in case they have changed. For this, see my follow up posting here:

If you need to do a batch of users, I personally think WSSUserUtil and SPSUserUtil is the way to go.

Hope this helps!!!

Keith Richie

Previous posts in this series:

SharePoint Account Management using SPUserUtil - Part 0 - Removing Accounts
http://blogs.msdn.com/krichie/archive/2006/05/17/600040.aspx

SharePoint Account Management using SPUserUtil - Part 1 - Cloning Accounts
http://blogs.msdn.com/krichie/archive/2006/05/17/600218.aspx

SharePoint Account Management using SPUserUtil - Part 2 - Adding Accounts
http://blogs.msdn.com/krichie/archive/2006/05/19/602057.aspx

SharePoint Account Management using SPUserUtil - Part 3 - Auditing Accounts
http://blogs.msdn.com/krichie/archive/2006/05/22/604021.aspx

SharePoint Account Management using SPUserUtil - Part 4 - Replaying Permissions and Moving Webs
http://blogs.msdn.com/krichie/archive/2006/08/03/687850.aspx

Additional Reference Material:

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

For More information on the Windows SharePoint Services MigrateUserAccount() API:
http://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:
http://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:
http://www.microsoft.com/sharepoint

SharePoint Account Management using SPUserUtil - Part 4 - Replaying Permissions and Moving Webs

krichie — Thu, 03 Aug 2006 22:30:00 GMT

SharePoint Account Management using SPUserUtil - Part 4 - Replaying Permissions and Moving Webs

Originally posted as: Moving a web and preserving permissions using SPUserUtil. Because of a ton of recent queries on this exact subject, I'm re-posting it but also re-titling it to include it in the "SharePoint Account Management using SPUserUtil series.

Aside from user migrations, another issue where the SPUserUtil tools come in handy is with site relocations. I don’t mean Site Collection relocations, as you can easily use STSADM backup and restore for this, but rather “Web” site relocations within the Site Collection hierarchy, or to another server in general. You can't use STSADM backup/restore to accomplish this task, as STSADM does not allow granular level web relocations. (This applies to Windows SharePoint Services 2.0 and SharePoint Portal Server 2003. Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 allow you to do this with STSADM, so there's some improvements with the next version :))

Consider the following two requirements:

In your organization, it is deemed that a particular sub-web of a site collection is growing beyond the quota or scalability limits imposed by the site collection it belongs in. The sub-web needs to be placed into it’s own site collection.
Based on corporate needs, a sub-web needs to be moved into a different location within the URL namespace of a SharePoint server.

In order to accomplish those goals, you have to use SMIGRATE to export the data, and then import the data in a different location. When using SMIGRATE to export/import site data, the security information is not captured and is lost. But, using SPUserUtil, you can preserve and re-play the security information after the move has occurred. You can also use this same method to just replay a set of permissions onto a new web or entire site collection.

The steps to accomplish this are broken down as follows:

Collect the webs current security map
Export the web data to disk
Provision space for a new site collection or new web location
Import the web data into the new location
Prepare updated security map
Reapply permissions
Remove the previous web.

The following sections will detail the steps above as an aid to help you in preparing your site relocation plan. Since we’re speaking of Team Sites, we’ll be using WSSUserUtil. In our theoretical scenario, the HR sub web of our divisions site collection on our SharePoint site at http://server/divisions/hr has grown beyond it’s previous requirements, and it was deemed necessary to move it into it’s own “Human Resources” site collection. We’ll create the new site collection at http://server/sites/hr

Collect the webs current security map

When an SPUserUtil analyze operation is run, there are actually two files generated, the user map and the webs manifest file. (See the SPUserUtil documentations description for the analyze operation.) The Webs Manifest file is the key file used for re-applying permissions on a web. If you do not specify the name of the web manifest, one will automatically be created for you using the name portion of the User Manifest File, and appended with “-webs”. For example, if you specify –usermap c:\portalusers.xml, a file named c:\portalusers-webs.xml will be created for the webs manifest.

The first step to perform is generating a webs manifest file using the analyze operation such as the following:

WSSUserUtil -o analyze -url http://localhost/divisions/hr -r -usermap c:\hr.xml

This creates two files, the hr.xml file which contains our user map of unique users found on the site, and the hr-webs.xml file which contains our Web Manifest file. We used the -r switch to analyze recursively down the web heirarchy from the point of the hr web. The end result in our test case looks something similar to the following:

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilWebFile>

<webs>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</web>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</web>

</webs>

Something to consider in a later step, is that from reviewing the data above, note that there are actually two sub-webs underneath the /hr/ web. One of the sub-webs is named Benefits, the other named Legal. If you look closer you’ll notice that the Legal sub-web is using unique permissions, but the Benefits sub-web is not, thus inheriting it's permissions from the /hr/ web. SPUserUtil currently just writes out the permission set it finds for the web, regardless if it is inheriting or not. This gives you a complete XML section for that web, and it's security, in case you have to strip it out and re-use it later.

Also take note, that the current version of the SPUserUtil tools does not differentiate between a User Account, and a Group Account. The NA\EditorGroup in the above XML actually refers to a Security Group. A later version of SPUserUtil will help differentiate the difference.

Export the web data to disk

Once you have preserved your current security map, the next step is to actually export the data using the SMIGRATE tool.

smigrate -w http://localhost/divisions/hr -f f:\moveweb\hr.mig

This creates an export of your webs data. Since we did not specify the –e option, this export file contains the hr web and all of its sub-webs. For more information on the SMIGRATE tool, please refer to the Windows SharePoint Services documentation.

Provision space for a new site collection or web location

You can use either the Windows SharePoint Services Central Administration UI pages, or STSADM to provision a new site collection or provision a new web in an existing site collection. In our example, we’ll use STSADM as follows:

stsadm -o createsite -url http://localhost/sites/hr -ownerlogin YOURDOMAIN\YOUROWNER -owneremail yourowner@yourdomain.com

This command provisions new space for a site collection and creates a top level site, yet no template is currently chosen for the site. Choosing a template is not needed for this process. For more information on the STSADM tool, please refer to the Windows SharePoint Services documentation.

If instead, you need to move a web to a new location within the same site collection, use STSADM in the following fashion

stsadm -o createweb -url http://localhost/divisions/newlocation/hr

Import the web data into the new location

We’ll use the SMIGRATE tool once again to import the saved data into the new site collection

smigrate -r -w http://localhost/sites/hr -f f:\moveweb\hr.mig

This imports the web data contained in the hr.mig file into the site collection at web location provided. For more information on the SMIGRATE tool, please refer to the Windows SharePoint Services documentation.

Prepare updated security map

Before re-applying permissions, it’s important to understand that when using the add operation, we key off of the url attribute for each web element in the webs manifest file in order to apply permissions. In other words, this is the URL used to open a web context to, to then apply the permissions. In it’s current state, the add operation would try to open the previous locations of the webs and try to re-add the permissions, which of course would not have the desired results J. So, we need to update hr-webs.xml to match the new location for the webs.

Notice in the copy of hr-webs.xml above, the url attribute of each web element points to http://localhost/divisions/hr/... The easiest way to update this file, is simply change all references of http://localhost/divisions/hr/ to http://localhost/sites/hr/. Since we’re not going to modify any of the permissions themselves, and just re-play the permission map onto the webs, we’re ALMOST ready to go.

SPUserUtil currently has one limitation that requires you to make a slight change to your imported webs in the site collection. When running SMIGRATE to import web site data, each subweb is set to re-inherit permissions from each parent, thus any webs which had the “Use unique permissions” flag set, are set back to always inherit. SPUserUtil currently does not care if the web inherits permissions or not when using the add operation, so it’s necessary to either:

Remove the <web> element for the sub-web that is going to inherit from it’s parent, or
change the web site to use unique permissions.

Refer to the Windows SharePoint Services documentation for the steps to disable security inheritance.

Which ever choice you decide to make, is up to you. A future version of SPUserUtil will have options to “Re-set” inheritance etc based on the uniqueperms attribute in the manifest file.

You could also use this time to make adjustments to the user elements for each web, but that is beyond the scope of this tutorial.

Reapply permissions

With our updated hr-webs.xml manifest file in hand, let’s now run WSSUserUtil using the add operation to re-apply the permissions back onto our migrated web hierarchy.

wssuserutil -o add -url http://localhost/sites/hr -webfile f:\moveweb\hr-webs.xml

The above command will enumerate over each <web> element found in the manifest file, and apply the permissions as noted in the file.

Remove the previous web

After you have re-applied permissions, validate everything is correct and then remove the old webs from their current site collection

If the web you are deleting did not have sub-webs, you could easily use STSADM to accomplish this task using the following command line:

stsadm -o deleteweb -url http://localhost/divisions/hr

The problem with this, is that it will error out, as you cannot delete a web which currently has sub-webs. You would have to issue the command for each sub-web, then finally remove the parent web, such as:

stsadm -o deleteweb -url http://localhost/divisions/hr/Benefits

stsadm -o deleteweb -url http://localhost/divisions/hr/Legal

stsadm -o deleteweb -url http://localhost/divisions/hr

If you have a lot of nested sub-webs, it could be fairly time consuming.

The SharePoint Utility Suite at http://www.microsoft.com/sharepoint/downloads/components/detail.asp?a=724 has a tool call SPPruneWeb that was designed just for this purpose. It will traverse a web hierarchy and remove all child webs from the specified parent then remove the parent web you specified. More information on SPPruneWeb can be found in the SharePoint Utility Suite documentation included in the package above.

Hope this helps!

- Keith Richie

Previous posts in this series:

Additional Reference Material:

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

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

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

The SharePoint Utility Suite recommended as number 1 tool kit of “must haves” !! Thanks Joel!

krichie — Thu, 27 Jul 2006 01:04:00 GMT

Joel Oleson has the following to say in his Top 10 and a few "MUST HAVE" Management Tools for WSS v2 & SPS 2003 posting about the tools I've been writing:

Site, Database & User Management

SharePoint Utility Suite v2.5 – User, Site, & Database Manager & Analyzer

Keith Richie has put in some huge investments to make the life of the IT Pro easier. This is my number 1 tool on the this list of “must haves”. Use it for Sites, Users, and managing databases. Don’t forget to use this to move subsites, My sites, and move users between domains… This stuff is incredible. He’s now working on the next rev of this and other cool stuff. I recommend following his blog.

Thanks Joel!!

deletecollection bug in SPUserUtil 2.5 - fix described

krichie — Mon, 24 Jul 2006 23:45:00 GMT

Someone noted this problem to me, and I just confirmed it to be a bug with the deletecollection operation in SPUserUtil.

The problem is that regardless of what you have specified in your usermap file when you run the deletecollection operation, it removes more users than you specified.

This is fixed in the current build, but in the released version in the utility suite, you'll need to make this slight correction:

In the file WebUserUtil.cs, in the method DeleteSiteUsers(), make the following change as noted in "Bug fix 07/24/2006"

/// <summary>

/// Removes any users found in the usermap from the specified site.

/// </summary>

/// <param name="site"></param>

/// <returns></returns>

public int DeleteSiteUsers(SPSite site)

{

int iUser = 0;

bool bContinue = false;

Logging.Information("Deleting users from Site Collection");

try

{

iUser = site.RootWeb.SiteUsers.Count;

while (--iUser >= 0)

{

// BEGIN Bug fix 07/24/2006

// Reset continue boolean.

bContinue = false;

// END Bug fix 07/24/2006

SPUser user = site.RootWeb.SiteUsers[iUser]; // Can't use the itterator (foreach) while I'm deleting users.

if(m_Options.strUserMapFileName != null)

{

UserMapItem uMap = getUserMap(user.LoginName); // See if this is a migrating user.

if(uMap != null)

bContinue=true;

}

...

- Keith

SharePoint Account Management using SPUserUtil - Part 3 - Auditing Accounts

krichie — Mon, 22 May 2006 22:15:00 GMT

SharePoint Account Management using SPUserUtil - Part 3 - Auditing 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.

I went back and renamed some of the previous posts I had written about SharePoint Account Management to reflect that these are all really within the realm of SharePoitn Account Management, and each post covers a specific aspect of such.

In fact, the oldest post is now called "Part 0" :)

For a recap (And to unravel any confusion this may have caused :)), here is the series so far.

In this post, I'll show you the many different ways you can use SPUserUtil to audit accounts in your SharePoint environment

Out of Box methods for auditing accounts

The OOB (Out of Box) way to currently audit security principals on your sites and webs is to visit each respective site collection or web and look at their corresponding users list. But nothing (outside of purchasing a third party tool) gives you the ability to quickly audit for users and groups across site collections and webs.

Out of Box methods for auditing accounts

Auditing accounts for a web through the UI

If you just want to view the current account rights on a web, you simply need to access the "Manage Users" page for the web in question. The navigation path to this page (for Windows SharePoint Services) is:

From the home page of the site, click "Site Settings" on the top navigation bar
Click "Manage Users"

If you have removed the navigation bar on your site, or you want to just jump right to the page, you can access it by navigating to the users.aspx layouts page directly in your browser. For example:

http://server/sites/asite/asubweb/_layouts/1033/user.aspx

This will take you to the "Manage Users" page for the subweb named "asubweb" underneath the top level site "asite" within the managed path "sites" on the "server" in question.

From this page, you can view the account resources on the web. If you have many accounts, you will need to click on the previous and next links on this page to paginate through the list of accounts.

Note: Keep in mind, that the Windows SharePoint Services Capacity Planing Guide states that the The size of the access control list is limited to a few thousand security principals, in other words users and groups in the Web site. The Guideline for optimum performance is 2000. If you need to utilize more than 2000 individual security principals, consider using NT Security Groups, as I have seen many customer experience problems when they exceed these guidelines. SPSiteManager (Also located in the SharePoint Utility Suite) can assist you in detecting and reporting where you have exceeded this capacity planning guideline.

Auditing accounts for a site collection through the UI

If you want to audit accounts that have access from a site collection perspective you simply need to access the "Manage Site Collection Users" page for the site collection in question. The navigation path to this page (for Windows SharePoint Services) is:

From the home page of the site, click "Site Settings" on the top navigation bar
Click "Go to Site Administration"
Click "Go to Top-level Site Administration"
Click "View site collection user information"

If you have removed the navigation bar on your site, or you want to just jump right to the page, you can access it by navigating to the siteusrs.aspx layouts page directly in your browser. For example:

http://server/sites/asite/_layouts/1033/siteusrs.aspx

This will take you to the "Manage Site Collection Users" page for the site collection whose top level site is "asite" within the managed path "sites" on the "server" in question.

From this page, you can view the account resources at the site collection scope which shows you all users who have at least Guest rights on a web within the site collection. This shows you a concise list of all users whom have hit a web within the site collection. If you have many accounts, you will need to click on the previous and next links on this page to paginate through the list of accounts.

Cumbersome Problem Number 1

This becomes an administrative headache if you have 100's or 1000's of account resources on your webs or sites, in which case you have to paginate through all these resources on either the users.aspx page or the siteusrs.aspx pages, to "find" an account.

Cumbersome Problem Number 2

If you have 100's or 1000's of site collections, it makes it nearly impossible to find what sites and webs a given account has, or ever had, access to.

SPUserUtil to the rescue.

You can use the analyze operation of SPUserUtil to analyze a Windows SharePoint Services web or SharePoint Portal Server Portal for auditing purposes. This operation will scan your targeted URL and produce two files (the user map and the webs manifest file) which can be used for security audit reviews.

You can adjust the scope of this analysis to a single web, a series of webs, a complete site collection, or multiple site collections on a specified virtual server.

The Webs Manifest (depending on your analysis scope) can give you a holistic view of user security across your SharePoint farm.

Note: SPUserUtil and SPSiteManager are being merged into one all encompassing tool. This will give you the added benefit of taking advantage of the SPSiteManager SDD (Site Distribution Document) as well as the ability to scan multiple virtual servers at once for auditing purposes.

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

Auditing accounts for a web using SPUserUtil

By Using the analyze operation in SPUserUtil, it's extremely easy to analyze a single web, or multiple webs and produce a file in XML that can be used with any tool capable of displaying XML to audit user rights.

For example:

wssuserutil -o analyze -url http://server/sites/asite -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml

This example starts its analysis at the web/site designated by –url, and scans all subwebs recursively underneath which results in producing two files as noted below:

UserMap file

The UserMap file will contain a distinct list of unique users found within the scope of the analysis operation

Webs Manifest File

This file gives you a complete hierarchical view of the webs and their individual rights on each.

For example:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE SPUserUtilWebFile>

<webs>
<web url="http://myserver/sites/artists" title="Artists Site"
description="Cool Artists Web" lcid="1033" template="STS" uniqueperms="True">
    <user loginname="MUSIC\edgarf" displayname="Edgar Frose" email="edgarf@tangerinedream.org" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" >
      <crosssitegroups />
      <sitegroups>
        <group name="Contributor" />
      </sitegroups>
      <listpermissions />
    </user>
    <user loginname="MUSIC\cfranke" displayname="Christopher Franke" email="cfranke@sonicimages.com" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" >
      <crosssitegroups />
      <sitegroups>
        <group name="Contributor" />
      </sitegroups>
      <listpermissions />
    </user>
    <web url="http://myserver/sites/artists/movies" title="Movies Subweb" description="This site contains information related to movies" lcid="1033" template="STS" uniqueperms="True">
      <user loginname="HOLLYWOOD\bwillis" displayname="Bruce Willis" email="bwillis@hollywood.com" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" >
        <crosssitegroups />
        <sitegroups>
          <group name="Contributor" />
        </sitegroups>
        <listpermissions />
      </user>
      <user loginname="HOLLYWOOD\glucas" displayname="George Lucas" email="glucas@hollywood.com" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" >
        <crosssitegroups />
        <sitegroups>
          <group name="Contributor" />
        </sitegroups>
        <listpermissions />
      </user>
    </web>
</web>
</webs>

Notice that for each web found within the scan, an individual <user> element is written for each security principal found. Each <user> element will contain a <crosssitegroups> and <sitegroups> container that may contain a list of Cross Site Groups or Site Groups the security principal is in. These individual groups will be noted by a <group> element with each respectively.

Also, for each document library or list where you have explicit permissions set, you'll see a <list> entry within the <listpermissions> container with the title of the list/document library and the permission mask.

The web manifest file only shows the accounts which currently have permissions on sites/webs detected in the scan, but does not have the complete list of users that may exist in the site collection, and thus the usermap will only reflect those users. If you want to see a complete unique list of accounts that have ever hit the site collection (and were not removed from the site collection) use the -asu or -asuonly switch.

The -asu switch causes the usermap to be populated with the complete list of Site Collection users regardless if they currently have permissions on a web or not. When using this switch, we write out all the site collection users, then proceed to do the normal web analysis.

The -asuonly switch performs the same function as the -asu switch, but bypasses the web scanning to create the web manifests file.

If you don't specify a -webfile switch, a webs manifest file is still created for you using the name of the usermap appended with "-webs" in the filename.

Auditing accounts for a site collection using SPUserUtil

In the example in the previous section, asite is the top level site in the site collection, thus the complete site collection was analyzed with the above example. If you wanted to analyze every single site collection on a virtual server, add the -ac switch

For example:

wssuserutil -o analyze -url http://server/sites/asite -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml -ac

Even though the above example still specifies a direct site collection in the -url, by specifying the -ac (All Collections) switch we simply connect to the virtual server for the URL, and analyze every Site Collection found for the virtual server.

In this case, the usermap will contain a distinct list of users detected in the scan by distinct across the entire virtual server for all site collections.

The Webs Manifest file will also have a top level <web> element for each site collection found within the <webs> container.

Auditing a single account across the farm using SPUserUtil

In this example, we'll use the -usermask switch to filter the analysis down to a single account, or find accounts using a given mask

For example to scan an entire virtual server to determine where a specific user has rights:

wssuserutil -o analyze -url http://server -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml -ac -usermask "TAILSPINTOYS\krichie"

This will produce a webs manifest file, but only the account TAILSPINTOYS\krichie will be reported on.

If I wanted to filter for accounts only matching a portion of the login name, say perhaps all users from the WINGTIPTOYS domain

wssuserutil -o analyze -url http://server -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml -ac -usermask "*WINGTIPTOYS*"

This will produce a webs manifest file, but only report on accounts which have WINGTIPTOYS within the login name

You would repeat this process for each virtual server in your farm to get a complete list of account right locations through your farm.

Note: Once the merge of functionality of SPUserUtil and SPSiteManager is complete, the resulting output will not include the nested webs when filtering on specific account masks as it does now. The way SPUserUtil works in it's current iteration, you could have many <web> elements and nested <web> elements in the resulting file for your entire farm, even though the account only exists on one web.

I hope you see the benefit in the auditing capabilities of SPUserUtil. Our goal is to improve this experience in the next release of this tool set. If you have any questions or comments, please let me know!

- 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:
http://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
http://office.microsoft.com/en-us/assistance/HA011608091033.aspx

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

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

SharePoint Account Management using SPUserUtil - Part 2 - Adding Accounts

krichie — Fri, 19 May 2006 22:10:00 GMT

SharePoint Account Management using SPUserUtil - Part 2 - Adding Accounts

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:

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 http://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>

<webs>

</sitegroups>

</user>

</sitegroups>

</user>

</web>

</sitegroups>

</user>

</web>

</webs>

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

Copied the singleuser-webs.xml file to addusers.xml
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”
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>

<webs>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</sitegroups>

</user>

</web>

</sitegroups>

</user>

</sitegroups>

</user>

</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 Managing Users and Cross Site Groups in SharePoint
http://office.microsoft.com/en-us/assistance/HA011608091033.aspx

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

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

SharePoint Account Management using SPUserUtil - Part 1 - Cloning Accounts

krichie — Wed, 17 May 2006 22:15:00 GMT

SharePoint Account Management using SPUserUtil - Part 1 - Cloning Accounts

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:

Figure out exactly what you have access to across the farms you have access to :)
Note your individual user Role/Rights where you have an individual ACE entry on a a site/web/
Note the groups you are a member of and that groups Role/Rights on every single web, etc.
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.

SPUserUtil to the rescue.

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:

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>



<users>

<user loginname="MYDOMAIN\margie.richie" newloginname="" />

</users>

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

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilUserMapFile>

<users>

</users>

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

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

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

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

SharePoint Account Management using SPUserUtil - Part 0 - Removing Accounts

krichie — Wed, 17 May 2006 19:26:00 GMT

SharePoint Account Management using SPUserUtil - Part 0 - Removing Accounts

There are many ways to remove an NT account resource (User or Security Group) from a SharePoint resource. You remove an account resource at the web level, or the site collection level.

Considerations

Consider an account resource which only permissions on one web within a site collection. In this scenario if the account resource only had permissions on one single web in the site collection, it's easy to just navigate to that one web and remove it.

If the account resource had permissions on a lot of webs in the site collection, you can just visit the siteusrs.aspx page for the site collection and remove it from there. When you do this, it completely removes the account resource from the site collection as a whole, thus removing all references to the resource on any web they exist on.

If you don't want to just mass remove the resource from the site collection in whole, but only want to remove a resource from multiple webs in a site collection, you have to visit each web and remove the resource manually for each one.

I'll detail each of these OOB (Out of Box) methods further down, then detail how to do the same process (which I believe is easier) using SPUserUtil

It's not a bug :)

When an account resource is deleted from Active Directory or NT, SharePoint does not automatically remove the account resource information from it's sites and webs. This is not a SharePoint problem, as the same issue exists on any other NTFS resource. For example, a folder on your PC, or a file share on the network.

For the most part, most administrators don't worry too much about cleaning up dead account resources from NTFS resources, as those accounts ARE deleted from AD, and can never compromise security...They're just (for the lack of better words) orphaned ACE's on the resource.

When you do decide to remove the account resource, it's pretty easy to just bring up the resources properties dialog....Scroll down to the orphaned ACE, and remove it.

For SharePoint on the other hand, it is quite cumbersome because you have to paginate over, and over, and over, and over until you get to the account resource in question to remove the ACE.

Basic scenario

A user in your enterprise is terminated, or departs on his own free will :) You need to either

Remove the user from SharePoint Sites.
Transfer Ownership of SharePoint sites/webs/etc to another individual or

This post will deal with simply removing the user completely. We'll cover ownership transfer in a future post.

Leaving the user information on the sites doesn't necessarily present a problem, but it can be an administrative headache. I have seen a few reports that when trying to remove users from Portal areas, that it balks because it still tries to do a domain lookup on the user when you're deleting them. If you have a repro of that, you should call Customer Support Services if it is preventing you performing your administrative task.

Out of Box methods for removing users

Removing a single resource from a web through the UI

If you just want to remove an account resource from a web (whether the account resource is deleted or not), you simply need to access the "Manage Users" page for the web in question. The navigation path to this page (for Windows SharePoint Services) is:

From the home page of the site, click "Site Settings" on the top navigation bar
Click "Manage Users"

If you have removed the navigation bar on your site, or you want to just jump right to the page, you can access it by navigating to the users.aspx layouts page directly in your browser. For example:

http://server/sites/asite/asubweb/_layouts/1033/user.aspx

This will take you to the "Manage Users" page for the subweb named "asubweb" underneath the top level site "asite" within the managed path "sites" on the "server" in question.

From this page, you simply select the users/groups you want to remove via the check box next to each resource, then select the "Remove Selected Users" link.

This removes an account resource from this web only. If you need to remove this user from multiple webs, follow the same process noted above for each web.

Removing a single resource from a web using STSADM

You can simplify the process by using STSADM if you have sufficient rights using the deleteuser operation.

stsadm.exe -o deleteuser url http://server/asite/asubweb userlogin DOMAIN1\AUser

This removes an account resource from this web only. If you need to remove this user from multiple webs, follow the same process noted above for each web.

For more information on STSADM operations, see: http://office.microsoft.com/en-us/assistance/HA011608091033.aspx

Removing a single resource from a site collection

Removing a single resource from a web, DOES NOT remove them entirely from the site collection, even if the account resource only had permissions on the single web in the site collection from which you just removed them. For some of the reasons why, see my previous blog post about Using SPUserUtil to synchronize SharePoint user Display Names and Email addresses with the information in Active Directory.

If you want to remove a single resource from an entire site collection (whether the account resource is deleted or not) you simply need to access the "Manage Site Collection Users" page for the site collection in question. The navigation path to this page (for Windows SharePoint Services) is:

From the home page of the site, click "Site Settings" on the top navigation bar
Click "Go to Site Administration"
Click "Go to Top-level Site Administration"
Click "View site collection user information"

http://server/sites/asite/_layouts/1033/siteusrs.aspx

This will take you to the "Manage Site Collection Users" page for the site collection whose top level site is "asite" within the managed path "sites" on the "server" in question.

From this page, you simply select the users/groups you want to remove via the check box next to each resource, then select the "Remove Selected Users" link.

This removes an account resource from this site collection only. If you need to remove this user from multiple site collections, follow the same process noted above for each site collection.

There is no equivalent STSADM operation (such as seleteuser noted above) to remove a user from the entire site collection

Cumbersome Problem Number 1

This becomes an administrative headache if you have 100's of account resources on your webs or sites, in which case you have to paginate through all these resources on either the users.aspx page or the siteusrs.aspx pages, to get to the resource in question so you can mark them for deletion. You could certainly script it using the deleteuser operation for STSADM, but this does not remove them from the site collection.

Cumbersome Problem Number 2

As noted above, scripting calls to STSADM can still be cumbersome, as you would have to run it on every single web in your entire farm to remove the user from the webs. Since there is no STSADM equivelant for removing users from the entire site collection, you have to manually visit each site collection in your farm (There could be literally 10's of thousands of site collections) to remove the user.

SPUserUtil to the rescue.

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

Removing a single resource from a web or series of webs using SPUserUtil.

If you just want to remove an account resource from a web (whether the account resource is deleted or not), using SPUserUtil, following these steps:

Prepare a SPUserUtil usermap file with a user element which has the loginname= attribute set accordingly.
loginname= should be the NT Login Name as reflected in SharePoint.
I actually recommend running a analyze of the site to get a complete list of all users. You can then use this file as a template.

For example:

WSSUserUtil –o analyze –url http://server/sites/site -usermap users.xml –asu

Note: The –asu switch means Give me All Site Users associated on the site collection, regardless if they have any direct ACE entries on any webs.

This will produce a listing of all users and generate the file users.xml. An additional file, users-webs.xml, will be generated that contains the web hierarchies and the location of user permissions on each web.

Here is an example of the output (Of course, your results will be different :)).

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilUserMapFile>

<users>

<user loginname="MYDOMAIN\margie.murphy" newloginname=""

displayname="Margie Murphy" email="margie.murphy@MYDOMAIN.com"

sid="S-1-5-21-5555555555-555555555-5555555555-1111" />

<user loginname="MYDOMAIN\Administrator" newloginname=""

displayname="" email=""

sid="S-1-5-21-4444444444-555555555-5555555555-500" />

<user loginname="MYPORTALSVR\administrator" newloginname=""

displayname="MYPORTALSVR\administrator" email="administrator@MYDOMAIN.com"

sid="S-1-5-21-3333333333-555555555-5555555555-500" />

</users>

Here is a version prepared to work on a single user account. (Note: the account listed below would NEVER be deleted from my world :))

<?xml version="1.0" standalone="no"?>

<!DOCTYPE SPUserUtilUserMapFile>

<users>

</users>

It's actually much easier than that in the current release of SPUserUtil. With this updated version there is a new usermask switch that will filter down to a specific user. For example:

WSSUserUtil –o analyze –url http://server/sites/site -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).

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.

With this file prepared, we can utilize the -o delete operation of SPUserUtil to delete a user from a web, or series of webs

When running the -o delete operation using WSSUserUtil, it will read in and process all the user elements found in the xml file.

For Example:

WSSUserUtil –o delete –url http://server/sites/asite/asubweb -usermap users.xml

Every single user found in the users.xml file will be removed from the web pointed at by the -url switch.
If you want to recursively remove the user from the web and all of it's subwebs, use the -r switch.

For Example:

WSSUserUtil –o delete –url http://server/sites/asite/asubweb -usermap users.xml -r

Every single user found in the users.xml file will be removed from the web pointed at by the -url switch and all of it's sub webs.

Much easier than using the UI or STSADM -o deleteuser for every web.

Removing a single resource from a site collection using SPUserUtil

If you just want to remove an account resource from a site collection (whether the account resource is deleted or not), using SPUserUtil, following these steps:

Prepare you list of users as noted in the previous section
Run SPUserUtil with the -o deletecollection operation using WSSUserUtil, it will read in and process all the user elements found in the xml file.

WSSUserUtil –o deletecollection –url http://server/sites/asite -usermap users.xml

Every single user found in the users.xml file will be removed from the site collection pointed at by the -url switch.
To remove a user from every single site collection on a virtual server:
WSSUserUtil –o deletecollection –url http://server -usermap users.xml -ac

Every single user found in the users.xml file will be removed from every site collection on the virtual server specified using the -url switch.

Purging all those deleted accounts

So you've discovered that a deleted account resource (Either a User or Security Group) currently has permissions on a web or site in your environment and you want to remove them completely. With the above information in hand, the following short list of steps using SPUserUtil should to the trick.

Generate a valid usermap for a single resource or multiple resources
a) Generate a usermap for a single resource

    WSSUserUtil –o analyze –url http://server/sites/site -usermap singleuser.xml -asuonly -usermask "*krichie*"

b) Generate a usermap for alot of resrouces

    Either run an analyze operation:

    WSSUserUtil –o analyze –url http://server/sites/site -asuonly -usermap users.xml

    And trim out the users you don't want to operate on.

c) Or Create and additional <user> element in the UserMap for each account in question.
Run WSSUserUtil with the deletecollection operation and the -ac switch to completely purge the user from ALL site collections on the virtual server.

WSSUserUtil –o deletecollection –url http://server -usermap users.xml -ac
Repeat step 2 for each virtual server

Note: Like SPSiteManager, there WILL be an -allvs switch added in later that will allow you to perform all operations across all virtual servers, etc, in a future version. That would make the process even simpler by executing a command such as the following:

WSSUserUtil –o deletecollection –allvs -usermap users.xml -ac

My next postings will be about Ownership transfers and Adding accounts en-masse, Brahahahahahha (I'm feeling like a mad scientist right now :))

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

- Keith

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

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

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

SharePoint blog ideas

krichie — Wed, 17 May 2006 06:58:00 GMT

Man time flies.

I'm finally getting to the point where I'm going to have some time to actually start working alot heavier on my User Management training. I dug around for the old post where I outlined this and see that it was WAY back in January!!

I'm also working on an update to my previous post about Moving a web and preserving permissions using SPUserUtil. This update will include steps on completely moving a subweb into a new site collection, in a new content database. I probably should have noted in that previous post that the steps are pretty much exactly the same...You just create the content database first, but there's a "Few" more steps than that, so expect a Part 2 coming soon.

Part of the delay boils down to the following specific details:

I've been freakin' busy!
I was pushing hard to get the 2.5 release of the Utility Suite out the door.
My team and I have been troubleshooting WAY too many reactive issues recently such as process crashes, perf issues, etc, etc, etc (BTW We've been using SPSiteManager ALOT to help us identify perf issues...It's amazing how cool this thing is turning out to be)
The next wave of SharePoint technologies, is just going to be simply BIG, COOL, and the absolute ShizNit IMHO.

Regardless, I have a list of topics I want to blog about. Some related to Windows SharePoint Services 2.0/SharePoint Portal Server 2003, and then All new SharePoint 2007 stuff as we move further along the road to RTM.

First up is going to be some sample blogs of how to "View" the SPSiteManager analysis data. I had to leave some blanks in the SPSiteManager scenario sections of the documentation titled <details coming soon>, like I had to do with SPUserUtil when I released it. (Sorry, but it's not my full time job :)). And also on some simple re-partitioning operations surrounding that, such as:

Analysis Scenario to help determine needs for site restructuring.
Backup sites based on mask
Delete/Purge sites based on mask
Site re-partitioning

Move a single site into a new content database
Move a series of sites into various content databases using a SDD

These will also set the stage for future posts in regards to the same subject matter for SharePoint 2007.

These are GOING to happen :) I promise.

- Keith

It's Live! The SharePoint Utility Suite release 2.5 is now live!

krichie — Thu, 27 Apr 2006 04:17:00 GMT

It took a few days :) But it's finally live.

Download the 2.5 version now! http://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724

For quick details on this release:
Announcing the SharePoint Utility Suite Release 2.5

- Keith

The Next Big Thing - The SharePoint Configuration Analyzer V.Next

krichie — Fri, 21 Apr 2006 18:13:00 GMT

Yesterday, I did a quick presentation on the new analysis features in SPSiteManager (See attached PPT to this post)

Those of you following my blog may have noticed that I have stated a few times that SPSiteManager, SPUserUtil, etc.. were going to be combined into one tool in the future which I eluded to as the "Next Big Thing". At the end of the attached PPT, I made that annoucement on what that "Next Big Thing" is all about.

For those who don't have PowerPoint, or the PowerPoint viewer, let me just state it here :)

nThe Future of SPSiteManager

We will be rolling in all the following functionality into a future version of the SharePoint Configuration Analyzer

See §http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=183 for some forward thinking on this as well as what's noted in the PPT and noted here:

§Integrate SPUserUtil features
§Integrate SPSiteBuilder features
§Integrate functionality of SPReports

http://www.gotdotnet.com/workspaces/workspace.aspx?id=8eb2bfa3-aac8-4b5a-b3a2-5accb29970eb

§List and Document Library “Split” option to aid when lists and document libraries were detected that exceed capacity planning guidelines.
§Web Part discovery across the farm. §Lots and Lots of feature requests that were punted previously J

The SharePoint Configuration Analyzer

The SharePoint Configuration Analyzer is a tool that you can download from the Microsoft Download Center to analyze and report on your Microsoft Windows SharePoint Services installation and content. SharePoint Configuration Analyzer reports on a wide range of configuration errors and also copies a set of log files, configuration files, and other data to a results folder for further analysis or archiving.

SharePoint Configuration Analyzer is particularly useful for analyzing and troubleshooting Web Parts on your servers. For example, you can configure SharePoint Configuration Analyzer to list each Web Part installed on a virtual server and to report on all of the pages that contain an instance of each Web Part. This is useful when upgrading a Web Part to a newer version or when deleting a Web Part. Before upgrading or deleting the Web Part, run SharePoint Configuration Analyzer with these options selected. Then, by using the usage data, contact all owners of pages containing the Web Part you are about to upgrade or remove, giving them notice of the impending change.

Note: SharePoint Configuration Analyzer is not supported, and is available as is. It does not change the state of your Windows SharePoint Services nor does it repair errors that it reports. SharePoint Configurration Analyzer only copies its analysis results, along with any configuration files, log files, or other data that you requested, to its results folder, as described in this topic and in the SharePoint Configuration Analyzer Help.

SPReports integration

SPReport is a command-line utility that gathers metrics about a site and its subsites, the document library and other lists in each site, and the documents in each document library.

SPReport uses the SharePoint object model to retrieve information about the current configuration and hence, the tool needs to be run locally from a SharePoint Web front-end server. The current version of SPReport cannot be run remotely.

The current release of SPReports is located at: http://www.gotdotnet.com/workspaces/workspace.aspx?id=8eb2bfa3-aac8-4b5a-b3a2-5accb29970eb

As you can see, there is a lot of overlap between the SharePoint Configuration Analyzer, SPSiteManager, and SPReports.

Each tool noted above grabs a bit of data from here and there, and we've found that most of our customers use a combination of all these tools for all their internal reporting, etc.

We had to write and update SPSiteManager to grab data that was needed because of the lack some metrics in everything we've seen.

Maurice and I have talked about combining and taking SCA to the next level for over a year now, and we think that updating the SharePoint Configuration Analyzer with all this work is the best combination of all worlds and everyone involved is extremely excited about the possibilities and results this initiative will produce.

It's analysis engine can be used non-interatvely like how SPReports and SPSiteManager are used today, but will also provide a GUI for all you GUI fans out there to invoke the same functionality.

We're currently generating the specs and our current goal is to design it to support both the currently released versions of Windows SharePoint Services and SharePoint Portal Server 2003 as well as the next version of Windows SharePoint Services and Microsoft Office SharePoint Server 2007.

I'll be making further blog posts on using the new version of SPSiteManager, SPUserUtil, etc here. These postings will provide recommended guidance on how to use it effectively, but future blog updates on The SharePoint Configuration Analyzer will be placed on SharePointThoughts, so get your RSS aggregators configured to this site if you don't already :)

Have a great day!!!

- Keith Richie

Announcing the SharePoint Utility Suite Release 2.5

krichie — Wed, 19 Apr 2006 21:53:00 GMT

I sent the 2.5 package of the SharePoint Utility Suite off for update on the SharePoint Products and Technologies Web Component Directory yesterday and it will hopefully be live within a couple of days at http://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724

The purpose of the SharePoint Utility Suite is to provide a packaged collection of Tools and Utilities showcasing the rich Object Model that is delivered with the SharePoint Product and Technologies SDK (which includes Windows SharePoint Services 2.0 and SharePoint Portal Server 2003). This package includes code and tool examples that SharePoint Developers and SharePoint Administrators might find useful.

The source code examples provided in this package are delivered “AS-IS”.

Key Updates

This release contains the following Key updates:

SPSAddCS
- updated slightly to “Read” content source settings
SPSProtocolHandler
- This is a great sample Protocol Handler written entirely in C#.
SPSiteBuilder
- Updated with additional “Randomization” options for creating site build outs, stuffing existing sites with content, generating lists, document libraries and more!!
SPUserUtil
- This release adds a bit of newer functionality, but is more of a stability release, and alterations based on usage and customer feedback.
SPSiteManager
- The changes in this puppy require a whole section of their own J

SPSiteManager Update

Not to distract from the other great updates in this package, the biggest change are the updates to SPSiteManager such as the following:

Rich SharePoint Farm Analysis

SPSiteManager offers many levels of analysis that administrators can use to generate reports. Some of which are (but not limited to) the following:

Detect where sites/webs have exceeded the Capacity Planning Guidelines.
Get a holistic view of the entire farms site distribution for auditing and review.
Determine the percentages of file types used within a farm
Determine the average/minimum/maximum number of web parts utilized on pages.
Determine which and where specific site templates are used.
Content makeup such as number of lists and document libraries per site, as well as the mix of document types throughout the installation, as well as the mix of which are list attachments vs documents stored in document libraries.
Sum of content database sizes

In Analyze mode, a Site Distribution Document (SDD) is created in which the resulting data can be used to prepare reports, or as a template for other SPSiteManager operations. The analysis mode of SPSiteManager will also generate Warning elements to inform you of possible problems it has detected. All this data is in XML format (See SPSiteManager XML DTD)

Global actions across the farm

SPSiteManager can assist administrators by performing the following actions across the entire farm via a direct URL or driven by a Site Name Mask or Site Distribution Document:

Locking/Unlocking of sites
Quota changes and quota setting resets from quota templates
Site Backups/Restores/Deletes

All of these operations give you the flexibility to supply a Site URL Mask to identify sites on which to operate. As well, you can use a site mask or a a Site Distribution Document and supply granular information on what SQL Database Server, Content Database name, access credentials, and other properties to use on a per site level.

SharePoint Portal Server 2003 Site maintenance

If you have a SharePoint Portal Server 2003 installation, SPSiteManager can assist administrators with the following common site tasks on sites specified via a direct URL or driven by a Site name Mask or Site Distribution Document from sites within our outside of the current farm:

Adding/Removing sites from the list of sites to Crawl
Adding/Removing sites from the portals Site directory.

For more information on some of the newer updates to SPSiteManger, please refer to the following articles:

A sampling of the analysis data from the new version of SPSiteManager

http://blogs.msdn.com/krichie/archive/2006/04/14/576542.aspx

With Great Power comes Great Responsibility or Wicked Cool stuff you can do in SPSiteManager 2.0

http://blogs.msdn.com/krichie/archive/2006/03/20/555316.aspx

Enjoy! And let me know if you have any questions.

- Keith Richie

SharePoint Utility Suite for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007

krichie — Sat, 08 Apr 2006 18:08:00 GMT

I've had quite a few emails already asking "Are you planning on continuing and building a SharePoint Utility Suite for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007"

The answer is Yes.

The next question is, "what will be in it" :)

I will not be blogging on anything related to the next release of SharePoint Products and Technologies until the first public beta, but suffice it to say I am currently build and unit testing SPSiteManager, SPUserUtil, SPSiteBuilder, and other various tools for inclusion in a SharePoint Utility Suite for the next wave of the products.

Fortunately, it doesn't look like much is going to need to change that dramatically in the base source.

More to come once the public beta is released.

- Keith Richie