#Modern Workplace

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

The current version and some earlier versions of 7-Zip have a security vulnerability which could allow hackers to escalate privileges. The zero-day referred to as CVE-2022-29072  exploits the misconfiguration of 7z.dll. Hackers can gain unauthorized access to systems when a file with the .7z extension is placed within the Help > Contents area . The command then runs as a child process under the 7zFM.exe process. At present, 7-Zip has not released a security update to address this vulnerability, which means that all current versions of 21.07 are vulnerable. Luckily there is a workaround available to mitigate the vulnerability and through this blog, I will cover the remediation steps of implementing this workaround using ConfigMgr.  Workaround for mitigation To remedy this vulnerability, 7-zip.chm file in the 7-Zip installation directory needs to be deleted. This way the help section of 7-zip becomes unusable and the attackers cannot exploit it any further.  I have creat...

If you have CMG (Cloud Management Gateway) configured and have enabled MFA, then this blog post may just help you. I recently came across an issue involving Azure sign-in failures against CMG native\client app  under the name ConfigMgr-Client app in one of my customer's tenant. The failures created alerts in through Qradar (By IBM), a Security information and event management tool aka  SIEM.  On checking further, I could see the following sign-in failures. If you look closely, the Authentication requirement field shows Multi-factor Authentication , which must satisfy for successful sign-in. On checking the Conditional Access  tab, I can see which CA policy is failing.  The CA policy in question is Enforce MFA for Admins , which has been setup to enforce MFA for specific Directory roles across All Cloud Apps . If you think of it then the CA policy is doing what it is suppose to do, but since it is targeting all cloud apps, it is also taking  CMG cloud App...

I recently encountered an issue in a customer's envrionment where SQL Server Reporting service in ConfigMgr had broken down. On launching the Report Manager url and then running a report resulted in the following error. Similar errors were noticed when trying to run the reports from the ConfigMgr console. The error indicated that the issue is with the report service account credentials so that is where I started looking. It appears that the customer had updated the password of the report service account in AD, but the same was not updated in ConfigMgr. So the first thing I tried was to update the password and test the connection.  Well that was pretty easy. Atleast so I thought. The moment I clicked on Apply to commit the changes, I was presented with another error indicating an issue with the report server database. On checking further, I noticed entries in the SQL dump logs related to Transaction log being full due to SQL backup. library!ReportServer_0-1!5338!01/04/2022-23:16:38...