Tag Archives: Azure

Cloud distribution point support for Azure Resource Manager

This post will show deploying a Cloud Distribution Point in Azure Resource Manager which is a new feature in SCCM Technical Preview 1805. Now you don’t need to create and upload a management certificate to Azure.

For a list of the other new awesome features in SCCM Technical Preview 1805, see https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1805#cloud-distribution-point-support-for-azure-resource-manager

First step is to configure Azure Services to create the Client and Server app registration in Azure, otherwise you will get this error when creating the Cloud DP:


Right click Azure Services and select Configure Azure Services


Give it a name and select Cloud Management and click Next.


Click on Browse to create the Server and Client apps.


Click on Create


Give it a name and sign into Azure then click on OK to create the App. Do the same for the Client App.


Once you have created both apps, click on Next.


You can see the apps now in App registrations, then click on All apps in portal.azure.com


Azure Active Directory User Discovery doesn’t need to be enabled for this example. If you do choose to configure it, make sure to give permissions to the Azure apps above in the Azure portal. There are plenty of other blogs for this. Click on Next and leave the other options as default to finish off the wizard.


I have created/requested/exported a certificate using these steps here https://docs.microsoft.com/en-us/sccm/core/plan-design/network/example-deployment-of-pki-certificates#BKMK_clouddp2008_cm2012 . I have gone into portal.azure.com then Cloud Services, and clicked Add to create a new cloud service and entered in the cloud service name I wanted, only to make sure it was available (unique) like in the picture below then canceled out. I have used that name for the common name when requesting the certificate.


In the ConfigMgr console, right click Cloud Distribution Points, click Create Cloud Distribution Point.


We now get the option to use the Azure Resource Manager deployment. Sign in with your Azure account and click Next.


I have chosen to create a new Azure Resource Group. Browse to the certificate you exported from https://docs.microsoft.com/en-us/sccm/core/plan-design/network/example-deployment-of-pki-certificates#BKMK_clouddp2008_cm2012 . This will re-populate the service name (which I made sure was unique earlier) and click Next and configure the rest of the settings like Alerts etc.


Once the Cloud Distribution Point status is Ready in \Administration\Overview\Cloud Services\Cloud Distribution Points, or check CloudMgr.log make sure the Cloud DP is enabled in the Client Settings under Cloud Services.


Now I have distributed an application to the Cloud DP, tested downloading the application from Software Center on the client, and in the DataTransferService.log you can see it downloading from the new Cloud DP.



ConfigMgr CB 1610 -Cloud Management Gateway

One of the features in the newly released 1610 update for ConfigMgr Current Branch is the pre-release Cloud Management Gateway. This is similar to the Azure Cloud Proxy feature released in the Technical Preview 1606. I wrote a post on this here.

One thing to note that seems to be different from the TP, is that the on-prem distribution point isn’t supported for cloud management gateway traffic. You will need to set up an Azure cloud based distribution point for clients to download content (applications etc). However, you can enable the Management Point and Software Update Point to receive cloud management gateway traffic.

You can see the limitations of the Cloud Management Gateway here

This post will show you how I set up the Cloud Management Gateway in a lab. I won’t dive into the certificates part but information can be found at Step-by-step example deployment of the PKI certificates for System Center Configuration Manager: Windows Server 2008 Certification Authority and

A bit of info about my setup:

  • Azure subscription (you can get a trial here)
  • ConfigMgr Current Branch 1610 environment
  • Azure Management certificate uploaded to manage.windowsazure.com
  • Cloud management gateway certificate for <name>.cloudapp.net. Info for that can be found here Note: this name needs to be unique and cannot exist in Azure
  • Workstation certificate installed on clients and exported as the root certificate
  • Management Point and SUP configured for HTTPS
  • Windows 10 client with Workstation Certificate enrolled to test 

As this is a pre-release feature, I enabled it when installing the 1610 update


Now you will see the Cloud Management Gateway under the Cloud Services section. Click Create.


Enter in your Azure Subscription ID which can be found from portal.azure.com or manage.windowsazure.com and select the Management Certificate (which needs to already be uploaded to Azure)


When the cloud service PKI certificate is selected from the Browse button, the service name and FQDN will automatically be filled in (this is the common name from when the certificate was requested). Make sure a unique name was chosen earlier for the certificate as it will create a cloud service in Azure with <name>.cloudapp.net

Also specify the client certificate root. You can see instructions here. Make sure this is done properly as the client will get certificate issues when trying to connect to the Management Point.


