Windows 10 activation failure after restoring image to different instance of same hardware


Author
Message
merwinsson
merwinsson
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)
Group: Forum Members
Posts: 11, Visits: 85
Let me establish some background before I elaborate on the subject of this post.
I am a volunteer administrator for a small private school that has a handful of computers.
The computer count (just over a couple dozen) breaks down as follows:
10 Dell OptiPlex 760
8 Dell Vostro 270s
7 Dell Inspiron 3646
Because of the low count and tight expenses, we do not own or utilize a domain server - all of these computers are running Windows in a workgroup.
Originally, all these computers were purchased with Windows 7 Pro, OEM, but now all run Windows 10 Pro 1703 (15063) RETAIL [64 bit], as I dutifully ran the upgrade process on all of them before Jul 29th of 2016 and have kept them updated ever since.
Because this is a school, and the kids mess with the computers no matter how well they get "locked down", a computer gets "hosed" from time to time and needs to have an OS rebuild.
Now, even though I've outfitted all these computers with an SSD as the main boot and OS drive, it still takes the better part of 90 minutes to re-install Windows fresh, and reprovision the machine with all the desired software and settings.
Additionally, I go through this cleaning and reprovisioning process every year right before school starts, just to make sure everyone has a clean slate. It takes a LOT of time.
This year, I decided to make a "golden image" for each of the 3 different machines so that all I have to do is restore an image to "refresh" a machine.
I started with the Dell Vostro 270s machines, and, for the most part, all went well.
I imaged one, with the administrative account set to a simple password and the machine named "COMPUTER".
Then I restored it to another machine, put a strong password on the administrative account, and renamed the unit with its proper computer name.
The only thing that went wrong was that I did not disable "fast startup" before imaging and because of this when the restored image booted up the first time on a different machine I got a special blue screen that complained about the machine changing.
But I was allowed to hit a function key to re-boot cold, and then all was well. The cloned machine would come up and remain ACIVATED.
I then moved on to the Inspirons and OptiPlexes, and that's when things went awry.
On both these type of machines the restored image would fall out of activation very shortly after booting with a 0xC004F034 error.
I've been trying to figure out why this would happen but I'm at a loss as to what makes these computers different from the Vostros, which have no problems with my process.
I've also tried some fixes.
One fix involved running some slmgr command that created a GenuineTicket xml file for each machine while the machine was in activated state, and then placing that file on the machine after imaging, however, that did not work.
Another solution entailed using a microsoft account to link the digital license, again, while a machine was activated, and then logging into that account after imagaing the machine to restore activation. Again, no dice.
I've hit a wall.
At least I haven't LOST the activation status of these failed test machines as I can always re-install Windows 10 FROM SCRATCH and VIOLA, the machine is activated again.
Is there any command or set of commands I can run after restoring an image that will make the machine think it has no previous activation info? I think what's happening is that the activation info of the imaged machine is no longer correct on the restored machine and instead of trying to reactivate, Windows just gives up and says "NO, this is a bad activation state".
In any case, until I've solved this issue I have to spend 90 minutes reprovisioning a machine every time one gets messed up, so I'm very keen on figuring out what's going on.
Any ideas?


jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
You need to sysprep a Windows installation before you capture it as a gold image, and it's generally recommended to do everything required to build the gold image in Audit Mode, before any user accounts have been created, in order to keep the source image as clean as possible.  Sysprep causes Windows to go through the standard out-of-box setup when it next boots, including a new round of hardware discovery and a new activation attempt, since sysprep tells Windows not to assume it will be running on the same hardware the next time it starts. Additionally, if you wish to use Reflect for this type of image capture and deployment, you may need to have a Technicians Deployment Kit license. Having individual Reflect licenses for each PC might be an appropriate substitute, but you may want to ask Macrium Licensing, especially if the latter option would be more cost-effective for you since it also allows you to keep Reflect installed on each PC, which the Deployment Kit doesn't.  There are also free Microsoft tools that you can use to perform capture and deployment, but they do involve more effort and/or more infrastructure.  But yes, as you've found, having a gold image in general can save a massive amount of time over doing a fully manual rebuild of multiple systems every time.

