So is the repository up-to-date now as of 15th April or are there more update batches coming? Just want to know if it's ok to download now or wait a few days.
Thanks for the info Rick. I use a builder that can integrate updates, do wim and iso overlays. It can also create custom PE's as it has WinBuilder routine as part of the build process (optional). It's kind of a modular builder that can also use lite OS sources to build with (except for the PE part that needs full win source). But anyway, we use a (dual arch) autounattend.xml file there, which is why I had not utilized the xml method on the simple sysprepped images, so I can use it with this builder without conflict. It's just a private builder right now but it sure beats the heck out of anything I've ever come across so far, save MS' own tools of course. But as far as an integral approach to making customized images the MS methods aren't really that convenient for highly customized builds, but then again I'm not an IT pro so I'm sure a lot more is possible with those tools then I can currently achieve with them. But not in one app with a gui anyway
@RickSteele, Note that the image you create with unattend.xml with a setting of SkipRearm=1 indeed does not increase the rearm counts however the image must be installed and activated within 30 days of initial sysprep which might not be a good idea. it is better to sysprep first time with SkipRearm=1 and then sysprep again with SkipRearm=0. This way the pending updates problem will be solved and you have used only 1 rearm instead of 2. Also I tried sysprep->reboot first before generalizing and it did not work for me. I was not able to integrate all updates into my final images I kept getting lots of error 5 access denied errors however syspreping in the way I described solved this problem and slmgr /dlv showed that I have 2 rearms left so I am happy with my sysprep.
Did you do Sysprep: OOBE -> Generalize -> Reboot, though? This is what I did and it resulted in all updates integrating correctly. As I indicated, doing it this way is considered a full sysprep run because it takes off one rearm count. So when you do both the above-mentioned OOBE-generalize-Reboot, and then do your final OOBE-generalize-Quit, this accounts for 2 rearm counts. This is why I used that delwpa.bat method after the generalize-Reboot, so that only one rearm count gets taken off during generalize-Quit only, leaving one with 4 rearm counts on the final sysprepped image.
I also found at least 1 update that was superseded one month ago. 951422-v2 Windows-TerminalServices-RemoteConnectionManager.Resources has version 6.1.7600.21085 and not 6.1.7601.21855 and is only installed for RTM so 2667402 and 2647409 supersede 951422-v2 for everybody to check here a list of superseded updates I found in the repo 951422 975410 2496744 2514307 2524478 2563210 2566059 2589015 2600907 2617157 2619497 2621491 2636613 2637518 2639043 2641192 2641222 2646168 2647516 2664375 2665875 2669522 2672484 2673977 2675785
Looks like I forgot to generalize on my first sysprep, i tried again and it worked. I also followed your directions on removing WPA info and resetting rearms count and it worked perfectly. Thanks a lot for the info.
Small suggestion to KUC Windows Update Checker. Flat folder structure is not the best way for keeping updates... It would be better to look for update in subdirectories, so Copy_Files_2_add.cmd could be chaenged like this: Replace: Code: xcopy "%Repo_Path%\hotfix.msu" "%Work_Folder%\Normal" /y >nul To: Code: Call :CopyUpdate "hotfix.msu" "%Work_Folder%\Normal" Add to script end: Code: GOTO :eof :CopyUpdate for /f "Tokens=*" %%i in ('dir /b /s "%1"') do xcopy "%%i" %2 /y >nul GOTO :eof
I was just thinking about the superseded update remover... Do people actually use the LDR placeholder function? (in that they install the LDR placeholders to force the LDR branch instead of forcing the LDR branch directly)? Just that the SoLoR repository has LDR placeholders in mind, but the Cesidian server repository doesn't. In the future its possible both will reflect each other directly? (maybe)? Anyways, since the Cesidian server is updated more frequently I might start using that as the base, but in which case I need to remove the LDR placeholder function from the script. If anyone uses the LDR placeholders, let me know! (and if you want to, the reason for using it)! Thanks! I know I did promise an updated installer script last weekend, but I ran out of time. I wanted to update the system for WU satisfaction, and the satisfaction list - working out what is required as Komm knows, isn't an exact science! which is why my list is different... in any case, the only functional change will be the satisfaction list, and the satisfaction check, so in itself will not be massively different so don't let it hold you off using the current one. The main thing people will notice with the script update is a couple of KB's shaved off its size.