You have the ability to set thresholds to create alerts regarding the outbound traffic as Azure charges you based on the Outbound traffic.



You can watch the provisioning status. Or even better, examine the  CloudMgr.log so you can see exactly what is going on and look out for any issues or errors.


Enable the site to use PKI certificate. The workstations that communicate with the Cloud Management Gateway need a Workstation certificate enrolled. Workstation Certificates are covered here.


Next the Cloud Management Gateway connection point role will be added.


The information is filled in automatically


Once the role has been added, the Management Point and Software Update Point need to allow Cloud Management Gateway traffic. Make sure the Web Server certificate for the MP/WSUS is configured in IIS. There is a guide on that here 


On the client, while it has a connection to the Internal network, you can restart SMS Agent Host service so it picks up the new Internet management point.

Once that is done on my client, I have given the machine only Internet access and no internal network access. I have restarted SMS Agent Host and you can see in LocationServices.log it is using the Cloud Management Gateway and the ConfigMgr client connection type is set to Internet.


If you’re curious about what it looks like in Azure, if you go to portal.azure.com and go to Cloud Services (classic), you can see it created a ProxyService role which is meant to be running on an A2 VM.


Migrating a VMware VM to Azure using Azure Site Recovery

This blog post will show how I migrated a VMware virtual machine  to Azure using Azure Site Recovery. A full list of prerequisites for your Azure and on-prem environment can be found here.

My setup:

  • vSphere 5.5 on-prem
  • VMware account with read-only permission (this is what I chose, see here for account roles and what each one does. I do not need to shutdown the on-prem VM automatically)
  • Site to Site VPN in Azure – (no Expressroute yet) I will be failing over my VM into the Vnet associated with this site to site VPN so I can connect to it over private IP.
  • Configuration Server/Process server – A single Windows Server 2012 R2 in VMware with PowerCLI 6.0 installed. More info can be found here

 Creating the Recovery Services vault

In portal.azure.com click on More services, then search for Recovery Services vaults. Once in there create the Recovery Services vault.


Give it a Name, and select the Azure subscription, and either select an existing resource group or create a new one, and select the location.


Once the Recovery Vault is created, the Infrastructure will be prepared. In the Settings of the Recovery Services Vault that was created, select Site Recovery under Getting Started, then select Step 1: Prepare Infrastructure.



Microsoft Azure Site Recovery Unified Setup will be downloaded so it can be installed it on the VMware Configuration Server, and the vault registration key will be downloaded.


Installing Site Recovery Unified Setup on Configuration Server

In order to proceed, the Configuration Server in VMware needs to be setup. To do this Site Recovery Unified Setup needs to be installed on the Configuration Server in VMware.


MySQL Community Server will be downloaded and installed.


Browse to the vault registration key which was downloaded earlier


Depending on the environment, a proxy may need to be specified.


Specify a password which will be used for the MySQL database.


VMware machines will be protected. vSphere Power CLI 6.0 is already installed.


The network interface for the VMware virtual machine is selected.


The installation is completed.


Adding the VMware account to Azure configuration server to discover VM’s

On the desktop of the Configuration Server, there is a shortcut for Cspsconfigtool. Open this and specify the VMware service account. This will be used to discover virtual machines. I have created a service account in vSphere with read-only rights.

“A vCenter user account with a read-only role can run failover but can’t shut down protected source machines. If you want to shut down those machines you’ll need the Azure_Site_Recovery role. If you’re only migrating VMs from VMware to Azure and don’t need to failback then the read-only role is sufficient.”


The Configuration Server and vCenter host has been selected (I have greyed mine out)


Select the Azure subscription. I am using Resource Manager for my deployment model. Make sure you have a storage account to where the virtual machines can be replicated to, and a virtual network.


Give the Replication Policy a name and choose the appropriate values.


Select the appropriate capacity planning for your environment.


Installing mobility service on the VM to be replicated and migrated:

For the virtual machine to replicate to Azure, the mobility service needs to be installed. I have chosen to install this manually. The installation files can be copied from the Configuration Server in C:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc\repository directory.


Type in the IP address of the Configuration Server. You can get the passphrase by running the command below in the screenshot.


Now that the mobility service is installed, the virtual machine can be replicated. I have greyed out the values below. The source should be the Configuration Server, select Virtual Machines as machine type, vCenter and Process Server should automatically fill in.


Type in the name of the virtual machine which the mobility service as installed on


Type in the target name or leave it as default if it is supported


After the data has been replicated, the virtual machine is now protected.


