One of the things you might want to do is delete and remove components from SRM. When you go about doing that it's important to understand the relationships that bind the product together. SRM “protects” itself by stopping the SRM Administrator from deleting components we dependencies reside. This is something I’ve seen in other management tools – probably most notably the EMC NaviSphere/UniSphere application that stops you from removing objects, that will subsequently create orphaned objects or break a process altogether.
The experience can be somewhat annoying – hey, I’m the administrator you say, I should be able to do anything like. But I personally think the intention is good one. I’m the kind of guy who doesn’t like to be wrapped up in cotton wool, but at the same token – I rather like idea of not being able to make a situation worse by the indiscriminate deletion of bits that make the solution work.
From the perspective of SRM there is a tight relationship between the “Array Manager” configuration, the Protection Group and the Recovery Plan. Together these components are what make SRM work. So lets work down the dependencies, to show the warnings you would get – if you tried to sit on a branch, and with saw – cut through the very branch you were sitting on.
Deleting or Disabling Array Manager Configurations:
New to SRM 5.0 it is possible to disable the “Array Manager” configuration – however, if you have a Protection Group you won’t be allowed to do this.
In order to disable or delete an array manager group you have to delete all the protection groups that are using it.
Deleting Protection Groups that are in use:
Once you test or run a recovery plan (which utilizes a Protection Group) the Protection Group becomes “locked” and cannot be deleted until the “Clean Up” of the Recovery Plan phase. In this case you will find the option to edit or delete the protection group will be dimmed in the menu.
Deleting Recovery Groups that are in use:
Similarly, if you're testing or running a Recovery Plan, it will be locked until the clean-up phase has been created.
Deleting Protection Groups when NOT in use:
It is possible to delete a Protection Group when a Recovery Plan is not being tested or run. However, this can have undesirable consequences. First, you will see an error indicating that the Recovery Plan is missing a Protection Group like so:
There are some other unintended consequences to consider when deleting Protection Groups – it also removes the “placeholder” references – which also removes the references from ALL recovery plans. It is possible to recreate the Protection Group, but the Recovery Plan would need to be edited to add it back in. The Placeholder VMs would need to be relocated to the correct position in the recovery plan, and any customization such as scripts and IP addresses added to it.