[6-Jul-2018: Updated Script to v 1.2 – New .NET 3.5.1 install command (per Mike Horton @mikeh36)]
After attending MMS one of the items that I put on my “Post-MMS To Do” list was to patch my OS Upgrade package source the proper way. I don’t want to do it manually, nobody does, so I set out to learn exactly how to do it right and script it.
That where Mike Terrill and Johan Arwidmark come in.
“It’s been a long time…”
– Jimmy Page [Led Zeppelin]
It’s been too long since my last post.
Well, my wife’s laptop started getting the popup to reserve her copy of Windows 10 so I thought I’d spend a Sunday doing the upgrade. The problem was that the hard drive in her laptop was just about full. The laptop was a few years old and the drive (120GB) which might have been enough when it was new just wasn’t making the cut lately.
To be honest with her birthday coming up next month it’s about time to get her a new laptop.
Anyway, I needed to replace the original hard drive with a larger one so I could 1) complete the Windows 10 upgrade and 2) giver her some breathing room for a while.
The upgrade from Windows 7 to Windows 10 is pretty straight forward and well documented so I’m not going to focus on that. Instead I’m focused on the process of cloning her hard drive to the bigger drive.
Ran into a problem deploying build 10061 using SCCM 2012 R2. It would get as far as the standard “Setup Windows and ConfigMgr” action, reboot into the full OS and fail to continue the OSD task sequence. My test machine would join the domain and I could log in, but it was as if it just got bored and gave up on running the rest of the task sequence.
I would open up Control Panel and there would not be a Configuration Manager applet. The client folder (C:\Windows\CCM) didn’t exist either.
Did some searching and ran across this posting by Jörgen Nilsson. This was my exact problem.
The workaround is to skip the Windows Update Agent installation. So in my task sequence I added an ” /skipprereq:windowsupdateagent30-x64.exe” to the Installation Properties:
And now I’m off and running.
Several weeks ago Johan Arwidmark published an article about creating a Windows 10 ISO using the install.esd file generated from the upgrade process. He also included a PowerShell script to automate the process. His article can be found here.
I’ve used this a number of times and it works wonderfully. Call me odd, but I have a set of 4 virtual machines that I use simply to generate the ISOs and installation source files. I have a pair of Windows 10 Professional (32bit and 64bit) and a pair of Windows 10 Enterprise (32bit and 64bit) VMs. I use the Professional SKU in my lab and the Enterprise SKU for testing at work.
I modified Johan’s original script to automate some “branding” of the process. For example, the ISO generated includes the build number, SKU and architecture. When a new build is released to the Fast Ring my VMs update and then I just run this script. The script determines what build, SKU and architecture the VM is running and generates a unique name for the ISO as well as the parent folder that also contains the contents of the ISO.
I’ve been working on integrating Windows 10 into our environment and ran across a couple of issues learning opportunities while doing so.
Upgrading from 9926 to 10049
First off I hit a snag attempting to upgrade my test machines from build 9926 to build 10049. The SCCM Team published a blog article back in October of last year on how to use a task sequence to upgrade a client to Windows 10. You can find the article here. A couple of weeks ago I had the opportunity to work with Paul Winstanley (SCCMentor and WMUG author) on a live blog he was writing on upgrading from one build to another using this method. In the lab environment it worked wonderfully, but when I tried it outside of the lab it failed every time in my environment.
Now, your first question might be along the lines of, “Why are you upgrading builds like that?” That is a good question. I cannot use Windows Update to upgrade my machines as new builds come out because the company I work for uses a combination of Group Policy and SCCM client policies to block access to WU and use WSUS/SCCM as the source for all of our updates. So I have to upgrade builds outside of the native process, hence using the task sequence in SCCM to perform the upgrade.
Last week ConfigMgr blogger and Twitter friend Paul Winstanley ran a live blog detailing the process of using SCCM 2012 to upgrade an existing Windows 10 machine from one build (build 9926) to the next (build 10041).
Paul is a number of time zones ahead of me so he had a good head start when I tuned in Tuesday morning. We both ran into a bit of a stumbling block when our upgrades failed.
While Paul ran into this error upgrading 9926 to 10041, I received the same error attempting to upgrade Windows 8.1 to Windows 10 (9926).
In both of our cases the error was triggered by a mismatch of our original OS with the intended OS we were trying to upgrade to. Specifically in my case I was starting with the evaluation version of Windows 8.1 from the TechNet Evaluation Center, so the SKU of my Windows 8.1 machine was “EnterpriseEval” while the Windows 10 SKU was “Enterprise“. This mismatch triggered the error.
While I was troubleshooting the failure I started to document the process of setting this all up in my lab and I decided to share it for others who might be interested in giving this a try.
[Updated: After enabling Client Hyper-V on 10041 the machine blue screens on boot up!]
[Update 2: After much trial an error I have narrowed my upgrade problem to Hyper-V. If that is enabled on 9926 then the upgrade to 10041 fails for me. So what ever changed with Hyper-V between 9926 and 10041 is the root of the problem.]
I have had quite a difficult time moving from Windows 10 Build 9926 to Build 10041. Prior build updates didn’t give me this much grief.
My system was a pretty simple setup. Hardware-wise it’s an older AMD A8 with 24GB of memory. I have a single 120GB SSD as the boot drive, a pair of 240GB SSDs in a Storage Spaces pool and a single 1TB HDD. On the software side it’s just Windows 10 (9926), Office 2013 and Client Hyper-V.
I had my machine in the Fast Ring so back on 18 March I ran the upgrade to 10041 and it failed.
Video Driver Problem?
Some searching lead to people getting this error when upgrading from Windows 8 to 8.1 and it being caused by Nvidia video card drivers. I do have an Nvidia video card, but it was using the built-in driver from build 9926. But I thought I would give it a shot and upgrade the drivers to the latest direct from Nvidia.
No luck. Still failed with the same error.
Moving to Slow Ring
I rebuilt my system with 9926 and switched to the Slow Ring. I wanted to buy some time to see about finding anything on the errors before attempting to upgrade again.
This time I only had Client Hyper-V and the Storage Spaces pool. I was focused on spinning up some VMs to test the upgrade.
Then on 25 March Build 10041 went out to the Slow Ring and my system ran the upgrade.
And failed with the exact same error.
Starting All Over
At this point I thought I would start over with a clean slate. So I rebuilt my system with 9926. This time I didn’t install Office and Hyper-V, nor did I configure the Storage Spaces. So all I had was a basic install of 9926 and nothing else.
The time the upgrade worked.
So, what was the culprit?
I don’t know. Client Hyper-V? Storage Spaces? I honestly could not say. I may try to rebuild back with 9926 and try the upgrade with one or the other. Maybe I can narrow it down to a single thing that did me in.
Regardless, it doesn’t bode well if a Windows upgrade could not handle features that are native to Windows.
Ran into this today. I have a PowerShell script that builds a series of VMs as part of a lab build-out. After upgrading my machine to Windows 10 the script no longer works. What is supposed to happen is that it starts building a VM and loops every couple of minutes looking for the VM’s state to see if it is “Running”. At the end of the VM’s build MDT shuts the VM down. The script sees that the VM is no longer running, powers it back on and moves on to the next VM.
What happens when I run this on Windows 10 Hyper-V is that the script never notices that the VM has shut down.
Just finished upgrading my machine from build 9879 to build 9926 and wanted to document some issues. 1) before I forget since the Windows Feedback app won’t work and 2) so others might learn from my pain.
First, the updated Start Menu is awful! I cannot re-size it. I can only make it full screen or the size that Microsoft has decided to make it. In 9879 I had made it taller, but now with 9926 I cannot. I also lost all my pinned items in both my Start Menu and my Taskbar. (Search isn’t working so I have to hunt my apps all down and re-pin them.) The alphabetized Start Menu is terrible. Some might like it, but not me. How can I change it? The Customize button is disabled.
My paused Hyper-V VMs will not restart. I get an error about the saved state is not compatible. I probably shot myself in the foot and should have powered my VMs down before starting the upgrade. But I imagine that if I had left them up and running over the weekend the 9926 build would have installed anyway, so….
I was really hoping to try this but there looks to be some GPO setting in our domain that is blocking it.