In order to migrate the virtual machine to Azure, an Unplanned Failover will be performed. I have shutdown the on-prem virtual machine manually because a read-only account was specified for VMware (read-only role can run failover but can’t shut down protected source machines)

More information on Failovers can be found here


The Unplanned Failover is now complete.


On the virtual machine, select More, then select Complete Migration. This will remove the virtual machine from being replicated.


Once the migration has been completed the virtual machine can be seen running in Azure. I have deleted the on-prem VM in VMware and have updated the on-prem DNS to point to the private IP of the VM in Azure.

The virtual machine will be accessed over the site-to-site VPN (or even better if you are using an Expressroute)


Running VPN gateway dianostics in Azure Resource Manager

Recently when setting up an Azure Site to Site VPN, I was having a lot of issues and ran into Keith Mayer’s great blog post about how to run the diagnostics in Azure resource manager for Azure gateways. Most of the older blog post focused on the gateways in the older Azure portal (manage.windowsazure.com)

Take a look at Keith’s PowerShell script here – Step-by-Step: Capturing Azure Resource Manager (ARM) VNET Gateway Diagnostic Logs

When you run the script and use your admin credentials to login to Azure resource manager (portal.azure.com) and the older Azure portal (manage.windowsazure.com) you are left with a vpnlog.txt which has diagnostic information.

Examining the vpnlog.txt I was able to find:

Failure type: IKE/Authip Main Mode Failure
Type specific info:
Failure error code:0x0000362c
Policy match error


I was having a policy error. I was trying to set up RouteBased Azure Gateway with an on-prem Cisco ASA fireall. Looking at the Validated VPN devices in Azure, the Cisco ASA is not compatible with RouteBased.

SQL Server 2016 on Windows Server 2016 images now available in Azure

Now that Windows Server 2016 has been released, you can now find SQL 2016 on Windows Server 2016 images in the Azure Marketplace to deploy. You can deploy them from here.

The versions listed are:
SQL Server 2016 RTM Web on Windows Server 2016
SQL Server 2016 RTM Standard on Windows Server 2016
SQL Server 2016 RTM Enterprise on Windows Server 2016




SCCM Power BI Solution Template preview

A few days ago Microsoft released a public preview of the System Center Configuration Manager Power BI solution template

“Stand up a scalable and extensible System Center Configuration Manager dashboard in a few hours. Information is collected daily so you can see not only how your organization’s computer health looks like today, you can also see how those key metrics change over time. Quickly identify machines not up-to-date with software updates, successful and failed mitigations to malware infections to be able to act quickly.”

More information on this can be found here and you can download the template from here 


  • System Center 2012 Configuration Manager R2 SP1 or later. Read access to System Center Configuration Manager database is required.
  • Destination database: Azure SQL database or SQL Server database (SQL Server 2008 R2 SP3 or later).
  • For the machine where the installation is run, Microsoft .NET Framework 4.5 or later & PowerShell version 3.0 or later.
  • Power BI Desktop (latest version)
  • Power BI Pro (to share the template with your organization)

In this post, I am going to test installing the public preview of SCCM Power BI solution template in my lab which has:

  • ConfigMgr Current Branch 1606 & SQL server 2012 SP3
  • Windows Server 2012 R2  with Microsoft .Net Framework 4.5 installed
  • Azure SQL Database as my target database.

First thing I am going to do is create my target SQL server which will be an Azure SQL database.

Login to https://portal.azure.com

Below, I have clicked on Add, then given my database a name, created a new resource group, chosen a blank database, created a new SQL server, and used “S0 Standard” pricing tier as my ConfigMgr site is a very small lab.

When you create the new SQL Server, take a note of the login and password as you will need this later for the ConfigMgr Power BI Solution template setup.


Once my SQL database deployment has finished, I have gone into the SQL database overview, and copied down my Server Name as it is required for later.


Next up in my lab I have installed Microsoft-SCCMTemplate.exe which I downloaded earlier from here  . Once finished installing, you can configure the solution template. Again the requirements are listed. Click Next.


Enter in your source ConfigMgr database server details and select your ConfigMgr database, then validate and click Next:


Next I will enter my target database which is my Azure SQL database name. I have selected “Using Azure SQL” . Make sure in the Azure portal you enter in your public IP for the SQL Server firewall in your SQL Server settings in https://portal.azure.com otherwise you will get the error below as it cannot connect. Steps to add your IP to the firewall are here.


This is how it should look:


On the Customize page I have left settings as default and clicked Next.

