SME 6.2R1 - features missing when relating to DAG

[biescas]

Hi,

Would somebody be able to provide some answers to the somehow negative observations from one of our Partners here below?

"Following conversations internally there are some areas that seem to be less than perfect scenario with SME, and therefore we would appreciate further conversation.

In particular, although SME 6.2R1 is “cluster aware” and it runs the Windows Jobs as you say in your email, or potentially a customer can implement a management servers for the jobs to run from, There are some significant features missing from the software when relating to DAG

·         When you run the SME config wizard you have to run it against each node as the master of the DAG, this requires using cluster cmdlet and forcing a change of the Microsoft DAG cluster host or rebooting nodes to change the cluster owner

·         When you set the jobs you select the passive or active databases and configure a copy backup to take place on the other databases, that’s all fine and good if the databases you have selected originally are up and running and what was passive at the time of creating the backup is still passive when the job is to run (this may not be the case for larger organisations that change their active databases depending on server loads, so for instance if you have configured the backup job to backup the passive databases, but then do a copy backup of the active, but for some reason the passive databases are not up or are no longer passive, or the exchange writer is non-responsive for those databases, the copy backup does not initiate. A better solution would be to select the DAG and then tell SME to backup passive databases and then do a copy, rather than be prescriptive and informing sme which databases are passive, just an indication of software that has been adapted to work with Exchange DAG, rather than being written for Exchange 2010 (hope this makes sense)

·         Copy backups do not adhere to the retention categories set in the primary’s Backup (rather annoying) Esp. when you change databases from passive to active.

·         It would be beneficial to have the ability to run verification after a backup on the copy backups.

There is a general feeling from some of our larger customers that the software doesn’t really give the “enterprise” backup solution they were expecting, but rather a more cumbersome adapted backup software updated from previous versions to support Exchange 2010 DAG.

Appreciate your input."

Thank you,

[qzhang]

I believe a lot of issues are due to misunderstanding on how to use the software. Here are my comments to the questions:

Ø  When you run the SME config wizard you have to run it against each node as the master of the DAG, this requires using cluster cmdlet and forcing a change of the Microsoft DAG cluster host or rebooting nodes to change the cluster owner

That is not what SME config wizard does while migrating databases in a DAG. It does not require changing the cluster owner in order to do the migration. Not sure where this information is coming from. Obviously, the database will be offline temporarily during the migration.

Ø  When you set the jobs you select the passive or active databases and configure a copy backup to take place on the other databases, that’s all fine and good if the databases you have selected originally are up and running and what was passive at the time of creating the backup is still passive when the job is to run (this may not be the case for larger organisations that change their active databases depending on server loads, so for instance if you have configured the backup job to backup the passive databases, but then do a copy backup of the active, but for some reason the passive databases are not up or are no longer passive, or the exchange writer is non-responsive for those databases, the copy backup does not initiate. 

SME backup cmdlet has full support of above scenario, which is to be able to always backup on special type of database (active or passive), even the active database has moved from one node to another node. When scheduling the job, check the cmdlet created by the SME. If you want to backup only on passive db (with special activation preference) or only on active db, the database specified in the cmdlet should not use “<db name>\<server name>” format. Instead, only <db name> should be specified.

Ø  A better solution would be to select the DAG and then tell SME to backup passive databases and then do a copy, rather than be prescriptive and informing sme which databases are passive, just an indication of software that has been adapted to work with Exchange DAG, rather than being written for Exchange 2010 (hope this makes sense)

As mentioned above, SME already has this capability. Admittedly SME does have a bug that the job scheduled from SME may not use the right cmdlet parameters to facilitate backup only on active or passive. When the database name is specifying as “<db name>\<server name>”, it is telling SME that only backup that database on specified server.

Ø  Copy backups do not adhere to the retention categories set in the primary’s Backup (rather annoying) Esp. when you change databases from passive to active.

This issue is well understood, and there are workarounds. In a future SME release, additional remote copy backup (I assume that is what you refer to) will have its own backup management group.

Ø  It would be beneficial to have the ability to run verification after a backup on the copy backups.

Not sure this is good idea or not. In a DAG environment, it is not mandatory to do verification per Microsoft.

Ø  There is a general feeling from some of our larger customers that the software doesn’t really give the “enterprise” backup solution they were expecting, but rather a more cumbersome adapted backup software updated from previous versions to support Exchange 2010 DAG.

Hopefully the above statement is based on the issues stated earlier. It would be helpful if there are other more specific problems other than what were stated earlier, so SME can improve to meet those customers’ requirements.

Thanks, Qing

[biescas]

Hi Qing,

Thank you for your previous reply.  Our partner has now come back to us with the below email/reply following a customer visit. Can you further help with your comments?

"Sorry to drag up an older email chain, but this came up in conversation with a customer again today, and I thought with Foresight round the corner for you we could ask if some questions around SME get asked to the product team, and perhaps an NDA on what / when we can expect a next release?

Retention policies – Seems to be some issues around Public Folders, and again within the below questions, being able to configure a single job across multiple active/passive groups and have the same settings across the single job (today multiple jobs has to be created depending where the active/passive DAGs may or may not be).

What happens to jobs when a DAG fails over. We know what should happen, but customers are reporting irregularities in what actually happens.

It seems there are some issues around named snapshots also. We have a customer with some irregularities when creating backup jobs on the passive node and want to enforce a named snapshots (__recent for tape backup) and this isn’t always too successful.

I think the biggest issue, and the one that would probably fix many of these issues, we need a central management server to create, manage and protect all databases across an entire estate. This obviously needs to be fully DAG aware and as such this should resolve the issues encountered with different retention policies, not knowing which DAG is active, named snapshots, etc. etc.

Meeting with a customer today and they get the impression that SME isn’t entirely matched with Exchange 2010. If you could get any information from the product teams on the future of SME, both short and long term, it’d be a great help for us."

Thank you,

Elias

[qzhang]

My comments here:

>Retention policies – Seems to be some issues around Public Folders, and again within the below questions, being able to configure a single job across multiple active/passive groups and have the same settings across the single job (today multiple jobs has to be created depending where the active/passive DAGs may or may not be).

SME does not treat public folder database any differently than other databases, so I am not sure what problem may be. As I mentioned previously, by not specifying server name of the database, a job can be created to handle active/passive dbs change without worrying about which node the database is on. You can use -ActiveDatabaseOnly, or -PassiveDatabaseOnly with -ActiviationPreference etc to control where the backup should be created, and use -ClusterAware to handle DAG failover.

>What happens to jobs when a DAG fails over. We know what should happen, but customers are reporting irregularities in what actually happens.

As mentioned earlier, DAG failover use case is supported. I would not be able to comment on the issues the customers were seeing as I don't have any detail here.

>It seems there are some issues around named snapshots also. We have a customer with some irregularities when creating backup jobs on the passive node and want to enforce a named snapshots (__recent for tape backup) and this isn’t always too successful.

Depending on how the backup is scheduled, __recent snapshot name may not be used. For example if you use Gapless backup (additional remote copy backup) feature, remote copy backup will not be named as __recent. SME has run command after backup feature, which you can pass snapshot name to your tape backup script.

>I think the biggest issue, and the one that would probably fix many of these issues, we need a central management server to create, manage and protect all databases across an entire estate. This obviously needs to be fully DAG aware and as such this should resolve the issues encountered with different retention policies, not knowing which DAG is active, named snapshots, etc. etc.

Agree. Currently it requires some planning to make things working smoothly, considering DAG itself is very complex system. To support such complex system, having a flexible and easy-use at same time is a challenge to SME. Delopying SME also requires deep knowledge on various technologies, such as SME, Exchange, storage, and Windows etc. In any case, I believe the features available right now in SME should cover most of use cases, and there are workarounds for issues as far as I know.

Thanks,

-Qing