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

Project Server 2010 – Waiting For Resources

I ran into this interesting state in project server last week and was able to resolve it this morning.  You may find that the timer job never executes itself..why?  Have no clue!  Especially since we already ran it three times previously and it always worked!

So I figured a way to successfully fire it manually from PowerShell:

$job = get-sptimerjob -id 4d9b0bd6-2919-4256-b030-c9d50c168e57
$wa = get-spwebapplication https://projects.contoso.com
$job.Execute($wa.id)

Keep in mind that rather execute in the owstimer process it will run as the current PowerShell user.  That user must have access to the database server to apply security and create databases.

Enjoy!
Chris