Here is a strange one for you experts! Device policy ghosts!
I'll try to recall this from memory as it was a VERY complex and frustrating week last week.
We'd been having a lot of folks violate our "no USB/thumdrive written policy and rule" so I decided to let SEP take over.
I've been successfully doing this for months in a test group and a group where I put naughty folks. Block all USB, but in the exceptions, put HID, printers, scanners/cameras and the Olympus DVR (Digital Voice Recorder for dictations)
It worked fine - that group could print, but not use any USB memory stick, and their keyboards, mice, scanners, etc. all worked great!
In the larger group, I was blocking one device at a time, either by vendor or by device name and each week someone would drag in a new device and give it a go after their other quit working :-)
So on the larger group, I simply made sure the exclusions were there - they were from way back "just in case", and then added the "block USB" to the upper rules.
Well............ all heck broke loose! Suddenly NO HP USB printer would work! Deskjets, lasers, if it was USB it stopped functioning even though printers were excluded - and besides that, those with video camers now saw a popup when their camera was connected, something that had not happened before. The cameras worked, but they just got a new message stating it was ready.
OUCH!
I tried EVERYTHING! A massive policy refresh, and I even REMOVED the block USB line and it didin't help! For days, no one could print!
The one single thing that DID work on everyone was this:
Highlighted all computers in the main group, moved them to a test group with NO USB policy blocking anything but one or two items, waited a few minutes, did a forced "update content", waited a few more minutes, then moved them all BACK!
WOW, suddenly my inbox is filled with messages "blah blah blah enabled" as all their printers were enabled and it logged THAT and sent me an email!
WHY???
Why the email and logging that the printers were enabled, and why did moving them OUT, then back IN to that group "fix" the issue?
What the !@#%^&^&$% happened!???
Boss wants to know - in case. This was a disaster of epic proportions and we all got called to the principals office if you know what I mean..................
The policy is still not set to block USB - as I'd removed that bit in an attempt to fix things. It seems as if the block USB was stuck and mving the clients out and back unstuck it. HOWEVER, I have a test group that has USB blocked and they print fine - same exclusions, etc.!
WOW!
Comments
weird
Weird indeed. Even if the possibility existed that the HP driver and printer software somehow got updated via some auto-update feature, it doesn't explain why removing the policy didn't fix the issue.
But wait, there's more!
But wait, there's more! (LOL)
After I THOUGHT I had it settled last Wednesday, now today there's 4 computers STILL not printing to their USB printers.
Well, they go into the queue - but sit, and the printer says "off-line".
I had to work them back and forth between groups again, and then the printers went online.
I checked the policy, and nope, the block USB devices isn't there, and in fact, under EXCLUSIONS, I have
*USBPRINT\*
AND
the printing devices CLASS as furnished by Symantec in the default devices list.
So the printers are excluded by class and by device generically from being blocked.
I removed the "USB Class" from blocking LAST WEDNESDAY.
Geesh, it won't die!
Yet the test group has the USB class in the blocked area and the printing device class in the exclusions area and works ok.
The main group even after removing the USB class from blocking caused printers to stop. Odd as other USB devices continued to work!
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
oh boy
sounds like it's time to open a case with support!
Subscibing to this thread.
Subscibing to this thread. Very interesting to say the least. I am sure you will keep us updated ShadowsPapa, you always do. Hope it all goes well and sorry I don't have any answer to give.
Grant
Please don't forget to mark your thread solved with whatever answer helped you : )
@ Grant - I'd say that this
@ Grant - I'd say that this would merit the attention of some ADV / GL / BL folks as well, not to mention the TPM's.
@ Shadowspapa - This is happening on MR4-MP2 right?
Abhishek Pradhan, PMP, MCT
Consultant | Microsoft Corp.
Blog: http://blog.abhishekpradhan.net | SIG Lead - Pune IT Pro (Microsoft Pune User Group) | http://www.puneusergroup.org
This is with MR4 MP1a. I'm in
This is with MR4 MP1a.
I'm in testing with MP2
Now - I'm asking anyone, INCLUDING tech support, the Symantec regulars - DOES THIS APPLY IN THIS CASE:
----------------------
Symantec Endpoint Protection Manager does not update content for clients after upgrading from MR4 to MR4 MP1
Fix ID: 1539713
Symptom: Content on clients is not updated after upgrading from MR4 to MR4 MP1.
Solution: When moniker and sequence number are not synchronized between Inetpub, symcdata and registry, SesmLU needs the full folder and if necessary SesmLU will create this folder by extracting the related full.zip file.
----------------------------
If my contention that Content = definitions and policies is correct, then,
IF I am correct, our move to MR4 MP1a is what broke this, and MP2 may fix it????
Can anyone verify this????
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
I have seen a similar issue
I have seen a similar issue with firewall rules.
The basics of the problem were editing a firewall rule did not change the policy serial number of the groups where that policy was applied. I was never able to definitively prove it, but it appeared that since the serial did not change, the policy never updated. Now when I change a rule like that, I open one of the group specific settings and just hit 'ok'. This updates the serial and you can verify that the clients get the new policy several minutes later.
Reported to support a long time ago with a number of other issues around MR3. Don't know what happened to it though. There are also some App/Dev things which require a reboot, could this be part of the issue?
We not only did a reboot, I
We not only did a reboot, I had them turn off the computer AND printer, and then start the printer, wait 1 minute, then start the computer. No affect.
I wonder about items that change serial number......... I thought any policy change actually changed the number because it was date/time based.
Is that not correct or am I thinking of something ELSE?
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Yes, it is date/time based. I
Yes, it is date/time based.
I just re-checked with my test MR4-MP2 install and everything seems ok now. Disregard my post above if you are using that version. Can you verify that the serial number on the clients who still have 'bad' policy is the latest version?
Shadows...
I have seen it before. I had a Framestore, connected via 2 FiberChannels to a PCIE card in a machine. Symantec, went ape sh** and detected that it was a "generic volume" and interpreted it as benig a USB stick. Yeah, a 10 TB USB stick... Anyway. Still no resolution on this one. Had to remove the app/device bloacking for that machine completely and disable the USB ports in the Bios.
Now, some HP printers, using the DirectJet printing ethernet adapters, when connected to a USB poprt on a machine, may be "interpreted", because they have some minimal storage capabilities as USB drives. I.E. Generci Volumes. I know you said you removed the rules... but are you blocking "storage devices"?
Might be worth looking into...
Or I can be completely off base on this one.
We block CURRENTLY, as the
We block CURRENTLY, as the policy is now, by specific brand or device ID.
I took blocking of USB out and do it device-by-device now.
I've excluded the USB printing class, and further, added my OWN hardware exclusion.
We DO block the HP drives that are installed with their printers because they are never ever ever used and they take a drive letter away from other devices we use.
So if you have an HP All-in-One, the slots on them won't work. Stupid, IMO - for HP to install those slots as a drive and assign a letter to them when we don't use them, so I block them. You can see that in this screen shot.
However, to this day, this AM, I've got 2 printers that won't print!
We block any devices that may carry our information unencrypted - it's the law here.
So we block any PDA or blackberry storage, they can't drag client medical info outta here.
We block the slots on the HP printers, note the last entry in the blocked devices area.
OTOH, note the last entry in the excluded from blocking section.
So we should be able to use any thing USB, except storage devices specifically named here.
ARRRRGGGGG!
Seems to me it's that the policy got out there that had the block all USB except these items, and it blocked printers for some reason even though printers have ALWAYS been excluded, and now that policy bit won't go away.
Seems like a nasty nasty BUG in the software, IMO.
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Interesting...
Well thats interesting but i have seen many weired things with SEP so i am not that much surprised.
As you said that once you changed the group and back again Printers started working.
That states content is getting updated so Fix ID: 1539713 is not a question over here and looking in the release notes other than
After enabling a "Block USB" write policy, files located on network shared folders take longer to open and save
Fix ID: 1475460
nothing has been touched in Application and device control so upgrade might not be that helpful.
However I dont see Human Interface devices in the exclusion list.
So if you try something out in the test group like put Human Interface deivces in exclusion list with all other exclusions that you have created and then try blocking USB.
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
See the scroll bars? That's
See the scroll bars? That's why you don't "see" HID in the list - it's at the top and out of view. Screen shots are limited to showing what's on the screen at the time of the shot, not what's there but you cna't see without scrolling...... ;-)
Keep in mind, when I change GROUPS, there's a WHOLE LOT more changing than just that one policy! Someone said that if some other thing was changed, it seemed to force the policy change, so I'm thinking that's what is doing it - changing groups changes those other settings, too, and causes the policy to FINALLY change.
Otherwise, it also seems that the old USB blocking I used to have in place gets "stuck" and moving groups is the ONLY way that unsticks it! There are many many dozens of things that change in a move to a different group, and I think that's what it triggering it. Otherwise, changes to this policy within the group don't have impact, or it's like they don't, then suddenly do with a vengence.
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
@ShadowsPapa: How do you get
@ShadowsPapa: How do you get the device name id for the specific USB storage device...
thanks..
Nel Ramos
Regedit - I use remote
Regedit - I use remote regedit connection to get info from machines used by folks who have been naughty.
I can't run said tool on 200 computers that are 4 hours away............
But I CAN regedit and do:
HKLM, System, currentcontrolset, enum, usbstor and see what they've connected..................
Once connected one time, the info is in the registry...........
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
@Dperfekgent
@Dperfekgent
DevViewer - a tool for finding hardware device ID for Device Blocking in SEP 11.x / 5.x
http://service1.symantec.com/SUPPORT/ent-security.nsf/ppfdocs/2007511906325898?Open&dtype=corp&src=&seg=&om=1&om_out=prod
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
Would you like to reply?
Login or Register to post your comment.