The Endless Sync Loop of DOOM

I figured it was about time that I posted about this very unpopular topic. I’m not attempting to smear the good name of Microsoft, and I know that Project and SharePoint have a very complicated relationship, (their FaceBook relationship status, would, in fact, be “In a relationship and it’s complicated”) but we’ve had a case open with them regarding this issue, so I know I can’t be the only person experiencing it. I thought I’d put it out there, in part because I’m hoping that someone else will ping me to say that they feel my pain.

Here’s the scoop:

Somewhere buried in the code, who knows why or how, there’s a piece that is actually *cAsE SensiTIVe*. Sounds like a barrel of monkeys, right?

Here’s what’s been happening in our environment:

Something in Active Directory changes, triggering Project Server and SharePoint to resynchronize the user. When that happens, the user’s NTAccount name can change too. Our “Pre-Windows 2000” compatible names in AD are set to UPPER FIRST INITIAL, LAST NAME FIRST INITIAL and then lowercase from there. So you know, the president would be BObama. Etc. (that’s kind of funny to say, try it!) But when this “call” happens, SharePoint apparently goes bananas and changes the resource NTAccount to all lowercase. (bobama!)

This is all well and good until the next night, when it “finds an invisible difference” between the name in Project/SharePoint and AD. Then it says, “I wanna sync!” but it can’t. It doesn’t seem to break anything in and of itself, unless it decides to deadlock, in which case what usually happens on our end is that resources get yanked out of SharePoint sites and are lost and sad without permissions.

MS knows about this. They found the code that causes it, but they haven’t been able to determine a fix yet, seemingly because they are worried about potential ramifications for other parts of the system.

So when our server deadlocked last night and I had to spend the better part of an afternoon resetting permissions for several users, I got to thinking that I should blog about this. Never fear, this isn’t just a pout session, I’m going to give you some pointers on our methods for dealing with it…

First of all, if you change that pre-windows compatible name in AD, the problem will right itself. If you catch it before a deadlock occurs, better still. You could set up something so that your Windows guys tell you when a change will come through that will affect your users (a change in their name, group, or manager, from what I can tell)

But if your Windows group isn’t giving you the low-down before it happens, how do you find out which users are causing the issue?

I have a couple of tricks up my sleeve for that.

1. Check the Resource Last Modified Date

When I come in the morning, I pull the resources from Project Server and check their last modified date. If they were modified at the moment when the sync occurred and they are all lowercase, I check them out against the domain controller. This is easy and doesn’t usually require any access to anything. I just do a simple command at a prompt:

C:\Users\Ellij net user bobama /domain

If the user name listed here is still all uppercase, our Windows guys will fix it an all will be well in the next sync.

2. Compare the GUIDS from the TraceLogs

So the TraceLogs will shovel a lot of errors out, saying that it’s syncing people, and it will provide the user’s AD GUID. An easy way to compare the GUID to the list of users is to just pull it into Excel (you knew I was going to say that, didn’t you?) using a snippet like this in your query:

convert(nvarchar(50), resourceUID)

If you don’t put the convert in there, Excel won’t pull that data (though PowerPivot will)

3. Compare the Cases

You can also use the cmd prompt to pull the list of users in a group:

C:\Users\Ellij net group projectusers /domain

…and then pop those into an excel worksheet alongside the NTAccounts from Project Server (minus the domain\ portion) and then use the following to compare them:


This will show you if they match in case, etc.

In Conclusion:

So this was a much longer post than I had originally planned, but you get the picture. And please, if you do come across this issue, or verify that you’re experiencing the problem, please report it to MS! The more of us who kick and scream the more chance we have for a resolution. I grow so weary of restoring SharePoint permissions!!!!



We’re getting our Hotfix! I got a call from MS last week, and they are putting it in an upcoming release. I feel so special. They should name it after me!

Update Update!

The CU is officially out: Project Server 2010 cumulative update package June 11, 2013

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s