Configuration Manager

Enable TPM inventory

So a couple of weeks ago I wrote a post on how to verify that your computers are running UEFI and SecureBoot (read here). After that there was a post on the importance of staying supported with up to date hardware (read that here). As a follow up to both of them there is another part that should be monitored as we move deeper into to Windows as a Service. This becomes especially true when we look at todays security landscape and the need to enable all of the new security features.

Some of these new features requires TPM and furthermore some require TPM 2.0. Now this can be inventoried using tools like Microsoft Endpoint Manager. The issue here is that by default ConfigMgr only inventory information about if TPM is present, enabled and owned. It does not keep track of TPM spec version.

So this will be a quick fix! Open up your client settings that targets your workstations and laptops and make sure to enable the TPM spec version. Check out the hardware inventory page and the classes part. If you do a quick search for TPM you will find that spec version is not check. So go ahead and check that. Watch the inventory data flow in and make decisions based on it!

TPM

Happy deployments!

/Peter

#MEMCM and the stuck hotfix

While doing a new install at a customer the last couple of weeks we ran into a strange issue. To make matters worse this is an offline site so all the normal posts and tricks don’t apply.

Now the issue here is that when we run the serviceconnectiontool it will create a telemetry file and download needed hotfixes and upgrades. Now this all works as intended, the challenges is that once the dowloaded files have been imported over and the tool run on the primary again the hotfix is stuck as “available to download”. Now in most scenarios a simple restart of SMS_EXECUTIVE or kick the download process a bit. However, in a offline scenario re-downloading the patch doesn’t really help.

After a bit of looking and trouble shooting it turns out that I’m not the first (and probably not the last) to encounter this. Now Prajwal Desai has made a post on how to fix that on an online system, read the full post here https://www.prajwaldesai.com/sccm-1906-hotfix-download-issues/. What he either doesn’t know or have encountered yet is that the same principles apply to offline systems as well, meaning you should run the serviceconnectiontool as described in the official documentation. When done you still execute the storeprocedure spAddPackageToDownload with the guid as described. Restart the SMS_EXECUTIVE service and wait for extraction of the cab file to happen. The the hotfix will be available to install as expected.

MEMCM1906HF

A shoutout to Parjwal for documenting the fix!

Happy deployments!

/Peter

Staying secure with UEFI and SecureBoot

One of the bigger issues I still see with a lot of customers is devices that has still not been converted to run UEFI and SecureBoot. This will prevent you from enabling a bunch of security features in Windows 10. This includes but is not limited to new features such as Credential Guard (to protect your identities).

If you already have ConfigMgr CB today the new SMS_Firmware class is enabled by default in hardware inventory. By using this information we can get insight into the environment and see how many machines should be converted. Now you can either create collections for this or if you just need to know and want to use the data for a presentation or something like that a simple SQL query can be used.

Running the following SQL query would give you status for SecureBoot and UEFI.

select Secureboot00, UEFI00 from Firmware_DATA

The downside here is that you won’t see what devices. The next issue would be that certain bios versions won’t have full support for UEFI and SecureBoot. Furthermore there are certain vendors and models that requires specific BIOS versions to support new features like Credential Guard. This can however be fix by running a slightly more complex SQL query

select
Case
When SecureBoot00 = 0 Then ‘FALSE’
When SecureBoot00 = 1 Then ‘TRUE’
End AS SecureBootEnabled,
Case
When UEFI00 = 0 then ‘FALSE’
When UEFI00 = 1 Then ‘TRUE’
End AS UEFIEnabled,
dbo.vSMS_R_System.Name0 as PCName, v_GS_WORKSTATION_STATUS.LastHWScan as LastScan
,PC_BIOS_DATA.ReleaseDate00 as BIOSReleaseDate, PC_BIOS_DATA.BIOSVersion00 as BiosVersion
from dbo.Firmware_DATA
Inner Join dbo.vSMS_R_System on dbo.Firmware_DATA.MachineID = dbo.vSMS_R_System.ItemKey
Left join v_GS_WORKSTATION_STATUS on dbo.vSMS_R_System.ItemKey = v_GS_WORKSTATION_STATUS.ResourceID
Left join PC_BIOS_DATA on dbo.vSMS_R_System.ItemKey = PC_BIOS_DATA.MachineID
order by PCName

The output from this gives you a nice list with the status of SecureBoot, UEFI, PCName, bios release date and bios version. Something like below which can then be exported to excel or PowerBI.

SecureBootUefi

Happy deployments!

/Peter

Nice to Know – Defender Sandbox

So another step in the right direction for Windows Defender, it can now run in sandboxed mode. For now you have to turn it on but in the future that will be default.

