Author: Andreas Stenhall

A really bad decision that Microsoft changes Windows 10 Enterprise LTSC from 10 to 5 years support!

In a statement a few weeks ago Microsoft announced significant changes to how long Windows 10 LTSC (Long Term Servicing Channel) is supported.

I have been working with about 30 customers around Windows 10 since the launch of Windows 10 almost six years ago. I am the strongest of cloud advocates and for Windows as a service, but I must as a professional adjust and look at customer needs and conditions as well as cost efficiency. Among all deployment projects and customers I have worked with, only in two of those cases did we have to go with LTSC edition of Windows 10, after very careful and thorough evaluation of cloud and Windows as a Service being the natural top choices.

The reason for choosing LTSC with these two customers are simple and has been the same in both cases; they are ideal for devices that typically do not have any dedicated users and serve one purpose only, and that is to display information or let users interact with it through a single application as a kiosk. Often the hardware is not easily accessible. These devices must in many cases also be up and running 24/7 with no interruptions.

Another aspect to take into consideration is that the business does not care if it is Windows 10 version X or whatever version of anything if the monitor is displaying the information or performing what the business needs are.

Currently with 10 years support – Fire and forget

Windows 10 LTSC version 2019: Deploy to a computer purchased and it can run theoretically to January 2029. Typically, with 10 years support, if you deploy new hardware with the latest Windows 10 LTSC version you are good for up to 7-9 years. You will not have to touch the device until it is time to replace the computer after X number of years.

After Microsoft changing to 5 years support – Additional work and costs with no business value

Windows 10 LTSC 2022 (I guess 2022 will be the name as that applies to Windows Server 2022 which is based on the same bits and bytes) it will be supported to say fall 2025. If a new computer is installed in 2023 with Windows 10 LTSC 2022, it will have support for an additional 2 years, and at some point, before reaching the of support, it will have to be upgraded to a new version to remain supported for additionally five years.

The problem

The huge problem here is that this bring not only doubled license cost (or even more), but also mean that more work by IT will be required to upgrade the machines. This requires development of upgrade process and a lot of testing. The manhours required are at least three figures and will also involve and impact the business, with once again, no added business value whatsoever.

As this is often special hardware it is often placed in physical locations where the computers are not easily accessible, and the lifetime will likely exceed the typical lifetime of a device. And the fact that the hardware is placed in physical tight areas are also driving additional costs to exchange as there often needs to be special glass or metal work included.

Action!

Microsoft must reconsider to keep the support lifecycle for Windows 10 Enterprise LTSC at 10 years. Switching to Windows 10 IoT is not an option as that it not doable in terms of licensing as IoT is not available on enterprise agreements or through volume licensing, limited number of OEMs and re-imaging!

Problem with “New User” being the only account on the sign-in screen after reboot

This is one of the most mysterious problems I’ve encountered and anyone who can provide input is more than welcome to ping me on Twitter or Teams.

Problem

You restart your Windows 10 device (Azure AD Joined + MEM/Intune enrolled) and after the restart, instead of displaying the last logged on user, the only account on the sign-in screen is an account named “New User”.

This happens extremely rarely, but I’ve seen it a few times. The “New User” comes from nowhere and if you click Switch user it just returns to the same view as below.

I have seen the problem a few times for multiple Windows 10 versions back to at least Windows 10 v1909, and on multiple devices from multiple vendors. The other day this problem hit a colleague of mine as well so it’s not just me :) .

Workaround

Two potential workarounds, which are are far 100% reliable:

  1. Do a Shutdown of the computer. This is often the most successful and quickest recovery.
  2. Restarting multiple times will eventually get you to a point where you can click Switch user and it will give you “Other user” where you can manually enter the UPN of your regular user account together with password, which is the only way of getting in. After that everything works as it usually does!

Thoughts and ideas

I have no idea where to start. A local user account with display name “New User” and username “defaultuser100000” do exist in the affected Windows 10 devices.

