Event banner
Event details
47 Comments
- How can we prevent devices from going to sleep during Enrollment Status Page ESP? Some OEMs ship their devices with short screen or sleep timeouts by default, which can cause a device to go to sleep during ESP, or just turn off the screen. Former will interrupt deployment, the latter will force users to sign in again with their (complex and new) password, spoiling the otherwise great experience. If there is no way right now, can we add this as a feature / policy option please?
- + 1 more on this question. I see the same and once it sleeps it can take hours to re-sync back up.
- Sean_McLaren
Microsoft
Hi Dominique, is the device plugged into power when it 'goes to sleep'?- It seems to happen on both AC and DC power, depending on the OEM's default power settings. But tbh imho it shouldn't matter. There should be an option for us to prevent sleeping during ESP so that devices can reliably complete deployment and users don't have to sign in over and over again. Shouldn't be too hard.
- Folks, when we (or customers) do a device wipe through Intune, everything is wiped clean, including device entries and records in Intune. But Entra retains the device records - which for us is not only not needed, it is positively annoying. Can we get an option to tell Entra to also delete the device on Device Wipe actions? Ideally, as a global/general setting or a applicable by group or filter. Thanks!
- Sean_McLaren
Hi Dominique, when you Wipe a device, you are correct, it will retain the Entra device. If you want to remove the Entra device, you can Retire the device as opposed to the wipe and for Windows 10 and later it will also remove the Entra device (Table in that article describes behavior on each platform, including Windows). For cleanup of stale devices, we also have Cleanup rules in Intune under Devices > Device cleanup rules where you can set a rule to delete devices after a certain number of inactive days.
- Thanks Sean. My understanding is that "Retire" won't wipe data on the target device - hence the "wipe" option. In almost all cases, "wiping" is the best option for our customers and also the easiest to understand. Also, company portal always triggers the "wipe" on EJ and Intune enrolled devices. I'll put a feedback item on the feedback site for this.
We have a very high turnover of devices within the organisation (school with pupils age 11 - 18 where each pupil has a Microsoft Surface Pro) both with devices coming back in to be reused by other users and new devices coming in after existing stock is sent off for repair, and we are struggling with keeping the process fast and efficient both on a technician side to make sure that devices are ready for users but also from a user side so that they aren't waiting for too long on device set ups. All devices are purely Azure AD joined.
What is the recommended process/best practice for this scenario?
Currently, for devices that are coming back from users to stay in the organisation we make sure the device has all its updates and then do an autopilot reset. For new devices coming into the organisation, either as new or repair replacements, we go through the standard set up with a service account, run all the updates (often including the update from Windows 10 -> 11) and then do an autopilot reset so that all devices that are ready to go out to users are in the same state.
There are a few issues with this, one is a bug where the Microsoft documentation here: https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset says: "When Autopilot reset is used on a device, the device's primary user is removed. The next user who signs in after the reset will be set as the primary user.".
This is not the case, primary users are not removed on reset nor are primary users set on set up. This is true for both local autopilot resets and those triggered through Intune.
This was raised with support last year who confirmed they could replicate the behaviour and nothing else came of it. While not the end of the world, it does require technicians to always remember their manual intervention to make sure primary users are up to date to allow for elements such as self service app installations and configuration reporting.
Additionally, we run into numerous issues with the user set up section where the devices don't show their progress (only shows "Pending" for all stages until it is complete), where updates with pending reboots prevent the process from working but requires the ESP to time out before it shows the reboot required error or where apps that are marked as required in the ESP are not installed but the process completes "successfully". This section also takes between 3 and 30 minutes to complete when it does complete successfully with no obvious reason as to the variation in time.
Furthermore, app installation status, configuration profile status and other records tied to the intune record of the device persist through every autopilot reset. I appreciate that part of the point of an autopilot reset is to keep the intune record, but it gets ungainly relatively quickly.
Previously we have tried using pre provisioning set up however this ended up taking too long to process devices on the technician side to make sure that they are ready while also hitting multiple issues such as requiring that the intune record be deleted and time outs on provisioning.
Happy to work through any issues we have with our deployment, however would appreciate some advice as to what the "intended" or advised route would be for this situation.
Hey JoeWhite, pretty experienced M365 MSP here.
We ask customers/users to reset their own devices via Company Portal app, which works reliably and doesn't show any of the issues you describe. Given that many students probably forget to do this, have you considered doing a "device wipe" from within the Intune Portal's device page? You can do that as a "bulk action" on multiple devices or groups simultaneously. This also is extremely reliable in our experience, resulting in factory-fresh devices and no stale entries or associations in M365 (except for Entra, which inexplicably retains the old device records that need to be cleared separately. But as long as devices get new device names this has no impact). You would need to change your re-deployment process to accomodate, but it may be worth it.
If you're getting restarts during ESP, that is a known issue when you apply policies to devices. Windows (as we know) often needs to restart for the most trivial reasons, and many Intune policies can do that too. Try applying most policies to USERS instead of devices, and you'll find those annoying reboots go away. We know many policies are supposed to be "device" policies, but find that almost all of them work just fine when applied to users. The only ones we apply to devices are Endpoint Security policies - and they don't cause reboots. There are a few other device security settings we deploy by script as a registry change - such as hardening LSASS and enforcing HVCI. Those normally require a restart, but if you just change reg keys, Windows doesn't know that during deployment. 😉
Also, DON'T try to force updates during ESP - that's a sure way to timeout ESP and/or cause unwanted restarts in our experience. Windows will automatically download and install updates roughly one hour after the primary user first signs in - including all security patches and updates. This works really well and our customers like it better. Devices are subjectively ready to use quicker. Also, if students perform the enrollment/onboarding at home (do they?), you've offloaded a lot of network traffic as well. Once the updates have downloaded and installed (devices can already be used!), students receive a prompt to restart which also enables the registry changes we made earlier. Even if students don't restart, I'm sure your update policy will enforce a restart <48 hrs after the updates installed. Right? 😁
So instead of trying to get as much work done BEFORE handing the devices over to students, maybe consider allowing them to finish certain things AFTER students have enrolled? --> Sure works great for us!
- We currently use Group Policy Preferences to push registry values to our domain joined computers. What is the best way to push the same registry values to our Entra joined Intune managed devices?
- Btw, there is a feedback item on this: https://feedbackportal.microsoft.com/feedback/idea/559b62fb-6ac2-ed11-a81b-000d3a0450e3 More upvotes = more attention by program managers! 😉
- No sure if it's best, but what works well for us is doing it as PowerShell scripts, which are packaged as a Win32 app. No Joke. Here's why: 1. We get good local and remote reporting and logging (using -verbose options and start-transcript) on whether it succeeded or not. 2. Re-applying (ie re-installing) can be triggered locally in multiple ways, one of them being the Company Portal app (=user friendly) and remotely. 3. It visibly happens during the ESP phase in the user deployment section. It gives users a rapid app deployment counter, which makes it look like a lot is happening. 4. We can use Azure DevOps repos and git for development, so we can treat registry keys as software code instead of OS settings.
- Same for us, Powershell scripts packaged up as Win32 apps and deployed out works a treat 🙂
- My organization is looking to setup a company announcement Teams Channel with a private channel for each region is which we operate. I was hoping to setup the private channel membership dynamically but I'm not seeing a way to do this. We have a DL for each region and my plan was to use this as the reference point for the dynamic membership. Does Microsoft have a recommended way of handling something like this?
- EricMoeRobert, this question would be better for https://techcommunity.microsoft.com/t5/microsoft-teams/ct-p/MicrosoftTeams where someone with more experience in this area can assist.
- I would like a checklist for all settings / plugins etc. needed to make LDAP fully functional in an Azure Hybrid environment.
- EricMoeLes, please post your question over in our Entra community, https://techcommunity.microsoft.com/t5/microsoft-entra/bd-p/Azure-Active-Directory where the right folks with the right expertise may be able to address it.
- I would like a checklist for all settings / plugins etc. needed to make LDAP fully functional in an Azure Hybrid environment.
- EricMoeLes, please post your question over in our Entra community, https://techcommunity.microsoft.com/t5/microsoft-entra/bd-p/Azure-Active-Directory where the right folks with the right expertise may be able to address it.
