Windows 10 PC in Unassigned group even with AD Sync?

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

Hello Stuart,

by design there are no duplicates in AD.
Unless this is a quirk of AD Sync I haven't seen yet these computers have already a "twin" in the correct SEC group - could you check? If there are no twins please verify, if possible, that Sync is syncing these computers. Turn off one of the computers. In the console click All in the Computers pane on the dashboard, use CTRL+F, enter the name and click Find Next. Delete this instance, click Find Next to make sure there is no other instance. After the next sync the computer should have reappeared and be in the correct SEC group.

Christian 

Hi

There are no duplicate computers in Sophos either?  I did delete the computer from Sophos anyway, then tried what you suggested and it just reappeared in the unassigned group?  I tried this with 2 computers and got the same result?  AD Sync is working apart from this as I created a new OU recently and that was synced to Sophos no problem?

Thanks

Stuart

Hello Stuart,

it just reappeared in the unassigned group
and the computers were switched off? This would be very strange. AD Sync works like this: The computers in the OU tree are enumerated as are the computers in the associated SEC groups. Computers from the OU tree not in the SEC groups are added to the applicable group, computers in one of the SEC groups not in the OU tree are moved to Unassigned. Thus a computer from AD not in SEC at all before the sync shouldn't appear in Unassigned afterwards.
Apart from the name additional attributes are considered when Sophos is installed on an endpoint and the endpoint sends its status to SEC - domain/workgroup and operating system and version. If the endpoint is joined the domain should match, OS (version) might differ though. In that case you'll get an (unmanaged) computer in the correct group and a managed one in Unassigned.

To summarize, if the AD OU1 is snyc'ed with SEC's GrpSYNC and PC7-OU1OU2 is in the child-OU OU1\OU2 then a computer with the name PC7-OU1OU2 should be in SEC's GrpSYNC\OU2.

Christian

Sorry for opening this older thread.

We have the same annoying Problems with unassigned groups while migrating from Windows 7 to Windows 10. The migrated computers where renamed to reflect the new OS (W10- instead W7) now for some computers they are doubly present where the active (green) one is unassigned and the inactive (grey) one is in the correct group. Please tell us how to fix that!

Thanks,

Dirk

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

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