What to do when Endpoint Manager upgrades don’t go as planned. Hint: logs


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.


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.


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 !

This entry was posted in 1910, 2006, detach database, SQL Server 2017. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.