User Interface Overview

The Ops Center Protector user interface follows a general pattern for the hierarchical layout of pages. Understanding this hierarchy will help you navigate the UI more effectively, enabling you to locate, create and edit resources quickly and easily.

The main banner appears at the top of all pages in the user interface and provides links to all the frequently accessed monitoring and administration functions.

Control	Description
Dashboard	Opens the Dashboard
Jobs	Opens the Jobs
Logs	Opens the Logs
Monitor	Opens the Monitor
Storage	Opens the Storage Inventory
Reports	Opens the Reports
	The name of the currently logged in user is displayed here. Opens the menu from which the Settings Wizard Dialog and the logout option can be accessed.Click to logout.
Session Notifications	Click to view the list of session notification messages. The messages listed here are a cache of the pop-up messages displayed in the web UI. The number of unread error notifications is displayed to the right of the button. All unread session notifications are considered to have been read when the list is opened then subsequently closed. All notifications can be cleared by selecting Clear at the top of the popup list. NoteIf you have a number of browser tabs open simultaneously, the notifications displayed here are local to the tab in which you are currently working.
Help	Displays a menu from which the Online Help dialog and About dialog can be accessed.

The breadcrumbs appear at the top of all pages in the user interface and show the hierarchical location of the current page. This allows the user to navigate back to a parent page by clicking on the page name.

The sidebar is displayed to the left of all pages in the user interface and provides links to all the frequently accessed management, configuration and design functions.

Tags can be applied to the following objects:

• Nodes
• Node groups
• Policies
• Policy Operations
• Data Flows
• Recovery Points

Jobs and recovery points are objects that are generated by the system after a backup / snapshot operation.

To assist the manageability of these, they inherit the tags from the objects that were involved in creating them. Jobs and recovery points will inherit the tags from:

• The source node they represent in the data flow
• The node group the source node is in
• The storage node that stores the recovery point
• The data flow that created the recovery point
• The policy that created the recovery point
• Custom tags that were included if manually triggered

Inherited tags are assigned at the point that the jobs or recovery points are created and stored as independent tags against those objects. The tags assigned due to inheritance persist unchanged even if the originated object’s tags later change, e.g. if a recovery point has inherited the tag “Production” from the Application Node, later removing that tag from that Application Node will not affect existing recovery point.

Note also that new recovery points and jobs will also only inherit any tags changes once the affected data flow have been re-activated. So if you were to alter the tags on a node, new recovery points will not reflect those changes until you re-activate the data flow that have those nodes.

You can add and remove tags on recovery points. You can modify tags on Recovery Points by either selecting the Recovery Point on the Restore Screen and selecting the "Edit Tag" icon, or viewing the Recovery point record and selecting the "Edit Tag" icon.

There are two types of tags; simple tags and key value pair tags.

Simple tags are straight forward labels. You may for instance tag all your production source machines with the tag “production”. You could then go to the RPO report and check the RPO only for machines that are marked “production”.

There are also key value pair tags. They are in the form of key:value . The concept is the ability to categorise a tag. For instance you can assign nodes a location tag in the form of location:paris or location:London. If you lost connection to a data center, you would be easily see that all the nodes at a particular location are down.

Tags can only contain alphanumeric characters, underscores and spaces. The “:” in a tag will designate it to be a key value pair. Capitalisation of tags is preserved but from a search and filter point of view ignored.

Many inventory screens have the ability to perform filter queries using tags. On those screens you will be provided with an entry box for adding a tag to search on. The search will return results that contains any tags that are in the search query, e.g. this search is an "or" operation on the selected tags. The tag needs to be an exact match the tag or the key value of the tag. The search however is not case sensitive.

So if you had an entry tagged: "Location:London" and "production" the following is the behaviour of the searches:

• Searching for tag: "Production" will return the entry because it is a case insensitive match.
• Searching for tag: "Prod" will not return the entry as this is a partial tag
• Searching for tag: "location:" will return the entry because the key value matches. "London" is not required
• Searching for tag: "location" will return the entry because the key is treated as a simple tag as well as key value pair tag
• Searching for tag: "Location:Paris" will not return the entry as the value doesn't match

