We had a well functioning SSR Managment Console (10.01), but decided not to use it anymore. We uninstalled it from the server that hosted it.
But now, the client boxes for which it was controlling SSR, have backup jobs and other settings that are locked. If we try to make changes, popup appears
"The backup job <name of job> is controlled by a central management system. contact your admin"
How do I remove the software on the clients that is locking SSR? I don't want to reinstall on each client box.
Solved! Go to Solution.
Go to the control panel and check if you have uninstalled "Symantec Platforms and Solutions".
If not uninstall the same and it should unmanage the backup jobs for all the clients.
You Need to make sure below mentioned plugins are been uninstalled from remote client system.
1) Symantec Management Agent
2) Symantec system recovery Management solution plugin
You dont have uninstall the Symantec System Recovery. If after removing the above components doesnt resolve the issue then you have to delete the backup job from the client system and then recreate the backup jobs.
Removing the symantec mgmt agent and the system recovery 2011 plugin did not unlock the backups.
Tech support had me delete the schedule folder, history, and servername.sv2i file from the SSR directory in ProgramData\symantec\Symantec System Recovery directory.
Here is the line from the .pqj file that contains the only two "managed" keywords AFTER I had recreated a new, unmanaged backup job.
vt="11">0</IncludeSystemFiles><Managed vt="11">0</Managed><GenerateACL vt="11">0</GenerateACL><EnableAutoSync
Is the zero in the top line the attribute you are referring to? Unusual format for attributes.
Markus and Tripti:
I had already removed the schedules manually, per the fix offered by Symantec tech support on the phone.
Your suggestion for fixing the PQJ file is certainly more elegant, but I won't have the chance to test it this time. I've used the brute force method of deletion on all my servers.
I'll remember the suggestion, though, for next time.
You may be aware of this but in case you are not...
To completely avoid this situation from occurring, the backup policy should have been disabled on the SSR-MS server. Once this was done, it is a case of waiting for all client machines (that are associated with that policy) to 'poll' the SSR-MS server for updates. At this point the policy would have been removed from each client machine.
Hope that helps going forward...
Chris-- Yes, that would have been the correct way to do this. But the SSR-MS had to be removed quickly because of a Nessus (security) scan. Fastest thing was to remove the SSR-MS server itself.