Why does it approximately one time out of 100 or even 1000 “lose” the last user and offer no options to login as you typically do, only displaying “New User”? Is it a localization issue? Intermittent problem and very rare to say the least.

Once again, if you have any input you are more than welcome to ping me on Twitter or Teams.

Case of the non-offered Windows 10 feature upgrade when using Windows Update for Business

I’ve seen this problem with a couple of customers now that is using Windows Update for Business, when some machines we’re not offered Windows 10 20H1 (May 2020 update a.k.a. version 2004) nor Windows 10 20H2 although no policies should block it.

Problem description

The new Windows 10 feature update is not offered via Windows Update (for Business) even if you do a manual scan for update. And, no feature update deferrals are configured, nor any specific Windows 10 version set using the “set feature update” to use. Still the new Windows 10 version is not offered which is sort of mysterious!

Investigation

Good old WindowsUpdate.log comes to the rescue! Get-WindowsUpdateLogs generated the log and then the fun began. To be honest it’s been some time since I last went into this log file, and after browsing some hundred lines of logs something interesting popped up:

ProtocolTalker DeviceAttributes[URI]

which is followed by the data:

E:DchuIntelGrfxExists=1&IsContainerMgrInstalled=1&FlightRing=Retail&TelemetryLevel=1& HidOverGattReg=C%3A%5CWINDOWS%5CSystem32%5CDriverStore%5CFileRepository%5 Chidbthle.inf_amd64_fd8e0a54b983f85c%5CMicrosoft.Bluetooth.Profiles.HidOverGatt.dll& AppVer=10.0.18362.836&IsAutopilotRegistered=1&ProcessorIdentifier=Intel64%20Family%206 %20Model%20142%20Stepping%2012&DchuIntelGrfxVen=32902&OEMModel=Latitude%207200%202-in-1&UpdateOfferedDays=0&ProcessorManufacturer=GenuineIntel&InstallDate=1588155159& OEMModelBaseBoard=0PCKGK&BranchReadinessLevel=CB&DataExpDateEpoch_20H1=1611187200& IsCloudDomainJoined=1&Bios=2020&DeferFeatureUpdatePeriodInDays=0& IsDeviceRetailDemo=0&FlightingBranchName=&OSUILocale=en-GB&DeviceFamily=Windows.Desktop&QUDeadline=2& UpgEx_20H1=Green&WuClientVer=10.0.18362.836&IsFlightingEnabled=0&OSSkuId=4& GStatus_20H1=0&App=WU_OS&CurrentBranch=19h1_release&InstallLanguage=en-GB&DeferQualityUpdatePeriodInDays=0&OEMName_Uncleaned=Dell%20Inc.& InstallationType=Clien

The interesting parts is in DataExpDateEpoch_20H1=1611187200 and if looking up that UNIX timestamp, it appears as though the installation would be performed on January 21, 2021 at midnight.

Explanation

The variable for DataExpDateEpoch_20H1 or DataExpDateEpoch_20H2 is indicating that the feature update will not be offered until the date is reached.

The evidence is true for a specific model as all of the specific model are blocked with the same timestamp. The problem is seen with multiple vendors, Dell, and Lenovo at least.

The explanation for this behavior is that Microsoft are blocking upgrades due to model, driver of firmware issues. Instead of downloading the entire package, starting the setup, and then finding out of a compatibility issue is not optimal. What is better is to block the feature update from being offered at all and that is (likely) what is going on here.

This is described and can be followed up in detail by using Update Compliance which now holds the SafeGuard information!

As it turns out, it also seems that if whatever underlying problem is fixed on Microsoft’s end, the feature update can be offered before the data occurs.

New community focus – adding a climate smart twist to IT!

I’m adding a new dimension to my community work – combining passion in work with personal interest and believes.

My work which is all about helping organizations build and maintain a secure, mobile, and modern IT workplace. My interests are much about traveling and basically everything that has to do with flying. The last part is something very close to my heart and that is to help reduce impact on the climate and Earth’s limited resources, reaching a sustainable future.

