Typically, this is a function of the user being a local administrator on the machine. You could create a GPO that specifies the exact membership of the local administrator group on the OU the machine is located in. This will <i><b>REPLACE </b></i>the current members of teh local administrator group with the ones you supply in the policy.
This can have some consequences though, some applications may stop working properly or the user may have had access to directories becasue of their membership in this local administrators group.
In the case of applications stopping to work, most software vendors will say the age old “users must have administrator right to run the application”. This is not always exactly true, but instead is the easiest answer. Generally, the application either reads or writes to a location (either files or registry) that administrators have access to write or there is a right or privledge that the user needs to have that administrators have by default… but it’s easier for the tech support people to explain that the user has to have administrator rights. In these cases, you will have to push the subject with tech support, find out what rights/permissions teh user needs, or give them administrator rights to make the software work properly.
are you using Symantec Corporate Edition with the Symantec System Center Console to push the installations and updates to the workstations? If you are there is a setting in there that, if checked, will deny the user from being able to disable the client or make any changes to it. This is the best way to do it instead of creating more changes in your GPO’s.
To prevent users from stopping the SymantecAV services using a GPO. First create a new GPO named i.e. SymantecAV_ServiceLockDown using GPMC. Then edit the specific service settings in Computer Config–>Policies–>Windows Settings–>Security Settings –>System Services–>Symantec xxx. and set the ACL so only the local system and local administrator accounts have modify rights to the service. Then link the GPO to your targeted OUs. Note, As with any GPO make sure you test the GPO to make sure it does what you think it should so and that it does not break Symantec. I suggest creating a GPO Test OU and place a test system(s) into that GPO. Then link the new GPO to the GPO Test OU. Fully Vett the GPOs performance before rolling into production. P.s. if your users have the local administrators PW they will be able to log on with that account and muck with the service settings. Hope this helps