[23h2] Windows 11 Intune Woes - User Policies

[Westie1010]

Hi All,

 

Not sure where else to post, but I think I'm going to get the 'welcome to the club' reply as I think this is just the nature of Intune.

 

Whilst I love the concept of being able to cloud manage devices, I've noticed User Policies are inconsistent at best. Some will apply immediately, some will apply after 15 minutes and a second logon. For teachers and admin staff this is less of a concern, typically their devices will be 1:1 and once they have their policies they're sorted, assigning a primary user (I believe) will preconfigure that user to that device. My concern is student machines, with shared suites (no 1:1 scheme) it's rare students will login to the same machine twice so it's safe to assume a fresh login each time. Whilst they're standard users I'm still concerned with their ability to essentially run rampant on machines until policies are applied.

 

What could be some potential resolutions? I've considered looking into co-management but I'd like to steer away from SCCM where possible (That's a beast too intimidating to tame haha). Is it possible to have an AD Hybrid-joined environment where I could potentially use GPOs for user policies? Or am I asking for trouble?

 

Maybe it's best to stick with On Premise after all....

[foofighterjim]

Best to avoid user level policies on Intune for this very reason, especially in Education, where you need certain things locking down instantly. Simply put, it only really works at device level, so have "staff" devices and "student" devices.

[MYK-IT]

Yep, that's Intune.

 

We originally tried to go full Intune MDM few years back to manage all our devices (Hybrid & Azure AD) but soon realised that settings don't apply straight away - which would be problematic for shared devices. More so for (shared) devices where staff/student could log in.

 

So we did a combination of assigning / configuring Staff-only, Student-only & Shared-Devices and then worked through all our existing (GPO) settings sorting out which could be applied globally at device level (e.g. Intune Device Configuration etc) and which to apply instantly upon login (e.g. Local GPOs). Being very careful not to replicate or create conflicting settings etc.

 

As we move over to more 1:1 devices, naturally this will shift (more to Intune) but in the meantime this is a workable balance with our Hybrid AD Devices.

Edited June 11, 2024 by MYK-IT

[Westie1010]

Best to avoid user level policies on Intune for this very reason, especially in Education, where you need certain things locking down instantly. Simply put, it only really works at device level, so have "staff" devices and "student" devices.

How are you handling user policies such as Start Menu/Taskbar, Desktop Wallpapers, Control Panel / Settings at a device level? Scripts or anything like that?

Edited June 11, 2024 by Westie1010

[Westie1010]

So we did a combination of assigning / configuring Staff-only, Student-only & Shared-Devices and then worked through all our existing (GPO) settings sorting out which could be applied globally at device level (e.g. Intune Device Configuration etc) and which to apply instantly upon login (e.g. Local GPOs). Being very careful not to replicate or create conflicting settings etc.

So this is a similar setup to what I suggested in the OP? Applying some GPO settings using local AD or do you mean automating local Group Policy on the device?

[foofighterjim]

How are you handling user policies such as Start Menu/Taskbar, Desktop Wallpapers, Control Panel / Settings at a device level? Scripts or anything like that?

 

These can all be defined with device level policies, although I haven't bothered with Start Menu or Taskbar in Windows 11. LAPS in place if you need to circumvent the device level restrictions to make changes. With Intune, you just need to keep things as simple as possible.

[Westie1010]

These can all be defined with device level policies, although I haven't bothered with Start Menu or Taskbar in Windows 11. LAPS in place if you need to circumvent the device level restrictions to make changes. With Intune, you just need to keep things as simple as possible.

 

LAPS already in place and working great! Device restrictions has a good few start menu and control panel settings I've been looking for. Man I really do need to avoid Administrative Templates as much as possible. Sadly it looks like there's still plenty of other stuff I'm not able to control like restricting MMC, Registry and Command Prompt, maybe this is something I can do elsewhere. Doesn't look like I can apply JSON to the Start Menu either. Win some, lose some I guess.

Thanks for your help on this.

[MYK-IT]

So this is a similar setup to what I suggested in the OP? Applying some GPO settings using local AD or do you mean automating local Group Policy on the device?

 

We essentially have 2 configuration of Hybrid AD Devices, staff and pupils (which staff can also use, All Shared Devices) combined with applying device configurations via Intune (e.g. software deployment, driver updates, restrictions, remediation scripts, Bitlocker, LAPS, WUfB etc) by device type (e.g. using Filters - Staff, Pupil, Room etc) and any user-level specific configurations via Local AD GPOs for Hybrid AD Devices. Of course for 1:1 devices, all via Intune.

 

As you've found out, you cannot mix device and user filtering with Intune policies (it's only one or the other, unlike Local AD GPOs e.g. if user1 on device 2 then apply this etc).