If you combine this, you get Climate Smart IT (https://climatesmartit.com) and how IT can contribute to the organization’s sustainability goals! More can be done for the climate than just enabling double-sided printing :)

Did you for instance know that a typical corporate laptop in its entire lifecycle generates the equivalent amount of CO2 emissions as a 4-hour flight?

Follow my work with Climate Smart IT at climatesmartit.com or follow this LinkedIn group, the Meetup community page or Twitter!

Recent spike in number of views for a specific blog post

I noticed an interesting thing the other day when finalizing the annual MVP renewal stats for submission to Microsoft. One blog post, which I posted in October last year, stood out among all other posts on my blog. After looking into the stats for this specific blog post it turns out the number of views on this specific blog post has exploded in the last couple of weeks!

The blog post which has seen a huge increase in number of views recently is about remote controlling Windows computers and fixing the problem with not being able to elevate as administrator in the remote session. Specifically Fixing UAC elevation when remote controlling via Quick Assist or TeamViewer etc. As a side note, the number of views on my other blog posts remain pretty much the same the last month as before.

My interpretation of the increase for this particular blog post is the following. Many people are in a lockdown mode and working from home due to the coronavirus outbreak. IT personnel then need to support them while working remotely, and they encounter the issue of elevating as admin due to UAC and seek help fixing this problem.

Could it be a coincidence that this blog post has seen a huge increase in number of views the last couple of weeks? I think not. Stay safe and take care!

Line of business MSIX updating problem via Intune – deployment blocker

MSIX has been around for more than a year now and Microsoft is working hard with promoting and developing it. I consider this application packaging format to be the packaging format of the future as it has many benefits compared to traditional MSI packages.

However, in organizations you typically deploy applications using a deployment tool such as Intune or ConfigMgr. This is where the challenge lies today and to be very clear, this is a deployment blocker for starting to package and deploy line of business applications in MSIX format.

Problem

  1. You package a line of business application in MSIX format. I use a couple of versions of 7-Zip in my testing.
  2. You deploy the MSIX package via Intune (as a Line of Business app) as a required package to your end users. The app installs fine which is expected.
  3. Now package a new version of the line of business app.
  4. Deploy the package as required to your end users. The app installs fine, but the problem is that it is executed with the flag “ForceAppShutdown” meaning that the application while running is killed without warnings to the end user – This is not acceptable in any organization.

In the Event Viewer it is clear that the running app was shut down:

Microsoft > Windows > AppXDeploymentServer > Operational log
Event ID 646
The running app 7-Zip_8b28rabfxvc2a!SevenZFM was shut down for servicing (Priority=0x1).

Note: The problem is the same regardless if the app is targeted as required or available deploy and installed in user or device context.

Additional information

Since Windows 10 version 2004 there is a new switch to the PowerShell cmdlet Add-AppXPackage that will defer an app upgrade until the app is is closed, after which the update is installed on next start of the app.

The switch is DeferRegistrationWhenPackagesAreInUse which also works as you can expect when running the command manually on a Windows 10 v2004 machine. Source

Solution?

Microsoft, please make sure that Windows 10 utilize the switch “DeferRegistrationWhenPackagesAreInUse” when deploying custom packaged app updates to MSIX packages via Intune (and likely also ConfigMgr). An option in Intune to control how updates are handled would also be nice and there are probably other solutions as well.

If you also would like a change, vote on UserVoice!

Unfortunately, as it stands right now, this problem is a deployment blocker for using MSIX in organizations.

Fixing OneDrive and Office 365 ProPlus problems on Surface Pro X when MDATP security baselines are applied

I’ve got a myself s Surface Pro X, based on Windows 10 ARM-edition, and thought I’d share the solution to a problem that I suppose more will encounter. After configuring my Surface Pro X for Azure AD join and Intune I soon hit two major problems.

Problem description

  1. OneDrive not starting at all, leaving a crash reference in Event Viewer with reference to PayloadRestrictions.dll.
  2. The Office 365 ProPlus applications works until the device is restarted, then they refuse to start. To get them going again I had to do a repair and then they started working again. At least until the next restart.

Troubleshooting and finding root cause

The Event Viewer Application log show that OneDrive crashed with reference to PayloadRestrictions.dll whenever trying to start it.

Faulting application name: OneDrive.exe, version: 19.232.1124.5, time stamp: 0xc2fada7d
Faulting module name: PayloadRestrictions.dll, version: 10.0.18362.1, time stamp: 0x77901827
Exception code: 0xc0000409
Fault offset: 0x0006e6bd
Faulting process id: 0x2ef4
Faulting application start time: 0x01d5e8bd4968fce4
Faulting application path: C:\Users\<username>\AppData\Local\Microsoft\OneDrive\OneDrive.exe
Faulting module path: C:\WINDOWS\SYSTEM32\PayloadRestrictions.dll

PayloadRestrictions.dll has been around for quite some time as a component of EMET (Enhanced Mitigation Experience Toolkit) which is nowadays integrated as the security feature Exploit Guard in Windows 10. With that as a first clue and some interaction with Robin Engström the troubleshooting process continued!

Knowing that Exploit Guard is in play and mitigations seemed to be in play, looking at the Event Viewer log Security-Mitigation > Operational log showed that OneDrive was blocked due to ROP exploit indications:

Process 'C:\Users\<username>\AppData\Local\Microsoft\OneDrive\OneDrive.exe' (PID 12020) was blocked from calling the API 'LdrLoadDll' due to return-oriented programming (ROP) exploit indications.

So then the hunt for where the configuration was coming from started and as the device is of course Intune enrolled that’s were I started looking!

It rather quickly turned out to be caused by a Microsoft Defender ATP security baseline in Intune that was applied to my user account.

To be more explicit the Exploit Guard settings clearly state that OneDrive.exe is protected for a number of exploits, including ROP!

Resolution

The solution to both problems described in the Problems section is to adjust the Exploit Guard XML file to exclude OneDrive.exe and also the other Office applications to make the Office applications work as expected.

Fixing UAC elevation when remote controlling via Quick Assist or TeamViewer etc.

A problem since Windows Vista was launched is that when you remote control another user and try to elevate to Administrator, using for instance Quick Assist which is built into Windows 10 or TeamViewer, the screen on the admin side will freeze. This is due to UAC Secure Desktop feature kicking in.

The solution is to turn this secure desktop feature off, lowering security a little but at hardly no risk.

Configuration via Intune (MDM)

Create a Configuration Policy > Endpoint Protection and go to Local device security options > User account control. Set the setting Route elevation prompts to user’s interactive desktop to Enabled.

Configuration via Group Policy (GPO)

In the GPO editor, go to Security Settings > Local Policies > Security Options > User Account Control: Switch to the secure desktop when prompting for elevation to Disabled

Replacing AppLocker with Microsoft Defender Application Control in Windows 10 1903 and later

Forget AppLocker and all its weaknesses and start using Microsoft Defender Application Control for superior application whitelisting in Windows 10 1903 and later.

This is a guide to get you started within an hour or two with what I call “AppLocker Deluxe” and that is Microsoft Defender Application Control, formerly known as Device Guard and up until recently Windows Defender Application Control (WDAC).

Most customers that did not use AppLocker before Wannacry and other types of ransomware attacks are now using AppLocker to prevent malicious software to run on their Windows devices. As many security specialists have shown, there are numerous ways to bypass AppLocker and still get code to execute. One of them being using regsvr32 to download and execute script directly from the internet for instance.

What is superior to AppLocker is Microsoft Defender Application Guard (MDAC). This takes application whitelisting to a new level and with Windows 10 version 1903 it becomes the first time since Windows 10 launched that it is actually usuable in many common day scenarios as the administration can now be on a level which is really to manage. The reason for this it being rather easy to manage now is primarily:

  • Multiple policies. You can have multiple policies complementing each other so that you do not have to sign everything nor have to create an entirely new baseline each time you want to allow new things to run.
  • Path rules. You can use path rules as of Windows 10 version 1903. As always, this is a balance between security and useability and administration so bear in mind and use this with caution. What is good is that MDAC comes with a use writable protection.

Pre-reqs for getting started

So to get started in something that looks like a real world scebario you need this:

  • 2 physical machines, different hardware models, that run Windows 10 version 1903 or preferably 1909 or later as that gives you some better insights.
  • A couple of hours of your time to get going!

High level steps

  1. Create a baseline on each hardware model.
  2. Merge the baselines into one general baseline.
  3. Create a supplemental policy.
  4. Deploy the two policies.
  5. Start the testing.
  6. Switch from Audit to Enforced mode!

1. Create a baseline on each hardware model

Let’s start with creating a baseline policy from two different machines, which will later be merged to one baseline policy. We will start with auditing, and eventually in the end of this guide switch to enforced mode.

$CIPolicyfileXML = "C:\temp\CIpolicy_model.xml"
New-CIPolicy -MultiplePolicy -filePath $CIPolicyfileXML -ScanPath C: -level FilePublisher -UserPEs -Fallback Hash

Now we set the necessary options for the code integrity policy, which is to use Microsofts Intelligent Security Graph for whitelisting (option 14), to allow supplemental policies to be used (option 17) and then we set Hardware Virtualized Code Integrity (HVCI) to Enabled.

#Automatically trust what Microsoft has deemed trustworthy using the Intelligent Security Graph
Set-RuleOption -FilePath $CIPolicyfileXML -Option 14
#Set the following option to make sure the policy can be applied without reboot
Set-RuleOption -FilePath $CIPolicyfileXML -Option 16
#Set this policy to allow supplemental policies, otherwise we can't supplement this basepolicy
Set-RuleOption -FilePath $CIPolicyfileXML -Option 17
#Now activating Hardware Virtualized Code Integrity (HVCI) and set it to enabled
Set-HVCIOptions -Enabled -FilePath $CIPolicyfileXML

Repeat the above process for at least two models, but preferably for each model you have in your environment (or at least the top five mot used models).

Note: Enabling the Intelligent Security Graph option will white list the installer for 7-Zip for instance. It will then also white list all executables that the 7-Zip installer puts on your system.

2. Merge the baselines into one general baseline

We will now merge the baselines from the two models (or more) and create one single baseline policy.

#When done collecting CIPolicies, merge them to create a common baseline
$CIPolicyfileXMLMerged = "C:\temp\Merged.xml"
$CIPolicyfileBin = "c:\temp\Merged.cip"
Merge-CIPolicy -OutputFilePath C:\temp\merged.xml -PolicyPaths "C:\temp\CIPolicy_modelX.xml","C:\temp\CIPolicy_modellY.xml"
#Then convert to binary format
ConvertFrom-CIPolicy -XmlfilePath $CIPolicyfileXMLMerged -BinaryFilePath $CIPolicyfileBin

Last but not least you must change the name of the Merged.cip file to match the Policy ID of the file which can be found at the bottom in the Merged.xml file, see the <PolicyID> section. The end result should look like {76300157-42A0-4A2D-A383-AF140D64AAE0}.cip.

3. Create a supplemental policy

Now we will create the first supplemental policy to supplement the baseline policy created in step 1 and 2. This is using path rules which is something that was added with Windows 10 version 1903.

#Now create a supplemental policy with file path rules
$CIPolicyfileXMLSupplemental = "C:\temp\Supplemental.xml"
$rules = New-CIPolicyRule -FilePathRule "C:\Program files\*"
$rules += New-CIPolicyRule -FilePathRule "C:\Program files (x86)\*"
$rules += New-CIPolicyRule -FilePathRule "\\server1\installation\*"
New-CIPolicy -FilePath $CIPolicyfileXMLSupplemental -Rules $rules -UserPEs
Set-CIPolicyIdInfo -FilePath $CIPolicyfileXMLSupplemental -BasePolicyToSupplementPath $CIPolicyfileXMLMerged
#now lookup the PolicyGUID from the bottom of the Supplemental.xml file.
ConvertFrom-CIPolicy -XmlFilePath $CIPolicyfileXMLSupplemental -Binary Supplemental.cip

You must change the name of the Supplemental.cip file to match the Policy ID of the supplemental file which can be found at the bottom in the Supplemental.xml file, see the <PolicyID> section. The end result should look like {56B75B7A-06D3-49EF-BCF8-8FC47C6ADA20}.cip.

4. Deploy the two policies

Now, lets deploy the two policies by copying them to C:\Windows\System32\CodeIntegrity\CIPolicies\Active.

For the sake of it, restart the machine. You could also use the below PowerShell command to refresh the policy without reboot:

Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = 'C:\Windows\System32\CodeIntegrity\CiPolicies\Active\{GUID}.cip'}