On the Progress page you can download your PBIX file and open it up with Power BI Desktop. You can download PowerBI Desktop from here if you do not have it installed.


Once I have opened my downloaded PBIX file and opened it up in Power BI Desktop, I clicked on Refresh so it can get the latest data. It popped up for me to enter credentials to my Azure SQL database. Make sure you click on Database instead of Windows to enter your credentials, otherwise you will not have permission.


Once it has pulled the latest data, you can view the Overview as shown in the screenshot below, or you can view the other tabs Protection, Malware, Updates Compliance and Software.


Here is an example showing Update Compliance



ConfigMgr 1606 – Microsoft Operations Management Suite (OMS) in Azure

With ConfigMgr 1606, you can now connect Configuration Manager collections to the Microsoft Operations Management Suite (OMS) in Azure. The OMS Connector is currently a prerelease feature. As so, this is done in a lab. This blog will go through the steps on how to add the connector in ConfigMgr and the preqreuisite steps to take in Azure.

This blog post assumes you have a running ConfigMgr 1606 environment and a subscription in Azure.

The first step is to configure your ConfigMgr 1606 site to consent to use Pre-Release features.Make sure you read the disclaimer.


After this is done, we will turn on the “Pre-release  Microsoft Operations Management Suite (OMS) Connector”


Click Yes to the dialogue box (make sure to read the disclaimer)


Log in to the Azure Classic portal https://manage.windowsazure.com an go into your Azure AD, select Applications. Click on Add down the bottom.


Enter in the name you would like to use and select web application and/or web API and click next.


