How can I use Windows 10 Servicing when a language pack is installed using System Center Configuration Manager (Current Branch)

[anyweb]

Introduction

At the start of this series of step by step guides you installed System Center Configuration Manager (Current Branch), then you configured discovery methods. Next you configured boundaries to get an understanding of how automatic site assignment and content location works. After that you learned how to update ConfigMgr with new features and fixes using a new ability called Updates and Servicing and you learned how to configure ConfigMgr to use Updates and Servicing in one of these two modes:

• Online mode
• Offline mode

To prepare your environment for Windows 10 servicing (this guide) you learned how to setup Software Updates using an automated method (via a PowerShell script) or manually using the ConfigMgr console. Next you used a PowerShell script to prepare some device collections, then you configured client settings for your enterprise and finally you'll deployed the ConfigMgr client agent using the software updates method which is the least intensive method of deploying the Configuration Manager client agent.

 

As System Center Configuration Manager (current branch) is being delivered as a service now, version 1602 was made available (March 11th, 2016) and you used Updates and Servicing to do an in-place upgrade to that version as explained here. Next you learned about how to use the Upgrade task sequence to upgrade your Windows 7, Windows 8 (and 8.1) and even your Windows 10 devices to a later build of Windows 10.

 

You then learned about the new Windows 10 servicing features which use Servicing Plans in ConfigMgr (Current Branch). Next you integrated MDT 2013 update 2. MDT integration with ConfigMgr is useful as it provides additional functionality for operating system deployment scenarios such as Offline Language Package installation or User Driven Integration (UDI).

 

Next you learned how to deploy Language Packs offline for Windows 10. To assist with Windows 10 servicing and for applying appropriate software updates to your Windows 10 devices, you used PowerShell to add queries to the various Windows 10 collections.

 

Next you took a deeper look at the Windows 10 Upgrade task sequence, and learned one way of dealing with potential upgrade issues. While that method will flag a problem, such as determining the system UI language doesn't match the provided media, it won't allow you to continue with the upgrade. Next you learned how to upgrade the operating system when a language pack was installed, provided that the system UI language is from a 'list' of approved languages that you intend to support.

 

Next you learned how to display customized messages to a user during a task sequence, and how to set an exit code which could allow you to deliberately fail an action if necessary. You saw how easy it was to apply an Update Rollup containing a hotfix for 1602. In this post you'll return to Windows 10 servicing, and learn a method of dealing with an installed language pack (which would cause the servicing plan to fail otherwise).

 

Windows 10 servicing using Servicing Plans currently (as of June 12th, 2016) only works if the System UI language matches the Windows 10 upgrade edition you are updating. To get around this problem you have to do the following:

• Determine the language pack installed
• Copy a special file to those systems that match a particular language pack
• Make sure the correct language pack referenced in that file is available on a network share
• Target those systems with a servicing plan (already completed in this part)

Step 1. Create some Collections

You'll need to identify what language pack is installed (set as the System UI), to do that you can create collections based on a few things namely:

• Windows 10, for example Windows 10 Enterprise
• The Build number, for example 10240
• Language pack installed as the System UI, or LocaleID, for example Swedish is 1053

and that can be done via queries such as the following:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 10.0" and SMS_G_System_OPERATING_SYSTEM.BuildNumber = "10240" and SMS_G_System_OPERATING_SYSTEM.OSLanguage = "1053"

In the query above, the values looked for are:

• SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 10.0"
• SMS_G_System_OPERATING_SYSTEM.BuildNumber = "10240"
• SMS_G_System_OPERATING_SYSTEM.OSLanguage = "1053"

Assuming you are deploying Windows 10 Enterprise, the only two values you'll need to think about are the build number and language (locale ID). You can see a full list of locale IDs here. Remember that Windows 10 servicing is all about moving from one build to the next build number eg: build 10240 > 10586 so you need to create collection of devices that are running the build you want to service.

 

Note: The script mentioned below depends on a limiting collection called All Workstations which was created in this post. If you haven't run that script yet, please do so otherwise you'll see errors.

 

You could create the collections manually by manipulating the query used above or use a PowerShell script to do the hard work for you. In the downloads section of this guide you'll see a script called CreateServicingPlan_LP_DeviceCollections.ps1. Download it, open it in Windows PowerShell ISE and edit any variables prior to running it. This script will create collections for the following languages and for Windows 10 Enterprise version 1507, build 10240:

• Danish
• Finnish
• German
• Norwegian
• Swedish

and you can easily edit it to create more collections with the corresponding queries. Below is an example output when the script runs.

 

 

after the script has run, you'll see the new Device Collections have been created and populated with the correct devices

 

 

Step 2. Create a text file for each language pack

In order to workaround the Servicing Plan language pack problem, you need to create a file that points to a network share containing the language pack you intend to support. The file will should be named setupconfig.ini and it should contain valid data such as below:

[CommandLines]
/InstallLangPacks \\<server>\<share>

Both <server> and <share> must be valid values and unique for the language pack in question, so if you intend to support the Swedish Language Pack you'd place the Swedish Language Pack in a share and adjust the setupconfig.ini file for machines with the Swedish language pack installed as follows:

[CommandLines]
/InstallLangPacks \\CM01\Sources\OSD\OS\LP\1511\x64\Swedish

Note: If you followed the following post, you will already have the language packs copied to the share mentioned in the setupconfig.ini example above.

 

The <share> you specify in the text file must contain a sub-folder matching the language pack as shown below

 

 

and in that folder, the corresponding lp.cab file for the version of Windows you are updating to (in this example, version 1511) is present

 

 

Repeat the above exercise for each language you intend to support, this will mean you could have several setupconfig.ini files in their own respective folders like so:

• \\cm01\Sources\OSD\OS\LP\setupconfig ini files\swedish
• \\cm01\Sources\OSD\OS\LP\setupconfig ini files\danish
• \\cm01\Sources\OSD\OS\LP\setupconfig ini files\finnish
• \\cm01\Sources\OSD\OS\LP\setupconfig ini files\norwegian
• \\cm01\Sources\OSD\OS\LP\setupconfig ini files\german

 

Step 3. Copy setupconfig.ini to computers with the appropriate language pack

You need to the modified setupconfig.ini (with valid information pointing to the correct server and share containing the appropriate language pack) to computers you intend to service with the appropriate language pack installed. Now that you've got the collections created that should be easy enough. The file needs to be copied to the following destination on these computers:

%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\

if the destination doesn't exist, you must create it.

 

You can create a package/program to copy the appropriate file to all computers with the matching language package installed. To do that, do as folllows:

 

In the ConfigMgr console click on Software Library, then click on Application Management, Packages. Right click and choose Create Package. Fill in the following details:

• Name: Swedish Language Pack - SetupConfig.ini
• Source Folder: \\cm01\Sources\OSD\OS\LP\setupconfig ini files\swedish

 

when prompted to create a program, choose Standard Program

 

 

use the following settings for the program

 

Name: copy SetupConfig.ini

Command line:

cmd.exe /c echo d | xcopy /c /y "Setupconfig.ini" "%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\"

Run: Hidden

Program can run: Whether or not a user is logged on

 

as per the screenshot:

 

 

for requirements change it to Windows 10 x64 as shown here:

 

 

and continue through the wizard until completion

 

 

Now that the package is created, you need to distribute the content, right click on the package and choose Distribute Content.

 

 

add one or more distribution points and continue through that wizard until completion.

 

 

And in order to get the file on the computers, you must deploy the package, so go ahead, right click on the package and choose Deploy.

 

 

In the Deploy wizard, for collection choose the collection that matches the language pack the setupconfig.ini file was created for, in this example, Swedish, so use SUM - Windows 10 x64 (1507) Swedish LP

 

 

for Deployment Settings, use a purpose of Required

 

 

for Schedule, click on New and choose As soon as possible

 

 

and continue through the Deploy Software Wizard until completion.

 

 

Tip: You can use Configuration Items to verify the existence of the file prior to running the Servicing Plan and create collections based on compliance. This would ensure that the ini file is present on the device prior to the servicing plan running.

 

 

Step 4. Review the upgrade on Windows 10 devices with language packs installed

Note: Ensure that one or more applicable Windows devices are in the collection used when creating the servicing plan. Also note that if you are just testing the servicing plan, and you used the settings above that it may take up to 4 hours to show up on the client, adjust the servicing plan as necessary and choose Run Now again to re-deploy it with the new settings.

 

Everything should be in place for the update. But first, you might want to check that the setupconfig.ini file is where it should be on the client.

 

 

and once the policy is received by the client the update shows up in Software Center

 

 

 

notice the update warning text...

 

 