5. Start the testing

Now you can start the testing and see what is blocked by fetching the log files which are located in Event Viewer under Applications and Services Logs > Microsoft > Windows > Code Integrity > Operational.

6. Switch from audit mode to enforced mode!

Out of everything that would have been blocked by fetching the logs as mentioned in step 5, create additional supplemental policies and deploy until everything you need to run is white listed. Then, switch from audit mode to enforced!

Set-RuleOption -FilePath $CIPolicyfileXML -Delete -Option 3

Deploying via Intune

Even though there are existing configuration settings for enabling Microsoft Defender Application Control in an Intune endpoint restrictions policy, enabling it via those settings will mean very limited control and you cannot use supplemental policies. So, therefore you need to deploy these control policies in another way.

1. Create a source folder in C:\ named MDAC, in which you create a folder named Source, where you copy the .CIP files.

2. Create a textfile named SchTask.ps1 and add the following content.

New-Item -Path "c:\" -Name "CI" -ItemType "directory"
Copy-Item -Path ".\{76300157-42A0-4A2D-A383-AF140D64AAE0}.cip" -Destination "C:\CI" -Force
Copy-Item -Path ".\{56B75B7A-06D3-49EF-BCF8-8FC47C6ADA20}.cip" -Destination "C:\CI" -Force
Copy-Item -Path ".\MDAC.ps1" -Destination "C:\CI" -Force
$Time = New-ScheduledTaskTrigger -Once -At 12:00
$User = "SYSTEM"
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ex bypass -file `"C:\CI\MDAC.ps1`""
Register-ScheduledTask -TaskName "CI" -Trigger $Time -User $User -Action $Action -Force
Start-ScheduledTask -TaskName "CI"
Return 0

