Category: Microsoft Intune

Going passwordless should be the goal for anyone who cares about security and preventing identity and cyber attacks. It is possible to be almost 100% passwordless using Microsoft passwordless technologies. However, even if you have moved to not using your password, the password options are still available at Windows sign-in and also within Windows when signed in. It is now possible to reduce the password use in Windows.

New passwordless experience options available in Windows 11

One big step towards truer passwordless experience is to set the policy named EnablePasswordlessExperience. This will give you the following benefits:

• No password sign-in option on the default Windows sign-in screen.
• The primary user of the device sees only non-password sign-in options, and can only sign into the device using:
  • Windows Hello for Business.
  • FIDO2 security keys.
  • Web sign-in, which in turn uses either Temporary Access Pass (TAP) or the Authenticator app.
  • Smart cards.
• No password options within Windows, when for instance elevating as administrator (UAC prompts).
  Note: You can still use runas to elevate with password as well as use the password for a local admin account (such as when using Windows LAPS).
• The password setting option is removed from Settings > Accounts > Sign-in options.

This will mean that once this new setting is enabled, any user who used to use passwords is now much more likely to sign into Windows with anything else than the password. You can find more about this CSP setting at learn.microsoft.com: Authentication Policy CSP – Windows Client Management | Microsoft Learn.

Password credential provider is hidden from certain UI part of Windows

The reason why I say much more likely to sign in with anything else other than password is that the EnablePasswordlessExperience setting means that the password credential provider is only hidden on the Windows “primary user” sign-in screen.

That means that there are a number of ways to still use passwords in Windows, which is for example required to make sure for instance remote support through help desk is still a viable option:

