Arnab’s Blog

ConfigMgr Application Approval via Email

Arnab Mitra [MSFT] — Sun, 09 Dec 2018 00:16:44 GMT

ConfigMgr 1810 introduced the feature to receive email-based notifications for application approval requests. Here's a step by step configuring the flow for a user requesting an application, an email is sent to the application approver to either Approve or Deny the request.

Prerequisites

Turn on the Feature "Approve application requests for users per device"

Configure Email Notification

Go to Monitoring > Overview > Alerts > Subscription
Click on Configure Email Notification from the ribbon menu.

Populate SMTP server information and Port. For Office 365 EXO use smtp.office365.com with port 587
Specify a connection account.
Specify sender email address for the notification.

Use the Test SMTP Server button to send a test email for validation. Refer the NotiCtrl.log for troubleshooting.

Access SMS Provider over Internet

You may want the approval/deny workflow to work even outside corporate network. It's now possible to access WMI over HTTPS via CMG leveraging the ARM model with AAD User Discovery enabled.

On your ConfigMgr console go to Administration > Site Configuration > Servers and Site System Roles
Select the Server holding SMS Provider Role. [If unsure, check the Site Properties to confirm]
Go to the Properties of SMS Provider and check the box Allow Configuration Manager cloud management gateway traffic for administration service.

Back in ConfigMgr console go to Administration > Cloud Services > Azure Services
Select the Cloud Management Azure Service and go to its Properties > Applications tab.
Make a note of the Native Client App

Click the Discovery tab to ensure AAD User discovery is enabled.
Back in ConfigMgr console go to Administration > Cloud Services > Cloud Management Gateway
Make a note of the CMG Service Name

Go to the Azure portal, select Azure Active Directory, and then select App registrations. You may need to click View all applications
Search for the Native Client App you noted from ConfigMgr console.
Click to open the app and select Settings
From the Settings blade select Redirect URIs.
In the Redirect URIs blade, paste in the following path: https:///CCM_Proxy_ServerAuth/ImplicitAuth

[Replace with the CMG Service Name you noted from the ConfigMgr console.]
Click Save. Close the Settings pane.
In the app properties, select Manifest.
In the Edit manifest blade, find the oauth2AllowImplicitFlow property.
Change its value to true. For example, the entire line should look like the following line: "oauth2AllowImplicitFlow": true,
Select Save.

Deploy Application

Now its time to deploy your desired application to a User Group.

Check the box An administrator must approve a request for this application on the device.
You can also specify email address of the application owner or approver. This can be unique for each application and supports multiple email addresses.

From here the user requests the Application from Software Center The approver receives the email notification to Approve/Deny. When I hover over the approve link, it points to my CMG to access the SMS Provider over Internet. The application is automatically installed, and the requestor doesn't need any action to take! However for a decline, the user isn't notified and has to check Software Center. Thanks, Arnab Mitra

SQL Server Native Client Update Warning Prerequisite for ConfigMgr 1810

Arnab Mitra [MSFT] — Wed, 28 Nov 2018 00:13:55 GMT

If you are planning to upgrade your ConfigMgr infrastructure to the latest 1810 release, plan for updating the SQL Server Native Client to support TLS 1.2 If the SQL Server native client isn't already updated, the prerequisite check will fail with below warning. The details are available in the ConfigMgrPrereq.log <11-27-2018 20:27:21> PRIMARY1; SQL Server Native Client version; Warning; Configuration Manager sites require a supported SQL Server Native Client version. To enable TLS 1.2 support, you must install a supported version of SQL Server Native Client on the specified site database server. For more information, see https://go.microsoft.com/fwlink/?linkid=2026746

Update SQL Native Client

You do have the option to ignore the prerequisite check, however if you want to support TLS 1.2 now or in even in future, you should upgrade the SQL Native Client. Refer the link from log snippet to identify the applicable version. You can check Programs and Feature on the Server to identify the currently installed version. In my case I have SQL Server 2012 Native Client. From here I can choose to install the applicable version. This takes me to https://www.microsoft.com/en-us/download/details.aspx?id=50402 The version number here is in fact lower than what we see in Programs and feature screenshot above. Launch ODBC 64 bit > Drivers tab to validate the right version. 110.6540 is lower. Install the SQL Native Client Update installer, this will also confirm you are running the lower version and may request a reboot post install. Launch ODBC once again to validate the updated version to support TLS 1.2 Happy Upgrading! Thanks, Arnab Mitra

