Tag: userprofile

Posted on

SharePoint Active Directory Node Limit is hard coded! – EditDSServer.aspx

Since no one answered my question on twitter, I went back to trying
to figure this out on my own.  When you are editing the AD Connection on
the editdsserver.aspx you may run into an issue with not seeing all the
nodes in an OU.  Why?  Well, its because there is a limit on the number
of nodes that are queried.  One may ask…"can I change this"?

The
answer is no. You can change the timeouts in various different ways,
but there is NO WAY to change the node limit.  Why?  Because in the code
for the EditDSServer.aspx page, you will find a method called
"_DoLdapDirectorySearch".  This has a HARDCODED hex value of "0x3e8". 
What is that in decimal?  Its 1000.  Yes, you read that right, the hard
coded node limit is 1000 nodes.   Why is this a problem you ask?  Well,
if you needed to exclude a set of service accounts in an OU container
in your "User" OU, you won't be able to see it because it likely starts
with an "S".  If you scroll down the list, you will see the nodes end
around "M". 

Being that I am the one and only "CJG", I think to
myself, let's do this through ForeFront!  Easy enough, fire up
MIISClient.exe, change the values (b/c it DOESN'T have a limit), remove
the OUs and click Save.  I'm thinking, yeah…that was easy.  No,
Forefront will also un-check the "Users" OU when you do it like this. 
Then you lose the 1000s of users you had in the sync.  This is obviously
very bad (worse than having the service accounts in the list).

So
what do you do?  You find a blog post like this one by @mosshater that
shows you how to get at the AD connection to be able to set the naming
contexts:

http://mosshater.blogspot.com/2010/10/powershell-add-active-directory.html

This is SOOO painful…
Chris

Posted on

Upgrading UserProfiles to SharePoint 2010 Non Database Attach

Blog Post #2 of How I Successfully Upgraded eBay to SharePoint 2010 – Previous Blog in this series

One of the decisions I made as the Sr Architect of the eBay upgrade project, was to NOT do a database attach upgrade of the SSP.  I viewed the whole process as not very reliable and we didn't want a bunch of junk moving foward to 2010.  So, we went down the path of build it all from scratch.  This presents some interesting problems and this blog post will focus on the UserProfile Service Application component of the SSP.  In summary it entails:

  • Custom properties added in 2007 must be moved to 2010 (definition and data)
  • Custom profile privacy settings
  • All connections must be redone (BDC, Active Directory)
  • Migrate old custom user data

As part of the process, the first thing you have to do is to identify all the custom properties that were added in 2007.  This is actually an easy part as you can simply run a query against the SSP database and the PropertyList table.  Anything over a certain ID value is a custom property.  This definitely gets you the list, but what do you do with the list?  You COULD manually add each one to the UPS service application, or, you could write a lovely PowerShell Script to do the work for you.  How do the scripts work?

  1. We built a custom tab delimited file of their names, values, descriptions, privacy settings and connection information.
  2. We create a script that reads the data and will setup the properties – this was HUGE time saving as the property editing page in UPS is one of the worst designed pages in all of Central Administration
  3. Setup all BDC connections using SharePoint Designer (this includes assigning the proper permissions to the UPS service application accounts to be able to execute the BDC and retrieve data)
  4. We create another script that will setup the property connections (after BDC has been created)
  5. Custom profile privacy settings

That gets the basics done, but what about the data of the users in the 2007 farm?  Just so happens the SharePoint team though very hard about this one.  As part of the SharePoint Admin ToolKit, you have a User Profile replication tool.  This tool will grab the data in a target SharePoint farm (2007 or 2010) and move the data based on the account name of the user (not the recordid as that would change in each farm).

The only problem with this tool is that is doesn't like special characters very much.  These would include the main culprit the 'appersand' (ie '&').  We had to edit all the properties in the production farm that had this in the PropertyVal (of the UserPropertyValue table) to remove it and put 'and' in its place.  Once this was done, the tool was able to use it's error log to rerun for just those users.  You could slowly find all the special characters and remove them to have the users data get moved over successfully.

The last step, and this really is the most important one, is that you ensure that all the privacy settings came over.  We were told the Admin Toolkit would do this, but we found out that wasn't the case.  It is very simple to get these values from the older 2007 farm by joing the UserProfile_Full and the UserProfileValue tables on recordid and getting the "privacy" column.  Then all you have to do is to update the same values in the 2010 farm and BAM…you are DONE!

Enjoy, 
Chris

Check out the next blog in this series – Changing your Host headers