If you want to read more about the release of this check out the cloudblog from MS here https://cloudblogs.microsoft.com/microsoftsecure/2018/10/26/windows-defender-antivirus-can-now-run-in-a-sandbox/?fbclid=IwAR1BX92wvaqmse7bgucQtPbi_Si6XY1cMfIec9JW1XttX-4wqttIU39mokM

So lets assume you also run ConfigMgr, now this is where its gets intreseting. We can then use a CI to track if it has been turned on!

This is done using a very simple detection script.

image

Here is the small code snippet used to track compliance.

if ($env:MP_FORCE_USE_SANDBOX -eq 1) {
  return $true
}
else {
  return $false
}

Now two things remain, set the data type to boolean and as compliance set to “True”.

All set to measure this. Of course a simple script or package can now be used to force the setting of this, just remeber that its only supported on Windows 10 1703 and later and will require a reboot before taking effect.

Happy deploymnet!

/Peter

Improving the Windows 10 Upgrade Sequence

When you upgrade to Windows 10 or between diffrent Windows 10 versions there are genearlly several things you wish to do. This can include removing “bad” applications or install drivers. Among some common things that needs to be taken care of is diffrent pre-requisites and language packs. This posts covers some things you can improve in your Windows 10 upgrade sequence.

The small things first. As more and more users are working from a laptop a common problem is that someone intiates the sequence when the users has 10% battery left. Now the predicatable outcome is broken upgrade and rollback. To prevent this we can enable a small check to verify if the machine is running on battery power and if so exit the sequence quickly all while we leave a log trace for admins to track.

First we require a small powershell script, download that from here https://github.com/LofgrenP/Scripts/blob/master/Get-xTSRunningOnBattery/Get-xTSRunningOnBattery.ps1

Create a package with source files but no program. Then add a Run PowerShell Step in the begning of your sequence. Use the new package that has been created and set the script name to Get-xTSRunningOnBattery.ps1. Set the execution policy to ByPass.
image

That will take care of machines running on battery. Next common issue is that machines not connected to the wired network won’t reconnect to the network after a restart. To assist with this we can make sure that the upgrade does not run if its not a wired connection.

Download the script needed from here https://github.com/LofgrenP/Scripts/blob/master/Get-xTSEthernetConnection/Get-xTSEthernetConnection.ps1

Create a package with source files and no program then add another Run PowerShell Step in the beginning of your sequence. Use the new package that has been created and set the script name to Get-xTSEthernetConnection.ps1. Set the execution policy to ByPass.
image

With that taken care of lets move on to sorting the language packs. To sort this there are two things we need to sort out. First up is making sure to reinstall all language packs that are already installed. Now Nickolaj Andersen over at SCConfigMgr has an awesome post on how to do that, read that here http://www.scconfigmgr.com/2017/11/06/automatically-retain-installed-language-packs-during-windows-10-servicing/

The final piece to the pussel is making sure that the Language Pack scheduled task does not run. This can be achived in many ways but I prefer to just disable the task after the upgrade is done. For that reasone you can download a small script here https://github.com/LofgrenP/Scripts/blob/master/Disable-xTSLanguagePackTask/Disable-xTSLanguagePackTask.ps1

Now we create another package with source files but without any program and add a final Run PowerShell Step to our upgrade sequence. This time at the very end of the sequence. Make sure to use your new package, set the script name to Disable-xTSLanguagePackTask.ps1 and set the execution policy to ByPass.
image

Now you should be all set to upgrace your machines.

Happy deployments!

/Peter

Refresh scenario and LAPS

When doing reinstall of machines a common issue is that the LAPS password does not get updated due to the fact that the machine thinks the password is current. So to prevent the nice folks from Microsoft wrote a small script to reset the timer and force and update. The original blog post and script can be found here https://blogs.msdn.microsoft.com/laps/2015/05/06/laps-and-machine-reinstalls/

Now my issue with this is there is no log file created and no way for helpdesk to verify it actually happend (besides logging on which I don’t like).

So to solve this I have made an updated version of the script that centralizes logging basone if the script is run as part of MDT, Configuration Manager or Standalone.

image

Script can found on github here https://github.com/LofgrenP/Scripts/tree/master/Clear-xTSPasswordTimeStamp

Redistributing failed content

When working with ConfigMgr you always end up distributing content to several DPs. This normaly goes off without a hitch but from time to time this fails. If you then have several DPs spread across a large geographical area, WAN links may be questionable. So when a package then fails most are not happy to redistribute the content to all DPs again.

image

So to help sort that out the following script can be used. The script will find all failed packages on a specified DP and then redistributed them to that single DP only. All that is needed is to run in on the Primary site server / server with SMS provider and specifiy your SiteCode and DP FQDN.

The script is available on Github over here: Update-ContentForSingleDP

Happy deploying!

/Peter