Solved: SME Scheduling issues...

heinowalther · ‎2013-05-01

Hi there

We have a Exchange 2010 DAG setup with two servers, we have installed SD 6.5, SME 6.0 on both servers, created LUNs, moved the databases and logs to each LUN.

We are able to do snapshots from the SME GUI, but when trying to schedule the jobs, it all goes sauer 😞

First of all the Schedule jobs has been created using the SME, which doesn't do that good a job since it forgets to enclose the start program in " " which presents a problem when you try to alter the arguments, in which case the scheduler will complain about this... this was an easy fix, just added the " " arround the SMEJobLauncher.exe.

But, when running the schedule it fails with a status in the scheduler "0XFFFFFFFF" and if I look deeper in the eventlogs I can see that SMEJobLauncer returns this code: 4294967295

Not as an error, but as an information in the eventlogs... besides that, there are no traces of any errors in the eventlogs.

The jobs doesn't even create a backup log in the Report\Backup folder...

Here is an example of an argument string:

new-backup -Server 'EXCH03' -ClusterAware -ManagementGroup 'Daily' -RetainDays 5 -RetainUtmBackups 5 -StorageGroup 'DB01\EXCH01' -UseMountPoint -MountPointDir 'D:\Program Files\NetApp\SnapManager for Exchange\SnapMgrMountPoint' -ArchiveBackup -ArchivedBackupRetention 'Daily' -BackupType CopyBackup -RemoteAdditionalCopyBackup $False

Just to be clear... the database in located on EXCH01 (physical), and the virtual name is EXCH03 the above is right from the SME GUI as you select what options you want, and hit Schedule... if I hit Backup instead, it runs perfectly with no problems...

I have since tried to enable debugging, and this results in a bit of information in the Reports\Debug folder:

[05/01 09:03:32 828] CSmeServerBase::SmeGetEsefilePathInternal() start

[05/01 09:03:32 828] Get MounPoint setting from MountPointDir

[05/01 09:03:32 828] Entering Mutex SM_CREATE_MOUNT_POINT_ACCESS

[05/01 09:03:32 828] Entered Mutex SM_CREATE_MOUNT_POINT_ACCESS

[05/01 09:03:32 828] Get UseDrvLetterIfAvail from registry.

[05/01 09:03:32 828] UseMountPoint: D:\Program Files\NetApp\SnapManager for Exchange\SnapMgrMountPoint

[05/01 09:03:32 828] Exited Mutex SM_CREATE_MOUNT_POINT_ACCESS

[05/01 09:03:32 828] Getting EseUtilPath from the registry.

[05/01 09:03:32 828] Checking Eseutil.exe version.

[05/01 09:03:32 828] Verification Throttling is not set.

[05/01 09:03:32 828] CSmeServerBase::SmeGetEsefilePathInternal() end with 0x0

[05/01 09:03:32 859] Enter CSmeServerBase::~CSmeServerBase ...

And that's actually it... very strange issue...

The Scheduler is running as the same service account as the SME service is... so I guess permissions are out of the question, or else it should show somewhere...

But I guess this would also be too easy if it just worked out of the box 🙂 Just had a long fight with SMSQL Scheduling which also has issues when you have multiple instances and no default instance, but that's fixed and we just need SME to work now 😉

Anyone has a clue ?

/Heino

PADMANTECH · ‎2013-05-02

Hi Heino,

I've found a solution and now pinpointed the root cause. My issue was setting the option "-RetainUtmDays 0" This needs to be 1 or greater so i changed it to be "-RetainUtmDays 1"

The message from Task Scheduler "0XFFFFFFFF" from what I can see, means there is something wrong with the arguments like above. It would also be nice if NetApp could include a "Run Now" from SME console as when you switch to the Windows "Task Scheduler" I found it easier to select "Connect to another computer" and then enter in the virtual DAG name which means you will run the task from the node which is the current virtual DAG owner.

This helped me get over a lot of the "0XFFFFFFFF" issues as i was trying to run the task from the MBX server that the Databases were on, but would not run as it was not the DAG owner. When you use the argument "-ClusterAware" the task needs to be run from the current owner of the virtual DAG which could be any of the nodes and why I chose option "Connect to another computer" with Task Scheduler and entered in the NetBIOS name for the virtual DAG to make sure i was running the task i created in SME from the correct node.

Once I figured out I needed to run the task from the DAG owner node then it was easier to troubleshoot my script and find that I needed to not use a 0 for the "-RetainUtmDays" argument.

I hope this helps.

Jason

Message was edited by: Jason Padman

View solution in original post

PADMANTECH · ‎2013-05-01

Hi Heino,

Just letting you know i'm having the exact same issue. if I figure out anything i will post here for you.

Environment