CMG with just One Cert

Arnab Mitra [MSFT] — Wed, 24 Oct 2018 18:48:56 GMT

You read it correct! Cloud Management Gateway has evolved and its now easier than ever to deploy one. All you need is a single Web Server Authentication Certificate from a public CA.

What changed?

Primarily the introduction of a new feature in ConfigMgr 1806 called Enhanced HTTP Site System which replaces the requirement of an HTTPS Management Point for CMG communication. The site server generates a certificate for the management point allowing it to communicate via a secure channel. Another addition in 1806 is the Azure AD Device Identity can be leveraged for both Hybrid & Azure AD joined devices to securely communicate with its assigned site without a logged-on user.

Prerequisites

The modern workplace in a cloud first world is possible when your resources are accessible from anywhere. Below are two important prerequisites for stepping into one.

Sync On-Prem Domain Users to Azure AD

If you are an Office 365 user, your domain users are already synchronized in Azure Active Directory. This is configured via Azure AD Connect and requires planning. Refer this link as a starter - https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity

Register the Domain Joined devices to Azure aka Hybrid Azure AD Joined

Once your users are synchronized into Azure AD, the next step is to ensure the domain joined Windows 10 devices are also registered in AAD. All you need is to run AAD Connect and choose the option below (available in version 1.1.819.0 and higher). Refer this link for more info. Configure GPO to automatically register the devices in AAD.

Prepare ConfigMgr

Enhanced HTTP Site System

Introduced in 1806 as a pre-release (fully supported in production) replaces the requirement of an HTTPS Management Point for CMG communication. The site server generates a self-signed certificate for the management point allowing it to communicate via a secure channel. Only Hybrid & Azure AD Joined devices connected via CMG can communicate with the Enhanced HTTP MP. Since this is a pre-release feature, make sure you Consent it in the Hierarchy Settings Turn On the feature Enhanced HTTP Site System This will light up the feature in the Site Properties > Client Computer Communication tab. Check the box Use Configuration Manager-generated certificates for HTTP site systems.

Configure Azure Services for CMG – ARM based deployment

On the ConfigMgr Console, go to Administration > Cloud Services > Azure Services.
Click Configure Azure Services on the ribbon menu.
Select Cloud Management in the Wizard.
Provide a Name and click Next to proceed.

Click on Browse to either Import an existing App or click Create to start with a fresh App.

Provide an Application Name
You need to Sign in with a Subscription Admin.
Click OK to complete

Repeat the steps to create a Client App and click OK to complete.

Click Next in the wizard

Check the box Enable Azure Active Directory User Discovery.
Click Next to summarize and finish the wizard.

Domain User accounts will be populated with Azure AD information.

Setup CMG

Now we are all set to configure CMG.

On the ConfigMgr Console, go to Administration > Cloud Services > Cloud Management Gateway
Click Create Cloud Management Gateway on the ribbon menu.

Choose Azure Resource Manager deployment
Sign In with Azure Subscription Admin account
The subscription info and the Web App created in the previous section will auto populate. Click Next to proceed.

Click Browse to specify the CMG Certificate obtained by a public CA [desired_service_name.yourdomain.xxx]. This will auto populate the Service name in the wizard.

Note – Choose the service name carefully as this name should not exist in Azure. You can check for available name by attempting to create a classic service.
Choose your Azure Region
Choose Create new under Resource Group.
Optionally select the option to function CMG as a Cloud DP
Click Next to summarize and finish the wizard.

Note -Azure appends the CMG Service name with .cloudapp.net domain name. You have to create a CNAME record in public DNS pointing to Monitor the state of deployment and proceed to next step once the Status is Ready.

CMG – Connection Point

This is the on-premise site system role which communicates with the CMG. Add a new Site System Role and select Cloud management gateway connection point. This auto-populates the CMG name and its region. Click Next to summary and finish the wizard.

Allow CMG Traffic

On your HTTP Management Point, check the box to allow CMG traffic.

Validation

We are now ready to test the CMG connection on a domain joined client computer. The first thing you need to validate is ensure the device is Hybrid Azure AD Joined. You can run the command DSRegCMD /Status The device will also be listed in Azure portal under devices with a Join Type as Hybrid Azure AD joined. Reference snapshot of domain joined client certificate snap-in. All I have is two certificates from Azure. Open the ConfigMgr control panel applet to validate the CMG information is populated in the Network tab. Deploy a test application to validate a successful download of the policy via CMG. Install the application to further validate. Note – I don't have a public domain or cert hence I used .cloudapp.net for DNS validations. Thanks, Arnab Mitra

