Closed danboid closed 5 years ago
I've partly answered one of my questions now. I tried changing the Windows key in the config.ini because at first I used a KMS key but it turns out the machines we're deploying to can't access that key server so I wanted to try a different, non-KMS key.
The scripts are stalling on the error "Windows is already licensed with partial key ...." so, what files within the windows iso tree need replacing with defaults when re-running the openstack imaging tools, to save me replacing the entire ISO on every run?
It seems that deleting your entire Windows ISO directory between runs of the script is not sufficient to start over with different settings. I originally used a KMS key but now I changed that for a MAK key. After deleting the entire Windows ISO directory and running the script again (with my updated config.ini), I get the error "Windows is already licensed with partial key:"
How do I do a proper clean up between runs of the script to ensure that previous keys or other config.ini settings don't linger?
Hello,
I think somewhere in your workflow the image previously used in not removed. Although the script should remove the already existing vhdx. Can you give more details on what you are trying to accomplish? The script supports also golden/from golden image generation. Golden image is an intermediary image from which you can create different images with different behaviour.
I am trying to create a automated W10 Enterprise installer for MAAS that will be registered/activated after deployment.
Do the scripts modify the contents of the w10 ISO (that has been extracted onto disk beforehand)? This is what I presume is happening here as I don't understand where else it could be caching the previous keys that I used?
I have been making sure the vhdx images don't exist before running the scripts. I've had to delete them sometimes, when sysprep fails.
If it was the wrong type or an invalid key for the W10 SKU I'm using , it would give me a different error right ie not "Windows is already licensed with partial key:" - surely thart key isn't on the ISO I used as its a MS, non-custom ISO?
I'm presuming that the W10 ISO I'm using must be KMS only and I need to find a W10 Ent ISO that accepts MAK keys. I wish MS would cut down on the varieties of Windows!
Also, make sure if you changed something in the .psm1 files, remove-module
Nope, I've not touched any of the PS files, only modified config.ini.
Should a W10 Ent ISO accept both (valid) MAK and KMS keys, or just KMS?
I am trying to create a automated W10 Enterprise installer for MAAS that will be registered/activated after deployment.
Do the scripts modify the contents of the w10 ISO (that has been extracted onto disk beforehand)? This is what I presume is happening here as I don't understand where else it could be caching the previous keys that I used?
This might be the case in your setup, as the imaging tool is supposed to work only with mounted ISOs and has not been tested with copied ISO contents. Try with a mounted ISO or a fresh copy each time you create another image.
A Windows accepts only product keys valid for that SKU, make sure that you have valid keys for W10 Enterprise.
At what point during the image creation you get the 'I get the error "Windows is already licensed with partial key:"' error?
I get that error in the VM shortly after it says "Wating for sysprep to finish" in the PS console
I tried using my key on a W10 installation setup from the same ISO I've been using with the openstack scripts and it works so its not a case of my key being invalid or this key not being compatible with the ISO I've been using.
Unless you have any other ideas then I'll have to try activating Windows using slmgr in a post install script instead of including the key in the config.ini.
I've just looked at the custom script options in config.ini: RunBeforeWindowsUpdates.ps1, RunAfterWindowsUpdates.ps1, RunBeforeCloudbaseInitInstall.ps1, RunAfterCloudbaseInitInstall.ps1, RunBeforeSysprep.ps1 and RunAfterSysprep.ps1.
I'd want a RunOnFirstBoot.ps1 but that doesn't seem to be an option. Could it be added? It could be useful for tasks other than Windows activation, I'm sure.
Hmm, there is no need for run on first boot, as you already have SetupComplete.cmd "$env:windir\Setup\Scripts\SetupComplete.cmd"
This script is executed at the first boot only, after sysprep finishes.
You can add in RunBeforeSysprep.ps1 some code similar to https://github.com/cloudbase/windows-openstack-imaging-tools/blob/cabf47fc4075a46aaf4d57a1935ba20e907e54ba/UnattendResources/Logon.ps1#L250
Make sure to only add to that script, as there is already some code related to cloudbase-init already there.
Windows auto registers now.
I added the lines:
& cmd.exe /c "slmgr.vbs /ipk WINDOWSKEY"
& cmd.exe /c "slmgr.vbs /ato"
After the line:
Add-Content -Encoding Ascii -Value $logonReset -Path $setupCompletePath
in UnattendedResources\Logon.ps1
The first time I tried running the openstack scripts they completed successfully. However, on my first attempt I decided to leave out integrating updates to spare myself some time in case the image didn't work.
I have since tried a few more times to build another image using different config.ini settings but the script only gets as far as
I have waited up to 5 hours (on an 8 core i7 w/ SATA3 SSD , 16 GB RAM and gigabit internet) for sysprep to finish but it never does. The first time I ran the scripts sysprep took around 40 minutes to complete but that was with no updates applied.
Are there common causes for sysprep failing or things to avoid/do to make it work more reliably?
Is it neccessary to perform some manual clean up between creating images, apart from moving or renaming the previous output image, if using the same file name for the image?
I see running sysprep is optional but what are the disadvantages to not running it?
If I kill the script during the sysprep phase, it does not tidy up / remove the HyperV VM which prevents the user deleting the vhdx files until they manually delete the VM.