3. Create a textfile named MDAC.ps1 and add the following content.

Copy-Item -Path "C:\CI\{56B75B7A-06D3-49EF-BCF8-8FC47C6ADA20}.cip" -Destination "C:\Windows\System32\CodeIntegrity\CiPolicies\Active" -Force
Copy-Item -Path "c:\CI\{76300157-42A0-4A2D-A383-AF140D64AAE0}.cip" -Destination "C:\Windows\System32\CodeIntegrity\CiPolicies\Active" -Force
Return 0

4. As we will deploy this using a Win32 app, download the Intune content prep tool and run the following command from the extracted IntuneWinAppUtil.exe.

IntuneWinAppUtil.exe -c C:\MDAC\Source -s SchTask.ps1 -o C:\MDAC

5. Create a new Win32 app in Intune and use the following parameters when adding it:

Program install and uninstall command:
powershell.exe -ExecutionPolicy Bypass .\SchTask.ps1
Running as System.

Detection rules:
Type: File
Path: C:\Windows\System32\CodeIntegrity\CiPolicies\Active
File or folder: {GUID}.cip
Detection method: file or folder exists

6. Assign the app and wait for the MDAC policy to apply. This can be verified by running msinfo32.exe and watching the status for Windows Defender Application Control.

Next steps: Looking at the CSP for Application Control for even smoother deploying via Intune.