Deploy CCMSetup.exe via Intune

Arnab Mitra [MSFT] — Sun, 14 Oct 2018 20:46:16 GMT

Intune recently added the option to deploy Win32 Apps which allows the ability to directly deploy CCMSetup.exe via Intune. The process is straightforward -

Wrap CCMSetup.exe with Intune Win App Util.
Add the App to Intune
Assign to group.

Wrap CCMSetup.exe with Intune Win App Util

Download the Intune-Win32-App-Packaging-Tool Run IntuneWinAppUtil.exe and specify -

Source Folder:
Setup File:
Output Folder:

Add the App to Intune

Grab the resultant output CCMSetup.intunewin from the above operation.

Specify the software setup file

Sign in to the Azure portal.
Select All services > Intune. Intune is in the Monitoring + Management section.
In the Intune pane, select Client apps > Apps > Add.
In the Add app pane, select Windows app (Win32) from the provided drop-down list.

Upload the app package file [CCMSetup.intunewin]

In the Add app pane, select App package file to select a file. The App package file pane will be displayed.
In the App package file pane, select the browse button. Then, select ccmsetup.intunewin
When you're finished, select OK.

Configure Program

Install Command: ccmsetup.exe Don't forget to remove CCMSETUPCMD = "" In my lab I am using an internal CA hence I also added /nocrlcheck

Configure Properties

Customize App Information, Requirements, Detection Rules and Return Codes as desired.

Add the app

In the Add app pane, verify that you configured the app information correctly.
Select Add to upload the app to Intune.

Assign the app

In the app pane, select Assignments.
Select Add Group to open the Add group pane that is related to the app.
For the specific app, select an assignment type:
- Available for enrolled devices: Users install the app from the Company Portal app or Company Portal website.
- Required: The app is installed on devices in the selected groups.
- Uninstall: The app is uninstalled from devices in the selected groups.
Select Included Groups and assign the groups that will use this app.
In the Assign pane, select OK to complete the included groups selection.
If you want to exclude any groups of users from being affected by this app assignment, select Exclude Groups.
In the Add group pane, select OK.
In the app Assignments pane, select Save.

Validate a successful install Thanks, Arnab Mitra

Step-by-step: Highly available Site server

Arnab Mitra [MSFT] — Sat, 01 Sep 2018 16:03:53 GMT

The release of ConfigMgr 1806 introduced the concept of high availability of the Site server by adding an additional primary site as passive node. This post takes you through a step by step journey in configuring a highly available Site Server. Here's a high-level architecture overview of the configuration which depicts a remote SQL AlwaysOn availability group hosting the ConfigMgr database and a remote shared Content Library.

Prerequisites and Recommendations–

Remote SQL

As you plan to prepare your site for HA, the first thing to ensure is your SQL is also HA. This can be a SQL AlwaysOn or a SQL Cluster. You can also start with a remote standalone SQL and later add it to an Availability Group. Refer this link for guidance.

Remote Content Library

Note - Make sure the Distribution Point role is not installed locally on the primary site and needs to be removed before proceeding. The Content Library also needs to be moved off the primary to a centralized location which can be a network/SAN share.

Moving Content Library –

Create a Shared Folder
Add the System/Computer Accounts of the both the Site Server (Active and Passive) with full permissions to this share.
Open ConfigMgr Console > Administration > Site Configuration > Sites
Click Manage Content Library from the ribbon menu
From the dialog, specify a folder inside the share (Not the root of the share) and click Move.
Selecting the root of the share will result in the following error - CContentDefinition::SyncFolder failed; 0x800700a1 SMS_DISTRIBUTION_MANAGER
The console will show the move in-progress. You can also refer to the DistMgr.log

Remote SMS Provider

If the SMS provider is not already remote, install an additional SMS Provider [do not choose the passive site server] which is not local to the Primary Site. Note – ADK is a prerequisite for SMS Provider

Run the ConfigMgr setup and choose Modify SMS Provider configuration
Add the FQDN of the remote server [do not choose the passive site server] where you plan to install the SMS Provider and click Next
Validate a successful install from the console.

Remote SUP

If the SUP role is not already remote, do plan to offload it from the Primary Site Server to a remote Server.

