Now that the Creators Update is officially out and available, many people are looking for sources of download files for the new OS. When it comes to grabbing Win10 1703 ISO files, there are many ways to scratch that itch. I will name several in this blog post, but others will no doubt think of more. If so, please e-mail me or comment on this post, and I’ll add them in! For the moment, however, this is as complete a list as I can come up with. That said, I omit working with the Update Assistant and the Media Creation Tool, because neither actually produces an ISO file per se.
This is the graphic from the MS page entitled “New with the Windows 10 Creators Update.”
[Click to see full-size version.]
Ways of Grabbing Win10 1703 ISO Files Recited
One. Use HeiDoc.net Microsoft Windows and Office ISO Download Tool. I blogged about this in February, and showed how it can be used to obtain just about every known ISO for current Windows versions. It also works for 1703.
Two. Use the browser “trick” described in this TenForums note “How to Download Creators Update ISO via MS w/o Media Creation Tool” (4/13/2017). Basically, it consists of adding a browser extension that spoofs the MS website into seeing you visiting from a non-Windows OS. When that happens, you get access to an ISO download page where you can grab exactly what you need.
Three. Microsoft license/subscription sites where those who own volume licenses or subscriptions can grab OS ISOs and other access-controlled files. These include MSDN, the Volume Licensing Service Center (Enterprise editions), and the Download Academic Products page (for Education editions).
Four. Grab the Windows download files from Windows Update. Then, you can use the UUPtoISO tool from Kari the Finn at TenForums.com to convert those files into an honest-to-gosh ISO file. (Be sure to read and follow the instructions in this Tutorial “Create Bootable ISO from Windows 10 Build Upgrade Files…“. You’ll also find a download link to the tool there as well).
That’s as complete a list as I’ve been able to compile. Do please let me know if you know of others I may have missed or overlooked somehow. Thanks!
Reading an Ed Bott blog post this week reminded me that keyboard controls can come in mighty handy when restarting Windows 10. That goes double when the goal is to boot outside the normal OS restart umbrella. This could mean booting into UEFI or BIOS to change fundamental system settings. Or it might mean booting into a recovery partition, or from an alternate boot source. As it happens, there are several handy Win10 boot controls for Win10 that will let you do all that and more. Some work in combination with GUI buttons, however. Thus, you need some manual dexterity when using them. That’s why I also describe other methods to achieve the same ends when they’re available.
Show Me Some Handy Win10 Boot Controls!
I’m thinking of two primary tools in this particular case. One of them disables the fast startup setting that has been default for Windows behavior since the 8.0 era. The other involves accessing alternate boot mechanisms or techniques.
Bypassing Fast Startup, When It’s Not Wanted
Here’s a picture of how fast startup works, courtesy of TenForums.com:
With fast startup enabled, telling Windows to shut down actually involves writing to the hibernation file to speed the next boot along.
[Click image for full-sized view, please!]
Fast startup is good stuff, and can shave 20 or more seconds off normal boot times for PCs. But there are times when a real, honest-to-gosh cold boot involving all the steps at the top of the preceding figure are needed. These include: after installing device drivers, when testing boot or startup settings, or after major system or software changes of pretty much any kind. By default, fast startup is enabled in all modern Windows versions (8, 8.1 and 10). There are various ways to turn it off. But should you need to do so for your next boot only, a keyboard trick is all that’s needed. Simply hold down the Shift key when you click shutdown. Then, fast startup mechanisms don’t come into play when shutting down. Thus, the next boot will truly be a cold one and won’t involve reading a hibernation file.
Other mechanisms to change this involve toggling checkboxes in the Power Options item in Control Panel (easily accessible by typing “Power Options” into the Win10 search box). Then, click on “Choose what the power buttons do” in the left hand controls. Next, click “Change settings that are currently unavailable” to produce this window:
The key entry here is the one for fast startup (uncheck to disable, check to enable).
[Click image for full-sized view, please!]
I like using the Shift key method because it lets you skip fast startup just one time. Nor must you remember to go back and make changes once that next reboot comes and goes. As handy Win10 boot controls go, this one is great, simple, and fast.
Arranging for Alternate Boot
On more modern UEFI systems, messing with boot may sometimes require extra shenanigans. Most such systems support motherboard or system focused utilities designed to speed boot-up at the hardware level. Thus, for example, my Asrock based production PC uses the ASRock Fastboot utility. It lets users choose among three boot settings: Disable, Fast, and Ultra Fast. It, too, has a one-time toggle that reads “Enter UEFI setup on next boot.” But unless you use a shortcut program like AutoHotkey, you can’t really set up a keyboard equivalent to make this happen. That said, those who use such programs find this pretty darn handy indeed. By and large, these utilities work pretty well.
The motherboard- or system-specific utilities for UEFI/BIOS access vary by maker and appearance, but very little by function.
[Click image for full-sized view, please!]
My MSI system has a different utility, as do my various Microsoft and Dell tablets and laptops so YMMV is the rule of the day here. MS does offer its own alternative to access other boot options during startup. Click Settings, Update & Security, Recovery, then “Restart Now” under the Advanced startup heading. This provides immediate post-boot access to the boot options menu from the Windows 10 boot loader, including access to BIOS/UEFI, change Windows start settings, start up from a device or disk (alternate boot media), or restore Windows from a system image. Good stuff!
OK, then: let’s all say “So long Windows Vista!” This much-maligned and under-appreciated OS hit its end-of-life data on April 11 earlier this week. I’m now wondering if it’s purely coincidence that the official release date for Windows 10 Creators Update fell on the same date. I guess we’ll never know.
But for me, Vista was the first truly modern Windows OS. Among other things, it introduced a raft of great features. These included Aero Glass, volume shadowing, and modern OS imaging tools and techniques. Here’s a snippet from the table on the Windows lifecycle fact sheet that shows important dates:
Given its horrible marketplace reception, Vista’s departure won’t be overly sad or shocking to most.
[Click Image to see full-size view, if you can’t make out the fine print here]
So Long Windows Vista: Bye Bye!
By most metrics, Vista’s change to end-of-life status won’t have much impact. Most of the major OS counting services (NetMarketShare, Statista, Statcounter, and so forth) presently grant Vista something less than 1% of global OS marketshare. But I agree with Paul Thurrott‘s assessment that “Windows 7 was nothing more than Windows Vista Service Pack 3.” Thus, he opines further, “…we should give Vista, and its makers, the measure of respect they deserve.”
FWIW, I liked Windows Vista from the get-go. The UI was a big step up from Windows XP. Also, the OS seemed more robust and truer to the underlying Windows NT engine and spirit than XP ever did. Indeed, MS caught lots of flack because of the changes in device driver architecture. Alas, these stranded many devices (and the systems and people who used them) when they tried to upgrade from XP. But most of us figured out how to make our ways around this potential roadblock. Thus also, the concept of an Upgrade Assistant with pre-install hardware assessment capabilities also traces back to Vista as well.
Whatever your feelings about or recollections on Vista might be, Microsoft no longer supports it. And though some die-hards (or industrial/embedded systems) may not yet let go, it should otherwise vanish into the gloomy depths of ancient history very, very soon. Hasta la Vista, baby!
Over the past weekend, I upgraded 5 installations to Creators Update. Yesterday, I did likewise to my production PC. It is now happily ticking along, running the new release without apparent problems. However, I’ve discovered an interesting issue. Image integrity checks on the new installation using DISM do not always complete successfully. Instead, they may produce a warning that the component store is corrupted but repairable — on some PCs, at least. If the log file didn’t indicate a conspicuous lack of real issues, this might worry me. Given its contents, though, I see this as more of a Creators Update image integrity gotcha than as a real problem. Please, allow me to explain…
Why Say Creators Update Image Integrity Gotcha Rather Than “Problem?”
The following screen capture from PowerShell shows what I’m discussing here in the context of the DISM commands involved:
Notice the error persists, even when I try the /restorehealth option pointing to the MSDN ISO file for Win10 1703.
[Click image for full-size view/improved readability]
What you see in the preceding screenshot is the following sequence of commands:
- DISM /online /cleanup-image /checkhealth:
Checks component store integrity, and reports a finding of corruption that is repairable.
- DISM /get-wiminfo /wimfile:u:\sources\install.wim
Reports on the layout of the install.wim file from the 1703 ISO file (downloaded from MSDN on 4/11/2017). It shows that Windows 10 Pro resides in the first segment therein (Index:1) and Windows 10 Home in the second segment (Index:2).
- DISM /online /cleanup-image /restorehealth...
Uses the Install.wim examined in the preceding command as the source for attempted component store repair, but reports that “The source files could not be found.” I received the same error message when initially attempting to repair the image using the ESD file included on the USB Flash drive that the Media Creation Tool built for the actual upgrade. That’s what makes me think this is a Microsoft problem, rather than a real corruption issue.
DISM.log Tells a More Complete Story
The DISM log file reports corruption in a most mysterious fashion, too. It finds a single error, in looking for a driver file. That report appears as follows in the dism.log file (I break up this single long line for readability):
Error DISM DISM Driver Manager: PID=19052 TID=16324
Error, file not found 'oem0.inf'. -
A bit of explanation and history may help. The first item as shown provides a time stamp for the log entry. The second line indicates that the problem originates from the DISM Driver Manager. In turn, this tells me the problem is with a device driver rather than a component store entry. The third line provides the information that a driver file named oem0.inf is what’s missing. This is a generic entry for the first item in the Windows DriverStore. DriverStore Explorer tells me this entry is for the Nvidia Sound, video and game controller driver. We’ve seen similar problems show up in previous Windows releases where an Nvidia driver mismatch for the graphics driver caused a similar and equally spurious report of component store corruption.
I did some further checking. Indeed only those PCs that have Version 1703 Build 15063.11 or later show this “corruption” problem. (15063.138 is the most current Build ID for Current Branch Windows 10.) Microsoft has been informed of this issue on the Feedback Hub, so I expect we’ll see it fixed in some upcoming Cumulative Update. And again, that’s why I’ve entitled this blog post “Creators Update Image Integrity Gotcha” rather than “Creators Update Image Integrity Problem.”
Following release of Windows 10 1703 via the Media Creation Tool, I’ve been busy this weekend upgrading 6 of my 8 PCs. I’m delighted to report that Creators Update delivers easy upgrade experiences to early adopters. I hit zero snags upgrading those systems. Post-upgrade clean-up was more or less flawless, too. That said, I encountered one driver issue. Upgrading the Intel Management Engine (MEI) on my Dell Venue Pro 11 hybrid tablet caused a BSOD. Extracting those drivers from the Dell installer plus manual update in Device Manager put things right in under a minute.
When all is said and done, Creators Update shows up as Build 15063.13, with cumulative updates already applied.
After Creators Update Delivers Easy Upgrade, What Then?
For me the usual post-upgrade drill goes like this:
Run Disk Cleanup (cleanmgr.exe) using “Run as administrator.” It deletes Windows.old and other remnants of the previous Windows version.
Check drivers for updates or additions (my old standby for this is the for-a-fee DriverUpdate, but the free Windows Update Minitool, aka WUMT, does the job as well or better).
Run DriverStore Explorer (rapr.exe) and remove obsolete and unneeded duplicate device drivers.
Fire off PatchCleaner and clean up orphaned packages from the Windows Installer directory.
Run Uncleaner and root out duplicate and temporary files; CCleaner ditto (always grab the “Slim” version).
Make an initial image backup of the pristine upgrade environment (I use Macrium Reflect Free with great results).
I *always* make an image backup before starting the upgrade process. Thus, I am cavalier about deleting Windows.old. If you aren’t quite sure you’ll stick with Creators Update, remember you now have only 10 days before the old install gets deleted automatically.
In working through that process on the six installs I’ve upgraded so far, I observed just the one driver problem reported. I did find some duplicate or obsolete graphics drivers (both Intel and Nvidia), along with some duplicate system device and USB entries. PatchCleaner found very few orphaned packages (one or two). No action required there. Uncleaner and CCleaner both found hundreds of MB worth of detritus that was quickly removed. And with a clean image of the newly upgraded OS in hand, I’ve got a solid starting point for future recovery, if needed.
Bottom line: Version 1703 (OS Build 15063.13) appears ready for prime-time. My next upgrade, in fact, will be on my production PC. That says I think it’s ready for workaday use!
Late Wednesday, Microsoft pulled the trigger on making Windows 10 Build 1703. That’s when it made the Creators Update out and available to the general public. One need only visit the Download Windows 10 web page. Then click, the “Download tool now” button to grab the latest iteration of the Media Creation Tool (MCT). I verified for myself yesterday that using this latest and greatest mediacreationtool.exe does indeed create a version 1703 Windows 10 installer:
If you elect the “Create installation media…” option in the MCT, it now builds a Creators Update install environment for you.
Creators Update Out and Available, Now What?
Given that Microsoft says it plans to stage out the Creators Update incrementally as it did with the Anniversary update, access to 1703 through the MCT is a good thing. Why? That’s because this allows those are inclined to on Windows Update do just that. At the same time, the MCT provides a ready means for those inclined to upgrade to 1703 sooner rather than later do that, too. I find it interesting that MS has let this slip the week before the announced “official” release date of April 11. Could this be a positive payoff for the “Windows as a service model” emerging at last? You bet, because MS knows it can fix 1703 issues with cumulative updates as needed. Three of them have already been released, in fact, since 1703 hit the fast ring on March 20.
I’ve had two machines running this version since that date, and last week updated my Insider Preview test machine — a Surface Pro 3 — to the same release as well. At this point, it shows every evidence of being both stable and robust. Those inclined to track the Current Branch should be OK to upgrade over the next month or so if they’d like to wait on Windows Update. Those wishing to upgrade sooner no longer have a reason to hold back. And finally, those on the Current Branch for Business should take heart that all signs on the Creators Update are positive, and that things are looking good for a transition in the three to six month period during which business users hang back from the leading edge of production Windows releases.
Over the past week to ten days, lots of users have been reporting issues with Windows Update and Windows Defender. This applies to versions 1607 (Current Branch) and 1703 (Insider Preview aka Creators Update). The symptom is that while Windows Update reports a Definition Update for Defender is available, it cannot download or install same. As it turns out, these apparent Win10 Defender update issues are illusory. In fact, they’re easily addressed with a simple fix. One need only use Defender itself to grab its own updates, and the issue vanishes. Here’s what Windows Update reports when this error occurs:
The consistent thread for both 1607 and 1703 versions is error code 0x80070643 for this particular problem.
Normally, when Windows Update (WU) goes wonky, recovery requires troubleshooting. This usually starts with the “Fix problems with Windows Update” item available in the Troubleshooting widget from Control Panel. But for this particular issue, no such shenanigans apply. On version 1607, launch Windows Defender, click the Update tab, then click “Update definitions.” For version 1703, visit Windows Defender Security Center. Click the “Virus & threat protection” icon (third item from the top in the left-hand icons), then click “Protection updates.” Either way, this launches a manual update download outside the Windows Update umbrella.
Fix Step 1: Addressing Apparent Win10 Defender Update Issues
In 1703, clicking “Protection updates” produces this screen. Next, please click the “Check for updates” button at the bottom. This tells Defender to poll the server for updates, and to download and install any available updates it finds. The mechanism is independent enough of WU that it will work even when WU won’t.
Fix Step 2: Addressing Apparent Win10 Defender Update Issues
Something is obviously up with Defender update handling, because this also produces an error message as well, as shown here. Don’t let this trouble you. Although it says “fatal error,” indeed the update is working in the background to download and install the necessary malware definitions.
Fix Step 3: Addressing Apparent Win10 Defender Update Issues
Click the “Protection Updates” button again. The result is a successful download and install of the previously failed update (same version number as before 1.239.778.0). Wait a minute (60 seconds) before you do this or you’ll get an error message that says “You must wait for the previous update to complete …” But indeed it will proceed and complete successfully.
Fix Step 4: Addressing Apparent Win10 Defender Update Issues
Microsoft hasn’t yet explained what’s causing this issue, nor have they released a fix for it, either. I’m hopeful that it will be history by the time that April 11 rolls around to mark the official release date for Creators Update. We’ll see…
I’m in the processing of prepping my previous production PC for a family member right now. In so doing, I faced an interesting challenge. The unit incorporates a Gigabyte Z77X-UD3H motherboard, which in turn plays host to an mSATA SSD onboard. As things stood last Friday, that was a Samsung 840 EVO 500 GB unit, which still retails for over $300. Because I still have a 250 GB version of the same device at my disposal, I wanted to switch out the bigger unit for the smaller one so I can use it in one of my Lenovo laptops (or as a reasonably speedy USB 3.0 device, as I’ll proceed to explain). In determining how to make the switch, I learned that swapping out mSATA SSDs needs cool tools. Let me explain…
Why Say “Swapping Out mSATA SSDs Needs Cool Tools?”
The situation reminds me of a famous conundrum from Joseph Heller’s Catch-22. It goes like this: “How can you tell you’ve got flies in your eyes if you’ve got flies in your eyes?” That situation involves transferring the contents of one mSATA SSD to another on a system that has only one mSATA socket. Thus, there are two classic ways to solve the problem:
- Make an image backup of the source drive while it’s still installed in the socket. Remove the source drive and install the target drive. Then, restore the image backup to the target drive while booted to a recovery disk of some kind. Conduct any startup repairs that might be needed.
- Purchase a device to house the mSATA SSD for USB attachment to the PC. Clone the source drive to the target drive. Shut down the PC, and swap source for target, then conduct any necessary startup repairs.
Lessons Learned While Swapping Out mSATA SSDs
A quick Internet search showed me that Sabrent makes a $15 USB 3.0 enclosure for mSATA drives. Better yet, it was available at my local Frys superstore. I ordered it online, and drove down to pick it up on Saturday afternoon. It proved to be surprisingly sturdy, too. Its housing is made of nicely machined aluminum.
The unit runs pretty warm with an SSD inside, but it does the job and runs pretty fast.
I used the commercial version of MPW ($39) because it can switch from an MBR source disk to a GPT target disk as part of cloning operations. Next, I used its partition management facilities, and downsized the OS partition from 460-odd GB to 232 GB. Finally, I shifted the recovery partition adjacent to the OS partition so it fit the smaller drive, then cloned source to target. Then, a quick shutdown, and the actual swap of source for target drive on the mobo. After working through those gyrations, I then booted to the Macrium Rescue Media. Its startup repair facility let the new GPT-formatted 250 GB SSD do its job at boot time. The whole process took about an hour, as I noodled through necessary steps along the way.
Along the way, I learned some interesting lessons:
- The Gigabyte motherboard is old enough that it won’t boot from a USB 3.0 port. I got stuck on a “minus-sign” cursor on three different bootable UFDs (Microsoft Recovery, Macrium Rescue and Kyhi’s Recovery Tools) before it finally dawned on me that I had to plug into a USB 2.0 port to boot from a UFD.
- Even after the Windows 10 Recovery media booted the PC, its “Startup Repair” tools proved unequal to the task of fixing my boot environment. Instead, I got an error message that repair attempts had failed. The Macrium Rescue Media rebuilt my startup environment without a hitch, and did so in under a minute.
- I ended up switching the motherboard BIOS to UEFI boot only settings throughout, instead of the earlier combo (Legacy + UEFI) boot settings it had used. I didn’t realize I’d formatted the 500 GB SSD as MBR to begin with, and the previous setting probably explains why that happened. Going forward, UEFI only should prevent this from recurring
One of my test PCs is set up for dual boot, because I use it for both Windows 10 1607 (Current Branch) and Insider Preview versions. After upgrading to Build 15063 earlier this week, I noticed that the installer had knocked out BCD entries for both Macrium Reflect System Recovery and the 1607 OS. I turned to my normal go-to tool for handling BCD stuff: NeoSmart Technologies EasyBCD 2.3. But instead of fixing my problem, I found myself powering through Windows 10 dual boot mishaps both various and mysterious.
After using the Add New Entry button to restore entries for both Macrium Reflect System Recovery and my “other OS boot” ( labeled Win10 1607 in the screenshot) I expected to be back in action. But alas, when I attempted to access the latter boot option, I was treated to an error screen instead. It informed me that because it couldn’t find the file named “winload.efi” at the designated location it couldn’t boot, either. Yet that file was clearly present where it was supposed to be, in the %Windir%\system32 folder on the target drive.
To all appearances, these BCD entries all looked correct. But I couldn’t boot to my “other OS” successfully.
How I Found Myself Powering Thru Windows 10 Dual Boot Mishaps
What I did next has to be what caused the ensuing round of difficulties. Realizing something was wrong with my BCD data, I turned to EasyBCD’s “BCD Backup/Repair” tools, then elected the “Re-create/repair boot files” option.
However, when I tried my next reboot, I found the PC stuck in the UEFI shell, unable to boot anything. I even had trouble accessing the motherboard BIOS to force an alternate boot to a repair UFD. The only way I was able to fix my problem was to walk through a somewhat tortuous and time-consuming series of steps:
- I had to disconnect all the internal drives except for 1 boot drive at a time.
- I had to boot to the Macrium Recovery UFD, and use its boot repair tool on each drive individually. This restored each one to bootable condition.
- After getting each boot drive working, I performed a disk cleanup and made a boot image backup using Macrium Reflect (in case the same problem recurred).
- Once each one would boot by itself, I used EasyBCD to add a new boot entry while booted into Insider Preview to accommodate the 1607 OS version.
- I used Macrium’s tool in its “Other Options” menu to return the recovery partition to the boot menu as well (“Add Recovery Boot Menu Option…”).
I have to believe my error came from the confluence of Macrium- and EasyBCD-based changes to the BCD data. Using Macrium to make Macrium-related changes, and EasyBCD to make general BCD additions (the second OS from my Insider Preview boot) fixed the problem. But what a painful 3 hours it took me to put things back to rights! I hope others in the same boat can learn from my innocent and unthinking mistake, and avoid Windows 10 dual boot mishaps altogether.
By Kari the Finn, guest blogger for Ed Tittel, courtesy of TenForums.com
Note: this blog is Part 6 in a series of 6 parts on the topic of using Sysprep to craft a custom ISO for use in installing Windows 10, aimed at the upcoming Creator’s Update scheduled to become available in mid to late April. Your guest blogger for this series is Kari the Finn, well-known Windows Install expert at TenForums.com. He’s the person who put tools together (ESD2ISO and UUP2ISO) that let savvy installers convert Windows OS download files into ISO images that may be used to create bootable installation optical media or USB Flash Drives.
Part 1 covered the intro, and Part 2 started users with installation prep; in Part 3 you learn how to update and customize Windows; Part 4 dug into generalizing a Windows image using the Sysprep utility; Part 5 described how to capture the generalized Windows image and turn it into an installable ISO. Here in Part 6 we conclude by explaining how to update or change that ISO file over time. Don’t let the numbering bother you (Part 1 was an introduction, so step 1 of Kari’s 5-step process appears in Part 2, step 2 in Part 3, and so on…) Here’s Step 5/Part 6:
5. Update / Change ISO
The beauty of using Hyper-V VM as technician machine lies in how easy it makes the job of maintaining and updating a customized install image. I am a Fast Ring Windows Insider. That means I get new pre-release builds frequently and thus, want to upgrade my ISO at the same pace. I’m too lazy to go through this whole process weekly (or more often). The same holds true if I no longer want my custom image to include certain pre-installed software elements, want to update or add new software, or want to change the desktop theme or whatnot.
When I feel like changing the ISO I simply apply the Hyper-V technician virtual machine’s standard checkpoint I created just before sysprepping Windows. I can add and remove software, update software, run Windows updates, apply a new theme, or do whatever else I might want to.
When that’s done, I run Disk Clean-up, create a new checkpoint to be able to restore to this point, and repeat Sysprep, capture a new install.wim and make a new ISO. It’s much faster now. The whole process takes just minutes, because both Windows and basic software are already installed.
Upgrading the Custom ISO
As a Windows Insider I might also be interested in upgrading my ISO. When a new build arrives, I restore the checkpoint I created when the technician machine was fully setup after capturing the install.wim file. I can’t use the checkpoint made in Audit Mode before Sysprep because upgrading Windows in Audit Mode is not possible.
Now, booted to normal mode I can upgrade to the latest Insider Build or the next Feature Update Build using Windows Update or a standard ISO image. When that upgrade completes, I enter the following command in an elevated Command Prompt to restart Windows in Audit Mode:
%windir%\system32\sysprep\sysprep.exe /audit /reboot
Windows restarts, then signs into Audit Mode using the built-in Administrator account. The next thing to do now because my initial user account already exists is to open Settings app > Accounts > Other users and delete all existing user accounts also removing their profile folders. I also delete the custom made install.wim file from last time if it’s still located on the image drive (E: in this example) and check to ensure that the Scratch folder still exists (if not, it must be re-created manually as described in Part 4 of this 6-part opus).
Now a Disk Clean-up, Sysprep, capturing install.wim once again and finally writing a new ISO. That’s it!
For Further Questions or comments…
If you have any questions about this 6-part series, or comments to share, do not hesitate to contact me! Here’s my information:
Links to All Series Elements
Part 1: Introduction & Overview
Part 2: Install Windows and Prepare Assets
Part 3: Update and Customize Windows, Install Software
Part 4: Generalize Custom Windows Image with Sysprep
Part 5: Capture Custom Windows Image, Create ISO
Part 6: Update/Change Custom Windows ISO