In the continuing saga of the User Profile Service (UPS) kicking my butt, I have a heartwarming tale of one victory I can claim. It involves Event ID 6801 "Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed." and me besting the User Profile Service. Don't believe me? Well, here's my tale…

It was the best of times; it was the worst of times. I was getting a handle on the UPS, but it threw another error at me. A customer contacted us. The UPS refused to sync on their farm. It had never worked. I looked in the Application log and saw a string of Event ID 6801s and 6803s. The 6801s included the text "Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed." The 6803s were just saying that portion of the sync failed. A normal profile sync has 10 steps. Some pull from AD, some from SharePoint, some push, and so on. The initial AD import step, DS_DELTAIMPORT was working. The rest were failing.

Unlike a lot of error messages, this one was helpful. I wasn't sure where this broken URI was, or why it didn't have a port, but it was something. After going through the Windows logs and the trace logs, my next step was the fire up the miisclient.exe in the C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell directory. This let me watch each step as it happened. I could see the failures going through. After doing some research on the error, and comparing a working system to the broken system, I figured out the difference. Central Admin on the working system was on a nonstandard port, 1026. On the broken system, Central Admin was using https on the common port, 443.

Armed with this information I went back to miisclient.exe. I clicked "Management Agents" in the toolbar and opened the properties for the SharePoint agent. It's the one of type "Extensible Connectivity." This is how Forefront Identity Manager (FIM, the software behind the User Profile Sync) connects to SharePoint.

Once in the properties I clicked "Configure Connection Information" on the left to get the connection information. On the bottom, in the "Connect To:" box was the key.

This screenshot is from the working system. Notice my connection string has a colon and a port number. I looked at the broken system and it did not have a colon or a port, since it was running on the standard https port. The fix was to change direct://centraladmin/_vti… to https://centraladmin:443/_vti... After I did that, I started a full profile sync. All 10 steps completed successfully.

The moral of this story is that the UPS will not work if your Central Admin default zone URL does not have a colon and a port number in it. The fix is to specify the color and port in the connection setting in miisclient.exe.

Comments

FIM

Is one of my new favorite acronyms!! In building out our farm with SP2010 and only having experience with SP2010 it was very challenging to work through some of these issues. Especially in May when your book wasn't out, and there was little documentation on the web for its function...

However, having it setup and funtioning properly and writing back to AD is absolutely worth the pain and suffering. Thanks for sharing your hurdles and success you have. It really helps mentor the rest of us!

on 8/24/2010 11:58 PM

This is unsupported as of now

Editing anything in MIISCLient directly is unsupported as of now by CSS.

on 8/25/2010 10:23 AM

Re: This is unsupported as of now

Interesting. Do you have a link that explains that? If that's the case, is there a supported way to make the UPS run if central admin is on a common port?

There is no official KB on this. I havent tried with this configuration of CA. It may actually be a bug with UPS as there are many others. I will recommend your customer open a case with CSS to get a definitive answer.

on 8/25/2010 10:42 AM

Glad it wasn't just me

Had to do this in a deployment at the beginning of August. Took me a while to find the fix.

on 9/4/2010 8:36 PM

Error Comes back once a week

Do you now of a timer job or something that sets that information. I can make the change and it works (at least for 1 week) seems the Sunday job runs fine and monday's job fails. This happens every week. I go back in add the port and all is good until the next monday.

on 10/18/2010 10:06 AM

Re: Error Comes back once a week

This seems to be caused by the FIM services being paused, or restarted. When the service is restarted it reinitializes a bunch of settings, and this is one of them.

Unfortunately at this point I don't know of a fix or work around. Sorry. :(

tk

Todd O. Klindt on 10/18/2010 10:13 AM

Re: Error Comes back once a week

Thanks for the feedback. I would have to disagree that it is related to the restarting of the services though. I can reboot the server that the sync service runs on all I want and don't get the problem. Just the 1 time every week, I just can't pinpoint it to what corresponds to that time. I'll keep you posted if I find the answer

on 10/20/2010 4:32 PM

Re: Error Comes back once a week

The thing that I've seen that always seems to reset it is a farm level backup in Central Administration. That pauses some services to make sure they're in a consistent state. Unpausing the sync service seems to cause the URI to be rebuilt.

Do you run farm backups once a week?

tk

Todd O. Klindt on 10/21/2010 8:06 AM

Re: Error Comes back once a week

That would makes some sense. I do have a farm backup running once a week. Although the times didn't initially appear to add up, I suppose this could be the case since I really wouldn't notice the issue until the next UPS sync runs which is almost a full day later after the farm backup.

Its strange that a restart of the service doesn't produce the same effect since it does sort of reprovision the service everytime it restarts.