Jump to content


anyweb

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

Recommended Posts

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:

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.

 

powershell script has run.png

 

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

 

collections created.png

 

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

 

folder must contain the language pack sub folder.png

 

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

 

lp cab file.png

 

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

setupconfig ini package.png

 

when prompted to create a program, choose Standard Program

 

standard program.png

 

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:

 

copy y.png

 

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

 

run on windows 10.png

 

and continue through the wizard until completion

 

summary.png

 

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

 

distribute content.png

 

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

 

distributed content.png

 

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.

 

deploy.png

 

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

 

deploy to collection.png

 

for Deployment Settings, use a purpose of Required

 

deployment settings.png

 

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

 

as soon as possible.png

 

and continue through the Deploy Software Wizard until completion.

 

deploy software wizard completion.png

 

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.

 

setupconfig ini on the client.png

 

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

 

 

 

notice the update warning text...

 

update warning.png

 

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)

 

setupact log file.png

 

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

 

updating windows.png

 

and after a while it's done

 

windows 10 upgrade done.png

 

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

 

all done.png

 

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

 

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

Share this post


Link to post
Share on other sites


both work, give it a go

Share this post


Link to post
Share on other sites

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
        }
    }
}

 

Share this post


Link to post
Share on other sites

Welcome MdKnightR,

55 minutes ago, MdKnightR said:

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

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.

Share this post


Link to post
Share on other sites
58 minutes ago, 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.

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.

Share this post


Link to post
Share on other sites
3 hours ago, 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.

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
14 hours ago, TrialandError said:

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

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

 

14 hours ago, 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?

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

 

15 hours ago, 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?

See attached

 

16 hours ago, 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.

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

Share this post


Link to post
Share on other sites
On 8/1/2017 at 4:46 PM, TrialandError said:

can you copy your SetupComplete.cmd to %WINDIR%\Setup\Scripts\ and then try the upgrade?

Okay, here's the problem I've been experiencing today.  The feature update will not install if the SetupConfig.ini file points to %WINDIR%\Setup\Scripts\ .  Just as soon as I removed it from the WSUS folder, it installed.  I guess the installation must read the INI file at the early stages of the deployment?

Share this post


Link to post
Share on other sites

I drilled through your log file and the .ini file is definitely working as the /PostOOBE switch is correctly set to C:\Temp\SetupComplete.cmd. But obviously your custom script is not running even though the PostOOBE phase completes successfully. I am still testing on my end.

11 hours ago, MdKnightR said:

The feature update will not install if the SetupConfig.ini file points to %WINDIR%\Setup\Scripts\ .  Just as soon as I removed it from the WSUS folder, it installed

I apologize for not being clearer. Don't edit the setupconfig.ini file to look to %WINDIR%\Setup\Scripts\, leave the default settings but place your SetupComplete.cmd file in %WINDIR%\Setup\Scripts\ prior to the upgrade. This is a long shot and is independent of SCCM. Per https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-custom-script-to-windows-setup, this script will run before the logon screen appears. Even in your setupact.log this file is created and runs.

 

I have to ask, why not just use an upgrade task sequence? You can run your script during the TS and you have much more granularity. Another option is using AppLocker to stop the built in apps from launching.

KnightSetupComp.jpg

KnightSetIni.jpg

KnightOpComplete.jpg

Share this post


Link to post
Share on other sites
4 hours ago, TrialandError said:

I apologize for not being clearer. Don't edit the setupconfig.ini file to look to %WINDIR%\Setup\Scripts\, leave the default settings but place your SetupComplete.cmd file in %WINDIR%\Setup\Scripts\ prior to the upgrade.

To be clear, there is no SetupConfig.ini, or WSUS directory to put it in, until I create it.  However, I will leave out that part and just put the SetupComplete.cmd and SetupComplete.ps1 files in the scripts folder and see what happens.  It may be worth noting that the %WINDIR%\Setup\Scripts\ already has a SetupComplete.cmd file in it, along with a file named DisableCMDRequest.TAG (not sure if that is relevant).  Should I replace SetupComplete.cmd with my custom one, or edit existing with the additional content that triggers the Powershell script?  The existing one contains the following:

%windir%\system32\osdsetuphook.exe /execute 

 

4 hours ago, TrialandError said:

I have to ask, why not just use an upgrade task sequence? You can run your script during the TS and you have much more granularity. Another option is using AppLocker to stop the built in apps from launching.

I had considered it, but I have read that it might cause issues with the ConfigMgr client on the upgraded PC.  Also, we want to leverage Windows 10 Servicing for the Feature Updates, and from what I gather, you can't do both.  As for AppLocker, it just disables the apps rather than eliminating them.

 

