40 Posts
0
2979
Two questions about scripting ‘nsradmin’ to manage Protection groups
I am testing some Powershell scripts with ‘nsradmin’ command to create Policy/Workflow/Action configurations. I have two issues about protection group management.
- When running successfully the sub command ‘upgrade group: protection_group_1’, the group ‘protection_group_1’ appears in the workflow definition when using the sub command ‘print type: NSR protection policy workflow; policy name: policy_name; name: workflow_name’. But the group assignment is never shown in the workflow Properties in Networker Administration GUI. Is this normal?
- Is there a way to check whether a Protection Group has been assigned to a workflow without looking through every workflow? The workflow assignment information is not included in the output of the sub command ‘print type: NSR protection group; name: protection_group_name’.
Maybe I should use a different CLI command? Any help is appreciated. Thanks
ChiXC
40 Posts
0
September 13th, 2020 16:00
A final update: I still have the same display issue with our production server while on its clone there is no display issue: the protection group created by the CLI command would show up immediately in the workflow. My further tests showed that on the production Networker server, once the scheduled backup action was executed according to the scheduler, the protection group will appear in the workflow as well, but not before the action execution. I can’t explain why. Anyway, this is just a display issue as the protection group is in fact assigned to the workflow by the CLI commands.
As per the second question about how to check if a protection has not been assigned to a workflow yet, I didn’t get any answer from DELL/EMC support. So far I use a stupid work-around to avoid going through all the workflows to check: a dedicated empty Policy and Workflow was set up. I try to assign the protection group to this dedicated policy/workflow, if it succeeds, that means the group has not been assigned to other workflow yet. Otherwise it has been assigned already. Then I remove the group from this special policy/workflow. You might wonder why I don’t try to assign directly the group to its final destination policy/workflow. This is because my script will create the policy/workflow later. I don’t want to create the policy/workflow first and then realize the group is not an available one.
I will close this threat by marking this update as the solution. Thanks everyone for your help.
bingo.1
2.4K Posts
0
September 1st, 2020 13:00
Using nsradmin is o.k. but you need to know exactly what and how you use it. Use 'help' once you entered interactive mode.
Start with 'types'. This command will show you all configured rescource types, not all possible resource types.
But I personally would never try creating or modifying a policy/action/workflow from nsradmin. As you will see, there is no such resource with such names when you use the 'types' command. My personal guess to modify these resources is the 'nsrpolicy' command ... which I have not used so far. But this would result in a very long command which you do not really want to use.
When you run the 'upgrade group: protection_group_1' command I actually have no idea, which resource you want to modify. BTW - to change an attribute in nsradmin, the proper command would be 'update ....' not 'upgrade...'.
With respect to naming conventions - may I strongly recommend that you create 'self-describing names' which point directly to the fact what these resources are doing. This makes you admin so work much easier. So instead of using a policy like 'silver' or 'gold' which are nothing else but marketing buzzwords, let me suggest that you delete them and use 'DATA_TO_CLONE' and 'DATA_NOT_TO_CLONE'. Then use workflow names like "1800_MO_FULL_INT_2400" which clearly indicate that this workflow will start every day at 18:00 with a full on monday and incrementals for the rest of the week. Finally, use the same names for the groups.
IMHO this naming convention is much more straight forward and better to understand than the 'valuable' precious metal names which marketing wants to use. And I guess this is the case for 90+ percent of all NW installations. Just delete the policies and groups you do not use.
ChiXC
40 Posts
0
September 1st, 2020 15:00
@bingo.1Thanks for your reply and pointing out my typo. Yes it is 'update group: Protection_Group_1', instead of 'upgrade group:… ...'. I am using the sub command to assign a client protection group to a newly defined workflow.
I am able to use CLI command 'nsradmin' in scripts to create new policies, workflows and actions, although I am sure this is the best way to do the backup job definition in a script. The CLI command guide showed a few of examples of creating such resources. I think the 'update group' issue is a bug as the command ran successfully and I can see the assignment in CLI command interface, just not in Networker Administration GUI. I will open a case with DELL/EMC when I have time.
Thanks for the naming convention suggestion, we do have our naming conversion. I didn't use our names in the my question to avoid confusions.
And any idea about how to find out if a client protection group has been assigned to a workflow yet without looking through every workflow?
bingo.1
2.4K Posts
0
September 2nd, 2020 04:00
As there is no type 'nsr workflow' you cannot query for such resource. In fact the workflow information is inside the 'NSR Protection Policy'.
To see the secrets, just switch on 'option hidden' and enjoy the lengthy line while you search the entry 'workflowgroups' within the attribute 'policy definition'.
The only chance i see is to update the whole string with an appropriate "workflowgroups" parameter.
Once again may I suggest you to better use the 'nsrpolicy' command. Ask support for more details.
ChiXC
40 Posts
0
September 2nd, 2020 07:00
ChiXC
40 Posts
0
September 2nd, 2020 08:00
bingo.1
2.4K Posts
0
September 2nd, 2020 08:00
Please have a look at the screenshot ...
ChiXC
40 Posts
0
September 2nd, 2020 10:00
bingo.1
2.4K Posts
0
September 2nd, 2020 10:00
Sure. I understand your intention but this is all I can deliver so far. Please ask support if there is a possibility and share the result.
ChiXC
40 Posts
0
September 2nd, 2020 10:00
Okay. NP. Thanks a lot for your help. I will open a case with the group assignment GUI issue. And I will ask the question about how to find whether a group is assigned yet.
ChiXC
40 Posts
0
September 2nd, 2020 14:00
One update about the group assignment issue. I cloned our Networker VMs into an isolated lab environment and ran the same CLI commands to create a policy and a workflow, and then assign a protection group to the workflow. Guess what, the group assignment shows up in the Networker Administration GUI. I am totally confused. The clone server is an exactly same copy of the production server. But the results on the two servers were different!
BTW, a kindly reminder about cloning Networker VM servers in a VMware environment. Even if we usually clone the servers into an isolated VM network, if you include Networker VM vProxy appliances in the clone as well, you'd better be very careful. Even the vProxy and its clone counterpart can't communicate and their same IP address would not cause any conflict. The fact that they are in the same vCenter could confuse the vProxy. It seems vProxy checks the vCenter with the IP address and try to find the vProxy VM. Now vCenter would report there are two VMs with the same IP address and the vProxy operation would fail. This is the first time I saw a simple VMware VM cloning would break the production operation. You just need to change the IP address of the cloned vProxy appliance.