Skip to main content
Hi,

 

Has Webroot found a resolution to the problem of duplicate entries in the GSM console when agent systems upgrade to Windows 10?

 

We're constantly having to deal with going into the GSM and look for and deactivate the older duplicate (the windows 7/8 system) when they are upgraded to 10 in order to prevent being billed extra for endpoint usage.



Tsk Tsk...

 

John
Not that I've heard - the workaround is still just to remove the old entries. I'll double-check to make sure I have the most recent info.
yeah, that's hard to do when you have thousands of endpoints spread across 1200+ Sites on 2 GSM's.

 

This should be a top priority to get fixed. Neither us, nor our clients like to be double billed

 
Sorry about that. Here's the latest KB on the issue:

http://www5.nohold.net/Webroot/Loginr.aspx?pid=4&login=1&app=vw&solutionid=2428



If you're still having issues please open a ticket and that way we can make sure it gets documented and escalated.
This issue seems to have come around again with the Win 10 anniversary update and is a pain in the butt to deal with.

 

When is Webroot going to fix this issue?

 

Anyone have any update on this?



Thanks,

Jeff
Hi @,



Please contact our Business Support Team directly for the latest update:

Business Technical Support: Call 1-866-254-8400

Open a Support Ticket: http://mysupport.webrootanywhere.com/supportwelcome.aspx?SOURCE=ENTERPRISEWSA
Hello there,

 

Thank you for your response to my inquiry. I really wish it were that easy.

 

I have talked to the business support team yesterday and today when finding duplicate agents on different accounts from Win10 Anniversary updates. Submitted tickets both times with support.

 

Support advised that they have no idea when this will be fixed or resolved. Similar answers I got when this started happening with the initial Win10 upgrade issues that spawned multiple duplicate end points. When I pressed the issue support advised that other pressing issues arose that delayed the work on this issue, although still have no update when this issue will be looked at and/or resolved.

 

Would be nice to actually have an answer as to when this will be fixed and/or come to an end, however support does not have this answer to provide at this time.

 

Thanks,

Jeff
Webroot partners beware if you are billed through a 3rd party vendor for your Webroot seats that it is up to you to request and get credits for duplicate billed seats.

 

Dealing with a third party who we purchase our seats through who appears to have had no knowledge of this issue ever. When talking to someone at Webroot they got the same puzzled response as if this issue was brand new and no one seemed to have heard that this is a long standing issue.

 

I am calling Webroot on any incidents of duplication going forward as it does not appear that there is enough attention to this problem that has yet to be addressed and fixed.

 

It is also up to you to find these duplciates on your own as Webroot does nothing to track these down and take care of them that I have seen.

 

Disapointed in the response to this issue by Webroot. 



I can't be the only party that this is affecting and by the response by the thrid party billing entity and whom ever they are dealing with at Webroot it appears that this is a brand new occurance that they have never heard of before.

 

I am curious to hear if anyone else is getting this response from Webroot? Definately this forum thread is one that has not gotten any response or update as to the resolution of this issue by Webroot.

 

Thanks,

Jeff
Yes, we are experiencing duplicate entries with 10 and 10 anniversary upgrades as well. It's extremely annoying.

 

You have to manually go to each and every site and then the group management tab and then look for the duplicate hostname entry and then look at the windows version/build and remove the older entry. That way we won't accidently invoice our clients for too many endpoints.

 

There's no fix yet, but they soon better issue one as we are now pushing 5000+ endpoints and simply saying to contact support isn't getting to the root cause and it puts a strain on the support personelle. If i were to place a ticket or call to support for every incident of this and have them fix it each time, they'd have at least 100+ calls and tickets in.

 

 
@ & @ - I do apologize for the inconvenience, however, there is no "easy fix" being requested given the nature of how Windows works and our agent determines uniqueness about an endpoint.

 

> When the WSAB agent is first installed on a machine (Win7, 8 etc) it takes a set of parameters based upon hardware and operating system information to generate that unique machine ID.

> That unique machine ID, not just host name, is how our console identifies it as unique and different from all of the other millions of machines in the world we see in our systems. (You can reveal this information in the Group Management tab on your console and show the MID column.)

> When the Operating system is modified (Upgraded in place is usually the culprit) it changes one of the core unique parameters and therefore changes the machines unique identity.

 

So, there is no programmatic way our agent can detect this change when you or your end user upgrades in place. Windows 7 or 8 to Windows 10 is a core operating system changes and a major upgrade, not an incremental simple update.

 

If they're wiping the machine, upgrading and reinstalling the WSAB agent, again, the agent is simply reporting what it knows - a different machine.

 

The only option you guys have to get ahead of this is to address this BEFORE the user or your tech team upgrades these systems. Simply deactivate the old endpoint host in your console, upgrade the operating system and reinstall the WSAB agent after the upgrade is complete.

 

From a billing perspective, PM me, let me know who your third party reseller is and I'll reach out to the channel manager for clarification to their selling partner about these incidents.

 

If you're using a partner that supports 30 day true up billing, these duplicates will not effect billing as the reports are based upon a last active in 30 days. The older system (pre upgrade) will drop off after 30 days not seen as technically it's no longer active and should not show up on any invoice.

 

Hope this helps.

 

 
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.
@ - 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.

 

Thanks,

Jeff

 
@ - 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.
@ 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.

 

Thanks,

Jeff
@ - 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. 😎
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 @ 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.

@I 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?

Thanks,

Jeff

 

 
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.
Shane,

 

I know Webroot has it's own method for determining uniquemess based on MID, Session ID, but what us end users keep saying is that a uniqueness test based on the combination of site, computer name and mac address, especially where one agent has it's last checkin at a certain time/date and the other one does it's first checkin 2 minutes after that, is a pretty comprehensive case for being a duplicate. Even if we could be presented with a list of possible duplicates across all sites and manually deactivate them (or perhaps have each of the potential superceded dupes be already marked for deactivation. I would prefer just to get a report each month of the machines that Webroot has identified as dupes compared to another machine and automatically deleted.
By the way, this is another good use case for "server-side" sorting: finding duplicates would be much easier if we could sort all agents by MAC (instead of only the first 50).  That way we wouldn't have to export to csv to find duplicates.  🙂
Fair enough everyone. We've pushed to expand device sorting at the GSM level. I personally brought this up on recent PM calls, so it's in discussion. While changing the approach to uniquness is probably not going to take place until an overhaul is finished, I can at least offer that we'll push PM to put some tools in place to help eleviate this pain point. Also, we've brought up some automation around "not seen" in x, y or z days, so if the previous duplicate goes stale, it will fall off and be deactivated based upon a rule rather than even having to review these every month or so.

 

Please keep use cases coming as they help sell our story to the approrpiate team who can develop these changes. 😎
Thanks @, appreciate you communicating this stuff internally!
FYI for everyone else in the thread: I just learned about the Webroot Unity API today, and I think it's the solution to many of my problems.  I've gotten the Postman example from the getting-started guide working, and am trying to figure-out the Powershell code to connect and make simple queries.  If you're in the same boat as me, it might be worth checking-out.  There's also a specific forum for the API here

PS: I'm also gonna cross-post this in the "Out of Sorts" thread.
Here's a PowerShell script I wrote to help find duplicates.  Exports a csv of all endpoints at all sites, sorted by SiteName, MACAddress, and LastSeen.  If you tell Excel to highlight duplicates in the MAC column, the problem-children are easy to find. 

Permalink: https://community.webroot.com/t5/Unity-API-forum/PowerShell-script-to-locate-duplicate-computers-in-GSM/m-p/309165/highlight/true#M58

Reply