• Clicking Other users on the sign-in screen will allow the user to sign in using a password, as the password credential provider is enabled there.
• Password use is available in Remote Desktop Connections and for web sites in Microsoft Edge.
• Password can be used with runas to elevate with password as well as use the password for local admin accounts (such as when using Windows LAPS
• Password change can still be accessed from Ctrl+Alt+Delete prompt.

Pre-reqs:

Currently, the following operating systems support the new setting EnablePasswordlessExperience:

• Windows 11 22H2 build 22621.2361 + Windows Configuration Update (KB5030509) with “Get the latest updates as soon as they’re available” to On. Reference: Rolling out new features for Windows 11 (22H2) to the Release Preview Channel | Windows Insider Blog
• Windows 11 23H2 build 22631.2361 or later.
• Windows 11 Insider Dev build 23506 or later.
• Windows 11 Insider Canary build 25921 or later.

Configuration

The Enable Passwordless Experience settings are configured via Intune and are available in the Settings Catalog and this is how I recommend that you configure this new feature:

• Enable Passwordless Experience is set to Enabled. This will in practice remove the password credential provider from the aforementioned parts of the Windows UI.

• Enable Web Sign In is set to Enabled. This will show the “globe” as a sign-in option on the sign-in screen and acts as fallback for logging in if Windows Hello for Business sign-in fails, or if an administrator needs to sign into the device.

UI changed when passwordless is enabled

When these two settings are enabled, the password credential provider is removed from some UI elements, as well as introducing the web sign-in “globe” on the sign-in screen.

Sign-in screen

At the sign in screen, this is where we have maybe the most benefit of enabling the passwordless experience. The reason is that the option to sign in using password is gone! This will certainly reduce the use of password to sign in. At the same time you see the globe which can be used to sign in when or if Windows Hello for Business fails.

UAC Elevation Prompt

When trying to elevate as admin, UAC kicks in. With the passwordless experience enabled, you will only see passwordless options + the ability to use any local admin account (with password). This is to make sure that help desk for instance can still help via remote connections. The important thing is that the typical end users cannot choose any password options. Basically, this means that there is no option “Use a different account”.

Extra #1 – Interactive logon: Require Windows Hello for Business or smart card policy

Just to get this new passwordless experience one step further, I tried the good old policy setting Interactive logon: Require Windows Hello for Business or smart card policy to Enabled. The idea was to also prevent circumventing the “Other users” trick and disable password use even there, as well as completely in Windows.

But no, that setting will not allow you to sign in with Web Sign-in (which is working by design) so that means the setting is useless unless you can live with having no “back door” into your computers if authentication fails or there are problems.

Extra #2 – Excluding the password credential provider all together

To really go passwordless already, you can enable the more hardcore passwordless option that has been in Windows 10 and 11 for some time. It is the ExcludedCredentialProvider setting ADMX_CredentialProviders Policy CSP – Windows Client Management | Microsoft Learn.

This means that you can disable the password credential provider all together in Windows, leaving no room to use a password anywhere within Windows. This might sound good at first thought but will likely mean trouble for remote help for instance by help desk staff, as they will not be able to elevate as admin when needed.

Extra #3 – KQL Kusto Query to find out who are signing into Windows using passwords

The following query is something I use all the time, and it lists how many times your users sign into a Windows device using password. This is useful for “smoking out” password use at Windows sign-in but also in general in Microsoft 365, with a slight modification.

SigninLogs
| where Resource == "Microsoft.aadiam" and AppDisplayName == "Windows Sign In"
| extend authenticationMethod_ = tostring(parse_json(AuthenticationDetails)[0].authenticationMethod)
| extend succeeded_ = tostring(parse_json(AuthenticationDetails)[0].succeeded)
| where authenticationMethod_== "Password" and succeeded_ == "true"
| extend authenticationStepDateTime_ = todatetime(tostring(parse_json(AuthenticationDetails)[0].authenticationStepDateTime))
| extend displayName_ = tostring(DeviceDetail.displayName)
| extend trustType_ = tostring(DeviceDetail.trustType)
| extend deviceId_ = tostring(DeviceDetail.deviceId)
| summarize Count = count() by displayName_, Identity

Thanks to Michael Hildebrand for this blog for being a good inspiration on KQL and dashboards in this topic: Azure AD Sign-in Logs + Workbooks = Know Who is Using Windows Hello for Business – Microsoft Community Hub

Extra #4 – Single Sign-On to on-premises resources

When signing into Windows with Windows Hello for Business or security keys, you do not have single-sign on to on-premises resources such as file shares, printers or applications. By enabling Azure AD Kerberos you enable single sign-on using security keys and by settings an Intune setting to use Windows Hello for Business Cloud Trust, you enable single sign-on using Windows Hello for Business.

Summary

The Enable Passwordless Experience that has been added to Windows 11 is a great step in the right direction of becoming fully passwordless, at the same time as not interfering with remote help and support. Anything that can be done to reduce the use of passwords is simply great!

Sidenote: If you use security keys with multiple identities, you have probably learned that when trying to sign into Windows it will sign you in with the last written identity on the security key. If you like me want to be able to choose which identity to sign in with, please upvote this Windows Feedback item!

Smart App Control is a new feature in Windows 11 22H2 that allows only certain trusted, verified and reputable executables, DLL files and MSI installers to run. Anything not trusted will be blocked from running. This leaves us with a very high security posture.

Microsoft says this feature is intended for consumers and small businesses – and recommends larger organizations and enterprises to use Defender Application Control, which uses the same technology in the background, and has been available since the launch of Windows 10.

This blog post covers Smart App Control versus Defender Application Control in a cloud-native world, where Windows devices are connected only to Azure AD and Intune.

Background

One thing to start with – forget AppLocker as it is too weak and has too many flaws. We need something more secure that also includes anything running on the machine, regardless of user space vs kernel space and also applies to local administrators. At the same time, it must be hard to circumvent which is true for both Smart App Control and Application Control. AppLocker is too easy to circumvent, for instance by using a trusted process by AppLocker to load a malicious DLL file. See a number of examples on AppLocker bypasses here.

High-level overview

Goal is to set On (Block) mode, but first Evaluation (Audit) mode

Whenever enabling a technology that will effectively block stuff, it is highly recommended to first assess the situation obtaining intel about what would happen if we set a feature like this in On or Block mode.

So, our goal is without a doubt to first audit and collect information that we can use to evaluate how enabling either Smart App Control or Application Control in block would work. This is the focus to come, when we look at options on enabling audit/evaluation mode.

At the same time, we need to weigh in that running in audit mode gives us no raised security, it will only collect information. The sooner we can enable Block or On mode, the better.

Options to enable via Intune

¹ Registry value to configure Smart App Control is found in HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy. The DWORD value named VerifiedAndReputablePolicyState can be set to 0 = Off, 1 = On or 2 = Evaluation.

AppLocker CSP vs ApplicationControl CSP

The big difference is that the AppLocker CSP always requires a forced reboot, which means we cannot use it in practice when doing Autopilot and using the Enrollment Status Page. That leaves us with manual configuration of Application Control via ApplicationControl CSP, which is the most secure option where you are in total control. The only problem is that this involves many manual steps, and this surely needs a user interface (in Intune).

“WDAC policy deployment via the AppLocker CSP will continue to be supported, all new feature work will be done in the ApplicationControl CSP only”

https://learn.microsoft.com/en-us/windows/client-management/mdm/applicationcontrol-csp?source=recommendations

Example policies and check if policy is applied

You can check what policies are applied, if any on your computers, by looking at two places in the file system. If only one single policy is applied, which is the case if using Application Control with AppLocker CSP, it will be found in the below directory and names SIPolicy.p7b:

C:\Windows\System32\CodeIntegrity\CIPolicies

However, if multiple policies are applied, which is the case if you applied Smart App Control or using ApplicationControl CSP with base and supplemental policies, they will be found in:

C:\Windows\System32\CodeIntegrity\CIPolicies\Active

You can also start msinfo32.exe and see the current configuration.

Analyzing potential impact of Smart App Control or Application Control

Regardless of if you enable Smart App Control in Evaluation mode or Application Control in audit mode, you can and must follow-up in Microsoft 365 Defender portal (https://security.microsoft.com). This is where you find everything you need to get an overview of the current situation.

Timeline

If you go to a specific device in the Defender portal (https://security.microsoft.com), you can explicitly see the actions by Application Control (and Smart App Control).

KQL – Advanced hunting

To be able to get the big picture in a larger organization we need to use advanced hunting to get all the information we can about the audit events.

Smart App Control or Application Control in Evaluation / Audit mode

Use the following KQL query to list everything that would be blocked if switching the Smart App Control to On or Application Control policy to Block mode.

DeviceEvents
| where ActionType == "AppControlCodeIntegrityPolicyAudited"

Smart App Control or Application Control in On / Block mode

Use the following KQL query to list everything that is noticed by users that is blocked when running in On or Block mode.

DeviceEvents
| where ActionType == "AppControlCodeIntegrityPolicyBlocked"

To execute these KQL queries, head over to security.microsoft.com and go to Hunting > Advanced hunting and run the query and note the results, see below example:

Getting from audit / evaluation mode to Block / On

Getting from Evaluation mode to On when using Smart App Control is technically easy – but the limitation is that you cannot create any exceptions if necessary. This basically means that you will be forced to live with some things being blocked, provide other means of delivering that app such as via Cloud PC, or simply disabling Smart App Control. In the best of worlds, having Smart App Control in On mode from day 1, let it be only for some or almost all devices is a huge security gain.

Getting from Audit mode to Block for Application Control requires some work as you will have to create the baseline policies and test, test and test before deploying full scale.

Something to note here as well is that when using Application Control, it is a strong recommendation to have the policies signed with a code signing certificate to provide the best security, i.e. protect the policy or policies from tampering by users or administrators. The code signing recommendation also adds some complexity to the process and routines around handling the signing itself.

Summary

I agree with Microsoft that Smart App Control is limited when it comes to exceptions and that Application Control is the superior technology to use. However, as it looks right now, there are no shortcuts to using Application Control and for most organizations, the threshold to pass to get to a block mode today is extensive and very time-consuming. At the same time, there are technical implementations that break most Autopilot scenarios which is not OK to step aside from.

What I really like about Smart App Control is that you get it for free when fresh installing or obtaining Windows 11 22H2 machines, having the ability to easily turn on the protection mechanism that will truly protect your devices. And you can start monitoring from day 1, and with minimum effort easily enable the protection mechanism.

The big drawback of Smart App Control is that you cannot make any exceptions if something is blocked and you want to allow it, that is very obvious. In this scenario you would have to disable Smart App Control or present the application to the users in another way, via for instance Azure Virtual Desktop where you could publish the application as a remote application.

So, what Microsoft should provide are the tools that will help IT departments to enable Application Control. There must be an easy way via Intune to 1) making sure we have an easy way of defining the Intune agent to become a managed installer and 2) making it easy to create a great baseline policy, and 3) making it easy to create supplemental policies whenever something needs to be allowed (as an option to deploying the binary via the Intune agent).

