IDEA CSM-I-163 Display a user defined name for the CSM server

• Managing storage replication for large data centers can be a daunting task.  Often times there are different areas of the business that are separated either for security or organization reasons.  When this occurs, some customers have setup multiple CSM server instances to manage the separate environments. 
• Using separate CSM instances however, means that you have to login to each of the different CSM GUIs to managed the replication.  Since the GUIs look almost identical, if you jumping from GUI to GUI, even if the URL indicates the server IP or hostname, customer's might get quickly confused on what server is what. 
• Starting with the 6.3.14 release, customers can now choose a custom name for the server. On the Settings->Advanced Tools panel, there is a new section called "Set Server Name".  Enter a custom name for the server and click the Apply button.  That custom name then start to appear in the top navigator of the CSM GUI next to the name of the logged in user.  This name is persisted on this server but is NOT sent to the standby server.  So you can provide a custom name for the standby server as well.
• If no custom name is selected, the hostname of the system will display in the upper right hand corner. 

Support ability to issue local and remote Snapshots on Async PBR session 

• In a previous release CSM added in support for FlashSystem's Asynchronous Policy Based Replication (Async PBR).  With CSM's support for Async PBR, the server will discover any Volume Group with an Asynchronous Policy and automatically build a CSM session to manage and monitor the replication.
• CSM's Async PBR support covers all flavors or FlashSystem policy based replication, from non-partition asynchronous replication, to partition based asynchronous replication, to three site asynchronous based replication with high availability.  The CSM session managing these solutions allows you to failover, reverse the replication direction as well as start a recovery test.
• But...we saw if customers are managing their volume group with Asynch PBR, they would likely also want to manage Snapshots or Safeguarded Snapshots for these volumes groups!!!
• So starting with CSM 6.3.14, the CSM server will no not only automatically create an Async PBR session for the volume group, but it will automatically create Snapshot session for all FlashSystems where that volume group is replicated.  This means we will create a Snapshot session on both the local FlashSystem (both the management AND secondary system for HA environments) as well as the remote DR system.  These sessions will them be automatically associated to the Async PBR session so that you can manage the local or remote Snapshots, directly from the Async PBR session itself!!!!
• What does this solution provide???

• • Issue Create Snapshot or Create Safeguarded Snapshot to the Async PBR session to create a local snapshot with whatever frequency or retention is required at the Primary storage system.  

• • Issue Create Recovery Site Snapshot or Create Recovery Site Safeguarded Snapshot to the Async PBR session to create a remote snapshot with whatever frequency or retention is required at the Remote storage system.  

• • Because CSM knows which site is the Production site (knows the direction of the replication), the same command can be used within a Scheduled task to define the Frequency and Retention required for either the Production Site or Recovery Site

• • With CSM's Powerful Scheduler Task solution, you can setup multiple frequencies/retention all tied to the same Async PBR session managing the same volume group FROM A SINGLE PANE OF GLASS.  No need to login to all the storage systems and all the sites!!!!
• 

Support ability to issue local and remote Refresh Thin Clone against Async PBR session 

Many people may not know, but CSM already supports the ability from the Snapshot sessions to issue a Refresh Thin Clone command.  This command allows customers to quickly analyze the data in a Snapshot or Safeguarded Snapshot by attaching hosts to the volumes in a thin clone and simply refreshing the data in that thin clone with that of another backup. 

This means that you no longer have to write automation that will detach the hosts from one volume group, create a thin clone from a new or different Snapshot, and then attach the host to the new thing clone.  You can use a single thin clone for your Snapshot analysis such as Cyber Vault validation checking.

Starting with CSM 6.3.14 though you can now issue a Refresh Thin Clone or Refresh Recovery Thin clone command, directly to an Async PBR session!   This means you can define separate Thin Clones at both the local and remote site and setup different frequencies for tasks like Cyber Vault validation!!

Want to validate a Snapshot locally every 10th backup but remotely every 4th backup?   No problem!!

In addition, with CSM's powerful Scheduled Tasks, you can automate this all by either scheduling it at a given interval or even tying it directly into the backup process itself.  Create the Snapshot and Refresh the latest thin clone in the very same task!!!

This feature will make not only managing Snapshots easier but managing things like Cyber Vault validation easier.