Today I would like to talk about the upcoming update cycles you have to do, when you are using Windows 10 Current Branch or Current Branch for Business. This means, if you have started to install Windows 10 1507 (which represents the first Windows 10 Release, some may call it also RTM) in spring of last year, you will be soon required to upgrade to a newer version of Windows 10. Also if you are using Windows 10 1511, with the upcoming creators update, the 1511 version of Windows 10 will be soon unsupported, following the official guidelines.
This means you are required to plan a rock solid update mechanism, that respects your needs in order to satisfy the business in a client perspective. One of the most important advises for planning your update infrastructure: Create steps that you can reuse whenever a new image or version of Windows 10 is released, where it is possible.
For the past it have might been the best option, to use a System Center Configuration Manager (ConfigMgr) Current Branch update Task Sequence, if you wanted to fully control all aspects of an update installation. The options within this Task Sequence are quite similar to the existent operating system deployment Task Sequences. But in larger environments or with locations that are not well-connected to a distribution point, this can be very hard to run successfully, so the Servicing model might be an option. And if you think about the regular consumers, they always update Windows 10 with the servicing model, which means that the new version gets installed like a regular Windows Update. With this information you can come to the conclusion, that Microsoft prefers the option of the servicing model. Even with a ConfigMgr Infrastructure the servicing model can be helpful, if a client can download the new Windows Version from the Windows Update source, rather than download it from a DP (ConfigMgr Distribution Point) through a company VPN.
Now you might want to ask me: But I have multiple languages to support and servicing model only updates the base language. HOW U HANDLE THAT?
Well, there is a kind of messy part, and an easy part to handle that. Let me first talk about the easy part: The easy part is as follows, you can simply use a SetupConfig.ini file which points on a folder, where the Language Packs are available, and the Windows setup will install those Language Packs automatically. The usage of a SetupConfig.ini file is well explained on this blog on windows-noob.com.
And now here comes the messy part: What if you have to support more than 20 languages? And more on: All clients have as base language en-US (English United States), and they may have one or more languages installed?
Unfortunately there does not exist an option, or I did not find it like many others, to report the installed language packs within ConfigMgr, for using it within a query based collection. But you can add a WMI class to your clients and collect this class through the hardware inventory. This process has already been documented on the systemcenterdudes.com blog.
Now you can create collections or use this information in other ways to deploy the language packs to the correct clients.
The next big Question will be: But with the new Version, I will get the Windows Store-App Candy Crush again, which I have removed from the image. With the servicing model I can’t modify the image. HOW U HANDLE THAT?
There are different options to modify the freshly installed Windows 10, and one of them you can use within a regular OSD Task sequence as well, you may just change the way it gets executed. So if you need to modify System settings like which language will be used for a default user, or how the default start menu should look like, you can use a script, which will be executed at the end of the Windows 10 upgrade. To use this option, you simply have to add the following line to your SetupConfig.ini:
PostOOBE=C:\LP\Scripts\CommandAfterInstall.bat
Obviously the script has to exist at the location, I will point out how I achieved this later in this blog.
The second option which you can use to modify the System is when the user has logged on, this method uses the SetupCompletes.cmd option and is explained on this MSDN Site.
But as stated on the MSDN site: “This script runs immediately after the user sees the desktop”
So it might not be the best option.
So let’s go on and see, how I did the Script stuff for the upgrade.
First I created a Folder where my German language pack resides and I copied the language pack inside it and my 3 other required Files as well, which I will explain immediately:
Now I will show you the content of “Copy_LP_de.bat”:
mkdir c:\LP
mkdir c:\LP\Scripts
mkdir c:\LP\LP
copy "%~dp0*.cab" c:\LP\LP /Y
copy "%~dp0CommandAfterInstall.bat" c:\LP\Scripts /Y
mkdir "%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\"
copy "%~dp0SetupConfig.ini" "%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\" /Y
This batch file can be used for every language and also if you are using feature packs or even Language Interface Packs.
Now lets talk about the “CommandAfterInstall.bat”, which is quite a short speech: You can start whatever you like (afaik). In my case, I just created a folder to be sure that the batch gets executed.
And beside the language pack, the last two lines are the most important. Those create the required WSUS folder within the Default User profile, and copies our “SetupConfig.ini” file to this location. My example of the SetupConfig.ini is quite simple:
[SetupConfig]
InstallLangPacks = C:\LP\LP
PostOOBE=C:\LP\Scripts\CommandAfterInstall.bat
So my example does instruct the Windows Installation to watch out in “C:\LP\LP” for language packs and will start “C:\LP\Scripts\CommandAfterInstall.bat” after the installation succeeds.
For a full list of the available parameters that you can use within the SetupConfig.ini refer to this MSDN site.
Happy updating!