Add additional SUP Server/s
Remove SUP role from Primary Site and choose one of the remote SUP's as the new active source.

Passive Site Server - Prerequisites

Operating System:

The passive site server can run any supported OS and doesn't need to match the existing Primary Site Server OS. This enables the scenario where you might want to move to a new OS for your Primary Site without performing an in-place upgrade or a backup/restore.

OS Features and ADK

Download and Install ADK

Install the following features –

Remote Differential Compression
Remote Server Administration Tools > Windows Server Update Services Tools [WSUS sync will fail without this]

Permissions:

Add the System/Computer account of the Passive Site Server to the following locations –

Content Library Share – In case you missed from the previous step of moving the content library.
Administrators Group of Active/Current Primary Site Server.
Administrators Group of SQL Server (All nodes for SQL Clusters/AlwaysOn).
SMS Admins group on all SMS Providers.
System Management Container in AD.
SysAdmin on SQL Server (All nodes for SQL AlwaysOn). – Follow the instructions below –
- Launch SQL Server Management Studio
- Expand Security and select the machine account of the current Active Primary Site (Contoso\CM1$)
- Right click and choose Script Login as > CreateTo > New Query Editor Window
- Replace the computer account of the Active Primary Site to the Passive Primary Site and click Execute.
- Expand Databases > ConfigMgr DB CM_P01 > Security
- Select the machine account of the current Active Primary Site (Contoso\CM1$)
- Right click and choose Script Login as > CreateTo > New Query Editor Window
- Replace the computer account of the Active Primary Site to the Passive Primary Site and click Execute.

Installing Passing Site Server

Adding the Passive Site Server system is straight forward.

