A new feature in R2-CU4 – reconnecting to SQL server after a SQL outage

There is a new feature added to the R2 Cumulative Update 4 hotfix, which I recently wrote about HERE

This new feature enables the OpsMgr Management Server to tolerate a SQL outage hosting the OperationsManager database better in specific cases.  This feature is NOT enabled by default, by design.  In order to enable this feature you MUST have previously applied R2-CU4 or later to your RMS role.  You should only enable this feature, if you feel you have been impacted by this issue, and you find you have to restart your RMS services frequently to get things flowing again after a SQL connectivity outage.


Under typical situations, the Root Management Server reconnects to SQL pretty well, if the SQL server is unavailable for a short time.  This might happen if your SQL cluster is failed over (there is a short period where the SQL instance is unavailable during a failover) or when patching/rebooting a stand-alone (non-clustered) SQL server.

However – in larger environments, or when the SQL outage is extended beyond a short reboot/failover, we have seen where the RMS does not reconnect/recover successfully.  Subsequently, the RMS might start logging errors in the event log from the Health Service – including 2115 (bind) events, and 4506 (Data dropped) events.  Previously – this situation did not recover until the RMS OpsMgr services were restarted (and in some cases the HealthService on the Management server).


To enable this feature – On the RMS – create two new registry entries:

Under the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\DAL” key, create two new DWORD values, as below:



DALInitiateClearPool should be set to Decimal value “1” to enable it.

DALInitiateClearPoolSeconds should be set to Decimal value “60” to represent 60 second retry interval.


Here is a screenshot:



This change will take effect after you restart the RMS HealthService (System Center Management Service).

Comments (10)

  1. Kevin Holman says:


    This configuration is specific to SCOM 2007 ONLY. These registry settings do not apply to SCOM 2012 and will have no effect. Apparently SCOM 2012 was designed to automatically retry connections with SQL after an outage.

  2. Anonymous says:

    Thanks Kevin, after reading the KB article it wasn't clear what type of registry values needed to be created.  Especially as the KB describes one of the values as 'DALInitiateClearPool = true' – which I though it was a bit ambiguous.  You have cleared it up though 🙂

  3. Anonymous says:

    Thanks for the info, as pointed out already – the kb article doesn't tell you that you have to use dword entries and that true is actually 1.

  4. Kevin Holman says:

    Ok, I got the final low-down on this.

    We moved the DAL registry location. The settings in this BLOG POST apply to SCOM 2007 ONLY. The settings in that above referenced KB ARTICLE are correct, still valid, and apply to SCSM and SCOM 2012, 2012SP1, and 2012R2. I will have a quick blog post on this.

  5. thanks for the great post

  6. Amaury Greiner says:


  7. Mark Ison says:

    Does anyone know if this also works in SCOM 2012?

  8. Maekee says:

    Is this still needed in 2012 R2 (SCSM & SCOM)?

  9. Maekee says:

    Hi Kevin,
    No according to this KB (http://support.microsoft.com/kb/2913046/en-us), under Applies to you can find •Microsoft System Center 2012 Operations Manager Service Pack 1.

  10. Anonymous says:

    I wrote about this new feature we added to control this in SCOM 2007 R2 with the advent of CU4: http