Enter in sign on URL and APP ID URI. I added in my ConfigMgr server name (http://configmgr.domain.com) for both.


Next we will log into the Azure Resource Manager https://portal.azure.com and create our OMS Workspace. Click on Browse then go to “Log Analytics (OMS)” then click on Add


Once this is created, we will go back in the Azure Classic Portal and go into our Azure AD then Application we created earlier to make a note of our Client ID and generate a key.


Next we will create our connection to OMS back in the ConfigMgr console:


This is the part that Technet did not tell us. The part with the red box around it is misleading. We actually need to give our application we created earlier access to our Resource Group in the Azure Resource Manager Portal (portal.azure.com). This is probably because Operation Insights was moved from Azure Classic Portal to Azure Resource Manager. Without doing this, I will show you what happens:


I will type in my tenant name and Client ID and secret key from before, click Verify, then click Next.


ConfigMgr is unable to pull any information about the subscription or Resource Group or the OMS Workspace


To fix this, we need to log back into https://portal.azure.com and go into our Resource Group with our OMS workspace and give our Application we created earlier access.


Go to Settings, then click Users


Click on Add, and type in the name of the Application you created in the classic portal https://manage.windowsazure.com I gave mine Contributor role for testing.


Now if we go back and try and add the Operations Management Suite Connection again, you will see that ConfigMgr can pull the information from our Resource Group and OMS Workspace.


There we go. This looks better! It pulled the information now that it has access.



You can view the OMS Connector here. You can also right click on it and go to properties to view the properties and add collections.


Once the connector is set up, it should install the Microsoft Monitoring Agent.


Next we will log into the Azure Resource Manager portal https://portal.azure.com and enable the ConfigMgr collections. Once you’re in the Azure portal, go to Log Analytics (OMS) then click on OMS Portal


Once in the OMS Portal, go to Settings


Go to the COMPUTER GROUPS tab, and click on SCCM, then click “Import Configuration Manager collection memberships” and save.


After it updates you should see the collections (I added some more)


You can click on the links to view more information



SCCM Azure Cloud Proxy Service for managing clients on the Internet

In Configuration Manager Technical Preview 5 with update 1606, Microsoft introduced the Azure Cloud Proxy Service for managing clients on the Internet. More info can be read here.

This post covers how I set up the Cloud Proxy Service in my ConfigMgr lab to deploy software to a client on the Internet (this is a technical preview and NOT reccomended for production environment, it was simply to test out the Cloud Proxy Service). Make sure your lab Configuration Manager is updated to version 1606 so you have the cloud proxy functionality (In the Configuration Manager console, go to Administration > Cloud Services > Updates and Servicing). I had a Visual Studio MSDN subscription for Azure. You can also sign up for a 30 day Azure trial here


I followed all certificate requirements here  (under certificates section of Cloud Proxy)  to create the custom SSL certificate for the cloud proxy service and to create the client certificates (and also export the client root certificate)

These certificates were created the certificates below using this Technet guide:

ConfigMgr Client Distribution Point Certificate
ConfigMgr Client Certificate
ConfigMgr Cloud-Based Distribution Point Certificate (custom SSL certificate as mentioned in Technet)
ConfigMgr Web Server Certificate

For the management certificate for Azure, I exported the custom SSL certificate with the private key as PFX file, and also exported the certificate as a .cer file which I would upload to Azure. The custom SSL cert will be used when setting up the Cloud service later.

Log into manage.windowsazure.com and click on Settings down the left hand side, then click on Management Certificates. Upload the your management certificate (in my case, I used my .cer as described above). Take a note to copy down your subscription ID in a notepad, you will need it later. This is also shown in Subscriptions right next to Management Certificates below.


In the ConfigMgr console, in Administration, expand Cloud Services, right click on Cloud Proxy Service and click Create Cloud Proxy Service.


Type in your subscription ID (which you can get from manage.windowsazure.com in the settings where you uploaded the management certificate) and browse to the Azure management PFX certificate(I exported this earlier from the custom ssl certificate). Azure will validate the certificates.


Type in your Service Name. This will appear as <servicename>.cloudapp.net once created in Azure. Select your region and select Instance number (amount of proxies it creates in Azure). Once you select your custom ssl certificate for “Certificate file” it will automatically fill in your service FQDN. This has to be a unique name in your namespace (ie it cannot exist). For Root certificate file –  select the client root certificate you exported earlier (steps are here under the “Export the client certificate’s root” heading which is in section of Cloud Proxy Service for managing clients on the Internet).
I unticked Verify Client Certificate Revocation.


Continue on with the rest of the wizard. Once the Cloud Proxy Service starts to provision you can see it in the area below. You can watch CloudMgr.log in the site server log file directory to see what is happening. The status will be set to Ready once complete. It should take around 10-15 minutes.



Once the status was set to Ready, on the public DNS (Internet) I created a CNAME DNS record to point my Service Name to my Cloud Service Name. For example azure.domainname.com to azuretestproxy.cloudapp.net. You can get the Cloud Service name by logging into manage.windowsazure.com  and going into the Cloud Service created by the Cloud Proxy Service, and view the Dashboard. It will say Site URL.

This was so my clients on the Internet could resolve the Service Name when they try and connect. Configuration Manager also needs to be able to resolve the Service Name as it has to establish connections with the Azure proxy. You can see this in the SMS_CLOUD_PROXYCONNECTOR.log later on.


Under Site Configuration, click Sites, and right click your site server and click properties then click on the Client Computer Communication tab and make sure you’re set to use PKI certificates,


Next we will add the Cloud Proxy Connector point. In Servers and and Site System roles, select your site, right click and add the Cloud Proxy Connector point: (details on adding site system roles are here).



Once this is complete, pay attention to the SMS_CLOUD_PROXYCONNECTOR.log  on the site server. You will see your Configuration Manager site server try to establish a connection with the Service Name (make sure your CNAME DNS record points the Service Name to the Cloud Service name).

The first time I set this up I saw some illegal character XML errors in SMS_CLOUD_PROXYCONNECTOR.log. I stopped the service and waited for CloudMgr.log to show it was fully stopped until starting it again and it resolved the issue.


Next we will configure our Management Point and Distribution Point to allow Configuration Manager Proxy traffic (you can also add this to your SUP if you like. Currently only Distribution Point, Management Point and Software Update Point are supported by the Cloud Proxy Service at this time of writing)

In Servers and and Site System roles, right click on your Distribution Point/Management point and click properties then tick the box to allow Configuration Manager Cloud Proxy traffic.


After you have done the above, you can restart SMS AGENT HOST on one of your lab workstation machines. It should pickup the new Azure proxy location.

Below is the behavior on my Windows 10 client when removing it from the internal network and having Internet access only.


While still removed from the internal network and only on having Internet access, I deployed a test application and installed it from Software Center:


When checking the LocationServices.log it came back with the “Service Name” created in the Cloud Proxy Service (I had my public DNS CNAME pointing it to my Azure cloud services name)


This is a bit of background of what is actually provisioned in Azure to get the Cloud Proxy to work. Earlier we created 2 instances. You can see these below. Also the “Site URL” is what I used to point my DNS CNAME from “Service Name” to “Cloud Service Name”


You can monitor SMS_CLOUD_PROXYCONNECTOR.log to make sure nothing funny is going on. You can see every 60 seconds it scans the connections and confirm that the proxy connector is connecting to Azure ok.