Share via

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

  • Article

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

  1. 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.

  2. Set the displayname= and email= attributes appropriately, similar to the following 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=""displayname="Margie Richie" email="margie.richie@MYDOMAIN.com"/>

    </users>

     

  3. Run WSSUserUtil to update the information:

    WSSUserUtil –o update –url https://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 https://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

  1. 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.

  2. 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>

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

    <users>

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

    </users>

     

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

    WSSUserUtil –o update –url https://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 https://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 https://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:
https://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:
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

Comments

  • Anonymous
    August 22, 2006
    Hi Keith,

    I am a big fan of spuserutil, it's saved me so much time in the past.  Keep up the good work.

    Recently had a problem with wssuserutil. I wondered if you had seen this before:  I have just finished a sharepoint and domain migration.  I ran wssuserutil on a site in the new domain that had lists with item level security.  

    After running with the migration switch, the users had the right permissions to the list as expected, all the olddomainusers had been swtiched to newdomainusers.  

    The only problem was that they could not see the items they had created as olddomainuser.  

    The list has been set to only allow users to read and edit their own items.  I looked into it and found the 'created by' and 'modified by' attributes on the items were still for the olddomainuser.  Have you ever come across this in your testing?  Do you know any workarounds?

    Regards,
    Matt

  • Anonymous
    August 22, 2006
    Hey Matt,

    Did you use the -o migrate option or the -clone option?  If you used -clone, it does not truly "Migrate" the user, only clones olddomainuser to newdomainuser and thus, newdomainuser would not be able to see the items for olddomainuser.

    However, if you used the -o migrate option, then the Created By and Modified By attributes would be updated ttbomk.   A quick way to test this, is to setup a test document library in the same fashion (Unless you have one already) then use STSADM -o migrateuser user and test.  That will tell you if the problem is truly in the Migration APIs or not, because this is all that SPUserUtil does when using the -o migrate option...It simply calls the WSS MigrateUser API to migrate the user.    This then, might be something you want to open a PSS ticket on.   If we're still leaving the Created By and Modified By properties with remnants of the old user, that's something that should be fixed IMHO.  Don't know if they could bug it or not, but you should definately find out.

    Keith

  • Anonymous
    August 22, 2006
    Keith

    I used -o migrate and all was fine except the lists with item level permissions.

    I'll set up a test and see if I can recreate it.

    Cheers
    Matt

  • Anonymous
    August 22, 2006
    Cool, thanks Matt...definately let me know your results, but I feel you need to go to PSS on the end issue, especially if you can duplicate with just STSADM -o migrateuser.

  • Anonymous
    August 22, 2006
    Hey Keith,

    I recreated  the problem in 2 virtual pcs and realised what the problem is.  Because I am using the domain users group to set the item level permission I can't use the migrate switch, I have to use clone.

    In my lab, Sharepoint thinks there are 2 users with the same name.  They cannot see each others list items.

    Matt

  • Anonymous
    December 30, 2007
    PingBack from http://music.247blogging.info/?p=608

  • Anonymous
    July 09, 2008
    The comment has been removed