Centralized Exception Configured From The Console

[Migration User]

I'm on SEP 11.4000. If I were to configure some exceptions using the console, can the client see what those exceptions are?
 

[Migration User]

If you create a Centralized exception policy on the SEPM itself and apply the policy to the group in which the client exists, the client (PC) will receive the exception.

If you have configured, that ONLY SEPM centralized policies are accepted, than the user on the machine will not be able to create his/her own exceptions.

If the user has access to the Client and is capable of opening the console (Shield and green dot in the taskbar) without entering a password, he/she will Not see the centrally configured exceptions.  The only settings they can see are the ones they create themselves if permitted to do so, by the administrator of the SEPM.

[Migration User]

They will not be able to see the centralized exceptions that you created at the console.

[Migration User]

How do I know whether the centralized exceptions are getting applied to the client/agent?
I need to set some folder exclusions from scanning.

[Migration User]

Hi,

Another question - which overrides which? exceptions configured from the console or user exceptions added from the client?

[Migration User]

In theory, if the client is receiving it's updates and the policy has been applied to the group in which the client exists, than the client has received the updates. 

The second question is interesting.  One is for a single client (local) and the other is set for a group (global).  So if you both set the same rule, than one or the other will work.  If there are contradictary rules, I.E.  Client sets up: "do not scan C:\TEMP" and SEPM sets up: "scan C:\TEMP", than the global should take precedence over local...

[Migration User]

To know whether the centralized exceptions are getting applied to the client/agent?

To check the policy serial number at the server
Login to the Symantec Endpoint Protection Manager console
Select the Clients button on the left margin
Select the client group that contains the client that has the issue
Select the Details tab in the right hand pane
Copy down the policy serial number.

Example: E0C4-01/09/2008 14:39:16 311

To check the policy serial number in use at the client
Launch Symantec Endpoint Protection from the System Tray icon or the Start menu
Select View logs button
Select the View Logs button to the right of Client Management and select the System Log
Select the Filter from the main menu and select Show All Logs
Browse for the most recent entry labelled "Applied new policy with serial number..."
Compare the serial number with the serial number shown in the Symantec Endpoint Protection Manager console

Example: E0C4-01/09/2008 14:39:16 311

If policy serial number are same on both the side than the policy is implemented successfully


Please check this link also

Can no longer see the Administrator-defined Exceptions Tab on Clients after migrating to Symantec Endpoint Protection MR3 or MR4
http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/73a278b5de8e0af9882574d40064cd2c?OpenDocument

[Migration User]

Great thanks. I will check it out.

One more thing - when you configure an exception to exclude a folder, such as C:\Program Files\SQL Server, do I enter the exact path in centralized exception? Does the SEP console know how to handle the space in the path?

[Migration User]

You can enter the exact path, or use a common system variable that SEP provides. If you click on the question mark next to the "Prefix Variable" when you add the centralized exception, you will see an explanation of the variables that SEP provides. You shouldnt have any problem with the space in the path.

[Migration User]

Great thanks.

[Migration User]

You might want to check this registry

To see the exclusions that the client creates on 32-bit computers, you can
examine the contents of the
HKEY_LOCAL_MACHINE\Software\Symantec\Symantec Endpoint
Protection\AV\Exclusions registry. You must not edit this registry directly. On
64-bit computers, look in
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Symantec\SymantecEndpoint
Protection\AV\Exclusions.

[Migration User]

Oh Thanks. Is there a registry to see the centralized excpetion on the workstation?

[BobH1721]

I currently have unmanaged clients that have their own Centralized Exceptions defined. When I convert these clients to managed, I have a policy that prevents users from creating their own exceptions. In testing a client after I converted it to managed, the unmanaged exceptions are still listed on the client even though the user cannot add, edit or delete. Are these exceptions really still in affect?? If so, is there a batch (or any other) process I can use to get rid of the exceptions that were defined before the client became managed, i.e. registry key, file edit, utility, etc??   

[Migration User]

My recent testing with RU5 shows that local exceptions are still active. I excluded the entire C:\ and had no problem downloading EICAR to it. Whatever I did on the Manager,  the local exceptions stayed active, until I removed them from the local exception list locally.

Completely unacceptable! Is this a fundamental design flaw, or just a bug?

[Migration User]

@fnordgren - In the centralised exception you can set User restrictions. 

[Migration User]

Yes, but those only restrict the user from adding new or changing/deleting current local exceptions. The User Restrictions even block the user from removing any local restrictions he might have added earlier. 

Systems that haven't had a centralized exception policy applied from the very beginning, and for that matter, unmanaged systems turned managed, might have existing local exceptions. AFAIK, those local exceptions are 100% unmanageable by the central SEPM.

[Migration User]

 Well..Yes that is correct..it looks to be a design flaw.