I think this is a really interesting case and although Hybrid Azure AD Join is something I am not recommending over Azure AD Join, sometimes there are circumstances that leads to no other choice but to adjust and make the best out of the situation and plan for a better solution more long-term.

Current situation and scenario goal

The mission is to enroll all Windows devices (shared and Hybrid Azure AD Joined) to Intune and the specifications are as below:

• Windows 10 and 11 Enterprise 21H2 (or 22H2) computers which are Hybrid Azure AD Joined.
• The devices are used as shared computers, so there are no primary users of these devices.
• Intune licenses are device based, not user based which is the typical and most common scenario.
• Microsoft Endpoint Manager Configuration Manager is NOT used.

The million-dollar question is how these shared computers can be enrolled into Intune automatically? The scenario must cover both enrolling newly deployed computers as well as existing computers. The solution must be fully automated i.e., no manual steps must exist in the process.

Note: The typical GPO to enable MDM automatic enrollment via user credential cannot be used as the users do not have Intune licenses.

Potential solutions

My thoughts on how to come to a solution came pretty much in this order, and turns out to be a real challenge

1. Use “Device Credential” in the GPO “Enable automatic MDM enrollment…”

The GPO “Enable automatic MDM enrollment using default Azure AD credentials” got a new option some years ago and can be set to “device credential” instead of the default “user credential”. Sounds like the perfect solution!