Create a new Site System Server from the Administration node.
Browse the desired Passive Primary Site Server FQDN and click Next
From the Role Selection page, choose Site server in passive mode and click Next
Choose your desired option to provide the Source files.
Specify the Installation directory. [do not choose the root of the Program Files, it must be a directory inside and doesn't needs to be already present]
Click Next to complete and finish the wizard.
Validate the progress in the FailOverMgr.log

The Scheduler and Sender creates job to copy the files to the Passive Site Server. You can also check the ConfigMgrSetup.log on the root of the Passive Site Server.

Refer the Installation Workflow in this link.

Validate the successful completion on the console. Both the Active and Passive Site Servers with status OK

The following Registry Keys are created which reflects the Passive Site Server –

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Identification
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Site Failover

Troubleshooting Installation

If you experience issues while installation, let's say you missed a prerequisite and the installation failed, refer the below steps.

The Console status shows the Passive Site Server as Installation failed. You will get the right click option to Retry Installation
The reason for the failure is available under Monitoring > Site Server Status
Click on Show Status to view the reason of failure.
Once you resolve the issue, click Retry Installation.

Console

The ConfigMgr console is not installed as a part of the Passive Site Server installation and needs to be manually installed.

Go to Installation directory > Tools > ConsoleSetup folder to initiate the installation.
Connect to the Passive Primary Site Server

Promote Passive Site Server - Planned

Its now time to test the Passive Site Server by promoting it as Active.

Console > Administration > Site Configuration > Sites > Nodes Tab
Select Passive Site Server > Right click and choose Promote to Active and confirm.
Note the change in Status from OK to Promoting (Passive to Active) and Installing for the Active to Passive site.
Subsequent failover will only change to Promoting for the Passive Site as it doesn't need to install any components
Review the FailOverMgr.log on both the nodes.
The Mode (Active/Passive) switches between the two Site Servers and Status to OK.
The Primary Site Server name changes to the Passive Site Server which we just promoted to Active.

Here's a Flowchart - Promote site server (planned)

Promote Passive Site Server – Unplanned [30-minute delay]

This will be an actual disaster scenario where the Active Primary Site Server is offline, and you need to promote the Passive Site Server to Active. There is no automatic failover. The steps are same as above to switch a Passive Site Server to Active via the ConfigMgr Console. Note – There is a 30-minute wait before the Passive Site Server switches to Active mode. Refer the Unplanned Workflow snippet below. The time start when you click Promote Active and not since the server is actually offline which could be longer. I had to restart the Site Server to fully initialize and act as an Active Site Server.

Limitations and Non-HA Site System Roles

Refer the Site Server HA Limitations in this link.
Certain Site System roles do not support high availability (example – Service Connection Point), the option is to Uninstall and Reinstall the role on a new server. Refer this link for guidance on each role.
When you have two primary sites(active/passive), it may get confusing when you are troubleshooting and looking at logs. Always check the time stamps to be sure.

Thanks, Arnab Mitra

Inventory Installed Updates missing from QFE Class

Arnab Mitra [MSFT] — Fri, 22 Jun 2018 22:07:17 GMT

In ConfigMgr we have the capability to inventory the QFE [Win32_Quick Fix Engineering] class to query the installed Hotfixes. The challenge here is not all updates are reported in this Class like the Quality Rollups. So how do we capture the missing updates? Here's a PowerShell query to gather the desired information - For reporting purposes, we need to capture this data into the ConfigMgr DB. I did this by creating a custom WMI Class and dumping the output of the above query as a WMI Instance of the custom Class and extend the Hardware Inventory for reporting purposes.

Import Hardware Inventory MOF

Let's start by importing the Custom inventory class MOF to ConfigMgr. This can be only done from the Default Settings and not a custom device setting. Open the Default Client Settings > Hardware Inventory > Click Set Classes Click Import and here's the .MOF file, you need to import. <Download Query_Updates.MOF> Click OK on the default option and verify a successful import.

Customizations

The attached PowerShell script <Download Query_Updates.ps1> does the following –

Creates the Custom WMI Class and Instance
Gather's installed updates data [Thanks to Russ Rimmerman for helping me on this part]
Inserts into each Instance of the custom WMI class
Executes a Hardware Inventory Cycle.

Deploy Script

You can create a Package and a Program to execute the above PowerShell script and schedule to re-run. Program Command Line - PowerShell.exe -ExecutionPolicy Bypass -NoProfile -NoLogo -NonInteractive -File Query_Updates.ps1 Schedule – No recommendation here. (I've configured it to execute every 5 days and always rerun program.)

Output

Refer the Resource Explorer to view the captured data. You can also query this information directly from the Database. select * from Query_Updates_DATA Query_Updates.ps1 Query_Updates.MOF Thanks, Arnab Mitra

Step-By-Step: Cloud Management Gateway on ARM

Arnab Mitra [MSFT] — Sat, 31 Mar 2018 22:57:33 GMT

Introduction

Starting ConfigMgr 1802 Cloud Management Gateway is NO longer a Pre-release feature and introduced the option of Azure Resource Manager [ARM] deployment. This removes the requirement of the traditional Azure Management Certificate and relies on Azure AD auth. to create the modern resources. Note – The CMG deployment with ARM continues to use the classic cloud service, which the Cloud Service Provider [CSP] doesn't support. This blog post intents to give you a step by step instructions of implementing CMG on ARM.

Environment

Here's a snapshot of the lab environment I used to implement this feature. Note - Starting 1802 you can no longer host an HTTP MP to listen to CMG traffic. The change is introduced to provide better support for Azure AD token-based auth.

1 Certificates

The following certificates are required -

Client Authentication Certificate – For Clients and MP
Server Authentication Certificate – For HTTPS - MP
Cloud Management Gateway Certificate – For CMG
Trusted Root Certificate – For CMG

Here's a table for additional clarification –

1.1 Instructions

Refer this table for instructions to generate the required certificates.

Type	Instructions to create
Client Authentication Certificate	https://technet.microsoft.com/en-us/library/gg682023.aspx#Deploying%20the%20Client%20Certificate%20for%20Windows%20Computers
Client – Trusted Root Certificate	On a client PC, follow the instructions – MMC > Add remove snap-in Certificates > Local Computer Personal > Certificates Right click and Open Click on Details Tab Click Copy to File Follow the defaults from the wizard to save the certificate file.
CMG – Trusted Root Certificate	The above certificate will work if you are using the same CA, else get the Trusted Root CA cert from the Certificate authority. Not needed for public CA's
Server Authentication Certificate	https://technet.microsoft.com/en-us/library/gg682023.aspx#Deploying%20the%20Web%20Server%20Certificate%20for%20Site%20Systems%20that%20Run%20IIS

I have generated the following certificates from my CA (Trusted Root cert was copied from client cert) -

Type	Name	Notes
CMG Certificate	cmgarm.contoso.net	For Cloud Management Gateway
Server Authentication Certificate	remote2.contoso.net	For HTTPS Management Point
Client Authentication Certificate	win102.contoso.net	For the test client running Windows 10

2 HTTPS Configuration

We need to configure the Primary Site & Management Point for certificate authentication.

2.1 Primary Site -

Go to Administration > Site Configuration > Sites
Properties of Primary site > Client Computer Communication Tab
Check the box – Use PKI client certificate (client authentication capability) when available.
Clear the box – Clients check the certificate revocation list (CRL) for site systems. [Clear this only if you haven't published the CRL on internet.]
Under Trusted Root Certification Authorities click Set to specify the Client Root Certificate from section 1.1
Click OK to commit the changes.

2.2 Management Point –

Before proceeding, make sure that you have already associated the Server Auth. Certificate (remote2.contoso.net in my case) in the IIS website Bindings as per instructions (Configuring IIS to Use the Web Server Certificate) in step 1.1 Next Steps -

Go to Administration > Site Configuration > Servers and Site System Roles
Select the Site Server holding the MP role which you plan to change to HTTPS. [Remote2.contoso.net in my case]
Under Site System Roles, select Management point and go to it properties
Change the Client connections to HTTPS and click OK
Monitor the mpsetup.log for a successful install and mpcontrol.log to validate the health

3 Configure – Azure Services

For the new CMG-ARM model, we first need to configure Azure Services by creating a Web and Client applications which will be leveraged by CMG to create Azure resources.

On the ConfigMgr Console, go to Administration > Cloud Services > Azure Services.
Click Configure Azure Services on the ribbon menu.

Select Cloud Management in the Wizard.
Provide a Name and click Next to proceed.

Click on Browse to either Import an existing App or click Create to start with a fresh App.

You need to Sign in with a Subscription Admin.

Follow the steps for both Web and Client App to proceed with the wizard. Click Next, Enable Azure AD User discovery is not required for CMG and is optional if you'd like to check it and finish the wizard.

4 Setup CMG

Now we are all set to configure CMG.

On the ConfigMgr Console, go to Administration > Cloud Services > Cloud Management Gateway
Click Create Cloud Management Gateway on the ribbon menu.

Choose Azure Resource Manager deployment
Sign In with Azure Subscription Admin account
The subscription info and the Web App created in Section 3 will auto populate. Click Next to proceed.

Click Browse to specify the CMG Certificate generated by following instructions from Step 1.1 in my lab I used cmgarm.contoso.net
This will auto populate the Service name.
Choose your Azure Region
Choose Create new under Resource Group.

Add the Client Trusted Root Certificate from section 1.1
Verify Client Certificate Revocation checkbox [Clear this only if you haven't published the CRL on internet.]
Click Next to finish the Wizard.

The deployment in azure begins - CloudMgr.log will show the details of the CMG deployment. Sample snippet below – Resource Manager - Creating resource group cmgarm with location South Central US SMS_CLOUD_SERVICES_MANAGER 3/27/2018 6:02:27 PM 3140 (0x0C44) Resource Manager - Resource group cmgarm created SMS_CLOUD_SERVICES_MANAGER 3/27/2018 6:02:28 PM 3140 (0x0C44) Resource Manager - Creating cloud service cmgarm with deployment CreateCloudServiceba0f51cf-SMS_CLOUD_SERVICES_MANAGER 3/27/2018 6:02:28 PM 3140 (0x0C44) Resource Manager - Creating storage service cmgarm with deployment CreateStorageService7cabb6ec-SMS_CLOUD_SERVICES_MANAGER 3/27/2018 6:02:45 PM 3140 (0x0C44) Uploading file C:\Program Files\Microsoft Configuration Manager\inboxes\cloudmgr.box\CloudProxyService.cspkg to container deploymentcontainer with blob name cmgarm.cspkg in storage account cmgarm SMS_CLOUD_SERVICES_MANAGER 3/27/2018 6:08:44 PM 3140 (0x0C44) Log in to the Azure Console to view the resources Validate the status Ready from ConfigMgr console.

4.1 CMG – Connection Point

This is the on-premise site system role dedicated for communication with CMG in Azure.

Add new site system role and choose Cloud Management Gateway connection point
Validate the Gateway name we just created and the Region to finish the wizard.

The Connection Point server will show as associated in the console. For troubleshooting this component, you can check SMS_Cloud_ProxyConnector.log.

4.2 Allow Gateway Traffic

We need to configure the Management Points and Software Update Points to listen to CMG traffic from Internet clients.

On the Management Point Properties, check the box Allow Configuration Manager cloud management gateway traffic
Follow the same steps for Software Update Point.

Once associated, the server endpoints will be listed under CMG – Connection Point

5 Client Validation

The client machines will receive CMG connection info which can be verified by the following registry key – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Internet Facing On a test client outside corporate network, check CCMMessaging.log to validate a successful communication with CMG Raising event: instance of CCM_CcmHttp_Status {

ClientID = "GUID:12EF623B-2210-4C6B-A718-5CB7EB768BF7";

DateTime = "20180328050333.897000+000";

HostName = "CMGARM.CONTOSO.NET";

HRESULT = "0x00000000";

ProcessID = 2100;

StatusCode = 0;

ThreadID = 5228;

};

CcmMessaging 3/27/2018 10:03:33 PM 5228 (0x146C)

Initiate a Machine Policy Cycle and verify a successful download from PolicyAgent.log Initializing download of policy 'CCM_Policy_Policy5.PolicyID="{bbeea4ad-d0bf-4d64-b0a3-fabe72e99c56}",PolicySource="SMS:P01",PolicyVersion="33.00"' from 'https://CMGARM.CONTOSO.NET/CCM_Proxy_MutualAuth/72057594037927959/SMS_MP/.sms_pol?{bbeea4ad-d0bf-4d64-b0a3-fabe72e99c56}.33_00' PolicyAgent_ReplyAssignments 3/27/2018 10:05:04 PM 7588 (0x1DA4) Thanks, Arnab Mitra

Using ConfigMgr Co-Management to offload Windows Updates to Intune

Arnab Mitra [MSFT] — Tue, 12 Dec 2017 01:18:12 GMT

This post walks through moving Windows Update workloads to Intune. Co-Management for Windows 10 devices introduced in ConfigMgr 1710 release which enables you to move various workloads from traditional on-premise management to newer modern management capabilities hosted in cloud like Intune. One of the most sought-after requirement by enterprises is patch compliance and keep devices secure no matter where they are. For machines outside the corporate network, this typically requires hosting SUP in DMZ with IBCM or implementing CMG. However, in this case we will use Intune to deploy Windows 10 Quality and Feature updates.

Requirements –

Hybrid Azure AD joined (joined to AD and Azure AD) Azure AD automatic enrollment Intune Subscription Windows 10 version 1709

Co-Management Setup –

From a ConfigMgr 1710 console click Administration > Cloud Services > Co-management to launch the wizard. Sign In with your Intune account. Note – If its failing to connect, check the account has license for Intune/EMS. Now as we are ready to setup co-management, you want to decide if you'd like to Pilot the setting or apply for all clients. I am going with Pilot for testing. Now its time to move the workloads. In this case, we are moving the Windows Update policies to Intune. Choose a collection for the pilot group of computers. Click Next to finish the wizard. You will notice a configuration policy deployment is created and targeted against the collection you chose. A corresponding Production policy is also created and targeted against All System collection.

Intune Software Updates Configuration –

Next, we need to configure Software Updates policies in Intune. From the Intune console, click on Software Updates > Windows 10 Updates Rings. Create policy as desired settings and Assign to a Group of devices. (sample screenshots). For guidance on these settings refer this link - https://docs.microsoft.com/en-us/intune/windows-update-for-business-configure The client will receive new MDM policies for deployment. MDM Registry settings are stored in - HKLM\Software\Microsoft\PolicyManager\current\device\Update If you notice above screenshot has a policy named "Do not connect to any Windows Update Internet locations" This is in fact the Dual Scan Policy Enabled by ConfigMgr which blocks the client's ability to scan against Internet (Microsoft Update)

ConfigMgr Windows Update for Business Policy –

From the ConfigMgr console, create a Windows Update for Business Policy (matching the Intune policy) and target against the same collection of machines. This will disable the dual scan deferral policy. Now the client is ready to receive updates as per Intune defined settings for Software Updates. I have a 30-day deferral for Quality Updates, below is a screenshot of device after only applying the October updates. Checking for new updates don't offer November updates.

Reporting –

The ConfigMgr compliance reports will stop reporting the compliance for Quality & Feature Updates. You will have to rely on Intune dashboard > Software Updates Overview which isn't very detailed and I highly recommend implementing Windows Analytics Updates Compliance feature in OMS.

Managing Office 365 Updates –

You can continue using ConfigMgr to deploy Office 365 updates and report its compliance

Troubleshooting –

Verify Azure AD Hybrid Join Status – Use the command dsregcmd /status If the machine isn't Hybrid Azure AD joined, implementing Co-Management features will not help. You will see the device listed in Azure AD > All Devices Verify Intune Management – You should see the device listed in Intune > All Devices. If you don't see your device, make sure its member of CoMgmt collection and Intune device group which has targeted Software Updates Policies. For troubleshooting you can refer CoManagementHandler.log on client PC. Sync device to receive Intune MDM Policies. If you don't see Info button, its an indication machine isn't registered in Intune yet. Thanks Arnab Mitra

CMG Tip – Why you shouldn’t disable CMG from the default client setting

Arnab Mitra [MSFT] — Wed, 01 Nov 2017 00:21:04 GMT

If you are planning to use the Default Client Settings from 1706 to disable cloud management gateway which is enabled by default, you should reconsider your decision if you'd like to perform client installation over internet because the client will never receive the custom device settings.

Finding

If you end up in the above situation, you won't see any policy downloads – PolicyAgent.log - Synchronous policy assignment request with correlation guid {14F22612-ECB8-4D5E-B9A0-0FEC930CF69A} for Machine DESKTOP-OAV38LH completed with status 87D00231 PolicyAgent_RequestAssignments 10/28/2017 8:49:42 PM 6368 (0x18E0) From the ClientLocation.log you will find the actual cause - Cloud Management Gateway is not allowed to use on this machine ClientLocation 10/28/2017 9:10:12 PM 3840 (0x0F00) The resultant client setting can be misleading here – Using the PolicySpy tool, I could confirm CMG is in fact disabled.

Recommendation

A better approach to disable the cloud management gateway for clients which are always on-premise (Desktops/Servers) would be to create a client setting for Intranet Only devices. Changing this now won't remediate this existing Internet facing client because it's not allowed to receive any polices from CMG unless you reinstall the agent to receive the default client settings. Thanks, Arnab Mitra

Windows 10 Compatibility Scan with Configuration Manager

Arnab Mitra [MSFT] — Thu, 21 Sep 2017 18:23:05 GMT

Before deploying Windows 10, it's a good idea to check the readiness of your existing machines running Windows 7, 8/8.1, Or even Windows 10. In this blog post I will use setup.exe with /compat scanonly switch to check the compatibility without performing the upgrade. The reason for not choosing the Upgrade task sequence for this job is to avoid sending the whole 3.5 GB source files over the network.

Package & Command line

Here's the command line with switches to silently check the compatibility. setup.exe /Auto Upgrade /Quiet /NoReboot /Compat ScanOnly Since the clients don't need to download the full set of source files to check the compatibility, as the setup.exe only validates the existence of the files which can be even on a network share. Instead of creating a package with full set of source files, all i am using is a 1KB batch file to call a network share where the source files are located. Command line of the batch file: - start /wait \\\setup.exe /Auto Upgrade /Quiet /NoReboot /Compat ScanOnly exit /b %errorlevel% The client will still download some source files which is significantly less than the whole set. Here's a snapshot of the SMB traffic during this operation -

Program

The program for the package above simply executes the batch file. Based on the above network traffic, you might want to set the estimated disk space and the Max allowed run time. It should run regardless a user is logged on or not.

Results

The resultant output of the scan results is not the typical 0 for success, refer the table below for the list expected Decimal Output returned by ConfigMgr and Hex Code returned by the windows setup log files.

Reporting

For reporting purposes, you can leverage the attached report which takes the package name as input. Refer the screenshot below.

Task Sequence

The above package can also be called out in a Task Sequence where you can add additional steps to capture logs in case of failure. Attaching the exported TS for reference. Step 1 – Add an Install Package step to run the above package. Make sure you check the box Continue on error in the Options tab. Step 2- Add a group to Capture Logs if the result is anything other than -1047526896 which is Success/No issues found. Step 3 – Map Network Drive to a server share where you want to dump the log files Step 4 – Create Folder for each computer. Step 5 – Copy the Log files to the network share. Step 6 – Copy the XML files to the network share. Step 7 – Disconnect the Network Drive

Reporting – TS

Refer the attached report which takes the Task Sequence name as input to display the compatibility results. Screenshot below. Download Reports - Note – The reports are built using SSRS 2016 schema. Legacy Reports - For importing into SSRS 2008 R2, 2012 & 2014 Download Task Sequence Thanks, Arnab Mitra