Edited June 11, 2024 by MYK-IT

[Westie1010]

We essentially have 2 configuration of Hybrid AD Devices, staff and pupils (which staff can also use, All Shared Devices) combined with applying device configurations via Intune (e.g. software deployment, driver updates, restrictions, remediation scripts, Bitlocker, LAPS, WUfB etc) by device type (e.g. using Filters - Staff, Pupil, Room etc) and any user-level specific configurations via Local AD GPOs for Hybrid AD Devices. Of course for 1:1 devices, all via Intune.

 

As you've found out, you cannot mix device and user filtering with Intune policies (it's only one or the other, unlike Local AD GPOs e.g. if user1 on device 2 then apply this etc).

 

Thanks for following this up, sounds like you're doing exactly what I thought would be the best solution. Is there a specific configuration you had to do in order to be able to use Local AD alongside Intune? I assume just installing MS Entra Connect on the Domain Controller and configuring devices to join both Azure AD and Local AD through there? How does this work with Autopilot? If at all.

 

Sorry for all the questions. You're my only hope at the minute haha

[MYK-IT]

Thanks for following this up, sounds like you're doing exactly what I thought would be the best solution. Is there a specific configuration you had to do in order to be able to use Local AD alongside Intune? I assume just installing MS Entra Connect on the Domain Controller and configuring devices to join both Azure AD and Local AD through there? How does this work with Autopilot? If at all.

 

Sorry for all the questions. You're my only hope at the minute haha

 

For your Hybrid Azure AD Computers,

 

- I would initially go through all your existing configurations / GPOs etc and sort them out (e.g. device, group, staff, student or indeed if they are needed anymore)

- Determine which ones can be applied globally or to specific device groups / filters - These can then be Intune Device Configurations etc

- The remaining ones should then be user-specific (e.g. student, staff - ones that you need applying as the user logs in) - These would be your Local AD GPOs etc

 

IMPORTANT - you may need to rethink/redesign your existing Local AD Units, perhaps create new ones in readiness for Local AD Computers to become hybrid. This way, you have control and clarity over which GPOs are being applied (and devices being synced). Very useful when things don't work and you are trying to understand why? Or if GPO or Intune is at fault (or conflict)

 

You'll need to use Azure AD Connect as you'll be syncing device objects (for Hybrid Azure AD Join).

 

Certain settings you 'may' have to configure separately (e.g. GPOs for Hybrid Azure Joined devices and Intune Device Configurations for Azure AD devices) even though for the same result. For example, if being applied to certain user / groups - those 'groups' may not exist in Azure AD (if not synced from Local AD) or Local AD (if Azure AD only).

 

A quick look at our Local GPOs, I have the basics (with the rest through Intune) for example:

 

Devices

Enabling SSO

Automatic Intune MDM Enrollment

Firewall / Applocker

 

User

Drive Mappings

Start Menu etc

Staff/Student Specific Settings

 

OneDrive

And if you are intending on using the OneDrive Client (on Shared-Devices) you will also have to setup and apply a Device Configuration to re-enable the OneDrive client (as Shared Devices disables it). Again, Intune is used to setup & configure KFM (OneDrive Known Folder Move) and StorageSense.

 

Intune

For everything else

 

Oh, and try and change / implement one thing at a time during (Intune) testing. You may get lucky and changes are applied quickly, but other times may be hours!

Edited June 11, 2024 by MYK-IT

[Westie1010]

For your Hybrid Azure AD Computers,

 

- I would initially go through all your existing configurations / GPOs etc and sort them out (e.g. device, group, staff, student or indeed if they are needed anymore)

