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

Windows 10 PC in Unassigned group even with AD Sync?

Hi All,

We are seeing a few (not all) Windows 10 machines getting stuck in the Unassigned group in SEC.  We have AD sync configured so I can't manually move the PC to the correct OU to get it's policies.  Where can I look please to see if there are any errors/clues on either the client or server?

Also can I install Sophos with the -G switch if I have AD Sync configured?

 

TIA

Stuart



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

    AD Sync should grab a matching computer object from whatever group it is in (whether the default Unassigned, one specified with -G, or by a manual move before AD Sync has been enabled) and move it to the applicable group. V.v. if it finds a computer in the sync'ed group that from its POV doesn't belong there it will move it to Unassigned. That a computer pops up in Unassigned suggests that there's already on with the same name in the group associated with its OU. You won't see any error when this happens.

    Christian

  • Hi Christian

    Thanks for the reply.

    I have doubled checked our AD Users and Computers and the computers in question only exists once in AD in the correct OU.  Other computers in the same OU are syncing fine with Sophos, I just have 4 Windows 10 computers that are in the unassigned folder in Sophos.  I have tried deleting them, performing a rediscover, reinstalled Sophos on the EndPoint, but no joy, they remain in the unassigned group in Sophos?

    Cheers

    Stuart

  • Hi Dirk,

    My suspicion for why this happens is that the Sophos Endpoint is installed on the endpoints before the computer is pulled via AD Sync to Enterprise Console.  After install the machine will go to the unassigned group as there is no reference of it, then when an AD sync is performed a new grey entry is added to the proper group.  To prevent this you can use the "Install Sophos security software automatically", so the software is guaranteed to installed after an AD Sync.

    As for how to fix the current machines, this is likely not supported but should work:

    1. Take a backup of your SOPHOS5## database: https://community.sophos.com/kb/en-us/114299

    2. In an administrative command prompt, run the below command to get a list of computer entries in your SOPHOS551 database with duplicate names:

    sqlcmd -E -S .\sophos -d sophos551 -Q "select * from computersanddeletedcomputers where name in (select name from computersanddeletedcomputers group by name having count(name)>1)"

    3. Run the below command to delete the computer entries in your database with duplicate names:

    sqlcmd -E -S .\sophos -d sophos551 -Q "Delete from computersanddeletedcomputers where name in (select name from computersanddeletedcomputers group by name having count(name)>1)"

    When the computers re-connect to Sophos Enterprise Console, they should repopulate themselves in the correct AD synced group.

  • Hello Dirk and MEric,

    MEric already described how to deal with the duplicates. Allow me some addition though:
    this happens [when] Sophos Endpoint is installed on the endpoints before the computer is pulled via AD Sync
    I don't think this is a sufficient condition because after deletion the re-connect can occur before or after the next sync. In the former case the endpoints will first (re)appear in Unassigned and subsequently sync will move them to the correct group. Haven't tested AD sync for some time but as far as I can tell the duplication can occur when Sophos is installed before the computer is joined to the domain. The computer reports workgroup membership and is subsequently joined to the domain. If AD sync imports the computer object before the endpoint sends its updated status that indicates domain membership there will be two computers in SEC. If the status update happens before the sync the computer will be correctly moved though. A similar race condition can happen when computers are renamed.

    Christian   

  • Thanks for your replies guys. For me it is a bug.

    Sophos WERE already installed on these computers, the computers were in the same AD OU, they were always a joined part of the domain, nothing changed, Sophos seems to have problems to recognize a simple computer name change, what shouldn't as in the AD the machines still had and have the same SSID. My workaround is to delete both of the computers and then let them rediscover. Sometimes this works asap, sometimes I had to delete them more often until they get recognized correctly again.

    cheers

    Dirk

  • Hello Dirk,

    Sophos doesn't use the SID - and using the SID would just shift the problem. In case of a reinstall of a computer it's the SID that will change, as it will in the install-before-join scenario.
    It's IMO not a bug as there's no solution to the "is this the same computer?" - or is this Theseus' Computer - problem. Whatever algorithm you devise there's always at least one scenario where it either produces unwanted additional objects or merges some.

    Christian 

  • >Sophos doesn't use the SID - and using the SID would just shift the problem. In case of a reinstall of a computer it's the SID that will change

    What is fine as you usually remove the "old" computer from the AD to join the new installed one (new sid then) AND you have to newly install sophos then.

    >It's IMO not a bug as there's no solution to the "is this the same computer?"

    I disagree here still, hehe, sophos should be able to recognize that there is the same computer with sophos already installed and just the name in AD has changed. The funny thing is SOMEHOW Sophos IS doing that, that's why we get the duplicate ;-)

    cheers

    Dirk

  • Hello Dirk,

    I disagree here still, hehe
    hehe too :). From your POV you're probably right.
    No customer works with all possible scenarios. Keep in mind that AD Sync is one possibility. You don't have to use it, you don't have to have AD, you could have a mix of workgroups and domains. Different environments, different workflows. Last but not least non-persistent VMs.
    IIRC Sophos did consider the SID at some time. There are customers that frequently re-image machines, install from scratch but same name. They expect that they don't have to delete the previous incarnation of PC-101 from SEC, so in this case the SID should be disregarded. SEC isn't "domain-aware", AD sync wasn't there from the start, workflows were already established. AFAIK a true AD integration (that would have increased complexity) was never really considered.

    just the name in AD has changed
    as said, I assume a race condition. E.g. if AD sync "sees" and imports a new name it isn't aware that this is the result of a rename. Thus it creates, say, the unmanaged PC001-W10 in the appropriate group and moves PC001-W7 (that is no longer in AD) to Unassigned. If subsequently the endpoint tells that it is PC001-W10 the computer in Unassigned is renamed (but not merged with the imported unmanaged object).

    Christian

         

  • These are valid and good points Christian!

    as said, I assume a race condition. E.g. if AD sync "sees" and imports a new name it isn't aware that this is the result of a rename. Thus it creates, say, the unmanaged PC001-W10 in the appropriate group and moves PC001-W7 (that is no longer in AD) to Unassigned.

    That is not what exactly happend, I get PC001-W10 TWICE. EVEN I delete BOTH with the next AD sync I get BOTH what makes no sense as I just have one PC001-W10 in ONE OU. I still call THIS a bug :-P I have to delete the unassigned one asap after sync so that the correct one "works" (the workaround).

    Dirk

  • Hello Dirk,

    delete in the console or SQL DELETE? If the former then ... well, I haven't tried to assesses the (SQL) procedures in the SEC 5.5.x versions, seems there have again been some (minor) changes and more of the logic has "on-loaded" to the management service. SEC delete just sets a flag so that the computer (and its associated alerts, events, whatever) isn't shown and not considered for reporting. Might be that both are incorrectly un-deleted. I vaguely remember that a while ago a change has been made so that a SEC-delete would cause a "selection" of the remaining entry as the active one. IIRC it didn't (and perhaps doesn't) always work as intended.  

    Christian 

  • Hej Christian,

    delete in console.

    Dirk

  • Hello Dirk,

    as said, the console delete leaves a computer (both in this case) in the database with all associated information (including e.g. its group) intact.

    It's probably expedient to add some background information
    There a basically two ways a computer is added to the database

    1. Discover, import, sync - some basic information, if available, is stored in addition to the name. The computer appears as unmanaged (grey).
    2. The computer, after installation of RMS, registers with the server - a unique ID, a certificate, and "auxiliary" identifiers are created (and subsequently product status values are sent). The computer shows as managed.

    In both cases the matching algorithm searches for candidates for a potentially already existing entry (usually created by the other option), if candidates are found the best is determined, and its information is merged with the one from the new entry. Matching and merging are pretty complex, and certain value combinations preclude a merge (most notably different OS versions or workgroup/domain), and the outcome also depends on which kind (un-/managed)  is added and thus what is searched for.
    And if you think this is complicated - if you rename a computer it normally affects only its proper entry in SEC, the matching algorithm doesn't kick in (and it also doesn't when you move a computer between groups).

    Hm, not sure what happens if you change its name while a computer is in a synced group (but the next synchronization is not in the near future). I assume the change is simply reflected in the console but the computer stays in the group. If so ensuring that the next sync only happens after the rename and AD update are completed should avoid the problem.

    Christian       