Switch to modern patch management and free time to improve security in other areas

It’s a fact that the world is constantly changing and with it we can choose if we want to tag along or continue doing what we’ve been doing forever. This blog post is about shifting the mindset and daily work from traditional patch management and creating time to make efforts in other security related areas that matters. Change management at its finest!

Fundamental idea: We all know that we need Windows patches, and if you have made the move to Office 365 ProPlus the principle is the same, you need to deploy and install the patches that are released. It really is as simple as that. Testing is a must of course but the fact remains, you need those patches.

Traditional vs modern patch management

A discussion I have with many customers is the patching story around Windows 10 devices. The benefits of using Windows Update for Business (WUfB) are many although leaves less control. What matters in the end is that the Windows 10 devices are patched, and that it is done in a user-friendly manner.

If you compare all the components and the flow that needs to be in place for patching to work all the way in ConfigMgr, you realize there are quite a few things that can go wrong. And in my experience, things do go wrong far too often.

High level overview of all the steps and components in the patch flow using ConfigMgr

Rough flow over the steps and components involved when patching via ConfigMgr.

High level flow overview of patching using Windows Update for Business

Simple flow for patching via Windows Update for Business (WUfB).

By looking at the above comparisons it’s clear that there are a lot more to manage and a lot more can and more often so do go wrong when patching via ConfigMgr.

