Unmanaged Detector Not Reporting Unmanaged Endpoints Correctly.

[Migration User]

Catchy title but unfortunately doesn’t describe much.  And, I know this topic has been beat to death, but…

I have an annoying situation whereby the results of my Unmanaged Client Detection Report contain systems that have been offline and disconnected for a long period of time; in the case of some systems, several weeks.  Another issue (to a much lesser extent) is that some systems that have pervectly good SEP Client Installations that check into the SEPM just fine and have Computer Objects in the proper SEPM group, are being reported as not having a SEP Client installed.

What I’d like to find out is how to go about “flushing” the IP/MAC-Address cache (if that’s what it actually is) on the Unmanaged Detector system.  

I’m not sure exactly what info you all need, but here are a few details that I’m guessing you might want to know.

-       Domain Properties: “Delete Clients that have not connected for specified time” = 14(days)

-       Database Properties: Truncate Database and Rebuild Indexes = Daily

-       Version 12.1.3

-       SEPM on 2008 R2 Std

-       Clients are mostly Win7 Enterprise or XP Pro

-       Using SQL database (2008 R2 Ent)

-       Using AD Authentication (for logon) but not Synchronized with Directory Servers

-       DNS has no record of the offending IP’s (and we don’t use WINS)

-       Many of our systems are road warriors who are in-office WiFi for a week or two and then out on the road for a week or two. Most systems, however, are in-office LAN-desktops.

I read that one solution is to remove the Unmanaged Detector and then re-add it but I hesitate doing that because I have a hundred, or so, exceptions added and they clear once the UD is removed.  Unfortunately this particular UD covers an entire B-Class range and there is an entire zoo of various non-Microsoft systems with non-sequential IP addresses all entered as MAC addresses (one at a time, of course-but that’s a matter for another thread).

Another solution was doing SQL commands in the database directly (which is sort of like brain surgery to me).

I’m somewhat lost here on this one.  Any and all help is seriously appreciated.

L.

[ℬrίαη]

Here is Symantec's recommendation:

http://www.symantec.com/docs/TECH93440

But I assume you won't want to go that route.

I used to have a query to remove from the DB, I'll see if I can dig it up. It's been a couple years since I've used it as I've moved away from unmanaged detectors.

I may suggest a support call could be the easiest (and supported) way of doing it. They may be able to get you sorted out quickly. Especially being the latest version, it could be a bug of some sort.

 

[Migration User]

Brian,

I think you're right about opening a support ticket.  and yes, I don't want to go the first-suggested route (yikes).  A bug, I can believe.  I can't for the life of me think why....

I also think that moving away from the unmanaged detectors might be a good idea, but until we get a better handle on our endpoints-as a whole-that might not be the best thing to do.

L.

[Mithun Sanghavi]

Hello,

Configure SEPM to remove clients which have not connected within a specific number of days.

1. In the SEPM, go to the Admin page.
2. Select Domains.
3. Under Tasks, select Edit Domain Properties. 
4. In the Edit Domain Properties window, on the default General tab, note the option to "Delete clients that have not connected for specified time."

Configuring a low value for this setting would clear up the duplicates more quickly. 

It is important to consider clients that are offline over the weekend. Setting this value to 1 or 2 will likely cause all your clients to be removed after a weekend.

 

A recommended value for large enterprise environments would be 7 to 14 days.

 

Check these articles:

 

http://www.symantec.com/connect/articles/duplicate-sep-clients-appear-symantec-endpoint-protection-manager-console

SEP Client UnManaged Detector sending wrong logs.

http://www.symantec.com/docs/TECH190291

Hope that helps!!

[ℬrίαη]

You can also consider setting “Delete Clients that have not connected for specified time” to something low, like 10 days to see what that does.

[Migration User]

Mithun,

Thank you for sharing.

I won't be doing the suggestion in TECH190291.  As I said earlier, when I disable the Unmanaged Detector all the exceptions vanish. ...All 100+ of the individually-input MAC addresses.  Until Symantec comes up with a way to export & import a list of them, there's no way I'm inputing them all, one-by-one again.

I'm not getting duplicate entries in the SEPM. It's just that some systems that were on the UD list at one time, that got a client successfully pushed to them through the SEPM, are still being reported as not having a client. It's as if the UD isn't clearing itself of previous entries that it found at one time.

The "Delete Clients..." value was set to 14 but per Brialn's suggestion I've set it to 7.  I don't think I want to go any lower than that.  When it was set to 14 days, I still had entries in todays UD Computer Report of computers that were take offline 26 days ago.

Said differently,  A small number of computers taken offline 26 days ago, that do not respond to pings nor have any DNS data, is still being reported today by the UD as not having a client.  If the system is not online, and hasn't been for 26 days, how is it being detected as not having a client?  How is the Unmanaged Detector detecting these systems?

Thank you.   Your input is greatly appreciated.

L.

[ℬrίαη]

This is why I would lean more towards some sort of bug. If the system is offline, I don't see how an unmanaged detector could possibly detect a "ghost". Perhaps something is hung in the database.

[Migration User]

After careful evaluation I've come to the conclusion that my best bet is to not use the UD system at all.  

And here's why:  (No order of precedence, just what happened to stream out first)

1.      Uncooperative Network Design.  Here’s what I mean by that. Our Network folks have segmented things by function rather than property-meaning we have linux windows cisco and all other manner of device in each segment all mixed together because they all work together.  No (or little) thought was given to dividing up the segment into logical IP ranges per device type; everything is given an IP address because the address was simply unused.

2.      The Unmanaged Detectors are essentially crap.  They don’t discriminate what they find, if it has an address, it’s listed.  Seriously? They can’t just show me the Windows units?

3.      The Unmanaged Detectors appear to be “buggy”.  Sometimes they list systems that have SEP Client installed fine; sometimes they don’t list the clients that have a corrupt installation; sometimes they list clients that are not online and haven’t been for weeks.  The UD is just unreliable.

 

OK, so if you’ve bothered to read to this point, you can stop now because this is where I start the rant.  (unless you’re a Symantec EP product manager)

I think that overall, if clear effort was given to making a UD System that actually worked as one would expect it to work, it would be a nice feature.  But…

Symantec is missing the mark on client discovery/installation/repair/reinstallation of the fringe endpoints in the wild.  IMHPO, the ability to completely silently, and without reboots, manage the installation conditions and properties of ALL SEP Client endpoints, regardless of where they are, is an absolute MUST HAVE.

The biggest battles I have with SEP are remediating corrupt or bad client installations remotely; especially the clients that exist on the other end of a café or hotel internet connection (not VPN).  Luckily, many of our endpoints exist solely in-house and sometimes have the same IP address two days in a row.  Our Help Desk can visit those if necessary. But should they have to?  Me-thinks not.

The take-away here is that Symantec needs to develop a mechanism to remotely remediate a SEP client malfunction, completely and silently, from the SEP Management Console. 

OK, rant over.  …and no you can’t charge me therapist fees.