Share this post


Link to post
Share on other sites

Adding the SetupComplete.cmd and SetupComplete.ps1 files to the scripts folder had no effect.  The apps are still there upon login after applying the Feature Update.

Share this post


Link to post
Share on other sites

are you sure it's running the scripts, for example if you get the script to drop a txt file in c:\temp to prove it ran, is the file there ?

Share this post


Link to post
Share on other sites
15 minutes ago, anyweb said:

are you sure it's running the scripts, for example if you get the script to drop a txt file in c:\temp to prove it ran, is the file there ?

I haven't tried that.  I just assumed that it isn't running, because it either runs and removes the apps or it doesn't.  I can confirm that the Powershell script is a good script.  I can run it manually with elevated privileges and it'll strip all the apps out that I want gone.  I just can't seem to make it work automatically.

Share this post


Link to post
Share on other sites

i would try to prove that it's running, to rule things out

Share this post


Link to post
Share on other sites
15 hours ago, TrialandError said:

MdKnightR I haven't forgotten about you. I had a drive fail in my lab so I rebuilt it with some SSD's. Have you had a chance to test anyweb's suggestion?

I did, but I also kinda switched gears.  I decided to try to accomplish the app removal by way of a scheduled task that runs on system start.  The task runs before a user logs in, and the txt file will appear in C:\Temp, but the apps are still there.  It doesn't make sense because  I can still run the powershell script manually to strip out the apps.

Share this post


Link to post
Share on other sites

Okay, I think you may be onto something.  I ran psexec -i -s Powershell.exe , then executed the script manually.  All it did was write the txt file and the apps are still there.

  • Haha 1

Share this post


Link to post
Share on other sites

Bit of a necro bump but has anyone tried this with 1803?  I had to revert to running the langpack installs with dism in my postoobe script. 

The language packs fail to install during setup, and fail the upgrade. Might have something to do with how they restructured the upgrade process... Works ok from my script but I dont like how there is now a 6-8 minute wait to complete the install when the screen is sitting at "100%" status... 

Share this post


Link to post
Share on other sites

The collections are empty for me. I have changed the script to reflect my languages (see below) but they do not become members.

If I query SMS_G_System_OPERATING_SYSTEM.OSLanguage i get : "English - United States" or "Japanese" but not the LocaleID

Am I missing something?

 

 

$Collection_1 = "SUM - Windows 10 x64 ($Windows10Version) French LP"
$Collection_2 = "SUM - Windows 10 x64 ($Windows10Version) Japanese LP"
$Collection_3 = "SUM - Windows 10 x64 ($Windows10Version) Chinese LP"
$Collection_4 = "SUM - Windows 10 x64 ($Windows10Version) Spanish LP"
$Collection_5 = "SUM - Windows 10 x64 ($Windows10Version) Mexican LP"
$LimitingCollectionName = "All Workstations"


write-host "Starting script..." -ForegroundColor Yellow

# connect to ConfigMgr
# thanks Skatterbrainz - https://www.windows-noob.com/forums/topic/13613-how-can-i-configure-client-settings-and-install-the-configmgr-client-agent-in-system-center-configuration-manager-current-branch/?p=53923
#

Get-CmAdminConsolePath
 
# Create collections based on the list of collections
Create-Collections

# add some queries to our collections
$TargetCollection = $Collection_1
$RuleName = "French Language Pack Installed"
$RuleNameQuery = "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 = '$BuildNumber' and SMS_G_System_OPERATING_SYSTEM.OSLanguage = '1036'"
Add-Membership-Query($TargetCollection)

$TargetCollection = $Collection_2
$RuleName = "Japanese Language Pack Installed"
$RuleNameQuery = "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 = '$BuildNumber' and SMS_G_System_OPERATING_SYSTEM.OSLanguage = '1041'"
Add-Membership-Query($TargetCollection)

$TargetCollection = $Collection_3
$RuleName = "Chinese Language Pack Installed"
$RuleNameQuery = "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 = '$BuildNumber' and SMS_G_System_OPERATING_SYSTEM.OSLanguage = '2052'"
Add-Membership-Query($TargetCollection)

$TargetCollection = $Collection_4
$RuleName = "Spanish Language Pack Installed"
$RuleNameQuery = "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 = '$BuildNumber' and SMS_G_System_OPERATING_SYSTEM.OSLanguage = '3082'"
Add-Membership-Query($TargetCollection)

$TargetCollection = $Collection_5
$RuleName = "Mexican Language Pack Installed"
$RuleNameQuery = "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 = '$BuildNumber' and SMS_G_System_OPERATING_SYSTEM.OSLanguage = '2058'"
Add-Membership-Query($TargetCollection)

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...