Reply
  • Hello Dirk,

    as said, the console delete leaves a computer (both in this case) in the database with all associated information (including e.g. its group) intact.

    It's probably expedient to add some background information
    There a basically two ways a computer is added to the database

    1. Discover, import, sync - some basic information, if available, is stored in addition to the name. The computer appears as unmanaged (grey).
    2. The computer, after installation of RMS, registers with the server - a unique ID, a certificate, and "auxiliary" identifiers are created (and subsequently product status values are sent). The computer shows as managed.

    In both cases the matching algorithm searches for candidates for a potentially already existing entry (usually created by the other option), if candidates are found the best is determined, and its information is merged with the one from the new entry. Matching and merging are pretty complex, and certain value combinations preclude a merge (most notably different OS versions or workgroup/domain), and the outcome also depends on which kind (un-/managed)  is added and thus what is searched for.
    And if you think this is complicated - if you rename a computer it normally affects only its proper entry in SEC, the matching algorithm doesn't kick in (and it also doesn't when you move a computer between groups).

    Hm, not sure what happens if you change its name while a computer is in a synced group (but the next synchronization is not in the near future). I assume the change is simply reflected in the console but the computer stays in the group. If so ensuring that the next sync only happens after the rename and AD update are completed should avoid the problem.

    Christian       

Children
No Data