Problem: Error code 0x80180001 in the event logs “Device based token is not supported to enrollment type OnPremiseGroup PolicyCoManaged”. It turns out that this setting is only supported using MEMCM/SCCM or Azure Virtual Desktop, and obviously blocked or not meeting the technical requirements on other machines.

2. Autopilot self-deploying mode profile

That was a good idea although self-deploying profiles cannot be used as it supports only Azure AD Join and not Hybrid Azure AD Join.

3. Provisioning package – Only enrollment

Using a provisioning package (PPKG) you could potentially enroll into an MDM solution (such as Intune) using Workplace/Enrollment settings as noted in Bulk enrollment – Windows Client Management | Microsoft Docs. However, “username and password security type not supported”. However, this enrollment seems to primarily be targeted and intended for third party MDM solutions or the now long gong feature to enroll into on-premises MDM in Configuration Manager, not Intune. Or did anyone succeed in enrolling into Intune this way? If so, please ping me!

4. Provisioning package – Using bulk enrollment token

Although this way is typically used for performing Azure AD Join + automatic Intune enrollment using a Device Enrollment Manager (DEM) account, I thought I’d try it out to see what happens as I never tried this on a Hybrid Azure AD Joined computer.

Well after obtaining the bulk enrollment token through the simple wizard in Windows Imaging and Configuration Designer, I switched to advanced mode and got rid of everything from the provisioning package apart from the Azure/bulk enrollment token parts.

I then ran the provisioning package on my target test machine and the enrollment seem to have worked. Although, it resulted in another device object in Azure AD, and it successfully enrolled into Intune.

Hmm, not ideal but a big step in the right direction. Another question or thought is that even though this works technically, how far from being a supported is this scenario? Intune-device based licensing supports DEM accounts as enrollment type as per Licenses available for Microsoft Intune | Microsoft Docs, and the bulk enrollment is supported as well as per Enroll devices using a device enrollment manager account – Microsoft Intune | Microsoft Docs.

Next steps and summary

Well, automating the application of PPKG from step 4 above as part of the deployment process is easy, it needs some additional checks though as the provisioning package must only be run after the successful Hybrid Azure AD Join has taken place, otherwise I see this will fail. Not optimal and requires more testing, and even if this would work the scenario is a true corner-case!

Going back to Autopilot self-deploying mode seems a lot easier, so let’s evaluate what needs to be in place for this to become reality, overcoming the hurdles!

By connecting your Windows devices solely to Azure AD and Intune you will improve the work lives of for your users and make it easier for you in IT to manage the platform during the device lifecycle.

