I can understand that, but in an organization where the systems have different host names, a duplicate hostname is a bit rare and should be able to trigger something.
Plus, we can't always deactivate BEFORE because these updates for Windows 10, either from 7/8 to 10 or from 10 to 10 anniversary edition because in the case of upgrades within 10, MS forces that down our throats and we don't always have control if our clients endpoints or the client themselves update the systems.
This still needs to be addressed. This doesn't seem to be an issue with other management consoles for other vendors i've seen/used.
Can't even get a report at the GSM top level that can tell us what sites have systems with duplicate hostnames and their OS version/build. At least then we could narrow it down.
@jhartnerd123 - fully understand the frustration and problem regarding how the current MID implementation effects you guys Getting this resolved is something that's been put forth to our development team on my calls and communications, so it's not falling on deaf ears, just not easy.
How the agent currently derives uniqueness is complex and not trivial and changing that mechanism will be hard, was the point I was/am trying to express. 8-)
A quick fix to help would be GSM level endpoint/site searches for various variables, duplicates included. This feature has been asked for and from what I understand, it's in the works.
Just an update to the end point duplication saga and perhaps another wrinkle in it.
I found while reviewing an account today that there were multiple systems duplicated on an account (3) and none of them look to be from a Windows OS upgrade / update.
It appears that there are server and desktop OS systems that had endpoints duplicated.
Just called support and placed a ticket to have the duplicates merged in the account (ticket # 58787) and support advised that this probably won't get done till the new year as they are quite backlogged at the moment.
@Jcard - I can't speak for the specific response by support, but there are several scenerios where duplication may occur besides OS upgrades. Virtualization, VDI and ghosting/imaging technology all have specific issues based upon how those images were created/generated/duplicated.
If these were in fact unique physical machines, then that's something dev/pm team will have to investigate and get resolved.
If you're interested in creating uniqueness or forcing it, use the -uniquedevice (Instead of the -clone) switch during installations.
This help document may help. (-uniquedevice is not listed, but it may give you an idea about various deployment options to minimize duplicates.
@coscooper for the most part our end points are deployed through LabTech which I thought when working with WR support was already set to use a uniquie identifier as when I see the endpoints in the webroot console I can see the there is the system name with a "dash + additional digits" such as the following: LR90FRU32-1FF5E0D5.
Not entirely sure if what you referenced is already set to deploy when doing so through Labtech, although that was my impression when talking with support initially when moving to Webroot.
@Jcard - Yep, that's what I was referencing and yes, LT has the Unique Device enabled by default. So, guess that wasn't helpful for your situation. 8-)
I understand that there might be customers where having multiple endpoints in the same site with the same computer name might be required, this situation is obviously far from normal. Wouldnt it be feasible to have an option to turn on (even if this is not the default) to not allow more than one endpoint with the same computer name in a given site?
+1 for a duplicate-finding aid of some sort. Maybe a report showing duplicate MAC's along with hostname and last seen date?
I've been removing duplicates this week, and the process is very repetitive: export to csv, open in Excel, sort by MAC, tell it to highlight duplicates, and then resolve each pair by removing the one with the oldest "last seen" date.
I feel like this should also be doable programmatically with a SQL procedure that does the same thing: look for records with duplicate MACs, then delete all but the one with the latest "last seen" date.
Thanks @AdamCMorgan for the post to this ticket as it brought it back to mind again.
I skimmed back through the ticket to review things and find that it is coming up on 18 months since the initial post and 12 months ago since my first post on this thread.
Anyone from Webroot have an update on when this issue might be resolved?
I put a ticket in with Webroot on every duplication I find requesting that they merge the units. It is a pain, yes, however I am hoping to raise more awareness as I list the subject of every ticket as "WR duplicate end point with Win10 upgrade" tagging it to the specific account. It takes WR about 24 to 48 hours to actually merge the duplicates for me as it appears that support can't do this themselves and have to put the request in elsewhere to do so.
@coscooperI was hoping that we would have heard something by now as to the status of this and when something might be forthcoming as to resolving the issue. Do you by chance have any update on this?
Duplicates are tricky and dependant on iniqueness of the machine in question. This has been raised numerous times and there are many variables as to the answer to "why" my computer is duplicated. Copied Virtual Machines is number one reason, (which is on the virtual administrator to know and understand before deployment), in place upgrades from WindwosXYZ to Windows 10, is the other whereby it's more prudent to uninstall Webroots agent before the upgrade through the deactivate command prior to upgrading.
There is no "fix", rather it's a requirement to understand how our current agent determines uniqueness through MID, Session ID and host name (along with other hardware factors and hashes) to create uniqueness. If that uniqueness is duplicated through administration efforts or by nature of virtualization, which has no uniqueness, then it's difficult to "fix". Currently, the agent methodology for uniquness is not changing, as far as I'm aware. Any "changes" to the current metholody of creating and tracking uniqueness would greatly effect the current 50m endpoints already in place, so it's not an easy/simple task.
However, all that said, there are efforts underway in development for agent and console architecture changes, which agent uniqueness will likely be addressed. Unfortunately, that will not be realized for some time. Until then, duplication will exists because of fluid and uncontrolled approaches to deployments/upgrades with our current machine identification methodology.