02-27-2017 08:12 AM - edited 02-27-2017 10:21 AM
I tried an in-place upgrade of the host OS running this server from 2008 R2 to 2012 R2. The in-place upgrade went well and Backup Exec did restart. But deduplication jobs were failing to save Granular Recovery Technology details. This is a known problem because the OS upgrade removes some Registry items and the solution is to do an in-place repair.
I do that, and I get this, from the Windows Installer log:
02-27-2017,09:52:59 : CopyPvlData: Failed to get Database Server Name from registry, rc=0x7a. Using default value [old-caso-server].
Solved! Go to Solution.
03-07-2017 12:02 PM - edited 03-08-2017 08:25 AM
With no comments or suggestions from anyone else, this topic turned into a blog of sorts. At least now it's searchable for the next poor soul dealing with this.
The solution, ultimately, was to set up a temporary CASO server with the old CASO server's name. This allowed the repair to work. I also needed that temporary CASO server whether I did the repair on 2008 R2 or 2012 R2, as it appears a former MMS server will still look for an old CASO server even after supposedly removing any references to the original CASO server.
Fortunately, I would just have to go to the temporary CASO server and delete the former MMS from it, after completing the repair on the former MMS. This would uninstall the MMS-related components, at least until the next time I'd need to do a repair.
Once a MMS, always a MMS, apparently.
02-27-2017 12:35 PM
To add to the confusion, the contents of HKLM\Software\Symantec\Backup Exec for Windows\BEDatabase are missing entirely. There are references to the old CASO server scattered through other reg keys and even some files.
One solution to de-associate a former MMS was to check the contents of this key and make sure BE was referring to its local SQL database. But there are no entries in here at all!
I'm almost ready to nuke this media server and start from fresh, since I can attach this dedupe store to a fresh install, and then restore the catalogs and BEDB database to it. I don't suppose I can still raise a support ticket with the maintenance contract expired...
02-28-2017 08:14 AM - edited 02-28-2017 10:52 AM
Now the plot thickens... I have the original 2008R2 media server restored from my pre-2012R2 backup, and on a lark I spun up a virtual machine with a trial edition of the CASO server software. The new server runs with the old CASO server's original name.
I attempt removing the MMS components from the media server, only to find they're not installed and the option for Managed Media Server was not selected. I do remember removing the MMS-related components from this media server after the dedupe-to-dedupe copy attempts now.
Did the in-place upgrade from 2008R2 to 2012R2 somehow revive some idle settings pointing to the former CASO server?
[...]
The confusion continues. After restarting services on the former MMS server, I could again see the MMS option marked as 'installed' and referencing the old / new CASO server. I was able to change the setting to a locally managed media server and actually proceed with the installation maintenance. There were also some references to a nonexistent tape library on the CASO server that had the same name as the dedupe store on the former MMS. I tried removing and re-adding that, and it got confused further because now I couldn't re-import the dedupe store because of a name collision...
Some SQL hacking afterward cleared that up and I was able to re-add the dedupe store under a new name. Inventory will come next, just to be safe.
I also see that in the event log it's no longer trying to open a SQL database on the old CASO server finally. And the Managed Media Server option is no longer selected on installation maintenance, though I'm going to re-check that later today. And once that's all done, I'll attempt an in-place repair with the "old / new" CASO server turned off; if that succeeds, I'll try the in-place OS upgrade once again.
02-28-2017 01:07 PM
Attempted the repair. The repair succeded but the patient died the BEserver service wouldn't start. Turned out it was still trying to retrieve information from the old CASO server, this time the cataloging bits. So something in the repair process is restoring this server's former status as a Managed Media Server. When I powered my placeholder CASO server up, BEserver would start. I could then remove it from the list of servers on the placeholder CASO server, and then it would behave like a standalone server again. Presumably, until I try repairing it again.
This seems to mean there's something lingering still that's triggering the repair process to restore MMS components. If I have to, I'll keep my trial-mode placeholder CASO up long enough to do the in-place OS upgrade, then remove it (again) after everything else is settled. I don't consider this a solution though; the permanent solution would be to stop looking for the old CASO server during a repair.
03-07-2017 12:02 PM - edited 03-08-2017 08:25 AM
With no comments or suggestions from anyone else, this topic turned into a blog of sorts. At least now it's searchable for the next poor soul dealing with this.
The solution, ultimately, was to set up a temporary CASO server with the old CASO server's name. This allowed the repair to work. I also needed that temporary CASO server whether I did the repair on 2008 R2 or 2012 R2, as it appears a former MMS server will still look for an old CASO server even after supposedly removing any references to the original CASO server.
Fortunately, I would just have to go to the temporary CASO server and delete the former MMS from it, after completing the repair on the former MMS. This would uninstall the MMS-related components, at least until the next time I'd need to do a repair.
Once a MMS, always a MMS, apparently.