Maintaining and fixing the infrastructure or doing more valuable things?

With ConfigMgr you must spend significant time managing and making sure that infrastructure is up to date and working (orange colored bar below). The green colored bar illustrates how much time you typically spend on patch follow-up and fixing patches that could not be installed correctly etc.

Rough estimation in my experience is that you spend significant time fixing broken ConfigMgr infrastructure and agents etc.

With Windows Update for Business, you can focus almost entirely on follow-up and hopefully by doing so also shifting your security work to other areas patching other stuff such as insecure firmware, applications and drivers, so that it makes your environment safer overall.

With Windows Update for Business, you really have no infrastructure that needs fixing, only some policies basically.

Pros and cons for using Windows Update for Business

Here is my list of pros and cons of using Windows Update for Business, if you are still not convinced Windows Update for Business is the natural way to go.

  • User friendly restart prompts. ConfigMgr isn’t exactly known for its user-unfriendly restart prompts. Using WUfB you get the built-in Windows 10 restart features which gives your end users more control, postponing and picking a time that suits them.
  • Get control over devices away from office network. Many organizations have little, less or no control or possibility to patch devices that are solely on the internet or away from the network office. With WUfB that is not an issue as you can not only patch but also follow-up on each and every Windows device that has a working internet connection.
  • Less error prone = higher patch level. By cutting all the steps and infrastructure components that need to be in place for patching via ConfigMgr you get a higher success rate of patching your Windows 10 devices.
  • Timesaving for IT admins. No more spending time on approving patches and dealing with distribution and install problems. Instead leaves time to focus on other more relevant security work.
  • Fully automatic. Well, you can achieve fully automation in ConfigMgr as well but not many do that as they want to stay in control. With WUfB everything is automatic and only if problems during the multiple testing phases are discovered is the flow paused.
  • Less control. Yes, on the negative side, you lose control as you cannot really choose which Windows patches you deploy. This revolves back to the question which there is typically only one answer to: Do you really need this control as you need to have all Windows (and Office) patches?

Summary

By shifting to modern patch management using Windows Update for Business you can free time and put that time on patching other stuff, for example insecure firmware, applications or device drivers.

You can also focus on activating Windows features that raise security, such as the Windows Defender technologies Exploit Guard and Application Guard, or Microsoft Defender ATP which can take your security work to a level you could only dream of.