This is a follow up to this post : https://blog.adexis.com.au/2019/06/14/sccm-powershell-errors-after-moving-primary-site-server-via-site-failover/
Another issue i ran into this upgrade – which was far more interesting, was that all packages and task sequences which had windows 10 ticked within their “supported platforms” – the tick was now gone after upgrade.
Now, before we go any further, i should state that i am dead against using this functionality in programs and task sequences – i see it create way more hassle than help where-ever clients use it…. if you want to limit, use a limiting collection or exclude collections on your targets…. additionally – if you are still using packages – get with the times, move to applications!
That being said, this client did have multiple outsourcers in their environment, lots of politics and bafflingly bad decisions (how bad? they have DP’s on DC’s…. yes… absolute insanity) – so while i would prefer that setting wasn’t used – the guys that utilise SCCM just wanted what they had back – and fair enough too.
Now, back to the issue.
in order to troubleshoot, i ticked the win 10 box within a dummy package/program and compared it to one of the broken ones – this was done using
Get-CMPackage -id <package ID> -fast | Get-CMProgram | select –expandproperty SupportedOperatingsystems
the output you’ll get will be something like this
SmsProviderObjectPath : SMS_OS_Details
MaxVersion : 10.00.9999.9999
MinVersion : 10.00.0000.0
Name : Win NT
Platform : I386
SmsProviderObjectPath : SMS_OS_Details
MaxVersion : 10.00.9999.9999
MinVersion : 10.00.0000.0
Name : Win NT
Platform : x64
SmsProviderObjectPath : SMS_OS_Details
MaxVersion : 6.10.9999.9999
MinVersion : 6.10.0000.0
Name : Win NT
Platform : x64
SmsProviderObjectPath : SMS_OS_Details
MaxVersion : 6.20.9999.9999
MinVersion : 6.20.0000.0
Name : Win NT
Platform : x64
on the one that was manually ticked – the output was this (cut down to win 10 for sake of post length)
SmsProviderObjectPath : SMS_OS_Details
MaxVersion : 10.00.99999.9999
MinVersion : 10.00.0000.0
Name : Win NT
Platform : x64
The difference is subtle – but there. The broken one has 4 x 9’s in the middle, the “correct” one has 5 x 9’s in the middle…. at some stage during the CB’s – the Maxversion of windows 10 obviously changed – and for reasons im still not sure about – the upgrade process did not correctly update them.
This can also be viewed by directly viewing the SQL table dbo.PKGProgramOS . Program names with “*” are for task sequences.
There were a couple of ways to address this.
Initially, i looked at using powershell and doing everything through the SMS provider, so everything would be supported. The downside of this is that there was no way to delete/change the stuffed entry – only to add the correct entry.
Working the script out really sucked, as when using get-CMSupportedPlatform on 1902, there are multiple windows 10 entries, including “All windows 10 (64-bit)” – which doesn’t work when piped into a script… instead, you have to use “All windows 10 (64-bit) Client” – sure, it seems logical now… but i, and one of my team spent hours on that!
Once that was sorted, the plan was to use a script such as: (the below was never completed, tested or implemented, so its below for a conceptual reference only! it does not work!)
$programs = Get-CMPackage -fast | Get-CMProgram | select packageID, PackageName, PackageVersion, ProgramName -expandproperty SupportedOperatingsystems
$win10x64 = Get-CMSupportedPlatform -fast -Name “All Windows 10 (64-bit) client”
write-host “Programs: ” $programCount.count -ForegroundColor Green
foreach ($program in $programs) {
if ($program.MaxVersion -eq “10.00.9999.9999”) {
write-host $program.PackageID $program.PackageName $program.PackageVersion $program.ProgramName $program.MaxVersion $program.Platform
if ($program.Platform -eq “x64” {
Set-CMProgram -PackageName $program.PackageName -StandardProgram -ProgramName $program.ProgramName -AddSupportedOperatingSystemPlatform $Win10x64
}
}
Fortunately, this client has an awesome database guy (thanks Alan) when was able to help in a much more sensible way – updating the SQL table directly.
While this is unsupported by MS (use at your own risk etc etc) – since MS support has basically become completely useless… their products are effectively unsupported anyway. It takes 2-3 weeks to get through the first lines of support to someone with a brain – and dont get me wrong, when you get to that person – they can be fantastic…. but the time frame is just unrealistic.
With that in mind, we made a copy of the dbo.PKGProgramOS table and then ran the following sql (comments included)
–First step is to backup all the records that could potentially be changed by the script.
–This table, PkgProgramOS_49s_20190603, can then be removed in a few days/weeks depending on the thoroughness of user acceptance testing
— NB – all the commented out “.PkgID = ” lines were used to test the logic prior to updating the records
–Count of records found (2 different runs)
–6836, 6777
SELECT *
INTO PkgProgramOS_49s_20190603
FROM [CM_C01].[dbo].[PkgProgramOS] (nolock) y
where 1=1
–and y.PkgID = ‘00100050’ –‘C01008EE’
and OSMaxVersion = ‘10.00.9999.9999’–Confirmation that expected number of records are in the backup table. Measure Thrice Cut Once!
select * from PkgProgramOS_49s_20190603; –6777–This is the select version of the update to bring back and confirm all records that will be updated.
–Requirement was to update all 10.00.9999.9999 records to be 10.00.99999.9999 where there was not already a 10.00.99999.9999.
–i.e. Update where all Package/OS/Program records with the 4 Nines to be 5 Nines, except where there was already a 5 Nines to prevent creating a duplicate 5 Nine.
–Join the Set of 4 Nine records with those with 5 Nines and return those with out the 5 Nine record
–Count of Records found
–6835, 6776
SELECT x.[PkgProgramOS_PK] ,x.[PkgID] ,x.[ProgramName] ,x.[OSName] ,x.[OSPlatform] ,x.[OSMinVersion] ,x.[OSMaxVersion] ,n.PkgProgramOS_PK, n.OSMaxVersion, n.OSPlatform, n.PkgID, n.ProgramName
FROM [CM_C01].[dbo].[PkgProgramOS] (nolock) x
LEFT OUTER JOIN ( — Records with 5 Nines
SELECT y.[PkgProgramOS_PK] ,y.[PkgID] ,y.[ProgramName] ,y.[OSName] ,y.[OSPlatform] ,y.[OSMinVersion] ,y.[OSMaxVersion] FROM [CM_C01].[dbo].[PkgProgramOS] (nolock) y
where 1=1
–and y.PkgID = ‘C01008EE’
and y.OSMaxVersion = ‘10.00.99999.9999’
) n on x.PkgID = n.PkgID and x.OSName = n.OSName and x.OSPlatform = n.OSPlatform and x.ProgramName = n.ProgramName
where 1=1
–and x.PkgID = ‘C01008EE’–00100050
and x.OSMaxVersion = ‘10.00.9999.9999’ and isnull(n.OSMaxVersion,”) <> ‘10.00.99999.9999’ –Include 4 Nines and Exclude where a 5 Nine is found.–Update version of the above Select.
–Always create the select, then copy and paste and convert to an update, that way the condition is always in place
–(This prevents the tragic error of writing update table set value =, and then finger slipping and hitting F5, before the where clause is added!)
UPDATE x set [OSMaxVersion] = ‘10.00.99999.9999’
FROM [CM_C01].[dbo].[PkgProgramOS] x
LEFT OUTER JOIN (
SELECT y.[PkgProgramOS_PK] ,y.[PkgID] ,y.[ProgramName] ,y.[OSName] ,y.[OSPlatform] ,y.[OSMinVersion] ,y.[OSMaxVersion] FROM [CM_C01].[dbo].[PkgProgramOS] (nolock) y
where 1=1
–and y.PkgID = ‘C01008EE’
and y.OSMaxVersion = ‘10.00.99999.9999’
) n on x.PkgID = n.PkgID and x.OSName = n.OSName and x.OSPlatform = n.OSPlatform and x.ProgramName = n.ProgramName
where 1=1
–and x.PkgID = ‘C01008EE’–00100050
and x.OSMaxVersion = ‘10.00.9999.9999’ and isnull(n.OSMaxVersion,”) <> ‘10.00.99999.9999’
–6776 — Records updated. Ooh look it matches our select!–Run the select to find if any 4 Nine records are left.
SELECT *
FROM [CM_C01].[dbo].[PkgProgramOS] (nolock) y
where 1=1
–and y.PkgID = ‘00100050’ –‘C01008EE’
and OSMaxVersion = ‘10.00.99999.9999’
–Pass the system back to the users for testing
After this – the programs and task sequences that previously had “All windows 10 32bit” (and 64bit) ticked will have it ticked again.
Clients that have evaluated these programs already will have the following status – Program rejected (Wrong Platform)
In order to get around this, simply update any properties of the program e.g. the estimated run time (for example) – this will force clients to re-evaluate the package – and with the fixed “supportedOperatingsystem” entry – this will now run correctly.