Also, note that Windows can distinguish between different PCs that have the same hardware. Motherboards often have unique IDs (called a UUID), network interfaces have unique MAC addresses, and hard drives have unique serial numbers.  What probably happened in your case was that if you didn't run sysprep prior to capturing your gold image, when you put the image onto the same model PC, the Windows installation on the new PC assumed that it was still booting on the original system it had seen before, but that it had just had its motherboard and hard drive replaced, and those changes weren't enough for it to fall out of activation.  However, moving to a completely different system MODEL is of course a much larger change.  I've explained this "points system" that Windows uses to allow certain types and quantities of hardware changes without affecting activation status in other threads here.  But the problem you may encounter eventually if you continue not to sysprep is that the license of the SOURCE machine might end up going defunct, because (I think) Windows updates Microsoft with the new "hardware fingerprint" for the original activation when it detects new hardware, and without sysprep, all of those other PCs would be updating the license that was applied to the image source PC.

Sysprep is a very useful and extremely capable tool if you start looking into using unattend files in order to automate things (the out-of-box setup answers, creating accounts, setting passwords, TONS of other stuff), but if you'd rather keep the prep simple and do a little more work on the back-end rather than increasing setup complexity to maximize deployment functionality/efficiency, basically you just have to do the following:

1. Perform a clean Win10 Pro install on your "gold image" system.  When the out-of-box setup interface appears, press CTRL+SHIFT+F3.  Typically you have to do this no LATER than the step where you choose your privacy preferences, but Win10 Creators might allow it right when Cortana starts yammering at you.  The goal is for the system to log straight into the Administrator account with a popup that it's running in audit mode.  Close that warning when you see it, including each time you reboot this system while setting up the image.

2. Perform any application/driver installations you may require.  Ordinarily this would also be a handy time to customize the Start menu, desktop icons, etc so that those settings would be applied for every new user profile created going forward, but that requires using an unattend file to specify this "default user profile update", and Win10 1703 frustratingly has a bug that breaks Search when that's used anyway.  Win10 1511 had this bug, Anniversary fixed it, and 1703 broke it again. Sigh....

3. When you've got everything ready, open Command Prompt and run the following:
cd c:\windows\system32\sysprep
sysprep /generalize /oobe /shutdown

4. The PC will shut down.  At this point, do NOT let it boot to the hard drive again until you've captured an image of its hard drive.  Capturing with Reflect will simplify things greatly if you have the correct license, otherwise you can boot into a regular Windows 10 Setup environment from installation media, open Command Prompt by pressing Shift+F10, and use the DISM tool to capture images of the system's C drive and its Recovery drive each to WIM files.

5. Deploy to other PCs using your mechanism of choice.  Again, Reflect makes this easiest (and you would NOT need to use ReDeploy afterward thanks to sysprep), otherwise you can boot into Windows 10 Setup and use DISM to apply the image files to the targets instead of stepping through the Windows Setup wizard, but that also requires you to manually set up the disk partition layout and (if using UEFI boot) configure the EFI and MSR partitions.  Another option (and the one I use) is to modify the Windows 10 installation media so that the Windows Setup wizard itself will actually install your customized image rather than the standard Windows 10 environment, in which case the setup routine will do all of the disk setup work for you (and you would be able to skip capturing the Recovery partition image), but that requires making tweaks to the image file you captured first.  Finally, there are network-based deployments (called PXE boot) that are even easier, but that requires something like Windows Server's WDS feature.

Edited 14 August 2017 5:54 PM by jphughan
merwinsson
merwinsson
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)
Group: Forum Members
Posts: 11, Visits: 85
Thanks for that most informative post jp.
I figured that someone was going to tell me I needed to sysprep.
I've stayed away from this tool up to this point but I guess I'll have to deal with using it now.
I certainly thank you for the bit about all the Vostro images looking the "same" to Microsoft, and possibly losing licensing status on the units that are not the "golden" one.
I'm going to re-image everything the way you have suggested, including the Vostros (to ensure licenses don't get stale), and we'll see what happens.
For clarification, all these machines are standard MBR double partition installs; basically I wipe (diskpart clean) the install drive then install Windows to it and Windows choses this double partition format (small System + large Boot).
As for my use of Macrium, I've been using Reflect 6 Free from a Windows ToGo environment.  I understand this is probably not kosher licensing-wise, but this is all in the test phase right now.  Moving forward, I guess I'll have to either use MS imaging tools or choose something that is truly free to use in a non-home environment.  A technician's license is too expensive.
I'd like to continue to discuss why the Vostros still work though.  What is at play here?
Windows certainly knows that each Vostro is different because--as you mentioned--each Vostro has a different MB serial, different MAC address for the embedded network, and a different disk ID.  The same goes for the OptiPlexes and Inspirons though.
So what's happening? Why does Windows activate fine on the Vostros but not the others?
I ran "slmgr /dlv" on two of the Vostros and one OptiPlex to get some insight.  I've attached the output to this thread as out1 out2 (Vostros) and out3 (OptiPlex).
I can see the Installation ID changes between the Vostros, and the Extended PID changes as well in the OptiPlex file.
Not sure what all this means but am hoping someone does.