Windows devices in the future are no longer connected to a traditional Active Directory, and they are not managed by Configuration Manager or other on-premises management tools, and not with Group Policies. The Windows devices of the future are independent of your datacenter which means IT can focus on improving availability of the resources the end users are dependent on in their daily work, which are applications, tools, and information.

End user experience and challenges today

Are you and your end users sick and tired of the fact that starting and logging into Windows takes several minutes? One common cause for this is a legacy of many years of GPOs and scripts that are executed at start and logon.

Do your end users still need to come into the office network to get all updates, configuration or changing password? This is something that becomes a non-issue in the cloud-only world. Even though these types of needs have decreased because of the pandemic I still see and hear about this too often.

Improving end user experience and simplifying are the keywords

The reasons of going cloud-only on your Windows devices are very much about significantly improving your end user experience, and at the same time making it easier to manage for you in IT. To continue doing what many organizations are doing today, i.e., managing Windows with existing on-premises AD and GPOs, running devices in Hybrid Azure AD Join state plus adding co-management and Intune just makes your life in IT more complex and harder, and give your end-users very few benefits to be honest. Everyone would gain from letting go of on-prem AD and traditional managing software such as Configuration Manager.

Microsoft recommends going cloud-only and not staying in hybrid mode

The fact is that Microsoft is recommending the hybrid scenario only as an interim solution for existing devices. For new devices Microsoft are very clear that they recommend cloud-only devices.

Keep in mind that while Microsoft fully supports hybrid Azure AD join, we designed this capability as an interim solution for existing endpoints. We strongly encourage customers to begin their planning and implementation of full Azure AD-joined systems as soon as possible.

Source(s): Success with remote Windows Autopilot and hybrid Azure Active Directory join – Microsoft Tech Community and Planning for cloud-native Windows endpoints and modern management – Microsoft Tech Community

The most common myth killed once and for all – access to on-premises resources

The fact is that most organizations still have, and will have for many years to come, user resources in their datacenter on-premises. How do users get access to file share, printers, and applications on-premises when the Windows device is only in the cloud? With Windows Hello for Business Cloud Trust or FIDO2 security keys, this has never been easier to setup and enable!

Pros for cloud-only Windows devices

• Performance and user experience. Microsoft’s former corporate vice president for Microsoft 365, Brad Anderson, compared his iPhone to a cloud-only Windows device s few years ago. The Windows device started and became usable faster than an iPhone. That is a notable example that still is valid. Mobility, speed, and battery life is something the users really appreciate.
• Reduced complexity. What I see is that customers that are running in the hybrid scenario has a complex day-to-day life in IT, in terms of managing and troubleshooting. You have two environments to take into consideration all the time which makes things sometimes twice as hard or take more time than it should to achieve the goal at hand.
• More time for valuable work. How much time do IT spend on keeping the basic infrastructure working? By that I mean specially Configuration Manager which always have had problems with agents, driver packages becoming corrupt after working for years etc. I have through my years spent too much time on just keeping things at a working level, it is time to bury Configuration Manager and spend this time on more valuable work such as follow-up and proactiveness.
• Get rid of your legacy. Most organizations have over the years migrated to a number of Windows client platforms, from Windows 2000, XP, Windows 7, to Windows 10 and soon Windows 11. What most organizations have in common is that the same GPOs and scripts are still being applied although first configured 15 years ago, even though some policies have been cleaned out through all migrations. Switching to cloud-only is the perfect fresh start of getting rid of all your legacy stuff and start building on something new!

Cons for cloud-only Windows devices

• Not for everyone. Being able to utilize Microsoft cloud services is a pre-req of course. To be honest, there are more challenges that could block an organization from going cloud-only. Things such as 802.1x can be a challenge and specific requirements around security another. The point is, if you do not even try you will not know what to solve or what Microsoft will eventually deliver in their product and services to solve your blocker. Adding cloud-only Windows devices to your roadmap and work on dependencies is essential in making progress.

How to get started?

So how do you get started? In its simplest form, start with Autopiloting (Azure AD Join + Intune) the device and then perform all your day-to-day work on a cloud-only Windows PC. After that start solving the challenges that you face, creating a configuration baseline and deploying applications that you need. Some challenges will be harder to pass than others, and some might be blockers. The point is, without starting your journey toward a future cloud-only future Windows device you will not know what to fix and what to talk to for instance the network team about.

