I always use English (en-US) installation media for Windows and have always had that as a preferred choice as I prefer to run Windows in English. Many customers do that as well. The problem with that is that every time a device is reset or freshly installed via the Autopilot flow, it will result in multiple keyboard layouts, as it will have English layout and then also the Swedish keyboard layout in my cases.
It is annoying to have these multiple choices of keyboard layouts as sometimes, and when you least expect it, it defaults back to English keyboard layout which is annoying. Plus, and although it is not a big deal, it is also nice to get rid of the UI elements in the system tray by resolving this finally.
Physically, I will always only have a Swedish keyboard so that is the only keyboard layout I want!
PowerShell to the rescue
There are some PowerShell cmdlets in Windows 11 (and Windows Server) to help you manage the situation, because honestly, the Language & region settings page in Windows is quite messy. The below cmdlet will get you results that show your current situation:
PowerShell
Get-WinUserLanguageList
To make sure that you get only the keyboard layout you want (sv-SE i.e., Swedish for example), this is the command:
PowerShell
Set-WinUserLanguageList sv-SE -Force
Depending on what language packs you have on the device, it might switch the Windows Display Language to that language and to prevent that, use this cmdlet:
This is a collection of aka.ms links that takes you straight to great Windows admin resources, which includes Windows, Cloud PC, Azure Virtual Desktop, Surface, and of course Intune. Enjoy! Use these links to quickly browse to more or less everyday admin tasks to save time.
This link guides you to enable Entra Kerberos for single-sign on to on-premises resources with modern authentication (passkeys and Windows Hello for Business).
Microsoft Defender for Endpoints Configuration Analyzer tool
Direct link to download the tool that let you check the configuration of Microsoft Defender for Endpoints agent on your Windows devices. More about the tool at Microsoft Learn.
This link takes you straight to the Windows Update for Business reports, which are actually not hosted inside Intune but in Azure > Monitor > Workbooks > Windows Update for Business report.
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.
Application
Automatically restarted
Unsaved data restored
Manual activation of “Register this program for restart” *
Adobe Acrobat Reader
❌
–
Application restarted but files do not re-open and thereby no data is restored (for instance in PDF forms).
Adobe Photoshop
❌
–
Application restarted but does not remember open file.
GitHub Desktop
❌
–
Application not restarted.
Google Chrome
✅
N/A
N/A
Microsoft 365 Apps (Outlook, Word, Excel, OneNote etc.)
✅
✅ (partly Microsoft 365 Apps feature)
N/A
Microsoft Edge
✅
N/A
N/A
Microsoft Notepad
✅
✅ (Notepad feature)
N/A
Microsoft Paint
✅
✅
N/A
Microsoft PowerShell ISE
✅
✅ (PowerShell ISE feature)
N/A
Microsoft Registry Editor
✅
N/A
N/A
Mozilla Firefox
✅
N/A
N/A
Outlook (new)
✅
✅
N/A
Spotify (Store app)
✅
N/A
N/A
WhatsApp (Store app)
✅
N/A
N/A
Wireshark
❌
–
Application restarted but does not remember unsaved state.
Visual Studio Code
❌
–
Application restarted and data restored.
VLC Player (MSI install)
❌
–
Application restarted but does not remember open file.
Zoom Workplace
❌
–
Application restarted.
* 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):
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.
“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:
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.
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 inand 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:
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
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.
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
Smart App Control
Application Control
Target audience
Consumers and small businesses.
Organizations and enterprises.
Modes
On (Block), Evaluation (Audit), Off.
Audit or Block mode.
Exceptions
No exceptions possible – you are 100% in hands of Microsoft control and deciding what is trusted and reputable.
You can create exceptions; however, it involves a certain amount of administration and manual work.
Enablement
Only for fresh deployment/installations, or resets of Windows 11 22H2.
Any given time – whenever you choose to deploy it.
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
Smart App Control
Application Control (AppLocker CSP)
Application Control (ApplicationControl CSP)
Technology
Registry value1.
Endpoint Protection configuration profile (uses AppLocker CSP in background).
Using Custom OMA-URI configuration profile using ApplicationControl CSP.
Default Allow policy in Audit or Block mode. “Optional” to use Intelligent Security Graph (reputable binaries), but if you want it to work and not block you from working you MUST use Intelligent Security Graph.
Custom policy which might contain any number and type of rules, including Intelligent Security Graph.
Managed installer
No, not available.
No, not available.
Yes, this is possible. You can set Intune agent as Managed Installer to trust everything that comes through Intune. However, Managed Installer can only be applied via a custom created AppLocker XML file which must be applied with an AppLocker PowerShell command, plus the Application Control must use option 13 which is the “Managed Installer” enable switch.
Reboot
No, not when applied but requires a reboot to take effect.
When applied it forces a reboot of the computer, both in audit and block mode. This breaks ESP (Enrollment Status Page) when using Autopilot.
No, not when applied, but needs a restart to take effect (unless you specify option 16 when creating the policy).
1 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”
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:
You can also start msinfo32.exe and see the current configuration.
Caption from msinfo32.exe
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).
Device timeline showing block actions for this particular device.
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:
Blocked actions, i.e. files that were prevented from being executed.
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.
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.
Running a PPKG using Bulk Enrollment token on an already Hybrid Azure AD Joined Windows device – this is the result in Azure AD!
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.
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.
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:
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
You package a line of business application in MSIX format. I use a couple of versions of 7-Zip in my testing.
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.
Now package a new version of the line of business app.
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.
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
OneDrive not starting at all, leaving a crash reference in Event Viewer with reference to PayloadRestrictions.dll.
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.
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.
You must be logged in to post a comment.