With Windows 11, many visual elements have changed, and one of the most noticeable ones is the Start Menu. With a new star menu comes a new way to manage it. With Windows 10, you can control the start menu with an XML file. Now, with Windows 11, you can control it with a JSON file.
What’s extra interesting is that you still control the taskbar with an XML file. If you want to know how to deploy a default taskbar, my blog post, Intune Deploy Default Taskbar, covers how to do that.
There are a few pitfalls when you control the Windows 11 Start Menu. The first one is that users will no longer be able to pin anything extra to the Start Menu.
The option to Pin to Start is no longer available
Another pitfall is that users can technically reorder the applications you pin in the start menu but the next time they log in, it is reset to the layout you defined.
In this post, I will show you step-by-step how to deploy a Windows 11 default Start Menu layout using Microsoft Intune.
Building the Start Layout
On a source system, pin the applications to the start menu in the order you want.
Export the Start Menu layout by running the following PowerShell command Export-StartLayout -path C:\temp\Win11-Start.json
The Company Portal application is a wonderful tool for Microsoft Intune. If you come from the world of ConfigMgr (Microsoft Configuration Manager aka SCCM (System Center Configuration Manager)), it is the Intune version of Software Center.
Company Portal allows users to install programs you publish on the Company Portal. My favorite part is that the users don’t need local admin to install the applications you make available to them.
You can also make Company Portal do more than just install applications for users on demand. For example, it can allow users to factory reset their devices or retrieve their own BitLocker keys.
There are three main ways to deploy the Company Portal on Windows.
Online Company Portal as System-based
Online Company Portal as User-based
Offline Company Portal
The original method for deploying Company Portal was to use the Microsoft Store for Business. At the time two options existed: the Offline Company Portal and the Online Company Portal. The main difference between the two was that the Offline Company Portal could use device-based licensing and could be installed system-based, while the Online Company Portal was user-based.
With the deprecation of the Microsoft Store for Business, the current Microsoft Store was updated with a new method for deploying the Online Company Portal. This method includes system and user based deployments, allowing us to achieve the same results as the old Microsoft Store for Business.
System vs User
A system-based Company Portal deployment makes the most sense when the organization fully owns the device or when items like Windows Autopilot are used.
A user-based Company Portal deployment makes sense when the device is a BYOD setup.
The difference between the two is that the system-based deployment of Company Portal only needs to be done once per system, which can help speed up login times. The user-based deployment needs to install Company Portal for each user that uses the system, which can result in users waiting for Company Portal to install, which can be a pain for shared devices like meeting rooms.
Offline Company Portal
The need for the Offline Company Portal is rare but can still be useful in some situations. Typically the Offline Company Portal is used in situations where the Microsoft Store is disabled or can not be used for various reasons.
What sets the Offline Company Portal apart from the Online Company Portal is that it does not use the Microsoft Store to install itself. Instead, it uses the Microsoft Intune Management Extension. The Offline Company Portal will require manual updates when new versions are released.
In this post, I will show you step-by-step how to deploy the Company Portal for Windows using Microsoft Intune.
Usually, when you want to control the Windows Update settings, you create a GPO to manage the settings or tweak some registry entries. Both methods alter the registry values in the registry key
To reset any custom Windows Update settings, I nuke out that registry key or reverse the GPO or both, and restart the Windows Update service, and everything would be good. However, that process stopped working consistently.
At some point, Microsoft tweaked something, and now there’s a scheduled task named Refresh Group Policy Cache. It’s unclear which update added this to systems, but it impacts Windows 10, Windows 11, and Windows Servers.
What is Refresh Group Policy Cache?
The Refresh Group Policy Cache is a scheduled task in the task scheduler under Microsoft > Windows > WindowsUpdates. It seems to be a custom scheduled task that uses the DLL %systemRoot%\system32\updatepolicy.dll.
Refresh Group Policy Cache scheduled task
I don’t know everything the DLL does but what I do know is that it is a Microsoft DLL, and its internal name is Update Policy Reader. I tried to find more information about it, but there isn’t much, and I’m not good at decompiling DLLs.
I did find the MUI file for the DLL. The MUI has a list of strings that provide an idea of the DLL’s purpose.
100 None<br />101 Set branch readiness level<br />102 Set period to defer Feature Update<br />103 Set period to defer Quality Update<br />104 Enable Update Pause<br />105 Branch readiness level<br />106 Enable Quality Update deferral<br />107 Quality Update deferral period<br />108 Enable Feature Update deferral<br />109 Feature Update deferral period<br />110 Pause Feature Updates<br />111 Pause Quality Updates<br />112 Exclude drivers from Windows Quality Updates<br />113 Start date for pausing Quality Updates<br />114 Start date for pausing Feature Updates<br />115End date for pausing Quality Updates<br />116End date for pausing Feature Updates<br />117 Enable Auto Restart deadline<br />118Auto Restart deadline<br />119Auto Restart deadline for Feature Updates<br />120 Disable check for updates by user<br />121 Enable Active Hours maximum range<br />122 Active Hours maximum range<br />123 Enable the method by which the auto restart required notifications are dismissed<br />124 Dismissal method forauto restart required notifications<br />125 Configures Auto Restart reminder schedule<br />127 Time period for displaying Auto Restart reminder notification<br />128 Turn off Auto Restart notification<br />129 Configure Auto Restart deadline warning notifications schedule<br />130 Time period for displaying Auto Restart deadline reminder notification<br />131 Time period for displaying Auto Restart deadline warning notification<br />133 Enable Auto - restart to Engaged restart transition schedule<br />134 Auto restart to Engaged restart transition schedule<br />135 Engaged restart snooze schedule<br />136 Engaged restart deadline<br />137 Auto restart to Engaged restart transition schedule for Feature Updates<br />138 Engaged restart snooze schedule for Feature Updates<br />139 Engaged restart deadline for Feature Updates<br />140 Enable skipping battery checks for EDU devices<br />141 Allow updates to be downloaded automatically over metered connections<br />142 Do not allow update deferral policies to cause scans against Windows Update<br />143 Disable Pause updates by user<br />144 Enable automatic wake up to install scheduled updates<br />145 Display options for update notifications<br />146 Specifies the number of days before Quality Updates are installed on a device automatically<br />147 Specifies the number of days before Feature Updates are installed on a device automatically<br />148 Allows device to have an additional grace period until restarts occur automatically for Quality Update installation<br />149 Do not attempt to auto reboot device outside of active hours before the deadline is reached<br />150 Target Version for Feature Updates<br />151 This setting specifies that a device that is configured with DeferFeatureUpdatesPeriodInDays or BranchReadinessLevel policies to skip safeguards.<br />152 Allows device to have an additional grace period until restarts occur automatically for Feature Update installation<br />1000 Microsoft Corporation.<br />1001 This task is used to refresh group policy cache in Windows UpdateCode language:Basic(basic)
By playing around, I think I have a basic idea of what the scheduled task is doing. It seems that the Refresh Group Policy Cache scheduled task queries the values in the registry key
What it takes to trigger that scheduled task, I’m not sure.
In my testing, there can only be two cache sets, and only one can be active. The value that controls which cache set is active is the REG_DWORD named ActiveCache. The number defined in the data value indicates which cache will be used.
The active cache in GPCache is CacheSet001
The Issue
The problem with Refresh Group Policy Cache is that sometimes Windows Updates ignores the settings defined in
This issue can impact any system with custom Windows Update settings. Also, it impacts systems imaged with ConfigMgr (Microsoft Configuration Manager aka SCCM (System Center Configuration Manager)) task sequences.
There’s not a lot of information about what happens when an Omnissa Horizon (formerly VMware Horizon) term license expires, specifically what end users will and won’t see.
In this post, I will detail what happens when an Omnissa Horizon Term License expires and the messaging that administrators and end users will see.
Starting with Omnissa Horizon 8 release 2111, all term licenses have a 30-day grace period. During the grace period, everything works normally.
Administrator Messaging
During the 30-day grace period, the Horizon Administrator Console presents an orange banner message to administrators. The message says, “Your license has expired and your service may be disrupted as a result. To renew, contact your sales representative.”
Messaging to administrators when Horizon is expired and the grace period is active
Things become disruptive after the 30-day grace period as end users can no longer use Horizon.
The orange banner message in the Horizon Administrator Console changes to red and now says, “Your license has expired and your service has been disrupted. To renew, contact your sales representative.”
If you browse to Settings > Product Licensing and Usage in the Horizon Administrator Console, you will see that the license has been removed.
Messaging to administrators when Horizon is fully expired
End User Messaging
During the grace period, end users will have no idea that the Horizon license has expired and is in the 30-day grace period. However, after the 30-day grace period ends, the end users will start seeing messages after they log in that Horizon has expired and can’t be used. The exact wording is slightly different depending on which Horizon client they are using.
Palo Alto Networks firewalls often require a device certificate. A device certificate is needed for items like device telemetry and for some of the CDSS (Cloud-Delivered Security Services) items, such as WildFire, DNS and URL filtering, and others.
In this post, I show you step-by-step how to check if a device certificate is installed and how to install a device certificate on a Palo Alto Networks firewall.
Before we proceed with installing the device certificate, we should double-check whether the firewall already has one.
Checking Device Certificate
Log in to the Palo Alto Networks Firewall
CLI
To check if a device certificate is installed, run the following command show device-certificate status
If the result is No device certificate found, move ahead with installing the device certificate.
GUI
Click on Dashboard
The General Information widget will display the Device Certificate Status.
With the GUI, you can also check if a device certificate exists in another place.
Click on the Device tab.
Click on Setup.
The Management tab will have a widget about the Device Certificate.
If there is no device certificate installed, we can move ahead with installing the device certificate.
Installing Device Certificate
Log in to the Palo Alto Networks Customer Support Portal.
Click on Products > Device Certificates.
Under the One Time Password section, click on Generate OTP.
Microsoft recently introduced the public preview of External Authentication Methods in Microsoft Entra ID. I am very excited about External Authentication Methods as they finally allow third-party MFA providers like Cisco Duo to integrate better with Microsoft Entra ID (formerly Microsoft Azure AD).
Microsoft has supported third-party MFA providers for years. The original method for adding external MFA providers is Custom Controls, which was introduced in 2017 as a public preview.
As MFA grew in necessity, the limitations of Custom Controls became apparent. In 2020, Microsoft announced that Custom Controls would not leave public preview but a new solution that addressed its limitations would be created. In May of 2024, the replacement solution External Authentication Methods (EAM) was released as a public preview.
EAM addresses the limitations with Custom Controls, such as satisfying the Multifactor authentication requirement in a conditional access policy rather than using a custom control. EAM is a big deal, as the Entra sign-in logs show Custom Controls as a single-factor authentication when that is not true. I suspect this is because Microsoft has no way of validating whether MFA was completed or not.
Here’s an example of the Entra ID Sign-in logs with Duo using a Custom Control that reports as a Single-factor authentication.
Entra sign-in logs for Duo with custom control grant
If we drill into more details under the Basic info tab, we will still see that the login is reporting as single-factor authentication.
Sign-in log basic info for Duo when using a custom control grant
If we look at the Authentication Details tab, we will see nothing. I suspect this is because Entra has no way of knowing what happened on the Duo side of things, only that Duo said yup this user is good move along.
Sign-in log Authentication Details when Duo uses a custom control grant
If we look at the Conditional Access tab, we finally see that Duo was applied with the custom control and that the result was a success.
Sign-in log conditional access using Duo custom control
The issue of Custom Controls reporting as single-factor authentication in the sign-in logs is resolved with EAM.
Using EAM, we can now directly use third-party MFA solutions like Cisco Duo as an MFA option in Microsoft Entra Authentication methods, allowing us to use the MFA setting in a conditional access policy instead of a custom control. This even allows you to be more granular with the accepted forms of MFA, such as allowing Windows Hello rather than just Duo to grant MFA.
External Authentication Methods is currently in preview. However, everything seems to be working correctly in my testing.
In this post, I will show you step-by-step how to set up Cisco Duo with External Authentication Methods in Microsoft Entra ID.
The Process
Initial Setup
Login to the Duo Admin console.
Click on Applications > Protect an Application
Search for External Authentication Methods and click on Protect beside Microsoft Entra ID: External Authentication Methods.
Click on Authorize to spawn the process for Duo to create the needed Enterprise application in your Microsoft 365 tenant.
Microsoft 365’s Stay signed in option is designed for user convenience but can increase security risks when used on public or non-corporately owned devices. The risk is due to the potential for unauthorized access to the user’s account and the resources they have access to.
The Stay signed in option presented to users
The stay signed in option, also known as KMSI (Keep Me Signed In), stores a cookie on the device for around 90 days when the user selects Yes to KMSI. When the cookie’s lifetime is active, users will see fewer prompts to log in with their Microsoft 365 account and fewer MFA prompts, this can pose a security risk on shared or public devices.
For corporate devices that are Microsoft Entra joined or Microsoft Entra Hybrid joined, the impact of removing the stay signed in option is minimal, as these devices already participate in Microsoft Entra SSO, which reduces the number of times users need to log in with their Microsoft 365 account when accessing Microsoft 365 web resources.
Turning off the stay signed in option in Microsoft 365 can help reduce your attack surface. This helps prevent users from accidentally selecting Yes to KMSI and can positively impact an audit or penetration test.
In this post, I will show you step-by-step how to remove the Stay signed in? option in Microsoft 365.
Palo Alto Networks has this awesome program called the User Identification Agent, aka the User-ID Agent. It allows you to identify which device a user is using, allowing you to craft security policy rules based on the users themselves.
In this post, I will show you step-by-step how to upgrade the Palo Alto Networks User-ID Agent.
Prerequisites
Verify that the new User-ID agent version is compatible with your current PAN-OS.
The User-ID Agent is typically compatible with the same release number along with earlier still-supported PAN-OS versions. For example, User-ID agent 11.0 works with PAN-OS 11.0 and earlier. You can confirm this by reading the OS Compatibility section in the release notes.
The Process
Log in to the Palo Alto Networks Customer Support Portal.
Click on Updates.
Click on Software Updates.
Select the User Identification Agent.
Click on the version you need to start the download.
Connect to the server that is running the Palo Alto User-ID Agent.
Active Directory is very much a database. It even has a schema to define what can and can’t be created and how everything is related and linked. An oversimplification is that the Active Directory schema is the rules about the types of items you can make in Active Directory, and this also includes the available attributes for each item.
Your schema level (or schema version) is not your domain functional level or forest functional level. The schema level doesn’t always match the domain functional level or the forest functional level.
Windows Server 2019 and Windows Server 2022 both operate at the domain and forest functional level of Windows Server 2016. Even though a server running Windows Server 2019 or Windows Server 2022 has a functional level of Windows Server 2016, its schema version is higher than Windows Server 2016.
