The newly updated Symantec Protection Suite Small Business Edition 4.0 contains Symantec Endpoint Protection 12.1. As part of that offering, there is a module called “Tamper Protection,” which is designed to prevent any form of malware from adversely affecting the operation of the Symantec Software.
As a managed service provider, I am using a third-party software product to monitor and maintain the health of my clients’ servers and workstations. The software takes an inventory of a variety of things and reports back to the data center on a regular basis. I get to view the results on my web-based portal.
Somehow, and quite unfortunately, Symantec Endpoint Protection thinks each of these activities is a threat to its existence, and the default setting for Tamper Protection is to block any offending program. When it does, it places an entry in the Windows Event log.
Windows EventID 45
Of course, my MSP software is designed to keep trying to get its information back to the data center – so the Event log just fills up with EventID 45 records as it struggles against Symantec Endpoint Protection.
There has to be some way of preventing this.
The Symantec documentation (Symantec™ Endpoint Protection Small Business Edition Implementation Guide) describes a process whereby you can create exceptions to eliminate this sort of conflict. Terrific, let’s follow the procedure and update the global Exceptions Policy.
Creating a Tamper Protection exception
You can create exceptions for Tamper Protection. You might want to create a Tamper Protection exception if Tamper Protection interferes with a known safe application on your client computers. For example, Tamper Protection might block an assistive technology application, such as a screen reader. You need to know the name of the file that is associated with the assistive technology application. Then you can create an exception to allow the application to run.
1. On the Exceptions Policy page, click Exceptions.
2. Click Add > Windows Exceptions > Tamper Protection Exception.
3. In the Add Tamper Protection Exception dialog box, in the Prefix variable drop-down box, select a common folder.
When you select a prefix, the exception can be used on different Windows operating systems.
Select [NONE] if you want to enter the absolute path and file name.
4. In the File text box, type the name of the file.
If you selected a prefix, the path should be relative to the prefix. If you selected [NONE] for the prefix, type the full path name.
5. Click OK.
6. If you are finished with the configuration for this policy, click OK.
So, I added the offending program files, assigned the updated policy to the server, and thought that all would be well.
Only it wasn’t. Not by a long shot.
The MSP software continued to generate errors. Symantec continued to block it.
Open up the documentation again and do some more reading. Aha! I can change the setting for Tamper Protection from “block” to “log” and assign the updated policy to the server.
Now that’s better! But only slightly.
The MSP software is now permitted to run; however, Tamper Protection is still logging the encounter as an error and posts EventID 45.
Naturally, I opened up a support case with Symantec. Over the past two days, I have spent more than an hour and a half on this, only to find out that “it is known issue and Symantec is working on this.”
Which is absurd! This product has been on the market for years, and the latest version is supposed to be the best one yet. How can the basic, built-in, functionality of the product not work the way it is supposed to?
So, I guess I will just have to wait for an update – after I archive and clear the filled up Event logs from the server.