SharePoint 2010–User Information Lists and User Profile Cleanup

Recently I was working on a farm and finally got around to being able to enable the User Profile Sync to Active Directory.  Everything worked beautifully, but there was a problem in SharePoint with orphaned users in the UIL.  There are two reasons why obsolete users or groups can exist in the SharePoint Server 2010 user profile store:

  • Obsolete users: The My Site cleanup timer job is not active. The User Profile Synchronization timer job marks for deletion users who have been deleted from the directory source. When the My Site cleanup job runs, it looks for all users marked for deletion and deletes their profiles. Respective My Sites are then assigned to the manager for the deleted user and an e-mail message notifies the manager of this deletion.
  • Obsolete users and groups: Users and groups that were not imported by Profile Synchronization exist in the user profile store. This can occur, for example, if you upgraded from an earlier version of SharePoint Server and chose to only synchronize a subset of domains with SharePoint Server 2010.

Since this was upgraded from a 2007 farm and there was a period of time when the Farm was not syncing with AD, we had a period of time when several colleagues were removed from AD who had been using the new upgrade farm; However, they still had entries in the UIL, and once the UPA was set up to sync with AD, SharePoint orphaned these UIL entries.  The solution for this is a pretty simple PowerShell script.

1. Open SharePoint PowerShell window.

2. Enter the following in order to get the User Profile Service guid.


3. Now using the UPS ID, type the following

$upa = Get-spserviceapplication <identity>

4. To see your Orphaned Accounts, use the following:

Set-SPProfileServiceApplication $upa -GetNonImportedObjects $true

5. Assuming everything looks as it should and you want to get rid of these Orphaned Accounts, use the following command (which is the point of no return as there is no recycle bin for these orphaned users).

Set-SPProfileServiceApplication $upa -PurgeNonImportedObjects $true

And now your orphaned accounts in the User Information List is all cleaned up!

PowerShell Profiles

Now that I’ve been using PowerShell for a while, I’ve found that as I remote onto different servers I’m having to use the Add-PSSnapIn commandlet and remember the various names of snap-ins that I want to use.  Because I’m always looking for shortcuts along the way I’ve found this little gem that I can put in the profile.ps1 file to effectively load all snap-in modules that are on the server:

get-pssnapin -registered | add-pssnapin –passthru

This can be added to individual servers profile.ps1 files, but that will affect all users who remote into the server as well.  Since I’ve got a network My Documents, I can place the script inside the “My Documents\WindowsPowerShell\profile.ps1” file and now for any server I remote into, when I open the PowerShell app it will load all of the registered Snap-in modules on that server.  The file can be further customized with colors and other preferences.

OWASP Los Angeles Meeting with Francis Brown on SharePoint Hacking Diggity Project


When: Wednesday, February 22, 2012, 7:00 PM

Where: Symantec Corporation : 900 Corporate Pointe , Culver City, CA (map)

SharePoint Hacking Diggity Project

The SharePoint Hacking Diggity Project is a research and development initiative dedicated to investigating the latest tools and techniques in hacking Microsoft SharePoint technologies. This project page contains downloads and links to our latest SharePoint Hacking research and free security tools. Assessment strategies are designed to help SharePoint administrators and security professionals identify common insecure configurations and exposures introduced by vulnerable SharePoint deployments.

Francis Brown

Managing Partner, Stach & Liu

Francis Brown, MCSE, CISA, CISSP, is responsible for overseeing the company’s business operations as well as finance and administration functions. He also manages Stach & Liu’s 6sigma service quality program and leads internal practice development initiatives.

Before joining Stach & Liu, Francis worked in the Global Risk Assessment team at Honeywell International where he performed network and application penetration testing, product security evaluations, incident response, and risk assessments of critical infrastructure. Prior to that, Francis was a consultant with the Ernst & Young Advanced Security Centers and conducted network, application, wireless, and remote access penetration tests for Fortune 500 clients.

Francis has presented his research at leading conferences such as Black Hat USA, DEFCON, InfoSec World, and has been cited in numerous industry and academic publications.

Francis holds a Bachelor of Science and Engineering from the University of Pennsylvania with a major in Computer Science and Engineering and a minor in Psychology.

“America Underwater”, Putting a Face on the U.S. Housing Crisis

America Underwater. This is a website where American families can upload photos of themselves and their homes that are currently underwater in their mortgages. It’s harder to ignore the crisis when confronted by the faces of men, women, and children who are affected. We bailed out the banks- now what can we do to help families stay in their homes?

SharePoint 2010 – Web Application Not Being Created on All Web Front End Servers

Interesting situation recently… We were creating a new web app in central admin and it was being provisioned on the application server (Which ran the WFE service for content indexing) but not the client facing WFEs.  Reboot of servers, IISRESET, it was starting to get a bit annoying.  Eventually came up with this process:

  1. Delete the newly created web application
  2. Stop SharePoint administration service from services.msc on all SharePoint servers
  3. run stsadm -o execadmsvcjobs
  4. Start SharePoint administration service from services.msc
  5. Create new web application

Web app should now show up on all servers running the web application server. If this does not work, then you can also trying clearing the SharePoint Configuration Cache, but it’s a bit more involved:

  1. Stop the Timer service. To do this, follow these steps:

    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint 2010 Timer, and then click Stop.
    3. Close the Services console.
  2. On the computer that is running Microsoft SharePoint Server 2010 and on which the Central Administration site is hosted, click Start, click Run, type explorer, and then press ENTER.
  3. In Windows Explorer, locate and then double-click the following folder:
  4. %SystemDrive%\ProgramData\Microsoft\SharePoint\Config\GUID
  5. Notes
    1. The %SystemDrive% system variable specifies the letter of the drive on which Windows is installed. By default, Windows is installed on drive C.
    2. The GUID placeholder specifies the GUID folder. There may be more than one of these.
    3. The ProgramData folder may be hidden. To view the hidden folder, follow these steps:
      1. On the Tools menu, click Folder Options.
      2. Click the View tab.
      3. In the Advanced settings list, click Show hidden files and folders under Hidden files and folders, and then click OK.
      4. You can also simply type this directly in the path if you do not want to show hidden files and folders.
  6. Back up the Cache.ini file. (Make a copy of it. DO NOT DELETE THIS FILE, Only the XML files in the next step)
  7. Delete all the XML configuration files in the GUID folder (DO NOTE DELETE THE FOLDER). Do this so that you can verify that the GUID folders content is replaced by new XML configuration files when the cache is rebuilt.
    Note When you empty the configuration cache in the GUID folder, make sure that you do NOT delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  8. Double-click the Cache.ini file.
  9. On the Edit menu, click Select All.
  10. On the Edit menu, click Delete.
  11. Type 1, and then click Save on the File menu. (Basically when you are done, the only text in the config.ini file should be the number 1)
  12. On the File menu, click Exit.
  13. Start the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint 2010 Timer, and then click Start.
    3. Close the Services console.
  14. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  15. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
  16. Check in the GUID folder to make sure that the xml files are repopulating. This may take a bit of time.