Time for another very specific question : Anyone else having issues syncing Sharepoint 2013 with another domain (with full trusts setup) when connecting to a domain controller running on Windows Server 2008?

Little bit more detail:
We are in AD forest ForestA. We have Sharepoint 2013 that sync perfectly with our AD which is mostly Windows Server 2012/R2's and one or two Windows Server 2008 R2 - but nothing lower that that. Here are the functionality levels:

Domaincontrollerfunctionality = 4      
Domainfunctionality = 4      
Forestfunctionality = 2      

We are trying to sync with a remote ForestB. All of the remote domain controller servers are Windows Server 2008 - except for one Windows Server 2003. Here are the functionality levels when talking to Windows 2008:

Domaincontrollerfunctionality = 3      
Domainfunctionality = 2      
Forestfunctionality = 2      

And with a 2003 server:

Domaincontrollerfunctionality = 2
Domainfunctionality = 2      
Forestfunctionality = 2      

Full two ways trusts are setup and working between ForestA and ForestB.

When setting up the UPS AD sync with ForestB when connecting to a Windows 2008 it fails with this error in the event log:
"System.InvalidOperationException: Retrieve schema failed.Microsoft.ResourceManagement: System.InvalidOperationException: Retrieve schema failed."

When setting up the UPS AD sync with ForestB when connecting to a Windows 2003 it works fine.

When trying to do an incremental sync to ForestB when connecting to a Windows 2008 it fails with this error in the event log:
"The management agent "MOSSAD-ADS" failed to run because the credentials were invalid. User Action - Verify the credentials and configuration for the management agent..
When trying to do an incremental sync to ForestB when connecting to a Windows 2003 it works fine - even though I am not changing a single thing with the credentials! I use a local host file to force Sharepoint to go to the 2003 server.

So to sum up - why can't out Sharepoint 2013 sync with ForestB when the connection goes to Windows Server 2008 but works fine when connecting to a Windows Server 2003?

EDIT: To add information to this - we do have a user setup in ForestB with proper permissions in their forest!

• Edited by Kristoffer75 Monday, January 26, 2015 10:09 AM More info

Functionality Levels aren't tied to an OS version (besides all of your DC OSes must support that functional level). DCs themselves do not have "functionality levels", those are only at the Forest or Domain.

I would take a look at that 2008 DC's security logs to see if you're getting failed logons and so forth.

hank you for replying Trevor.

domaincontrollerfunctionality level is a DC server unique flag which states what domain level that server can handle, and as such is tied to OS. A windows server 2003 (with domaincontrollerfunctionality level of 2) will not be able to handle a domain functionality level higher than two.

There is a a KB about it here: http://support.microsoft.com/kb/322692

But regardless of that, or if it's even a 2003/2008 issue or policy issue, I can't look at the security logs since I don't have access to the servers. They are completely outsourced and we only have access with LDAP to read information from their AD but nothing more. This is why Microsoft won't take this case further, they don't even want to test the scenario in a lab Environment until they can look at our Environment, which is impossible. The result is that 90% of my users are now showing up with only their account names instead of actual names - because our UPS can't read the information :(

Edit: This is the flag I'm talking about:

• Edited by Kristoffer75 Monday, January 26, 2015 2:54 PM

Not much we can do to help if you don't have access to the DC. You could look at miisclient.exe to see what error it is throwing, but that won't help you resolve it if it is an issue with the DC.

I fully understand it's hard to help - the question was more general "have anyone tried this and got it to work" since I can't get a yes/no answer from MS if this should work at all.

And it's not an issue with a specific DC, it's all DC's that are 2008.

I'll just have to set up a virtual environment to test this scenario but setting this up will take some time...

Yes, SharePoint 2010/2013 work just fine with any DC 2003 SP2 or higher.

The one thing missing from your statement, Trevor, is "over a trust" - because unlike a normal scenario (where you sync Sharepoint with the AD that the Sharepoint server is already a member of) this scenario was over a two way trust.

I've now tested in a Hyper-V Environment to have 2 seperate Forests with 2 domain controllers each (1 Win2003 and 1 Win2008R2 in ForestA and 1 Win2003 and 1 Win2008 in ForestB), set up a trust, installed Sharepoint and set up the sync. My first test replicated this error perfectly - when connecting to the windows 2008 server I get "credentials failed" but when I turn it off and it has to use the Windows 2003 server it works perfectly. I took a glance at the sec logs on the Windows 2008 server and it didn't show any failures.

I wish I had more time to dig into this but it's weekend and next week is full packed with stuff, will let you know of any updates!

Is this Win Server 2008 SP2?

I just set up a 2008 SP2 x64 DC and was able to successfully synchronize it over a two-way forest-wide trust.

In ForestA (our domain) I had:

DC1 = Windows 2008R2 64 bit
Forest level at 2008R2 (4)
Domain level at 2003 (2)

(I know I wrote I had two DC's there but after checking the other one (2003) wasn't actually promoted to a DC, I missed that but apparently that didn't mater)

SHP = Windows 2012 (NOT R2), Sharepoint 2013 SP1 Dec '14 CU (but this issue has been there since day 1 so SP1 is sufficient I believe).

SQL = Windows 2012 (NOT R2), SQL 2012 DEV edition.

In ForestB (outsourced domain) I had:
DC1 = Windows 2003 PS2 32 bit
DC2 = Windows 2008 SP2 32 bit

Forest level at 2003 (2)
Domain level 2003 (2)

On the Sharepoint 2013 in ForestA I was NOT able to sync with DC2, but no problem with DC1.

They are on the same virtual Hyper-V switch, even the same subnet and IP range and all firewalls are off so absolutely not a network issue. I'll do my best to set up another virtual environment at home just to make sure :)

One more thing to add here is that ForestB is 1 hour after ForestA to simulate real life where ForestB is located in UK and ForestA is in mainland Europe. Not sure how important that is...

As long as both of them follow UTC-/+TimeZone, that's fine. If you've forced a one hour shift while in any TZ, then that would prevent Kerberos auth between forests.

Hello all,

Thank you Trevor for replying and testing it on your end.

I've done extensive testing over the weekend, including setting up another Hyper-V environment at home, and it is working. I don't know what is wrong with our production environment (or rather "theirs" as this is an outsourced forest and infrastructure) or what was wrong with my first Hyper-V environment where I got the same error but it's working on both my lab Hyper-V environments.

So I must conceed. The error is something else. So chalk up another score for "in-house IT" as I can't troubleshoot this any further than this.