Anybody Upgraded to SC DPM yet?

[Fazza]

Looking at upgrading our DPM server to SCDPM 2019 this Easter half-term so I was wondering if anyone had already taken the plunge and if so, are there any gotchas/issues we should be aware of or did it all go swimmingly and backups are fine?

 

The reason we're looking to upgrade SCDPM is because I'd like to upgrade our VMs from Server 2012/2012R2/2016 to 2019 but as it's not supported in our current SCDPM server I need to upgrade SCDPM first but dont want to do it if everyone is having issues with it.

[MrBrow]

Planning mine at some point but I need to reinstall Server to 2016+ (as 2012 R2 is not supported).

 

That brings issues with:

File Servers being deduped and running as a shared VHDX.

Server 2016+ and a new version of DPM will enable MBR and wont work with my File Servers either.

Server 2016 needs VHDSets, which DPM does not support

End User Recovery is not a thing now so I will be saying goodbye to that...

 

I'll be honest, I went from DPM 2012 to 2016 to 1801 to 1807 without an issue but now they have binned SAC I need to jump to 2019 within the 18month support period. I just dont want to lose features that I currently have!

[Fazza]

Upgrade failed as for some reason it didnt upgrade the DPM2016 database during the install! Didnt roll back or anything so when I try and open the DPM console it doesnt open up DPM! The DPM server wont start, it just stops straight away. Event viewer says that the DPM service wont start as the database version isnt compatible with DPM2019, thus proving that the DPM database did not get upgraded!

 

I've got loads of backups but cant access them or create any new ones!

[MYK-IT]

Had a provisional look, and was tempted to upgrade (from DPM 2016) over the Easter Break, but as we still have a 2008 R2 Server(!) amongst others, that need to be backed up - I've left it for now as it is backing up and doing what we want it to do.

 

I have a few virtual 2019 Servers, and they are being backed up fine with DPM 2016.

 

I'll probably upgrade our VMM server to 2019; before we eventually upgrade DPM.

[Meldrew]

We've been trying to do this over Easter. We're new to DPM, so are starting from scratch installing DPM 2019. So far found that we had to install SQL 2016 SP2 as otherwise had difficulty installing SSRS when using SQL 2017. Then followed a list of issues too numerous to mention that we had to work our way through to get the thing installed. Software really, should never be this difficult to install. All the way through was 1 step forwards, 2 steps back.

 

Meldrew

[Fazza]

The only 'issue' I had with SSRS with SQL 2017 is that each section appears to have automatically been configured as it has been pre-populated with data but you have to click on each one in turn and press Apply until all the Apply buttons are greyed out - only then is it fully configured and ready for use with DPM 2019!

[markwilfan]

I've upgraded to DPM 2019 and server 2019. Backup locations were already REfs. Turned on dedupe for the lols and booooom space saving with little effort

[Fazza]

1 step forwards, 2 steps back

 

I think that should be the strap-line in DPM's advertising!!

[ADMaster]

I'm struggling to get it installed.

I've setup a fresh VM and plan to backup / restore the DB. The DB is currently on 2014 which is not compatible with 2019.

I installed sql 2017 but didn't see the reporting services check box so dpm failed to install. I figured out it was a separate download and it is now installed.

 

Now I'm getting some errors on the checks that say to look at the logs and this is what I have in the log.

This is a fresh install of server 2019, fresh install of sql 2017, reporting services 2017 and the dpm database is restored from the other server.

 

Ideas?

[4/25/2019 3:39:48 PM] *** Error : Initialize the SQLSetUpHelper Object
[4/25/2019 3:41:59 PM] *** Error : Can not access properties of the WMI class.
[4/25/2019 3:41:59 PM] * Exception : Failed to perform the check => System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Microsoft.Internal.EnterpriseStorage.Dls.Setup.Exceptions.ReportingConfigurationAccessException: Can not access properties of Reporting configuration class   at Microsoft.Internal.EnterpriseStorage.Dls.Setup.Inspect.InspectHelper.GetReportServerVirtualDirectoryName(String reportServerMachineName, String reportServerInstanceName, ConnectionOptions wmiConnectionOptions, String ReportingNameSpace)   at Microsoft.Internal.EnterpriseStorage.Dls.Setup.Inspect.InspectHelper.CheckIfReportServerURLIsAccessible(String reportingMachineName, String reportingInstanceName, ConnectionOptions connOptions, String reportingNamespace)   at Microsoft.Internal.EnterpriseStorage.Dls.Setup.Inspect.InspectPrerequisites.CheckIfReportServerURLIsAccessible(InspectContext context)   --- End of inner exception stack trace ---   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)   at Microsoft.Internal.EnterpriseStorage.Dls.Setup.Inspect.Inspect.RunCheck(String checkId)

[Fazza]

I finally managed to get our DPM server back in the state it was originally in (only took 3 solid days) so back to square one at the moment.

 

I have nicked a 2nd CPU and a bunch of RAM from my SCCM server and stuck it in a server we were keeping for spares and have just installed SQL 2012 on it ready to install DPM 2016 to match our current DPM server. I will then export the DPM database at the command line and then import it in to my test server and once I've got it working on that I will go through the motions of upgrading it the way I now think will work - if it does I will post what I did on here.

[MrBrow]

This all sounds terrible! (well apart from 1 person who has it working fine).

 

