Modern Device Management

If you provision devices using Autopilot, then you may have dealt with situations like delaying installation of certain applications to address provisioning requirements or simply get the process over the line. I recently had to deal with a something similar involving Zscaler in a customer's tenant. Installation of the application would halt the provisioning process, regardless of whether it installed in device or account setup phase. This is because the way Zscaler policy was configured in the customer's tenant which required user credentials before allowing access to internet.  Back in the day, if you were using ConfigMgr, then this could be addressed by creating a dynamic collection that would populate with the devices based on the completion status of an imaging task sequence. You would then target the same collection with such apps or scripts as post installation tasks. With Intune, the same isn't really possible using the native functionality and one has to come up wi...

Back in the day when Windows 10 OS was launched, it came with a lot of built-in apps that most enterprise customers didn't want to offer to their end users. This obviously created an additional task for the administrators to find a way to remove such apps during the build process. The method of choice was using a PowerShell script to remove the apps which you could simply put in a imaging process and work away. When the management of the devices moved to the modern solutions like Intune, so did this removal process. Nothing much changed in this aspect, other than how they were setup in the Intune admin portal. I personally used this method for a long time, even when the OS moved to Windows 11, but then eventually dropped the method in favor of using the Microsoft Store app type, built into Intune. I would just import the store app, create an uninstall assignment and be done with it. It was simple and elegant. Then Microsoft replaced it with the new store experience and segregated t...

When I blogged last week about whether it is possible to enrol a device in Intune without ever having to authenticate on the device itself , I wanted to follow it up with additional security measures that organizations may need to consider if they use device code flow for device registration purposes. While Microsoft Entra ID supports a wide range of authentication and authorization flows to provide a seamless experience across all application and device types, device code flow can be misused and exploited to carry out phishing attacks and therefore is considered high-risk. In general, Microsoft recommends blocking it altogether, but that may not always be an option as indicated in the my earlier post . In this post I will cover how to block authentication flow and how device registration can be allowed in certain scenarios. Authentication flows in a nutshell To provide more control over your security posture, Microsoft has provided the ability to control certain authentication flows t...

When it comes to enrolling devices in Intune, there are multiple ways to do so. In a user based enrolment, one will require to provide Entra ID credentials at some stage or the other. However, things can become challenging when there are other authentication requirements like certificates in addition to providing standard user credentials. This is normally a case in organization that are federated with Active Directory Federation Services (ADFS) or with a non Microsoft Identity provider. A configuration requires a trusted certificate issued to a user or a device before the authentication can be allowed, but one cannot really deliver the certificate if the device is being born in the cloud and hasn't yet enrolled in Intune yet. It's a chicken and egg kind of situation. So how does one get around this without compromising on the security? The answer lies in the sign-in options at the time of the enrolment. There are some options available with the Sign-in options, but it is '...