Introduction

Anyone that spends time with ConfigMgr knows that it’s an amazingly resilient product, and not only that, upgrades tend to go without a hitch.

I needed to upgrade one of my old labs to test new functionality, but when I restored it to a state that I wanted to start from (namely running ConfigMgr 1910), the upgrade wouldn’t proceed due to lack of space on the C:\ drive, and that was because SQL stored the ConfigMgr database and logs in the default path and it had grown in size.

Detach/Attach

No big deal I thought, I’ll just detach the DB and move it to another drive, do a site reset and be done with it.

I did go ahead and detach the DB, and moved it to the next drive letter with enough free space and after a site-reset and resetting SQL permissions.

With the space freed up, I decided it was time to perform an upgrade from ConfigMgr 1910 to ConfigMgr 2006.

After initiating the upgrade I saw it failed the prerequisites check again shortly after, so I was interested in finding out why. Did I make a mistake with the SQL permissions ?

The Update Pack Installation Status showed what was causing the problem.

But didn’t go into more details. For that I’d need to dig into the logs.

The interesting thing here is that even though I already detached the DB, did a site reset and reset SQL permissions, that it was bombing out on SQL Server requirements.

A quick look at the ConfigMgrSetup.log in the root of C:\ gave me more info.

And it politely told me to look at the ConfigMgrPrereq.log also hosted in the root of C:\.

And there it was, not only was there an error with the SQL Server configuration, but the ConfigMgrPrereq.log file also told me how to fix it.

Awesome.

Here’s the error:

ERROR: Invalid configuration for 'Service broker is enabled', to remediate: Use ALTER DATABASE to set ENABLE_BROKER $$<Configuration Manager Prereq>

Fixing it

Armed with this knowledge I started SQL Server Management Studio and used the following Query.

alter database [<dbname>] set enable_broker with rollback immediate;

As shown here. The ‘with rollback immediate’ allows it to complete regardless of the transactions that are pending, otherwise it’ll probably run the query forever.

Don’t believe me ? try it. 😛

After doing this I was able to upgrade the site successfully ! I have to say a big thanks to the Engineering team at Microsoft for not only clearly pointing out what was wrong, but explaining how to fix it (in the Logs).

Side note, I’ve had a similar problem before, and I even blogged about it then too !

ConfigMgr log files help you when you least expect it, oh and SCCM 1904 TP is out !