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

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.


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!



Windows Server 2019 Server Manager

We all like the new admin center, right? But logging on to a new shiny Windows Server 2019 and getting a popup saying “hey you know about Windows Admin Center” thats not my idea of nice server management. Pops ups should be killed with fire! So when I first saw the box below well that got me thinking, how do we get rid of it before I even log on?


Answer to this is simple, this is controlled by a registry value and as such subject to the power of group policy preferences. Create a new GPO and create a new registry item following these settings

Key Path: SOFTWARE\Microsoft\ServerManager
Value name: DoNotPopWACConsoleAtSMLaunch
Value type: REG_DWORD
Value data: 00000001


Now hit ok and then link the policy to you server OU/OUs. Done, no more annoying popup!


Windows 10 – Lifecycle change AGAIN!

Update 2018-09-07: Michael Niehaus was kind enough to supply some additional information on this subject. So to clarify this post and the information from MS. The currently available versions of Windows 10 Enterprise and Education will have 30 months of support and future releases starting with 1809 and 1903 will have 30 and 18 months of support.

Niehaus has also stated that Microsoft is still commited to deliver innovation and new features for every single Windows 10 release.

Orignial Post:

So its happend again, the lifecycle supportstatment surrounding Windows 10 has been changed. Some say for the better, but it remains to be seen. The change only applies to Enterprise and Education SKUs and only to the september relase of every year. So if you are on 1703 nothing has changed but if you are on 1607 or 1709 there has been some changes.

The new change is that Enterprise and Education now get 30months of support. There is also a small note to be made about a statment of the lifecycle facts page stating

“…you’ll need to install the latest feature update to help keep your device secure and have it remain supported by Microsoft.”

Which would mean that unless you apply the latest CU every month you are not really supported. How this will be “enforced” remains to be seen.

For more detailed information and source of the change review the lifecycle fact page from Microsoft here

One last thing to note, up until now Microsoft have only been testing upgrading the previous version to the lastest version of Windows 10, example when 1709 was released the only path that was tested was 1703->1709. With the new support statement you might have an urge to skip versions. However unless Microsoft changes their test protcoll and actually tests jumps like 1607->1709 it might still be worth going with every version, altho not as quickly as before.

Support dates as of 2018-09-06



The Death Of MBAM

Update: 2018-10-06
Microsoft has given out information that MBAM is not been removed but instead put into sustained engieering. Meaning it will continue to work and continue to recive bug fixes but no new features will be added. This also means that support for future Windows 10 release as well as new SQL release should be added.

This should hold true until Microsoft has a feature by feature compareable service elsewhere (Azure most likley).


Microsoft Bitlocker Administration and Monitoring (MBAM) has now recieved its finaly date. This means that if you have already implemented MBAM you have a couple of years to migrate away from it, but if you haven’t implemented it and was about to do so. Please refrain from it.

Mainstream support will end July 7th 2019, meaning up until that date new “features” will be brought out to support newer SQL versions and the like.

Extended support will end on July 7th 2024, meaning after this date there will be no security patches and no support at all available.


Hopefully Microsoft gives a solution to rotating keys and self-service through Active Directory or Azure Active directory soon to fill the gap between MBAM and a standarnd Bitlocker implementation.


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

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.

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

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.

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

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

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.

Now you should be all set to upgrace your machines.

Happy deployments!


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

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.


Script can found on github here

Updating the MBAM Agent

When upgrading MBAM there are a couple things to note. Number one, if you haven’t already you should make sure you have PowerShell scripts to setup everything on the server side. This will be a nice to have since every servicerelease requires a uninstall/reinstall. And with lots of serviceaccounts, groups and what not, not automating the install will cause you headaches everytime.

The next issue is that the agents needs to be ugpraded everywhere. Now there is no panic to upgrade the agents on the machines as the old version will keep reporting to a newer server release. However to benefit from all the bugs and security fixes the update should absolutley be deployed.

Now the issue, when you run the MSP on an already patches systems (let’s assume you already have a service release installed) nothing happends. Well this is due to the fact that the MSP only upgrades from version as can be viewed in the MSP itself. Below is from the x64 patch of the september release.


Now to fix this the easiest way is actually to create a wrapper around the MBAM agent installer and use that to install the agent. That way if there is already and agent installed we can uninstall it and reinstall the patched version. And if there is no version installed we can go ahead and install the version.

All of this can be done using PowerShell and checking the registry for known keys.


To save you the time on creating your own script to solve this you can use mine. It can be found on github overe here

Now the script requires a simple folder structure looking like this


Now in the source folder you place the MbamClientSetup.exe and the patch file from the latest servicingrelease. The script is prepped for the current September 2017 release.

Next up is you run the script as a administrator on a box, or run the script as part of a package in Configuration Manager, an application in MDT or basically however you want.

The logfiles will switch location based on if its run as part of Configuration Manager, MDT or standalone. The end result will always be the same!

Happy upgrading!