Re: SnapVault Integration with SnapManager Exchange

I'm quoting for a FAS 2050, so the licening has all changed as far as software now. Ops Manager is included in the base pack (free). Snapdrive is now part of another "bundle" and licensed on the filer only - no more a la carte. It's all quite confusing and annoying, but what can ya do

Re: SnapVault Integration with SnapManager Exchange

Hi there,

Do we really need to reinstall SnapDrive in order to configure the DFM integration? We have SnapDrive installed on several Exchange and SQL boxes prior to purchasing Operations and Protection Manager, so could/did not configure the OpsMgr integration at installation.

I have tried using the sdcli utility to configure the DFM configuration as in the following:

C:\Program Files\NetApp\SnapDrive>sdcli dfm_config set -host [dfm server hostname] -user [domain service account with admin priv] -pwd [password]

However, it fails:

Creating ConfigManagement web service client...
ConfigManagement web service client

A FaultException<SDResult> occurred:

Encrypt algorithm verification failed to succeed.
The operation completed successfully.

C:\Program Files\NetApp\SnapDrive>sdcli dfm_config list
List of DFM Servers

HostName        :
UserName        :
Port            : 0
Protocol        : HTTP
The operation completed successfully.

So, that doesn't seem to be workable. I have tried to account and password fields quoted and non-quoted and the username in DOMAIN\logon and UPN formats with the same result.

If we do have to reinstall SnapDrive (or run the setup and select Modify to enter the DFM settings), will this affect active iSCSI connections? Or are active sessions handled purely by the MSiSCSI service? In other words, will I need to schedule a short outage for each box this needs to be done on? Or can this be done without affective active LUNs?

Re: SnapVault Integration with SnapManager Exchange

Hi there

Because one of our customers did not want to use Protection Manager I just wrote a Powershell-script, which manages by means of the sdcli-capabilities all the snapshot deleting and renaming on the secondary storage.

The script takes as an input:

- the snapshot-name on the secondary,

- the retention on the secondary and

- the mount-points/snapshot of the exchange server as required by sdcli snapvault archive -a <snapname> -DS <mp1> <snap1> <mp2> <snap2>....

It is divided in three "sections"

1. check for snapshots on secondary by sdcli snapvault snap_list -d <mp1>

2. delete oldest snap if necessary and rename the remaining (eg. snap.8 -> snap.9, snap.7 -> snap.8 etc)

3. initiate the new transfer by using the *__recent-snapshots of the mount-points and then create the new snap on the secondary

The use of this scripted approach has the following advantages:

- less licenses / software required

- creation and naming of snapshots is under full control of the administrator (not those crippled names by PM with blanks in it...)

- thus having the newest snap always the same name, which allows in turn to back it up to tape automatically

- need of only one single SME-job for creating backups with generic-naming (*__recent)

- archiving is done with several scheduled jobs with different snap-names as an input (daily, weekly, monthly)

The latter two point might sound a bit strange. But imagine an exchange with several storage groups all with different backup-schedules. You need to create a job for every archive management group you whish to use...that could end up in a lot of jobs. With the script approach there is only one SME job, the "archiving-logic" is outsourced (yes I know: instead of having a lot of of SME jobs you now have a lot of script-jobs. But IMHO - listen PM-developers! - this is what I would have expected from PM: here is the place to schedule archive-events, here is the logic when and how long to retain archived backups. Why can't PM just take the most recent backup and just archive it...the scheduler and retention-definition is all there! So PM eg. would now "hey, it is the last sunday of the month - I have an event for that, let's archive this backup with monthly-retention" need for "archiving management groups", no jumping back and forth between two apps SME and PM....see the point?)

Of course this also has two huge disadvantages:

- no integration in SME, thus no "remote-verification"

- thus no "restore from secondary"