Endpoint Protection

This is mostly regarding AC 14-1.1

PLEASE read the full paths I post completely so you are sure it's what you think it is........ Thanks.
I have the policy set downloaded and am applying parts in TEST/log only mode (thank goodness!) Tech article 132337 for those wanting to follow along, and for those wanting to help, so they know to what I refer.  First, this is GREAT - KUDOS to the Symantec person who posted this. I learn by example and pictures, and this is one of the most helpful things to come along for SEP policies in a long time.

Now to the questions. I've found a couple of things that prevent this from allowing even a perfectly normal system from working. First, it prevents anyone from printing anything from IE either to a local printer or to a printer on a print server - I had to create exceptions similar to this:

C:\Windows\system32\spool\PRINTERS\*.SPL

%windir%\system32\spool\SERVERS\*\*.SPL

Second, I'm baffled - on the surface it would appear to block IE from keeping any history - in the cache or in the history.dat files, from writing cookies (even good ones) and from generally keeping the NORMAL windows logs for history and cache. WOW - HOWEVER, it appears to be doing so only on TWO computers!! Weird. For several hours, folks were merrily browsing along and I saw no log entries stating that the policy would block, if in production mode, any IE cache or history. Then two notebooks suddenly started triggering log entries for all sorts of things.

Can anyone explain the following - first, why do the two notebooks seem to say that IE could not write to the cache or log if this was production, while other computers seem to not care, second, what are some of the below entries and why would IE need or want to touch these files?

Why is IE touching or wanting to touch these:

C:\Windows\system32\AUTOCHK.EXE

C:\Windows\INF\setupapi.app.log

Next - why does this set of policies seem to block IE from using the normal cache and history on a couple of computers, but not others? OR, is it that it DOES, but no one else was browsing Friday?
SEP seems to want to block access by IE to these - but it would seem it's critical that these be put in as exceptions, correct? Anyone else using this policy set that can help? We REALLY need to harden things even beyond what my brilliant (cough-cough) mind has already done, and this is a great way, but I'd like to know what's up with these items, and what others have done....

C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Windows\History\History.IE5\index.dat

C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files

C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\

C:\Windows\system32\config\systemprofile\AppData\Roaming

C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\Windows\Cookies

C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\Windows\Cookies\index.dat

C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Windows\History

C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Windows\History\History.IE5\

Huge thanks to all.

1. You can ignore both of these files as they are both non essential. Autochk.exe is related reverting back core system settings back to their original state.

Setupapi.app.log contains info about application installation.

Since IE is just another app, I would suspect most apps on systems try to touch these files.

2. Is everyone on the same version of IE across the board?

Yes, they are all identical images with the same IE on all.

So if IE can't touch those files, say I put this into production mode - no ill effect?

OK, so what about the cache, history, etc. - IE obviously needs to touch those! So I would suspect I need to put exclusions in place.......... It's critical that Windows and IE be able to keep history files  - for some managment needs, etc. plus I suspect IE might break if it can't write to those.

Since they are non essential, I would think it would be ok. Perhaps test on your PC first?

Yep, exceptions would be the way to go. My thought was maybe a few were on different versions and file and folder paths may be different for different versions.

Almost every computer is also seeing IE touch this area:

C:/Windows/system32/rundll32.exe

Not sure why unless it's to launch a plug-in, or active-x thing. Pretty much all doing it, even totally normal computers with no risks, and visits to ordinary sites.

Yea, that's a tougher one. Possibly a BHO? But I didn't think you allowed them?

Process Monitor/Explorer would be key in finding which DLL wants to run.