This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Enterprise Console not syncing correctly with AD

Hi,

Initially, AD sync within the SEC worked great. But over time we have started to see some issues.

We have re-used computer names, renamed computers, or moved computers within the AD and it seems that the SEC isn't keeping up with all of the changes.

I have computers in AD OU's that are synced with the SEC, but they show under "unassigned" in the SEC.

I have deleted computers from the SEC, and when the next scheduled sync occurs, they are not re-synced.

I suspect this is due to poor administration on my part.

How can I go about cleaning up all of these discrepancies? Is syncing with AD recommended? Or is it better not to sync? When a machine is deleted or renamed in AD, should this change be reflected in the SEC after the next schedule sync?

Thank you,

Cheers



This thread was automatically locked due to age.
  • Hello toddh,

    basically AD Sync is an electronic monkey which creates if necessary a group tree under the synced group in SEC which mirrors the OUs in the synced AD container. Then it looks at the endpoint data in SEC (data that every managed endpoint sends via RMS to the management server) and that in AD comparing name, domain, and OS version.

    Apart from this interface SEC and AD management are independent and this can lead to discrepancies. SEC permits "duplicate" names as long as domain/workgroup and/or OS (version) are different. And - SEC does not delete computers but just flag (and hide) them. A scenario that could lead to problems is: Delete a decommissioned computer from AD (this will move its entry in SEC to Unassigned). Reuse the name with a new computer, install Sophos before joining it to the domain. SEC will create a new entry (as the Domain attribute differs). Join. IIRC the Sophos Agent is not immediately notified thus AD sync might see the name again in AD before the endpoint reports its domain membership and the old SEC entry will be moved back to the sync'ed group. When the endpoint finally reports its new membership the place in the sync'ed group will already be taken.

    Logic has changed over times, occasionally I've played with it (mostly motivated by forum posts) but didn't use it in production. The results suggest that data remains consistent if an endpoint only sends data when it's already joined (thus SESC should only be installed after the computer has been joined).

    is syncing with AD recommended
    it's not required. It might simplify management - OTOH the AD structure must be suitable for policy management. It can be convenient for small(er) or not too complex sites.

    Cleaning up usually requires fiddling with the database - unsupported unless Support suggests it, not forbidden, and unless you need to keep complete and accurate historical data (which you likely don't have anyway if you have to clean up [:)]) neither dangerous nor complicated.

    Christian