Microsoft has a good starting point at Get started with cloud native Windows endpoints – Microsoft Endpoint Manager | Microsoft Docs.

Summary

To summarize, the future is to have your Windows devices connected cloud-only Azure AD and Intune. That has great advantages for end-users as well as IT. The fact that Microsoft themselves are living by this already, and the fact that they point customers towards this direction and in combination with all benefits should make this decision easy.

I’ve seen this problem with a couple of customers now that is using Windows Update for Business, when some machines were not offered Windows 10 20H1 (May 2020 update a.k.a. version 2004) nor Windows 10 20H2 although no policies should block it. Note: This also applies to Windows 11 feature upgrades.

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 expiration date occurs.

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.

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.

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.

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

High level flow overview of patching using Windows Update for Business

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.

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.

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.

As with all new Windows 10 releases, there are a bunch of new features and bells and whistles. To the business and end-users this can mean great benefits. Here are the business values of upgrading to Windows 10 version 1903 (also referred to as 19H1), from a business, security and IT perspective.

Note: Windows 10 v1903 / 19H1 is not yet released, the features exist only in current Insider builds, which are possible to try out if you opt your organization into Windows Insider for Business.

The business case

By deploying the Windows 10 v1903/19H1 update your organization can:

• Save many minutes for each user in your entire organization
  Potentially you can save a few minutes times the X number of users per month in your organization, when your Windows devices are updated with new Windows updates. This is possible as the user login is done automatically after restart (with the screen locked of course), meaning your end users do not have to stare at the login screen waiting to start LOB apps.
• End-user improvements for finding relevant resources
  Chrome integration with Timeline feature is added and improvements to searching and finding stuff is improved. This means that users can find relevant resources they are working on or have worked on faster than before. 
• Reduction in help desk calls
  With the new features added in Windows 10 v1903/19H1 you can see a reduction of ~5%* or more help desk incidents and support calls. This is thanks to automated troubleshooters, disk space reservation changes and fixes that previously caused help desk calls.

Let’s break this down and go into more details!

Increase in user productivity

There are several new features and design changes that will increase user productivity.

• Automatic sign-on after restart and updating saves many minutes!
  This time-saving feature is to this date only available for cloud-only domain joined Windows 10 devices, not domain joined, nor Hybrid Azure AD joined (although GPO configuration tend to state otherwise). What it means is that the end-user will save many minutes after each update and restart!
  The requirements for this is (except for cloud domain joined Windows 10 device): BitLocker enabled which is not suspended during upgrade, which in itself requires a TPM 2.0 chip and Secure Boot to be enabled.
• Chrome Timeline extension
  The Timeline was introduced in Windows 10 v1803 and is a great way for the user to have all history of documents you worked on, sites you browsed etc. within a few clicks! With the Chrome Timeline extension (named Web Activities), the end-user will also see browsing history from Chrome in their Timeline.
• Enhanced search and indexing
  The search feature in Windows 10 v1903/19H1 is now listing top used apps and recent activities (i.e. opened documents) providing easier and quicker access to recently used files and apps. At the same time, for power users, there is now an option to index the entire C: drive and not only what is available in the user data folder. The settings for this are found in Settings > Search > Searching Windows.
• Restart without updating or upgrading 
  This feature has come and gone over the Windows 10 lifetime, but now it works as expected. Whenever a quality update or a feature update is installed, the user can now choose to shut down or restart without having to be forced to install the update. This is a real time-saver and can save the user quite some time and hassle as a forced updating of the device now has become optional.
• Windows Light Theme
  This is not really something you can consider time or cost-saving but has the potential to really impact the end user. For the first time since Windows 10 launched in 2015, there is a new theme that means a better user experience if you prefer light colors and not dark. Switch to the Windows Light Theme by going to Settings > Personalization > Colors and choose Light in the drop down.

Reduction in support costs

Microsoft are adding new feature and have made design changes that will reduce support for Windows 10 starting with Windows 10 v1903/19H1.

• Automated troubleshooters
  Ever since Windows 7 there are built in troubleshooters which can be used to ease the troubleshooting of Windows problems. Starting with Windows 10 v1903/19H1, Windows has the possibility to detect problems and prompt to run troubleshooters to fix problems, instead of the user having to call help desk.