Control	Description
Edit	Edits an existing node in the inventory. The Node Type Wizard is launched to enable the node's attributes to be changed.
Tags	Modifies the tags of an existing object from the either the inventory screen or the details screen of the object.
Authorize	Enabled only if one or more unauthorized nodes is selected in the inventory. Attempts to authorize the selected nodes with the Master node. Only nodes that have been authorized by the Master node may perform Protector functions. NoteIf an attempt is made to authorize an inactive or unknown node, or if the master node fails to communicate with the node, an error log is generated and the node remains unauthorized.
Deauthorize	Enabled only if one or more authorized nodes is selected in the inventory. Attempts to deauthorize the selected nodes. Nodes that have been deauthorized cannot perform Protector functions. Note Before deauthorizing nodes that are no longer required, they must first be deleted from the current data flow definitions, then any modified active data flows must be reactivated. If any attempt is made to deauthorize a node that is implementing rules in the currently active data flows, an error message is generated for each such node and the node remains authorized. It is possible to de-authorize a node with active mounts. This should be avoided because once de-authorized it is not possible to unmount.
Upgrade Clients	Enabled only if one or more authorized nodes is selected in the inventory. Attempts to remotely upgrade the Protector software installed on the selected nodes. The required upgrade installer and configuration files must be present in the C:\Programs Files \Hitachi\Protector\runtime\updater folder on the Master node. Note Only OS Host nodes can be upgraded. It is recommended to upgrade nodes in batches of 20. It is recommended to manually upgrade the master node.
Delete Node	Enabled only if one or more nodes is selected in the inventory. The node is deleted from the inventory. NoteIf an OS Host node is still running the Protector hub process and is configured to use the current Master node, then the node will re-appear as an unauthorized node as it periodically reconnects to the master node. Protector should be uninstalled from the node to stop this periodic reconnection.
Create a new item	Adds a new node to the inventory. The Node Type Wizard is launched to guide you through the process.
Existing Node(s)	Nodes on which Protector has been installed are automatically detected and listed here along side those that have been added by the user. The Node Details is displayed to enable the node's details to be viewed and edited. Note DHCP renewal can cause temporary disconnection of a node. If the host of a virtual machine(s) creates a Windows restore point, then the virtual machine(s) can temporarily disconnect. If a node has been assigned to another master, it will not appear in the inventory.
Filter on Node Name	Filters the displayed results based on Node Name.
Filter on User Tags	Filters the displayed results based on Tags contained in the data flow.
Filter on Node Type	Filters the displayed results based on Node Type.
Filter on Operating System	Filters the displayed results based on Operating System.
Filter on Connection State	Filters the displayed results based on Connection State.
Filter on Authorization State	Filters the displayed results based on Authorization State.

Using the Advance Query String you can get more control of how the queries work.

While the Tag Query box does an exact match of any of the tags. So in the Tag Query box you entered tags "vmware" and "location:new york" it would be equivalent to:

((userTagsKeys = "vmware") OR (userTags = "location:new york"))

There are however extra search methods available using the Advance Query. These include

If you wanted only to match any nodes with the string "vm" in the tag but only in location New York, you can use this custom query:

((userTagsKeys ~ "vm") AND (userTags = "location:new york"))

Triggering Operations from the Monitor screen now have the ability to add a tag to the trigger. In a situation for instance where you wanted to create a backup of a system prior to the upgrade, you could do a trigger with a tag “Pre upgrade”. It will be clear then in the restore screen the purpose of this adhoc backup and its timing.

If you have permission to modify an object e.g. Node, data flow, etc. as governed by the role based access rules, you will have the ability to add / remove tags. Tags belong to the object so any tags are visible to anyone who can view the object.

• There is no central inventory of existing tags. So currently there is no pick list or hint that a tag is in use.
• Generation 1 of the Repository does not fully support tags.