and off it goes...

 

 

 

during the upgrade, the setupact.log log file will reveal information about the language pack involved and where it expects to find it (taken from the setupconfig.ini file)

 

 

and the computer will restart and then the upgrade will being in earnest

 

 

and after a while it's done

 

 

after logging in you can see the new version of Windows 10 and the language is still in place after servicing, result !

 

 

Summary

With workarounds in place you can now upgrade your Windows 10 devices to the latest version of Windows 10 using servicing plans created in System Center Configuration Manager 1602 (Current Branch) even if your computers have language packs installed. Previously you'd need to use the Upgrade Task Sequence to deal with that scenario.

 

Related Reading

• How can I use servicing plans in System Center Configuration Manager (Current Branch) to upgrade Windows 10 devices ?
• Locale IDs - https://technet.microsoft.com/en-us/library/cc287874(v=office.12).aspx#Locale
• A deeper look at the Upgrade task sequence in System Center Configuration Manager (Current Branch)
• How can I deal with languages in the Upgrade Task sequence using System Center Configuration Manager (Current Branch)

 

Downloads

You can download a Microsoft Word copy of this guide here dated 2016/06/12

 

And here's the PowerShell script used to create the collections. CreateServicingPlan_LP_DeviceCollections.zip

[OffColour]

Great work!

Massive fail by Microsoft though.

[thorsten.frohberg@hotmail.]

[CommandLines]
/InstallLangPacks \\CM01\Sources\OSD\OS\LP\1511\x64\Swedish

is this still the right syntax?

 

Doc from Microsoft :

[SetupConfig]

InstallLangPacks = \\CM01\Sources\OSD\OS\LP\1511\x64\Swedish

[anyweb]

both work, give it a go

[MdKnightR]

Hello all.  I'm new here and I have a question related to this topic, specifically dealing with the use of SetupConfig.ini.  If I am posting this in the wrong thread, I apologize.

I am using Windows 10 Servicing in SCCM to update our clients from Windows 10 1607 to 1703.  I have done an exhaustive search for an answer to how to prevent provisioned apps from reinstalling themselves after the update, and all that I've found points to the use of SetupConfig.ini to trigger a batch file that will run a Powershell script before the user logs in for the first time.  I have no problem copying these files to the test machine using a task sequence.  I have no problem running the Servicing Plan.  The computer has no problem updating.  However, the WSUS directory under %systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\ completely disappears after the feature update, so it never gets a chance to run the script to remove the default Windows 10 apps.

Here are the contents of each file I am using:

SetupConfig.ini -

[SetupConfig]
PostOOBE=C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupComplete.cmd

SetupComplete.cmd -

@echo off

Set psfile=%~dp0SetupComplete.ps1
if exist %psfile% ( 
   Powershell.exe -ExecutionPolicy Bypass -File %psfile% -WindowStyle Hidden 
)

SetupComplete.ps1 - 

# Get a list of all apps
$AppArrayList = Get-AppxPackage -PackageTypeFilter Bundle | Select-Object -Property Name, PackageFullName | Sort-Object -Property Name
 
# Loop through the list of apps
foreach ($App in $AppArrayList) {
    # Exclude essential Windows apps
    if (($App.Name -in "Microsoft.WindowsCalculator", "Microsoft.WindowsStore", "Microsoft.Appconnector", "Microsoft.WindowsCommunicationsApps", "Microsoft.WindowsSoundRecorder", "Microsoft.DesktopAppInstaller", "Microsoft.StorePurchaseApp")) {
        Write-Output -InputObject "Skipping essential Windows app: $($App.Name)"
    }
 
    # Remove AppxPackage and AppxProvisioningPackage
    else {
        # Gather package names
        $AppPackageFullName = Get-AppxPackage -Name $App.Name | Select-Object -ExpandProperty PackageFullName
        $AppProvisioningPackageName = Get-AppxProvisionedPackage -Online | Where-Object { $_.DisplayName -like $App.Name } | Select-Object -ExpandProperty PackageName
 
        # Attempt to remove AppxPackage
        try {
            Write-Output -InputObject "Removing AppxPackage: $($AppPackageFullName)"
            Remove-AppxPackage -Package $AppPackageFullName -ErrorAction Stop
        }
        catch [System.Exception] {
            Write-Warning -Message $_.Exception.Message
        }
 
        # Attempt to remove AppxProvisioningPackage
        try {
            Write-Output -InputObject "Removing AppxProvisioningPackage: $($AppProvisioningPackageName)"
            Remove-AppxProvisionedPackage -PackageName $AppProvisioningPackageName -Online -ErrorAction Stop
        }
        catch [System.Exception] {
            Write-Warning -Message $_.Exception.Message
        }
    }
}

 

