Category: Microsoft Intune

The Windows features I am covering in this article will give the following end-user benefits.

• Improved user experience by:
  • having the applications that were open prior to restart automatically opened again after restart.
  • increasing productivity by letting the users continue their work instantly after having their device Windows patched.
• Reducing the risk of data loss in applications in case of (unexpected) device restart.

Introduction to restartable applications

Windows 11 (and Windows 10) offers a feature that allows users to automatically restart apps and start them automatically when they sign back in after a device restarts. This will enhance productivity by ensuring that users can quickly resume their work after a restart, and also get back potentially unsaved data in some applications.

Examples of some of the most common and popular applications

The below table lists which applications that by default are automatically restarted when you enable the setting “Automatically save my restartable apps and restart them then I sign back in”. The rightmost column is a note if you manually enable each application to “survive” a device restart and what the user experience is in that scenario.

* Right click an EXE file and choose Compatibility and then check Register this program for restart.

Although some applications have their own mechanisms to recover data after an application is “killed”, enabling the setting to re-launch to some extent increases the chances of recovering and saving the data that was worked on.

The settings are found under Accounts > Sign-in options

For manual testing and verification, the settings in focus of this blog post is found in Settings > Accounts > Sign-in options.

Configure “Automatically save my restartable apps and restart them then I sign back in” via Intune

Configuring this setting centrally via Intune ensures that all users in an organization benefit from this feature without needing to configure it manually.

Create the following as a PowerShell script and via Intune push out as a Script (make sure it is deployed in user context as it will write to HKEY_CURRENT_USER):

$Path = "HKCU:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
$Name = "RestartApps"
$Type = "DWORD"
$Value = "1"
Set-ItemProperty -Path $Path -Name $Name -Value $Value -Type $Type

Additional user experience improvement with enabling Automatic Sign-in after Windows patching

ARSO (Automatic Restart Sign-On) has been around for many years but is unknown to most Windows users and admins. This feature basically means that whenever you have installed Windows patches and the device reboots, the currently logged in user’s credentials will (securely) be used to automatically log the user in after reboot, while locking the screen.

The user experience gained is obvious. Whenever patch reboot happens, many users tend to perform other tasks or simply take a coffee. When ARSO is enabled and the user gets back, he or she will not have to wait for everything to load before being able to use the device and can start working instantly.

This feature in combination with enabling “Automatically save my restartable apps and restart them then I sign back in” makes the user experience even so much better.

Configure Automatic Restart Sign-On via Intune

The Automatic Restart Sign-On settings are available as a Settings catalog in the two settings:

• Configure the mode of automatically signing in and locking last interactive user after a restart or cold boot.
• Sign-in and lock last interactive user automatically after a restart.

Note: The sub-setting “Configure the mode of automatically signing in and locking last interactive user after a restart or cold boot (Devices)” will enable you to use this mode only if BitLocker is in Enabled state.

More information about this: Winlogon automatic restart sign-on (ARSO) | Microsoft Learn

“Automatically save my restartable apps and restart them then I sign back in” the equivalent to “shutdown /g“

The shutdown command has a “new” switch which is the /g switch:

Additional information and details on “Register this program for restart”

Let’s say you want an application to automatically start again after reboot, if it was running when the device was restarted, you can use central tools to push this out to all devices. What you need:

1. Windows ADK, Download and install the Windows ADK | Microsoft Learn and specifically “Application Compatibility Tools” within Windows ADK.
2. Using Compatibility Administrator (32 och 64-bit depending on what application architecture you are building the compat fix for). You can per EXE use “RegisterAppRestart” which is the equivalent to checking this on an EXE file by going to Properties > Compatibility.
3. Distribute the database/compatibility shim and apply it using the good old sdbinst.exe command.

Security concerns?

In everything we do in IT configuration management today, we should think about how this potentially impacts our security posture. There are no exceptions to this, so let’s see what the implications can be by enabling these two features:

Automatically save my restartable apps and restart them then I sign back in

Enabling this feature could pose as a risk as being used by malicious persons to achieve persistence on a device. Similar examples are available in the MITRE framework, Persistence, Tactic TA0003 – Enterprise | MITRE ATT&CK® . Always do your own assessment.

Sign-in and lock last interactive user automatically after a restart

User credentials are stored on disk temporarily so could be a concern. Microsoft have some security recommendations in their ARSO documentation, but like I mentioned, do your own assessment. Yes, any device can potentially be stolen. Does this mean that ARSO increase the risks of compromise or not, or make the device or credentials easier to compromise? In case of stolen device, there are other concerns, assumptions and measures you would take action on so back to the question, do ARSO increase the risk of compromise? Not necessarily! As always, using BitLocker with PIN will mitigate quite a few attack vectors.

Summary

Enabling Automatically save my restartable apps and restart them then I sign back in and Sign-in and lock last interactive user automatically after a restart will save time for everyone using a Windows device and at the same time it will reduce the risks of data loss. Now, if only more applications could support it.

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.