As I wrote about yesterday, there seems to be an issue upgrading to Windows 10 1709 when the OEM license in the BIOS is a different version than the one actually installed. I also mentioned yesterday, that our primary method of upgrade would be through SCCM using Task Sequence.
Well, today I found this article by Adam Gross, and well, this is exactly the same issue we were experiencing. More importantly, the solution mentioned in the article worked when we tried it, and we are now able to move forward with the upgrade to Windows 10 using SCCM.
What is interesting is that this issue is really hard to find on the internet. It took me googling different lines from the SCCM logs to finally find Adam`s post. I can only imagine, that as more and more administrators roll out Windows 10 1709 we may see more posts about this issue.
I have teased this issue in the past here and here. And today, with a little bit of help, I figured it out.
Let`s start from the beginning.
The company I work for began the process of rolling out Windows 10 this past summer (this makes sense as support for Windows 7 ends in about 23 months). I was designated as the one responsible for making sure the rollout commenced, the upgrade worked, and that users would not be adversely affected by the change. Most of the upgrades would be from Windows 7 Enterprise to Windows 10 Enterprise through SCCM.
Things began smoothly enough. We had some minor issues in the beginning with the A/V, and the profile management service we were using, but all in all, things seemed to be moving along pretty well.
This all changed with the Fall Creators Update. For some reason, certain machines would fail to upgrade. No matter what we tried the upgrade kept failing (upgrades to Creators Update worked fine).
The error code that kept showing up in the SCCM logs ended in 204, which indicated that there were some incompatibilities between the current OS and the OS we were trying to upgrade to. This was so strange as the machine was running Windows 7 Enterprise, and we were trying to upgrade to Windows 10 Enterprise.
One of us finally had the brilliant idea of running the ISO downloaded from the licensing portal to see what would happen. And wouldn`t you know it, the upgrade tried to install Windows 10 Pro. Hmm…
Now is probably a good time to let you know that the Fall Creators (1709) ISO came with Pro, Enterprise, and EDU all lumped together. It would be up to the installer to decide which version to install. This lumping together had something to do with our issue because as I said before Creators Update (1703) upgraded fine. The 1703 ISO comes with only one version so you have a 1703 EDU, a 1703 Enterprise etc.
However, this by itself could not be the problem, because these PCs clearly had Windows 7 Enterprise installed. I mean it said it right there in the system properties.
Another thing I must tell you is that these were the first PCs we ordered that came imaged with Windows 10 (Pro). This means that there was a license for the OS embedded in the motherboard. However, we didn’t use the OS the PCs came with, rather we would swap out the HDDs for SSDs, and then image the PC with an enterprise OS.
Sooo… it would seem that the upgrade was picking up the license still embedded in the motherboard. But could we prove this? Well as a matter a fact yes we could. There is a tool, called ShowKey Plus, which will retrieve the product key from the registry or even BIOS (kudos to Into Windows for the information about the tool).
ShowKey Plus confirmed what we suspected: There were two Product keys on the PC. One, for enterprise, installed with the current OS, and one, for pro, in the BIOS.
With the cause of our problem confirmed, it was now time to come up with a solution. I came across a post from the Superuser site. The user’s problem seemed similar enough to ours that I thought I would give the solution a shot. I added a file to the sources directory in the ISO called PID.txt. In the file, I typed [PID] followed by the product key. After this, I ran the ISO and thank goodness it picked up the product key and installed Windows 10 1709 Enterprise.
Now we just need to make it work in SCCM, and move forward with our rollout.
As you may have read here I managed to mess up my PC`s BIOS, thereby rendering my motherboard useless.
On Friday the MFR sent over a brand new motherboard under the warranty. However, unlike previous times (yes there have been previous times), this motherboard came without a tech.
This presented a number of challenges. Firstly, the serial number of the PC must be updated in the BIOS, which is something the tech is supposed to do. If this is not done, then the user will get an alarming beeping noise and a BIOS error whenever they boot up their PC.
Secondly, and most importantly, is that up to this point I had never changed a motherboard before. Plain and simple.
Don`t let that stop me.
Right off the bat I realized that I did not have an ESD bracelet. No matter, I told myself, as I grounded myself through the PC`s power supply. Next, I noticed that we did not have non-magnetic screwdrivers. Again, no matter, as I decided to risk it using my magnetic drill.
I began by unscrewing the fan and moving the CPU to the new motherboard; Simple enough. Then I began to unplug all of the cables, which brought on the I-won`t-remember-where-the-cables-are-supposed-to-go anxiety, or IWRWCASTGA for short. Then I unscrewed all 8 or so screws, and took out the board.
The next part should have been a cinch, and initially it was. I placed the new motherboard inside the case, tightened all the screws, and even managed to place all the cables back in their original one (except for the one that connects the power button to the motherboard).
It was when I was trying to tighten the screws for the CPU fan that I noticed I had a problem. For some reason the screws would not tighten. I looked into the holes where the screws were supposed to go, and I saw nothing. It was like looking into a deep dark abyss. At this point it occurred to me to check the bottom of the old motherboard, and I noticed a bracket holder. So I removed it, and after some more unscrewing, cable removing, and screwing I had my new motherboard all set up and ready to go.
At this point everything should have been peachy keen, but it was not. As you may recall from a few paragraphs back, when a motherboard is replaced, the serial number for the computer must be updated in BIOS. Otherwise, the PC will make an annoying beeping sound at boot and show a BIOS error.
For some reason I was unable to get around this beeping sound. Every time I tried to boot, it would not pick up the OS in the hard drive, and continued looping through PXE. This continued for a bit, until I changed the BIOS to boot in legacy mode. The PC booted all the way to the Windows login in screen…
…but that was as far as it was willing to go. I believe this had something to with the OS not knowing what to do with the new hardware, and causing the hardware abstraction layer to not work properly.
To make a long story short, I re-imaged the PC, and flashed the bios with correct information. And we lived happily ever after.
As a side note, after all this I tried to upgrade this PC to Windows 10 1709 Enterprise from Windows 7 Enterprise (I will write more about this issue a different time), and it worked!
We are currently dealing with an issue upgrading certain PC models to Windows 10 Fall Creators Update. No matter which method we tried (SCCM, ISO) the install would always try to install the Pro version, and we needed the Enterprise version (more on this a different time).
I had the brilliant idea of flashing the bios to solve the issue. I did this under the assumption that there is some kind of marker in the BIOS, that is telling the the Windows 10 installer to install Pro (whether this is true or not i have no idea).
Well… now the PC will not start. I mean it powers on, but it fails at POST.
My solution, call the manufacture of the PC to see if we could replace the motherboard under warranty.
The Desktop Support Spiel 