Modern Device Management

Picking up from my last post that covered the issue involving CMG Azure cloud resources and Tags, my battle was half won in the implementation project of CMG that I was carrying out for one of my customers. After the cloud service was created and the service reported the status as ‘Connected’, the next logical step was to test and verify the connection. This is where things started to go south. On running the ‘ CMG Connection Analyzer’ against the Client Authentication Certificate, I received the following error. SMS Cloud Proxy Connector log indicated the same. In my experience, that looked like a communication issue between the connection point and the HTTPS server configured to accept CMG requests. The ConfigMgr environment has a Standalone Primary (Co-located SQL) configured to cater to HTTP requests. Cloud management gateway connection point was also configured on the same server. Another server was stood up to cater to HTTPS requests. This server would

Recently w hile working on an implementation project for CMG, I came across an issue which I had never dealt with before. I had taken care of the usual pre-requisites, but nothing could have prepared me for what I was about to experience. While creating the Cloud Management Gateway Service, I got the following error. This didn’t make sense as I ensured that I have Contributor access to the resource group prior to initiating the configuration. SmsAdminUI.log logged some errors. This got me looking into the activity of the resource group and I verified that there was indeed an Azure policy blocking the creation of the objects. I matched the definition id and was able to identify the policy in question. It was no other than, but the policy of Tags. Classic providers within Azure don’t support tags. While CMG uses Azure Resource Manager framework, it still uses classic service providers for creating cloud objects. Mainly ClassicCompu

Starting SCCM 1806 comes the exciting new feature that will redefine the design and planning of SCCM sites. Or does it? Well the answer is, not entirely. With PXE responder, one can use a client OS (Windows 7,8,10) to respond to PXE request without the need to setup a WDS. Prior to CB 1806, if you had a remote distribution point and wanted to image using PXE, you’d have to use a server OS because of the pre-requisite of the installation of Windows Deployment Service (WDS). But now, since the introduction of PXE responder, the setup is simplified and certainly saves a lot of cost by eliminating the need to setup up a server OS, possibly with its own hardware that was being used as a distribution point. However, this new feature does come with some limitations – First, it doesn’t support Multicast, so if you need multicast, you need to stick with Windows Deployment Service (WDS). Second, client OS, especially Windows 10, still doesn’t support SMP. Which means y

When moving from Windows 7 to Windows 10, a lot must be taken into consideration. One of the main tasks is getting user data migrated seamlessly without having the need to invest in additional infrastructure. Until now, USMT in SCCM has been the favorite method of migrating user's data but it does require a considerable amount of setup and configuration if not already adopted. Starting CB 1902, Configuration Manager can be leveraged to move Windows known folders to OneDrive for Business. These folders include Desktop, Documents, and Pictures. This is especially helpful if an organization already has a policy of directing users to use these folders to manage their data. Even if there isn't one, organizations can adopt a policy to redirect users to start using these folders to future proof their data. There are two primary advantages of moving or redirecting Windows known folders (Desktop, Documents, Pictures, Screenshots, and Camera Roll) to OneDrive for Busine