• WWAN connections for built-in SIM improvements
  If you have devices with built-in SIMs, now this works much more stable than ever. First, there has been a problem with if the connection is lost, it was impossible to re-connect without disabling the device from Device Manager. Now, if the connection is lost you can simply re-connect as expected. Another important change is that now you can via the UI change the WWAN connection to not be metered network, meaning everything will from an end-user perspective work as usual (thus with the impact that it will generate more data).
• Reserved disk space minimizing problems
  With Windows as a Service it is imperative that the Windows device has enough disk space. With Windows 10 v1903/19H1 Microsoft has made the decision to reverse 7GB to be able to update itself. I think everyone can agree that a Windows device with 0 bytes left on the disk will with 100% certainty result in a help desk incident. This decision by Microsoft will not only reduce general support calls due to “out of disk space” issues, but also raise the possibilities that updates go well, which also reduces work load for IT.

Security

As with all new Windows 10 release, Windows 10 v1903/19H1 is no different. Security is a baseline pillar of the modern desktop and modern workplace, and with modern threats you cannot overlook this. Here are a couple of 

• Complete secure browser experience, with Chrome, Edge and IE11
  Windows Defender Application Guard (WDAG) has been available for a few versions now and really provides a super secure browsing environment. As many organizations use Chrome (and some Firefox), now you can “tie up the sack” so to say and make sure that Chrome and Firefox also adhere to WDAG, using the WDAG extension for Chrome and Firefox. This way, you can use IE11 for the old legacy web apps, while using Chrome or Firefox for other internal or external apps and then Edge for creating an extremely secure browsing experience on the web. Of course, you can use only Edge and IE11 together as well, but many users tend to want to use Chrome after all. The dependency for using WDAG with Chrome and Firefox is to use the Windows Defender Application Guard Companion app (this is not needed if only using Edge and IE11).
• Protection history for Windows Defender Exploit Guard features etc.
  Having history of protections for antivirus is something everyone expects and have solutions for, but what I want to highlight is that now you can find Exploit Guard protections here as well, meaning you can follow-up on actions related to Controlled Folders and Attack Surface Reduction. Go to Windows Security > Virus & threat protection > Protection history to find the history.

For IT

• Windows Sandbox
  The Windows Sandbox is a container solution where you quickly can get an isolated Windows 10 instance running, for testing stuff out. The use cases for this solution becomes a lot more when you consider there are config file possibilities!
• A bunch of new MDM possibilities…
  Many new MDM policies are added, and to be more precise 70** MDM settings are new for Windows 10 v1903/19H1. A few of them are listed in Changes in MDM enrollment documentation. You can also see all possible settings by taking an MDM enrolled device, go to Settings > Accounts > Access work or school > <click your join and then click the Info button> > Export results, and look at the last section which lists all possible settings which can then be referenced and investigated for options.
• …as well as new GPO settings
  In general we don’t see as many GPO settings added as MDM settings to each new Windows release, but some new GPO settings are for Storage Sense and Specifying deadlines for Windows Update restarts after quality or feature updates have been installed. 

Modern management and deployment

Note: The below is not related nor dependent on Windows 10 v1903/19H1 release and applies to previous Windows versions as well.

• Some highlights of Intune improvements since last Windows release:
  • BitLocker encryption status and TPM version reports.
  • Win32 app deployment feature is now General Availability – plus troubleshooting possibilities are added.
  • Rename a device from the Intune console – pushed to the device.
  • Security baselines so that you can secure your Windows devices easily.
  • ADMX templates adding some additional hundreds of settings that you can configure on your Windows devices!

Summary

With the changed support statement detailed by Microsoft last summer, many organizations decided to skip the spring releases and only deploy the fall releases of Windows 10.

With the above I think you have a good understanding on how your organization can benefit of deploying Windows 10 v1903/19H1 in many ways, and you can make a qualified decision on whether or not you will deploy the spring/H1 release of Windows 10. 

—————————————

Foot note:

* Very rough estimation based on my soon four year-experience with Windows 10 in multiple organizations.
** Based on Insider build 18356 compared to Windows 10 v1809. This number can change.