CASO & MMS - When CASO is offline

[Grafs]

Hi,

I have a new setup  with a CASO and MMS - The catalogs are configured as distributed.

When CASO is offline shouldn’t the locally created jobs not continue? (Now it's just stuck at Loading Media - Target is B2D locally)

I'm getting database error messages on the MMS and console becomes unstable. (See attached picture)

[VJware]

This can happen if during the MMS install, the option to centrally manage the storage/media was chosen.

[Grafs]

Raised a ticket with support - And their conclusion was to change it to a locally managed server. But, if I do that I can't share my deduplication store.

[CraigV · Accepted solution]

You are able to mamnually hack out the CASO server from your registry if it goes down and affects backups.

Do a search for the CASO server's name in the registry. THere is an entry for the BackupExecDatabase (something like that). Replace the name there with the name of the local MMS and this manually reverts it back to a stand-alone server and allows your backups to continue.

It means you need to re-add it to the CASO when it is up. And bakup your registry first, obviously!

THanks!

[Grafs]

Ok - Thanks for work around.

Just to be 100% clear.

If a managed server loses connectivity to the CASO, even for few seconds, it will become a  zombie until it reconnects or changed to a local managed server one way or the other?

I can understand if it is a job delegated from the CASO, but surprised it also effects a locally created job to a local storage on the MMS.

[CraigV]

Hi,

1. Yes it would. You can try mitigate this by setting the connection speed on the MMS itself to a slower state. I used to do this with sites in Africa and Asia that I monitored from a central location in South Africa. Worked well, but I would still get orphaned MMS servers, so it doesn't totally prevent it.

2. It probably would. Don't forget that the MMS is basically a controlled server, so if the CASO is down, you can expect the MMS to go down too when catalogs are centralised.

Thanks!

[VJware · Accepted solution]

The reason if affects the local job to local storage on the MMS, is because of the first option chosen during the MMS install. Typically, it centralizes the ADAMM (the DB which is responsible for the storage and media), so even when you run a local job to a local storage, the DB isn't local.

The registry change suggested is the same as the UI change proposed by Support. Formally, we recommend to make the change via the UI first and not the registry.

[CraigV]

...not sure if you have personally tried to do this on a support call, but last time I tried to make the MMS a stand-alone server again, it failed because it couldn't contact the CASO.

Hence manually doing this via the registry. This was with BE 12.5, and 2010 Rx, so not sure if you have improved it with the other 2 versions?

Thanks!

[VJware]

There have been major changes with BE 2012 onwards, for egs, if you look @ the BEutility options for CASO/MMS most of the options aren't there any more as they were in BE 2010 and earlier. Secondly, the MMS install (either a fresh or a repair) allows one to reconfigure the MMS and this does not require connection to the CASO. (If you look at the OP's second comment, he was advised the same thing by Support)

And yes, i am quite active on support calls even now and I would still recommend the UI vs the registry. If the UI doesn't help for a customer, i would instead recommend them to log a formal support case than editing the registry. (Especially for CASO/MMS environs)

[Grafs]

Thanks to both of you - I guess the where the catalog reside is not so important, when the MMS still need have a persistent connection to the CASO in order to work.

[JamesFSI]

I found a couple of registry entries with CASO, does anyone have specifically which values should be changed?