First published on TECHNET on Aug 09, 2017
During a recent customer engagement, I was tasked with upgrading the existing SCCM 2012 R2 site to Current Branch (1702). The upgrade went off without a hitch in the lab environment and I fully expected the production upgrade to go silky smooth.
At a very high level, here are the basics of the process:
Prior to the upgrade we ran TestDBupgrade without issue. Next, we downloaded the updated installation files and then began the upgrade by kicking off the splash screen and stepping through the initial wizard. The pre-requisite check passed with zero errors or warnings.....silky smooth. Interestingly, the installation began and immediately the dialogue window disappeared. A quick glance of the ConfigMgrSetup log showed an error during installation: 
I initially ruled out the common items like running the splash as an admin, installing off a fresh reboot, and verifiying that the version of SQL is supported (sql 2012 sp3). From there, I moved on to rule out any custom DB entries and custom hardware classes. Eventually I was able to narrow down the culprit to this:
INFO: D:\Install\SharedManagementObjects.msi installation process returned 1603.
I've done quite a few upgrades and have never ran across this error before. A Bing search doesn't reveal much either. (So much for silky smooth)
Next, we should probably take a look at what is installed. Jumping into Programs and Features I can see that the site has two versions of ShareManagementObjects (SMO) installed. SMO 2012 is installed and for some unknown reason, SMO 2014 is also installed: 
Interesting..... so let's take a glance at the version of SMO that the upgrade is attempting to install. If you drill down into the mounted .iso to SMSSETUP\BIN\x64 we find sharedmanagementobjects.msi. 
Glancing at the properties we can see that this is the 2012 version: 
Out of curiosity, I ran the installer and it revealed an error: 
Next lets examine the updated installation files. If you drill down through the files from the download location that is selected during the wizard we also find sharemanagementobjects.msi. 
Again, glancing at the properties we now see that this is the 2014 version: 
Again, running the installer we are prompted to repair or remove SMO 2014.
I compared the dates of the installed SMO versions in the lab environment with the production environment and noticed that the install date of SMO 2014 in the lab was the same date as the upgrade. Looking at the production server, the installed date of SMO 2014 was almost a year ago. Seeing as the evidence is pointing to SMO 2014 possibly being the culprit, we uninstall the 2014 version on the production server.
Once SMO 2014 is completely uninstalled, we kick off the 1702 Upgrade once more. This time the upgrade continued and completed successfully. Programs and features shows the newly installed SMO 2014 with today's date. Oddly, this wasn't caught in the pre-requisite check and there is a hard stop on the return code for a previously detected version.
Since there wasn't a lot of helpful content online, I decided to share this in the hopes that we can save someone a couple of hours worth of troubleshooting and have a more silky smooth experience.
Happy Upgrading!
Evan Mills - MSFT
Disclaimer: This posting is provided 'AS-IS' with no warranties and confers no rights.