We help IT Professionals succeed at work.

AD Connect sync issues - can the host server have other applications running on it?

High Priority
50 Views
Last Modified: 2020-02-18
We are having problems syncing an AD Connect server due to 'random' issues. The AD Connect is setup on a 2012 VM running off HyperV. The host server is a 2008 R2 server. The contractor feels that the sync issues are due to the host server running Peachtree accounting. I don't feel confident that is the case and he has not provided any evidence that Peachtree is the issue. He wants me to build a new physical host with no other applications for AD Connect to work as it should, but I'm not yet convinced that doing this will be a solution and it will be an added cost to us. I've allocated 6gb of ram and plenty of storage for the AD Connect server VM which is well above the needed AD Connect requirements.

My question is why would Peachtree accounting (or any other production software for that matter) on the host server cause sync issues to an AD Connect  VM?? We have no restrictive group policies or other local restrictions on the host server - it's just a standard application server that is pretty open.
Comment
Watch Question

CERTIFIED EXPERT

Commented:
I highly doubt that is the problem.  We run AD Connect on a VM in ESXi and actually run other apps, mainly NPS and Palo Alto Dirsync, on the same VM.  AD Connect is a light weight application, what problems are you experiencing?  How often are you syncing, and can you slow that down?  I don't recall the default setting, but I know in our environment we switched it to be every couple hours, we don'g make that many changes to AD, so it is not a problem.
SteveArchitect/Designer
CERTIFIED EXPERT

Commented:
Let's get something out of the way before discussing this:
Recommendations vs requirements.

It is best to take care before using a server for two different purposes.
In this case, AD Connect is pretty important to the smooth running of your systems, and ensuring security around anything that has deep access to your AD is worth considering.
in either of these cases, its best not to share a server.

These are recommendations however, not requirements.

on that basis, both Microsoft (Azure) and Peachtree (sage) recommend against installing their products on shared-purpose servers.
This doesn't mean it wont work, just that it may not be ideal.
So, it isn't ideal to put them on the same server, but there's no technical reason why you cant.

Therefore, if this contractor is suggesting Peachtree is the issue, clearly state you need them to provide evidence to back up the claim.
What diagnostics have they done to come to this conclusion?

Unless they are fighting over the same ports (unlikely) or are causing significant performance issues there is not reason to believe their claim.

In short, I agree with Bryant that they are very likely to be talking rubbish, unless they can provide evidence.
CERTIFIED EXPERT

Commented:
@Steve I agree mostly with your comments, however Microsoft does not recommend a standalone server for AD Connect, while it may be good practice.  I prefer to run many things on dedicated servers to minimize server outage impact, and as we run Windows Server Data Center, it really is just another light weight instance of Windows.

Microsoft's verbiage "Deploy Azure AD Connect on a domain joined server and restrict administrative access to domain administrators or other tightly controlled security groups."

Technically I don't see why ADConnect has anymore "deep access" to AD than any other domain joined machine does, it is just a tool to interface with AD which all domain joined machines do already.  Just depends on the account being used to connect.  That said, I also like to isolate and restrict security software to fewer hands.

Being the OP is already virtualized, I would recommend moving ADConnect to a dedicated VM.  But it does not have to be physical.

Author

Commented:
Thanks guys - going back to some points you made, the 'host' server has Peachtree running on it, not the dedicated VM that has AD Connect. The AD Connect vm has only AD Connect, nothing else. It's the Host server that has some applications running.

Author

Commented:
We were able to get AD connect setup and running then later that evening the service stopped working and went into a permanent 'starting' state, never fully starting. Rebooting and killing the service PID didn't resolve the issue.

Verified that the service login had the correct credentials, permissions and was part of the required local ADSync groups.

I built out another VM and retried everything. Same exact thing - ran for a day then the connection stopped in the evening some time and would never start up again. VMs are running Server 2012 R2.

When trying to startup AD Connect, this error occurs.
ad-con.jpg
Aaron TomoskyDirector, SD-WAN Solutions
CERTIFIED EXPERT

Commented:
2008r2 was never a great hyper-v host platform...do you have a 2012r2 or newer host you can use? I've setup hundreds if not thousands of 2012r2 hosts and VMs and they were bulletproof.

Author

Commented:
Unfortunately, all of our host servers are 2008. That is definitely an interesting point though. I may have to look into that as an option if we can't figure this out. For now, I'm prepping another spare physical server for AD Connect. May just have to throw a 2012 OS on it if it doesnt work out.
CERTIFIED EXPERT

Commented:
Could it be a bug in that version of ADConnect, can you rollback or upgrade the version?  Just throwing it out.  It is a strange error, that I am use to seeing in another application.  Basically it means that the program is trying to find an Object, but that object is not defined or null.  To fix it you would confirm you are setting the object before calling it.

So if I use that logic, I might look outside of ADConnect, such as do you reboot the database server or domain controller it relies on?  Anything happening in the network when it happens, ie backups or more latency?

Author

Commented:
So, we ended up creating a new AD Connect server on a physical machine and it works with some issues. It will sync our users successfully about 25% of the time while most of the time the server generates a password hash error (Error 1069: The service did not start due to a logon failure)

Our domain is at a 2003 ADj functional forest level with the AADC configured to a 2008 R2 server.

We have been working with Microsoft continually on the issue. They have suggested using different builds of AADC but we are still encountering the same problems.

Not really sure where to go from here...
CERTIFIED EXPERT

Commented:
I think you will have to work with Microsoft on this one.   We have 2008R2 as our functional level for the moment.  Being that 2008 R2 is end of everything in January maybe consider upgrading the domain controllers?

Author

Commented:
Yeah - we were going to upgrade our 2003 domain controllers after we migrated over to 365 and wrapped up other tasks relating to the project. Now we may have to rethink this if MS cant find a solution...

Author

Commented:
The issue ended up being due to permissions to the following:

1. Local server AD Connect groups required membership of the local ADC user account (it was automatically created from the install)
2. The service login for AD Connect requires the local ADC user account  to be the service login
3. The local ADC service account must then be elevated at the domain level as an accepted domain level administrator service account
The issue ended up being due to permissions to the following:

1. Local server AD Connect groups required membership of the local ADC user account (it was automatically created from the install)
2. The service login for AD Connect requires the local ADC user account  to be the service login
3. The local ADC service account must then be elevated at the domain level as an accepted domain level administrator service account