Server 2008 R2 sp1 running on VMware ESXi 4.1 host
Exchange 2010 SP2 setup with 4 node DAG
SnapDrive 6.5
SME 6.04
Symantec NetBackup 7.0 Agent Installed
SCOM 2007 R2 Agent Installed

Cheers,

Jason

Message was edited by: Jason Padman

PADMANTECH · ‎2013-05-01

What is very strange is that when I create a FRP scheduled task it runs without a problem?

Program

"C:\Program Files\IBM\SnapManager for Exchange\SMEJobLauncher.exe"

Arguments:

new-backup -Server 'MBX_Server' -StorageGroup 'Group1','Group2','Group3','Group4','Group5' -RecoveryPoint -RemoteAdditionalCopyBackup $False

heinowalther · ‎2013-05-02

Hi again

I found a solution or workaround to my problem...

I setup schedules on the physical servers instead, which works OK with scheduling. In the schedules I set it to backup all the datastores on that server. This takes care of datastores being moved from one server to the other... and snapvault updates also works.

It's just sad to see that both SME and SMSQL is developed and not really tested before release...

SMSQL in the latest release has debugging enabled by default... as a matter of fact I think the SME also has debugging enabled.... this can generate huge amounts of log files which netapp doesn't take care of.... so either you create your own script which deletes logs older than one month or so... or you compress the folder...

How hard can it be NetApp ? 🙂

Also SnapDrive has issues with large log and debug files dumped in the installation directory... very nice NetApp... also this you have to take care of in the registery to make it manageable...

Looking forward to the next Insight conference where I'll be that annoying guy in the 3rd row asking stupid questions 😉

/Heino

PADMANTECH · ‎2013-05-02

Hi Heino,

I've found a solution and now pinpointed the root cause. My issue was setting the option "-RetainUtmDays 0" This needs to be 1 or greater so i changed it to be "-RetainUtmDays 1"

The message from Task Scheduler "0XFFFFFFFF" from what I can see, means there is something wrong with the arguments like above. It would also be nice if NetApp could include a "Run Now" from SME console as when you switch to the Windows "Task Scheduler" I found it easier to select "Connect to another computer" and then enter in the virtual DAG name which means you will run the task from the node which is the current virtual DAG owner.

This helped me get over a lot of the "0XFFFFFFFF" issues as i was trying to run the task from the MBX server that the Databases were on, but would not run as it was not the DAG owner. When you use the argument "-ClusterAware" the task needs to be run from the current owner of the virtual DAG which could be any of the nodes and why I chose option "Connect to another computer" with Task Scheduler and entered in the NetBIOS name for the virtual DAG to make sure i was running the task i created in SME from the correct node.

Once I figured out I needed to run the task from the DAG owner node then it was easier to troubleshoot my script and find that I needed to not use a 0 for the "-RetainUtmDays" argument.

I hope this helps.

Jason

Message was edited by: Jason Padman

madden · ‎2013-05-02

Jason, the issue you encountered is a known bug and the fix should be included in the next SME release. Sorry for your bad experience, quite frustrating I can imagine!

Details of the bug are here: http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=649767

TITLE: SnapManager for Exchange (SME) backup job schedules not working after upgrading to the 6.0.4 release

DESCRIPTION:

Prior to 6.0.4, SME allowed a user to schedule backup jobs where UTM options

-RetainUTMDays and -RetainUTMBackups had the default value "0", which means

retaining UTM functionality is switched off and no transaction logs are

retained for any backups created (it deletes all logs).

The SME 6.0.4 Graphical User Interface (GUI) no longer displays the input UTM retain option "0" for

-RetainUTMDays and -RetainUTMBackups: the value 0 is not selectable in the "retain up-to-the-minute restorability" option.

However SME allows the user to type the value '0' manually and proceed.

SME handles this correctly when performing a backup immediately from GUI.

SME does not handle this correctly when scheduling the same backup from the same GUI selected options.

When the user attempts to create a schedule with the value 0 in the "retain up-to-the-minute restorability" option,

SME creates the scheduled job syntax with an incorrect parameter: respectively -RetainUTMDays 0 or -RetainUTMBackups 0.

The correct parameter should instead be -NoUtmRestore.

WORKAROUND:

Change the values of -RetainUTMDays and -RetainUTMBackups from "0" to any other valid number,

for example,

1) "255" if you want to retain transaction logs for all backups.

2) A value > 0, for retaining transaction logs according to the input value.

3) If you do not want to retain any transaction logs for any backups, manually edit the scheduled job by:

- removing -RetainUTMDays or-RetainUTMBackups

- inserting -NoUtmRestore instead.

(this switches off retention of up-to-minute restore ability).

NOTES:

Checking for a value of "0" for retain UTM in GUI scheduling will be implemented in a future release of SME.

PowerShell already supports this functionality.