- Determine which ones can be applied globally or to specific device groups / filters - These can then be Intune Device Configurations etc

- The remaining ones should then be user-specific (e.g. student, staff - ones that you need applying as the user logs in) - These would be your Local AD GPOs etc

 

IMPORTANT - you may need to rethink/redesign your existing Local AD Units, perhaps create new ones in readiness for Local AD Computers to become hybrid. This way, you have control and clarity over which GPOs are being applied (and devices being synced). Very useful when things don't work and you are trying to understand why? Or if GPO or Intune is at fault (or conflict)

 

You'll need to use Azure AD Connect as you'll be syncing device objects (for Hybrid Azure AD Join).

 

Certain settings you 'may' have to configure separately (e.g. GPOs for Hybrid Azure Joined devices and Intune Device Configurations for Azure AD devices) even though for the same result. For example, if being applied to certain user / groups - those 'groups' may not exist in Azure AD (if not synced from Local AD) or Local AD (if Azure AD only).

 

A quick look at our Local GPOs, I have the basics (with the rest through Intune) for example:

 

Devices

Enabling SSO

Automatic Intune MDM Enrollment

Firewall / Applocker

 

User

Drive Mappings

Start Menu etc

Staff/Student Specific Settings

 

OneDrive

And if you are intending on using the OneDrive Client (on Shared-Devices) you will also have to setup and apply a Device Configuration to re-enable the OneDrive client (as Shared Devices disables it). Again, Intune is used to setup & configure KFM (OneDrive Known Folder Move) and StorageSense.

 

Intune

For everything else

 

Oh, and try and change / implement one thing at a time during (Intune) testing. You may get lucky and changes are applied quickly, but other times may be hours!

 

Super thanks for the mass amount of information regarding Intune. It’s our first deployment of many so still trying to iron out the creases. This is the first bit of assist I’ve managed to get!

 

We’re familiar with Azure AD as far as AD Sync for users goes but devices is a whole different ballpark. Will look to update my original post with the final setup so future Googler’s can use the knowledge.

 

How do you handle users if you don’t mind me asking? Do you keep all users within local AD and sync over to cloud? Do you have some cloud? Are you able to login to local AD using Azure AD accounts?

 

As for groups do you handle those in AD or do you make use of M365 Groups so you can have Teams/SharePoint/Mailing List built in? Not sure if you can have Local AD Groups be 365 Groups? I know we could probably use Dynamic groups but we’d be having duplicates then.

[KK20]

we have transitioned about 80% of our GPO to intune policies. We are lurching towards serverless onsite. We are currently hybrid. There are a number of ways you can speed things up, ironically this can be scripted in GPO (!!) to get intune to work faster. When I have fully transitioned to autopilot then things get easier since autopilot pulls all the configuration policies before first logon. Anyhoo, a new user policy will take XX amount of time to apply, to see what your machine is doing you need to look at the management log

 

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

 

It is big, evil, unreadable but full of information. It generally works with intune IDs (we keep a spreadsheet of the common policies we look for) but also has a lot of test names in there. Use CMTRACE to view them, the search is good and CMTRACE breaks up the log nicely. I dont have the space here to empty my head on how to find things but searching for your policy will yield if it is queued for application, downloading, stalled, ignored, aborted. That gives you some idea of the status for your policy.

 

I have found it is easier to SCRIPT the lot, I no longer use intune policies to affect a change if I can help it. I have a set of master scripts that "do things" either in client logon registry or computer. This is exactly what I used to do back in 1996 with Novell Netware - how the wheel turns. Why script? These seem to reliably work. I have a single policy that affects user logon preferences and another that copies scripts to this "master". Utterly backwards, totally ancient but it works for us. We have start menu, task bar, user software, user settings, lock screen, desktops all sorted through intune. Software is installed from intune apps too with the preferences (mostly computer registry scripts or licence files to be copied) set as a prerequisite. I have toyed with winget scripting but only as a test, it is not suitable for production. Once an intune policy is pulled down, it seems to cache them all locally (similar to GPOs) and they run fine for subsequent alternative logons. Make a change to a policy and it could take a while.

 

Sure fire ways of getting Intune to phone home and apply:

 

