Hi there. I've been using wsusoffline for quite some time now and find it to be an indispensable tool. My perspective is that I work in a small tech shop which services residential and business clients with things like Windows installations, new systems, virus removals, troubleshooting, and so on. Thank you so much to all the developers and maintainers who keep this project working!
A similar topic to the one I am opening has been made here but it is very outdated and I can't read German!
The Goal
As part of my job, I have taken the responsibility to make custom Windows images for installs to new computers. I am not sure if the audience I'm writing to has any deployment experience, but the process is similar to this:
- Install Windows to template system
- Do all updates
- Install programs (Flash Player, Chrome, Libreoffice, etc.)
- Do all customizations (Background wallpapers, web browser homepages.)
- Apply an unattend file (An XML file Windows parses through to "wrap up" the system.)
- Take an image of the system (Any software could be used, but I prefer the use of wim files.)
At this point, the image/backup/snapshot I made of the system can be restored/applied to (nearly) any computer that comes through our business and we can get the systems out much faster. However, these images can get outdated really fast, and I simply don't have the time to keep 8+ images updated, seeing as how each one takes me about 4 hours to accomplish. What I would like to do is apply as many Windows updates as possible after I have applied that image. From what I can tell, wsusoffline might be a good place to start.
How I Thought This Could Work
So how would we actually get this thing to work out? Any developers of wsusoffline should be aware of the dism command-line tool. This thing is awesome. One of the pieces of software I could not live without (as long as I'm using Windows). One of the functions includes being able to apply packages to offline Windows installations. This is what got me thinking. The wsusoffline project is at a point where as long as the folder has been updated, we should have all the updates at our disposal to use. If we add a Windows PE into the mix, we'd have another way to install the updates as opposed to the traditional way of launching the UpdateInstaller.exe from inside Windows. A user would:
- Download the base of Wsusoffline
- Do all updates
- Boot to a Windows PE (Discussed later)
- Load up a custom Wsusoffline batch script
- Choose the disk & partition
- Install the updates (hands-off, interactivity ends)
- Log
- Reboot
Windows PE
This is an interesting topic I want to address. How will the Windows PE work? How can the user boot to it? What executables can be ran in the Windows PE? Is this even legal?
I'll try to address the technical questions as best I can. I'm not a programmer.
The Windows PE can be customized to load a .exe on boot. This could be whatever we want. Might be a simple program similar to UpdateInstaller that will ask the user to browse for the wsusoffline folder. Then it will ask some normal questions to the user like to point to the Windows drive they wish to service, and perhaps which updates they want to install.
A Windows PE can be booted in many ways. From optical media, to external storage like hard drives or flash drives, and also over PXE. Optical and storage (Go to heading "Next Step"). PXE. We could have a "winpe" directory in the client folder which our users can see the source files, as well as a pre-built iso. Then they can still make a bootable flash drive or even modify the PE if they intend to.
As far as which executables can be used, this is where my knowledge runs dry. I know that if you want to use powershell scripts in a Windows PE, you must add the support. I have done this with a PE I use. I can't really say which executables will work and which won't. Windows PE is meant to be minimal, so don't expect all libraries to be there. I don't think full .NET applications are ever going to work. Batch files will work for sure. VBScript should as well. We might have to play around and wrestle through the limitations.
- Includes only a subset of the Win32 API, including disk I/O, network I/O, and core Win32 APIs, which helps reduce the size of Windows PE.
- Does not support the Microsoft .NET Framework or the Common Language Runtime (CLR).
- Does not include the Windows on Windows 32 (WOW32), Windows on Windows 64 (WOW64), Virtual DOS Machine (VDM), OS/2, or POSIX subsystems.
With legality, I'm pretty sure we're in a grey-area. We're not using it to diagnose or install Windows, which is the intended purpose for the PE, but at the same time, we're not trying to dash around licensing by running a full Windows environment as a thin client or full user workstation, which (I think) is the main concern Microsoft has.
The technical challenges will be fun to overcome, and I don't think will actually be too big a problem. My main concern is the licensing aspect. And in the end, if we don't want to or are prohibited in using a Windows PE, we can still do offline updates. Our users would instead just need to have a technician system which they will use to update Windows by perhaps hooking up a hard drive/storage device into that system and updating it while a full version of Windows is running. That being said, Windows PE is a really elegant solution to the goal.
What I Can Bring
I'm not just throwing ideas around and hoping you guys catch them. I actually have a couple experiences I can bring in. You can check out the attachment "updates.bat" for what I have so far. It's a bit dirty, but I commented a lot so hopefully you'll be able to figure out what I was getting at. The pseudo-code is as follows:
- Code: Select all
get list of packages on the Windows drive;
log time;
for (packages available in wsusoffline) {
if (package not installed) {
if (package is not blacklisted) {
install package into Windows;
if (error)
{
log error installing;
remove package from windows;
if (error)
{
log error removing;
}
else
{
log success removing;
}
}
else
{
log success installing;
}
}
else
{
log skipped due to blacklist;
}
else
{
log skipped due to being previously installed;
}
}
log time;
You might be wondering why there would be blacklisted updates. The first time I tried this, I did it the way I think it will be used by many people, including myself. Appending updates to a new install of Windows without having to go inside Windows.
So I installed my Windows image to the drive, and without rebooting yet began my (old, no longer saved) update script (I don't use any version control. As I said, I'm not a programmer). The next time I booted Windows, it gave me an error telling me about how it couldn't complete the install. I don't remember the error, and I didn't take a picture. That's my bad.
So I did all this again from scratch, but changed my log output to include the errorlevels from dism.exe if it ever failed an update. In "failedUpdates002.txt" you can see the ones it couldn't install. Any of the negative return codes didn't do any lasting harm to the image. But I actually watched all the installs go by. Before the update on line 21, updates would only fail once in a while. After line 21, it's error to the terminal/command line said how the image was now "unservicable". This dism error will return an errorlevel of 5. From my observations, if it returns a 5, we should definitely blacklist it. Otherwise, it's safe. An update may fail, but if it doesn't destroy the system as badly as kb2918614 (The one I saw break the system), it's probably OK. My perspective is that I'd rather have the update throw an error and not harm my system, and spend the time to at least try to install it, rather than not try it at all. I hope that makes sense. It's a selective basis. This unfortunately, would require more maintenance into the wsusoffline structure to know which updates to blacklist if we were to implement anything resembling this. You can check out "w61-64.txt" if you want. It acts as the blacklist. It's just a return-separated list of .cab files to blacklist.
I added in the control for blacklisted updates and after that got the output and results I wanted.
Annotation of a Successful Log
Please refer to "log016.txt".
- See lines 3:8. On this system, it failed to install ie10 but didn't do any harm to the system, because the errorlevel is a high-magnitude negative integer. We can also see that the removal operation worked successfully. I'm not actually quite sure if the removal is necessary, but it takes about 5 seconds so it's worth it.
- See line 9. This line is an example of an update that was skipped due to it already being installed.
- See line 10. A line where the installation was successful.
- See line 149. This is the log entry of a skipped update due to blacklist.
Finally, notice the timestamps at the beginning and end of the file. To do all of these updates (70) only took 30 minutes. Very efficient. These updates were performed on a system in a Windows PE with an AMD A6 CPU, 4GB DDR3 1600MHz RAM, and to a conventional HDD. The updates were pulled off of a CIFS/SMB share over a gigabit network. As it is shown in this log, you don't need a lot of hardware to do the job. The real benefit is the speed in how it is done, and much like the automatic restart feature, it is very hands-off. I'm not sure how much faster this is compared to the automatic restart, but I think it would be faster because the overhead of Windows running normally as well as applying updates on shutdown/startup simply don't exist, as the binaries are not actively being used.
What Now?
I'm a student nearing the end of my spring break right now, so I won't be able to focus my time on this as much as I'd like to. I think this has awesome potential and regardless of what the devs decide to do with this, I'm going to try to implement it as best I can at the business I work at. If I get any useable scripts I'll be sure to forward it upstream, even if just for consideration. I'm aware that what I'm talking about here would require a lot of effort to get running, but I don't think it would be too bad to maintain. All we'd have to do is assign someone (me) to watch for updates to blacklist. I'd use my earlier criteria of a 5 dism errorlevel to start as the criteria, so we have a pattern we can start using.
PLEASE give me some feedback on this. Any comments are appreciated. Even if you don't understand the technical side of dism or how wsusoffline operates, would you consider doing updates offline if it meant the installs would go faster, and perhaps with fewer errors than trying to do them inside of Windows?
Thanks.
Link to Files