Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Disabling Tamper Protection

Created: 06 Mar 2013 • Updated: 06 Mar 2013 | 5 comments

Hello,

Recently we have finished upgrading all of our managed machines to SEP 12, and now that the upgrade is complete, I noticed that a large number of our clients in SEPM are not reporting client versions, definition versions, etc.  The machines show up as we have our AD structure imported into SEPM, however the fields just say "client version unavailable,"  or something similiar.  I did some research into this and it seems like it is a problem with the hardware ids on the clients being incorrect.  All of the clients I have tested so far are able to communicate with our server as they have updated definitions, and report having successful connections, but no information can be read from SEPM.  I am able to fix it manually by the following steps:

  1. Turn off Tamper Protection by opening the client
  2. Go to Change Settings and select Client Management.
  3. Select the Tamper Protection Tab and disable
  4. Then empty the Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink\HardwareID=""
  5. Delete the file:
    In Windows XP and Windows 2003 systems C:\Documents and Settings\All Users\Application Data\Symantec Shared\PersistedData\sephwid.xml
    In Windows 7.0 and 2008 the folders will be located under C:\Program Data\\Symantec\Symantec Endpoint Protection\PersistedData\sephwid.xml
  6. Delete any client that appears in the Symantec Protection Center.
  7. Go to Start > Run and type SMC -Stop and run
  8. Go to Start > Run and type SMC -Start and run
  9. Turn On Tamper Protection by opening the client
  10. Go to Change Settings and select Client Management.
  11. Select the Tamper Protection Tab and enable

    This will generate unique HardwareID's and sephwid.xml's for each client.

 

Because I have so many machines to fix this on (over 300) I was hoping to write a script that did this, as it would seem to be fairly straightforward, however I am having lots of issues disabling tamper protection from a script.  Doing some research on this it appears you can disable tamper protection by changing a registry key located here:

HKLM\Software\Wow6432Node\Symantec\Symantec Endpoint Protection\AV\Storages\SymProtect\RealTimeScan\disabled

I was reading that if you set that key to 1 it will disable tamper protection, the issue is that it won't let me change that key unless I already have tamper prtection disabled, which defeats the purpose.  Does anyone know of a way to disable tamper protection without having to manually do it on the client?  Ideally I would be able to just disable it temporarily on the machines that need fixed, correct the hardware id problem, and then reenable it, but it is turning out to me more difficult than I thought.  Any ideas?  Thanks!

Operating Systems:

Comments 5 CommentsJump to latest comment

.Brian's picture

I don't believe it is possible. 12.1 now protects registry keys from tampering as well so I don't see this working other than it being a manual process, which isn't really feasible.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

pete_4u2002's picture

disable from the SEPM, when client gets it should take the policy.

SebastianZ's picture

That's really the purpose of tamper protection - to prevent from tampering with SEP system files and registry changes - there isn't and probably should not be any automated way (beside disabling per policy from SEPM) to change this = to disable TP on the clients.

EV_Simon's picture

Sebastian, I have to disagree, I believe that there should be a scripted method for disabling TP on clients to allow for changes to be made to the registry.

 

As an example I have an issue where I have a number of virtual machines that aren't showing in the management console, the fix is to blank the hardware id number in the registry and rename the sephwid.xml file to allow a new hardware id and file to be created. Currently this has to be done manually for every previously provisioned VM and we need to look at how we are going to do this with future VM's (we run a mix of SCCM and VMware, anything built using SCCM OS Deployment get's SEP installed during deployment so that works fine, anything done via VMware uses a pre-imaged template that suffers this issue, if it was scriptable then we could do it during post-build guest customisation).