I jumped to 1807 last year so don't know if that will be an easier migration. Considering that I get the impression DPM is virtually abandoned by MS, I am not so sure. Can't they just buy Veeam and put that into the System Centre Suite?

[Fazza]

The only real issue is, we buy DPM cheaply and dont buy any support so everything we know about DPM comes from trial and error and the internet!

 

Our issue is that we're not just upgrading DPM but need to upgrade SQL 2012 as it's not supported by DPM 2019 so we've got to go through that pain first! I've read lots of guides and as with a lot of things there are several ways to do this and sometimes it works for people and other times it doesnt! If we had a supported version of SQL installed that works with both DPM 2016 and DPM 2019 then it would be a straight-forward upgrade of DPM but I've got to faff around with SQL as well and get the database versions to match etc.

[Norphy]

now they have binned SAC

 

Wait, what? When did that happen?!

[Fazza]

Having to put this on hold seems DPM 2019 will not backup anything less than 2012 and we have 1 2008R2 file server:(

 

https://docs.microsoft.com/en-us/system-center/dpm/dpm-protection-matrix?view=sc-dpm-2019

 

Unless I'm misunderstanding of course?!

 

 

The 2008R2 File Server in question is a VM on a Server 2016 Hyper-V Host so how would DPM 2019 know the OS of the VM as all it's doing is backing up the VM (i.e. the VHD file) isn't it? We dont have the remote agent installed on any of our VMs just the Hyper-V host itself.

[MrBrow]

There must be something about how DPM hooks into the HyperV VM and 2008 R2 is a bit different. I cant think what it will be but part of me is not surprised. Backing up just the storage only and not the whole VM could be a way around it?

 

 

As for SAC - announcement was early March. 2016 to 1801 to 1807 to 2019.... SAC (or '1903') for System Centre Suite will not exist anymore UNLESS you have SCCM where it DOES exist and you will get 3 updates a year. Oh the consistency!

 

I jumped to 1801/1807 but if I had stayed on 2016 I'd have 10 years of support. Now I have the 18months to jump to 2019.

[ADMaster]

It really is the SQL causing all the problems.

I tried and tried today to get it working on the new machine SQL 2017 reporting services was giving me trouble.

The documentation also says it will allow you to move the DB during upgrade, this isn’t really true.

I’d tried to upgrade it, but SQL was not supported, and install SQL 2016 said the DB files didn’t exist.

I also tried backing up and restoring the DB from the SQL 2014 to 2016 with no luck.

Here is what I’ve done in the end.

Take a snapshot of my DPM VM before any upgrades.

Install SQL 2016 with a new instance name.

Stop both instances and copy the DB files over to 2016.

Start SQL server

Attach the newly copied files.

Run the DPM install wizard pointing it to the new instance.

It found the files and appears to have upgraded.

 

The DPM console opened and I had all my protection groups. I updated the agents and everything is doing a consistency check now.

Now that the DB is updated for DPM 2019, I should be able to migrate it to that fresh VM, but that is for another time.

[Fazza]

UPDATE: I've got upgrading SQL to a version supported by both DPM 2016 and DPM 2019 down to a T but I have a problem with the upgrade to DPM 2019 not working...

 

 

When I try and upgrade DPM 2016 to DPM 2019 it fails the prerequisites as it says that the version number of the DPMDB database withing SQL (not to be confused with the SQL version) does not match the version of the currently installed version of DPM.

 

 

If I take a look at the DPMDB version number within SQL I get 5.0.158.0 (which is the RTM version of 2016). When I go in to DPM 2016 the version number that is on is 5.0.409.0 which is the Update Rollup 7 version which was installed via Windows Updates.

 

 

 

 

So it seems that when the Update Rollup 7 was installed it either: 1) hasn't upgraded the version of the DPMDB database. 2) it has upgraded it but not changed the version number or 3) there are in fact no upgrades/changes to make so it didnt bother to change the database number within the database in SQL!

 

If it's the last option (that Update Rollup 7 didn't need to upgrade/change the database so it didn't bother to change the database number within the database in SQL) then from Microsofts' own website they provide an SQL script to simply enable you to manually change the database number so you can continue with the upgrade - I'm just concerned in case it's not the third option but one of the other two and by simply changing the database number manually to trick DPM in to upgrading will cause the integrity of the data to not be right?

[MrBrow]

I've done my upgrade:

(Was WS 2012 R2, SQL 2014, DPM 1807)

 

1. Upgraded SQL from 2014 to 2016

2. In-placed upgrade from WS 2012 R2 to WS 2016

3. In-placed DPM to 2019

 

 

An issue with the agent on a SQL cluster server but that was it. Everything seems to be working right now. I guess by not doing a clean install it hasn't removed the End-User-Recover / Item-Level-Recovery ability, which is good. This will do for now (not virtualised so not making the most of Dedupe BUT I retained more important features).

 

@Fazza Not sure what to suggest. I just checked out DB version number and its definitely updated now within SSMS (10.19.58.0). Not sure what it was pre-update though.

 

Uninstall / re-install UR7? Take a backup of the DB of course before you do anything but surely the data itself would still be good if you messed anything up. Just relink and rescan source backup data....?

[Fazza]

Well, my boss has just announced that he has finished upgrading our Home Folders file server from 2008R2 Server 2019 (via 2016) so now I've got no choice but to get DPM upgraded to 2019 so this will be fun!

[Fazza]

Is this a good sign:

 

 

I've never seen a big red cross like that on DPM before!!