Attachments
out1.txt (0 views, 904 bytes)
out2.txt (0 views, 904 bytes)
out3.txt (0 views, 904 bytes)
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
I avoided sysprep for a long time as well, preferring tools like Norton Ghost, but once I got used to it I realized that it's not all bad.  The whole image capture and deploy process is MUCH easier the SECOND time. Smile

Again, I would contact Macrium Licensing about this (licensing at macrium dawt com), especially given that you're discussing your usage on their own forums.  If a Technician's Deployment Kit is too expensive (though they may offer discounts for non-profit/education scenarios....), as I said earlier, having a regular Reflect license for each PC in your environment may be an appropriate substitute, and I believe it would cost less given the quantity of PCs.  If you can't find a properly licensed Reflect solution that works within your org's budget, then if you require further assistance using DISM to capture or apply images, I can help, although that might be best done over private message since that would be a completely off-topic discussion at that point.

But yes, to prep your gold image, use diskpart to clean the disk and have Windows set up the MBR layout, which as you say will give you Recovery and OS partitions automatically.  After you get it set up in Audit Mode, whether you need to capture the Recovery partition depends mostly on whether you will be deploying the image using DISM or by tweaking the Windows installation media to lay your image down through that wizard.  In the former case, you'll need a capture of the Recovery partition; in the latter case, Windows Setup will handle that for you as part of its process.

In terms of activation, Microsoft understandably doesn't share the exact details of how their activation process works, but my THEORY for why this is working for the systems that are the same model as your gold image and not the others is that Windows is seeing each of the other Vostro systems as the original system but simply with a different motherboard and hard drive.  After all, motherboard and hard drive swaps aren't completely out of the ordinary, even when performed at the same time, so the Windows installation you're moving over is probably booting and saying, "Ok, this is the same system I was originally installed on, except that the motherboard and disk were changed" -- even though it's incorrect in that conclusion in your case.  So it might change its hardware fingerprint to reflect the new hardware, but not consider the change substantial enough to force reactivation or trip any other safeguards.  However, when you clone that installation over to a completely different model, it can actually see that the model of the system is different.  That information can be pulled from the BIOS (open PowerShell and type "Get-WmiObject win32_computersystem" and you'll see your Model reported), and I'm sure that by itself is enough to tell Windows that it's now on a completely different system, with no possibility that this was just a parts swap.

By comparison, if you sysprep those systems, then as long as you did in fact claim a Windows 10 Pro upgrade on all of the original systems at some point, the sysprepped installation will attempt to activate with Microsoft, and at that point those systems' hardware fingerprints should be recognized by Microsoft (even if you claimed the upgrade before the SSD swap) and then they should activate properly using their own licenses.

Edited 14 August 2017 11:47 PM by jphughan
merwinsson
merwinsson
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)
Group: Forum Members
Posts: 11, Visits: 85
Just to clarify...
I'm not trying to restore the Vostro golden image on an OptiPlex.  I have an OptiPlex golden image for that.  I would NEVER restore an image to a machine that was not an exact hardware replica (unless it was a data recovery emergency).
So in theory, the restore of the OptiPlex image to another OptiPlex is no different than a Vostro-Vostro restore...yet something IS different.
Perhaps there is some significant difference in what the BIOS reports for the OEM strings between the OptiPlexes, but the Vostros look exactly the same...I'll check this, but I have serious doubts that your theory about Windows thinking the machine had a motherboard swap is correct.  I wish there was some way I could access that info from Microsoft to see if it's true, like logging into some website to see activation info about a system...how many times it's been activated, how many times its hardware changed and WHAT was changed...that way all these theories could be validated...until then this is all just conjecture.
Also, to add some more info about my Macrium licensing, I DO possess a Macrium Reflect 7  Workstation license, otherwise I would not be able to post here at all.  But yes, for this imaging trial I realize I'm exceeding the bounds of the free version.  I'll just switch to an alternative free imaging solution when I've got everything down and working.  It's just that I've been using Macrium for so long as it's my goto program for all home imaging, hence it was natural to continue to use it at the school (and we are a tiny non-profit, so it still feels like home).  I simply wasn't thinking about licensing, so thanks for pulling me back into the reality of the business world.  Macrium products have served me well and I wouldn't want to anger them.
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
Ah ok, I didn't realize you were using different gold images for different models.  In that case I can't account for the different behavior.  However, sysprep is specifically designed to allow your "NEVER" scenario of building an image on one hardware platform and deploying it to another one -- that's what the "generalize" parameter I mentioned above does.  It's quite adept at that, and that functionality is quite handy because you don't have to keep several images maintained anymore.  I still remember what a chore it was at a previous job every time we had to change our corporate image standard when we maintained a library of Norton Ghost images, one per hardware model -- we had to find a "wipeable" example of the model of interest, push the current image to it, make the changes, capture a new image, and repeat that over and over again for each supported model. It was a gigantic waste of time (and storage), especially because we had to support entirely too many models.  With a sysprepped WIM file, worst case you have to ensure that drivers for all possible target hardware platforms are included in a single image, but given that you're deploying Windows 10, chances are that between its native hardware support and Windows Update, it will cover all driver needs for the models you're working with anyway.  And if not, you can inject driver packages into a WIM file using DISM, or if you ever do get a Windows Server box in order to use WDS, you can actually maintain a driver repository separate from your image(s), and when the image is deployed over the network, WDS dynamically pushes the drivers required for the target system from its library as part of the image process -- so if you want to add support for a new model later, you just have to add any necessary drivers to the library and you now support that platform, no need to touch the image at all.

