#Modern Workplace

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...

A large number of my customers are implementing Autopilot device provisioning process in an effort to move away from traditional imaging solutions like ConfigMgr and adopt cloud first strategy, whilst retaining their investment in ConfigMgr. This normally results in a mixed workload management through Co-management which can be setup and configured easily. For devices being provisioned using Autopilot, there is actually more than 1 way to achieve a co-managed state for the endpoints. If you are looking for a native solution, then Microsoft recently introduced Co-management settings right in MEM Console which can be used to apply the settings automatically during ESP phase. However, this method doesn't support all scenarios and there are some limitations, namely - - Hybrid Azure AD-joined devices are not supported. - Autopilot pre-provisioning, also known as white glove provisioning is not supported. - Workloads switched to Pilot Intune with pilot collections are not supported. - Cl...

I recently dealt with an Autopilot issue which prompted me to capture my experience in this blog. Now issues during Autopilot provisioning is fairly common. Especially when Microsoft introduces changes in the backend that affects the Autopilot provisioning process. Now I am not sure if the issue I experienced was a result of some changes made by Microsoft or not, but it certainly affected some tenants as many others reported similar issues on Twitter . Let me explain the issue in detail. In my case it started with AP timing out with the infamous 0x800705b4 error. Running Get-AutopilotDiagnostics led me to believe that something was wrong with how policies were getting evaluated as ESP showed as not assigned. This is odd. Why would ESP not show assigned when the very same policy had been running for weeks without any issues? What is even more strange that the diagnostics showed ESP as blocking. That would explain the timeout error I was seeing. To test my theory of a possible issue wit...

If you are managing Microsoft Defender AV and Microsoft Defender for Endpoint policies using Intune, then chances are that you may come across an issue where Windows Defender Real-Time Protection doesn't enable after a device has been provisioned using Autopilot. I started experiencing this issue lately which also resulted in device reporting as non-compliant.  On further investigation, I found out that Windows Defender Antimalware Real-Time Protection was not getting enabled because of the missing of Antimalware Engine. This is clearly evident under Windows Security > Settings > About section. It appears that the check for security intelligence updates was not getting initiated during and post provisioning and the updates were not coming down automatically. This is odd because I have got the policies for automatic update of Defender AV updates enabled as part of my policies in Intune. I must state that in my case the operating system is Windows 11 Enterprise and the devices ...

As part of an ongoing Autopilot project, I am installing ConfigMgr agent on devices with Azure AD identity to support Co-management. Workloads for patching Windows updates and Office 365 sit with ConfigMgr so it is important for me to have this working to support an existing monthly patching process in the customer's environment. Since I implemented CMG for the customer as part of another project last year, I was aware of the configuration, but when security patching didn't work using CMG on AAD devices, it came as a little surprise to me. I immediately put on my troubleshooting hat and started looking into the issue. Now update scan failures in the world of ConfigMgr is a common occurrence. Since I have dealt with such issues many times in the past during my career, I knew what and where to look for. I wanted to share some of my troubleshooting steps through this blog post which may help others in the future. The first thing I did was to check whether the client had installed ...