[TrialandError]

Welcome MdKnightR,

  On 8/1/2017 at 1:23 PM, MdKnightR said:

the WSUS directory under %systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\ completely disappears after the feature update

Expand  

Have you tried placing your SetupComplete.cmd in a different directory such as C:\Windows\Temp and then editing the .ini file to show the new location? The Temp directory's may get cleared as well so you may need to try a custom location.

[MdKnightR]

  On 8/1/2017 at 2:21 PM, TrialandError said:

Welcome MdKnightR,

Have you tried placing your SetupComplete.cmd in a different directory such as C:\Windows\Temp and then editing the .ini file to show the new location? The Temp directory's may get cleared as well so you may need to try a custom location.

Expand  

I haven't yet, but I'll give it a shot.  I'm just wondering if it is normal behavior for the WSUS directory to get deleted during the update?  And, if so, does SetupConfig.ini get read before the folder disappears?  If it does, then it would stand to reason that your suggestion should work.

[MdKnightR]

  On 8/1/2017 at 2:21 PM, TrialandError said:

Welcome MdKnightR,

Have you tried placing your SetupComplete.cmd in a different directory such as C:\Windows\Temp and then editing the .ini file to show the new location? The Temp directory's may get cleared as well so you may need to try a custom location.

Expand  

Okay, that didn't work.  The WSUS directory disappeared just like before, along with the SetupConfig.ini file.  I had placed the other 2 files in C:\Temp and they are still there.  Any other ideas?

[TrialandError]

I'm pretty sure its normal for the WSUS directory to get cleaned up after the upgrade completes. The setupconfig.ini gets cached in %WINDIR%\panther so it can survive reboots.

You had SetupComplete.cmd and 2 other files in C:\temp and the SetupConfig.ini file that was copied to the machine before the upgrade had: PostOOBE=C:\Temp\SetupComplete.cmd correct? Can you post the C:\Windows\Panther\UnattendGC\Setupact.log (remove any machine names\domain info) of one of the machines that upgraded yet didn't run your script? I am going to test some when I get back to my lab to see if I can replicate your issue but in the mean time, can you copy your SetupComplete.cmd to %WINDIR%\Setup\Scripts\ and then try the upgrade? Windows should run this after the install but before the logon screen ever comes up.

[MdKnightR]

  On 8/1/2017 at 8:46 PM, TrialandError said:

The setupconfig.ini gets cached in %WINDIR%\panther so it can survive reboots.

Expand  

I don't see SetupConfig.ini anywhere under that directory.

 

  On 8/1/2017 at 8:46 PM, TrialandError said:

You had SetupComplete.cmd and 2 other files in C:\temp and the SetupConfig.ini file that was copied to the machine before the upgrade had: PostOOBE=C:\Temp\SetupComplete.cmd correct?

Expand  

2 files total in c:\temp (SetupComplete.cmd and SetupComplete.ps1).  SetupConfig.ini in the WSUS directory with the modified parameter PostOOBE=C:\Temp\SetupComplete.cmd

 

  On 8/1/2017 at 8:46 PM, TrialandError said:

Can you post the C:\Windows\Panther\UnattendGC\Setupact.log (remove any machine names\domain info) of one of the machines that upgraded yet didn't run your script?

Expand  

See attached

 

  On 8/1/2017 at 8:46 PM, TrialandError said:

I am going to test some when I get back to my lab to see if I can replicate your issue but in the mean time, can you copy your SetupComplete.cmd to %WINDIR%\Setup\Scripts\ and then try the upgrade? Windows should run this after the install but before the logon screen ever comes up.

Expand  

This seems to have me stuck, and I've been working on it all day today.  I modified my task sequence to put the files where you recommended, and now it won't install the Feature Update.  It keeps returning an error code 0XC190010D.  I have tried re-imaging the laptop, same result.  I have tried removing the scripts after they were applied to the laptop, same result.  I suppose my next course of action is to disable the task sequence that deploys the scripts, reimage the laptop again, and see what happens.

setupact.log