#Modern Workplace

I recently encountered an issue as part of a project involving Entra hybrid join for existing domain joined devices and Co-management where devices stopped connecting to corporate wireless access points automatically. The devices would complain about missing credentials, resulting in authentication errors and eventually give up on connecting to the corporate Wi-Fi. Here is a snapshot of one such error - The environment is configured with Cisco ISE as the RADIUS solution with an authentication policy relying on PEAP MSCHAPv2 as the authentication protocol. The logs on the Cisco side reflected the same ' Internal authentication error ' as seen in the event viewer of the endpoints. This was strange at first because there was nothing set up in Intune or otherwise as part of the Co-management configuration that would interfere with the WiFi settings in general. On further investigation, it was discovered that the issue could very well be related to Credential Guard on the devices. ...

  It was a cold gloomy day when I set out on a mission to fix an issue involving ASR rules. Something which I may have done a dozen of times so I said to myself, why it should be any different this time. But if history has taught me anything, it is that no two issues are the same, despite how much they resemble and that for every issue there is a possible solution. You just have to stay relentless and you will eventually make it to the other side. The issue.. It all began with the ASR rules in 'block mode' starting to block macros on a set of devices. Pretty routine at this stage as the logical thing to do is either to configure necessary exclusions or put the relevant ASR rule in a non restrictive state like 'Audit' mode. The problem is that no matter what changes I made to the ASR rules, they simply didn't make any difference. Macros continued to be blocked and the events in Advanced hunting would confirm the same. When I checked the registry on the devices in que...

Working on a project led me to the requirement of targeting some Intune policies on devices that are both Intune and Co-managed. In case of Co-managed, I would normally use Cloud sync to assign the policies on a Microsoft Configuration Manager collection synched with Azure AD and in case of Intune, I would just create a Dynamic Azure AD group containing Autopilot devices or use some basic AAD group attributes in conjunction with device filters in Intune. But this time, I wanted to simplify the grouping and decided to explore the idea of using a single Azure AD dynamic group for all my policy assignments in Intune.  Enter deviceManagementAppid attribute for dynamic grouping of devices in Azure AD. Microsoft have provided Appids for Intune and Co-managed devices that can be used for dynamic grouping. For a complete list of supported device attributes, you can refer to the official link over here . In order to use the Microsoft Intune value ("0000000a-0000-0000-c000-000000000000...

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

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