1) manually, hit sync from either company portal or from "settings" (settings->accounts->"access work or school"->"select account"->Info->device actions->sync

2) start the deviceenroller with clientID manually. This is usually a scheduled task but you can manually trigger it. It is in Microsoft->EnterpriseMgmt->->

3) creating a NEW policy seems to take effect faster than editing an old policy. This is a REAL pain in the backside but it could trigger "please change this setting NOW" policies faster for you.

 

You can go into intune (or powershell script) and "ask" intune to update intune (yes, it is as mad as it sounds, a different application monitors intune requests to the one that goes out to get intune policies). This is a little sporadic.

 

If you arent getting any intune policies, run dsregcmd /status to see if the client is truly registered (hybrid or not, it doesnt matter). In short, Intune takes its merry old time to update but you can prod it along.

[Westie1010]

we have transitioned about 80% of our GPO to intune policies. We are lurching towards serverless onsite. We are currently hybrid. There are a number of ways you can speed things up, ironically this can be scripted in GPO (!!) to get intune to work faster. When I have fully transitioned to autopilot then things get easier since autopilot pulls all the configuration policies before first logon. Anyhoo, a new user policy will take XX amount of time to apply, to see what your machine is doing you need to look at the management log

 

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

 

It is big, evil, unreadable but full of information. It generally works with intune IDs (we keep a spreadsheet of the common policies we look for) but also has a lot of test names in there. Use CMTRACE to view them, the search is good and CMTRACE breaks up the log nicely. I dont have the space here to empty my head on how to find things but searching for your policy will yield if it is queued for application, downloading, stalled, ignored, aborted. That gives you some idea of the status for your policy.

 

I have found it is easier to SCRIPT the lot, I no longer use intune policies to affect a change if I can help it. I have a set of master scripts that "do things" either in client logon registry or computer. This is exactly what I used to do back in 1996 with Novell Netware - how the wheel turns. Why script? These seem to reliably work. I have a single policy that affects user logon preferences and another that copies scripts to this "master". Utterly backwards, totally ancient but it works for us. We have start menu, task bar, user software, user settings, lock screen, desktops all sorted through intune. Software is installed from intune apps too with the preferences (mostly computer registry scripts or licence files to be copied) set as a prerequisite. I have toyed with winget scripting but only as a test, it is not suitable for production. Once an intune policy is pulled down, it seems to cache them all locally (similar to GPOs) and they run fine for subsequent alternative logons. Make a change to a policy and it could take a while.

 

Sure fire ways of getting Intune to phone home and apply:

 

1) manually, hit sync from either company portal or from "settings" (settings->accounts->"access work or school"->"select account"->Info->device actions->sync

2) start the deviceenroller with clientID manually. This is usually a scheduled task but you can manually trigger it. It is in Microsoft->EnterpriseMgmt->->

3) creating a NEW policy seems to take effect faster than editing an old policy. This is a REAL pain in the backside but it could trigger "please change this setting NOW" policies faster for you.

 

You can go into intune (or powershell script) and "ask" intune to update intune (yes, it is as mad as it sounds, a different application monitors intune requests to the one that goes out to get intune policies). This is a little sporadic.

 

If you arent getting any intune policies, run dsregcmd /status to see if the client is truly registered (hybrid or not, it doesnt matter). In short, Intune takes its merry old time to update but you can prod it along.

Thanks for all the information, greatly appreciated! Interesting how you went the script route, funny enough I was actually thinking the same, my concern though was CMD and Powershell popups to the end user. I was also unsure how it would handle registry changes as I assume the script runs from the logged in user and not SYSTEM right? If CMD and Powershell are disabled to the user surely these scripts couldn't run either? Again, I'm still early stages of Intune so really not sure.

I think my plan for now is going the Hybrid route. I'll be looking into AD Sync to get devices atleast hybrid joined and then I need to have a play with how Intune policies and GPO interact. Hopefully I can piece something together without breaking everything!

I'll take a look into the logging stuff. I've heard about the GUIDs and Identifiers but never bothered looking for myself.

When you say policies are cached for alternative logons, surely that would be my student user policies should apply to each student right, assuming they have the same groups and what not? Wonder why I'm not seeing that in my environment...