And incidentally, the ReDeploy feature of Reflect is also specifically designed to allow restoring images to dissimilar hardware, albeit in a "single instance migration" scenario rather than a "capture gold image and deploy to multiple targets" scenario.  It too works quite well.  Deploying an image built on one hardware model to another one is not nearly as scary as you seem to think, as long as you learn to use the tools designed to enable this. Corporations do this all the time, not to mention PC manufacturers.

Another perk of DISM by the way is that you can install Windows Updates directly into WIM files, so for example every few months you could push the latest cumulative update into your image so that your PCs don't each have to download 1GB+ worth of updates immediately after they're imaged.

I'm telling you, Sysprep and DISM are worth your time to look into for your use case. It may be frustrating early on, but once you get a handle on the process, you're going to love the efficiencies and simplifications and the time you will consequently save overall. (That's even more true of learning PowerShell, but that also takes longer.) Work smart, not hard! Wink

Edited 15 August 2017 3:05 AM by jphughan
merwinsson
merwinsson
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)
Group: Forum Members
Posts: 11, Visits: 85
Well, my first attempt at using the sysprep method resulted in the restored machine having an another activation error.  This time it's C0EA000A.
Grrrrr.


jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
A quick Google says that that means "Activation not possible at the moment".  Seems like that's at least a step in the right direction over a hard rejection. If you haven't already, restart, make sure you have an Internet connection, and then try running "slmvr.vbs /ato"

Edited 15 August 2017 10:44 PM by jphughan
merwinsson
merwinsson
New Member
New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)New Member (15 reputation)
Group: Forum Members
Posts: 11, Visits: 85
Another error.
I attempted to paste an image inline however it came out very poor.
Attaching the jpeg instead.
BTW this is the actual sysprep machine after a sysprep reboot...it's not even an image restored on another machine.
Attachments
error.jpg (5 views, 182.00 KB)
Edited 16 August 2017 1:49 AM by merwinsson
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)Most Valuable Professional (4.3K reputation)
Group: Forum Members
Posts: 3K, Visits: 21K
So these systems originally had OEM licenses for 8.1 Pro, and you ran in-place upgrades to Win10 Pro, correct?  Was that before or after you replaced the hard drives with SSDs?  And when you ran the Win10 upgrade, had you already cloned a non-sysprepped 8.1 image from one PC to others? I've never seen that error before, but I'm now wondering if any or some combination of the following accounts for this:

- The SSD upgrade is preventing Windows from recognizing those systems as the same ones that claimed the Win10 upgrade. This would be rather unlikely, at least if it were the only factor involved.
- If you did NOT use non-sysprepped 8.1 images before the upgrade, then those systems should in fact each have unique Win10 licenses associated with them, but the non-sysprepped cloning you've been doing for Win10 thus far might have completely scrambled their individual Device IDs.  In this case, you may be able to use the automated phone-based activation mechanism to get them properly re-activated.  However, I've never had to do that with a Windows 10 digital license (as opposed to one associated with a product key), so I'm not sure on this.
- If you DID use non-sysprepped 8.1 images before the upgrade, then in addition to the above possibility, I'm wondering if some of those systems might never properly claimed their own unique Win10 upgrades to begin with, and instead just kept re-registering against the same Device ID from the source image PC, merely updating the motherboard and hard drive serial numbers associated with that activation profile's fingerprint, and they only all activated up until now because of the way that you cloned them.


Edited 16 August 2017 2:19 AM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search