• Automate your Monthly Maintenance Windows


    Hi All,

    A lot of customers I visit create their maintenance windows on  a monthly basis to patch servers, which is a boring and mundane task. I've dabbled in creating scripts with the help of some other PFE’s in the past but I recently created a very nice Dynamic PowerShell script that allows the creation of maintenance windows on a monthly basis and is based on the format of your collection. The idea came while I was onsite with one of my customers who formatted his collections similar to the following format.

    MW – Patching – Day 1 08:00

    This allowed me to take in the name of all collections and split the values to give me the day after patch Tuesday and the time of the day in 24 hour format of the maintenance windows.

    Ill run through an example and then show you how it works in the script.

    So based on the premise that Day 0 is patch Tuesday

    The collection above will create a maintenance window for that collection on Day 1(Wednesday after patch Tuesday)  at 8:00am local time

    The following script will work via PowerShell or you can incorporate it into Orchestrator which is what I have done with my customers with a slightly more complex script using PowerShell Remoting.

     Here is the entire script.

    #This Script will create maintenance windows dynamically for Monthly patches
    #Add Variables
    $Duration = '3' #Set the Maintenance windows duration e.g 1 for 1 hour
    $CollectionName = 'Maintenancewindows*' #Add Collection Name can use * as a wildcard e.g. MW - Patching - Day*
    $Exclude = '' #Add Collection Name can use * as a wildcard e.g. *OOB Day 0*
    $MWException = 'Ad Hoc*' #name of exclusions for maintenance windows e.g. Ad Hoc*
    $SiteCode = 'PRI' # Put your sitecode here
    $Trace = "" #leave this as is to clear the Trace variable this is used for logging

    #Import the Configuration Manager Module
    Import-Module (Join-Path $(Split-Path $env:SMS_ADMIN_UI_PATH) ConfigurationManager.psd1)
    CD "$($SiteCode):"

    #Run the function to get Patch Tuesday
    $Trace += "Getting Patch Tuesday `r `n"
    #Get Patch Tuesday in appropriate format
    $CurrentMonth = Get-Date -UFormat "%m"
    $CurrentYear = Get-Date -UFormat "%Y"
    $Day = "Tuesday"

    function Get-DayOfMonth {


        Process {

        $daysInMonth = [datetime]::DaysInMonth($year,$month)

        1..$daysInMonth | Foreach-Object {

            $d = Get-Date  -Year $year -Month $month -Day $_

            if ($d.DayOfWeek -eq $day)
                return $d
            } | Select -Index 1

    #Add the names of all the selected collectionsinto an array
    $Names = (get-cmdevicecollection | Where {$_.Name -like $CollectionName -and $_.Name -notlike $Exclude}).Name

    #for each collection get the name and split it into multiple variables
    Foreach ($Name in $Names)
        $CollectionID = (get-cmdevicecollection | Where {$_.Name -eq $Name}).CollectionID
        $NameSplit = $Name.split("")
            $Trace += "Splitting details for MW Monthly `r `n"
            $AddDays = $NameSplit[5]
            $AddHour = $NameSplit[6]
            $AddHoursplit = $AddHour.split(":")
            $AddHours = $AddHoursplit[0]

            #get the day for the Monthly MW Cycle
            $Trace += "getting date for MW Monthly `r `n"
            #Get Patch Tuesday
            $SUSecondTuesday = $CurrentMonth | Get-DayOfMonth -year $CurrentYear -day $Day | Get-Date -Format "yyyy/MM/dd" 

            #Add 1 Day to get Wednesdays Date
            $addday = (get-Date $SUSecondTuesday).AddDays($AddDays) | Get-Date -Format "yyyy/MM/dd HH:mm:ss"
            $addday = (get-Date $addday).AddHours($AddHours) | Get-Date -Format "yyyy/MM/dd HH:mm:ss"

            #Delete any Existing Maintenance windows which are older than today exluding any starting with either OOB* or Monthly *       
            $Trace += "getting MW details for MW Monthly `r `n"
            $MWNames = (Get-CMMaintenanceWindow -CollectionId $collectionID | Where {$_.Name -notlike $MWException}).Name
            Foreach ($MWName in $MWNames)
                #Compmare the MW time with today
                $Starttime = (Get-CMMaintenanceWindow -CollectionId $collectionID -MaintenanceWindowName $MWName).Starttime
                $Timespan = NEW-TIMESPAN –Start $StartDate –End $Starttime
                $compare = ($Timespan).Days
                #If the MW is older than today delete it.
                If ($compare -like '-*')
                    $RemoveMW = Remove-CMMaintenanceWindow -CollectionId $CollectionID -MaintenanceWindowName $MWName -Force
                    $Trace += "Removed the following Maintenance window $($MWName) from $($CollectionID) `r `n"

            #Create a Schedule
            $ScheduleDate = $addday
            $Schedule = New-CMSchedule -Start $ScheduleDate -DurationCount $Duration -DurationInterval Hours -Nonrecurring
            #Apply a Maintenance window
            $Trace += "Creating MW for MW Monthly `r `n"
            $NameMW = "Monthly $addday"
            $NewMW = New-CMMaintenanceWindow -CollectionID $CollectionID -ApplyTo SoftwareUpdatesOnly  -Name $NameMW -Schedule $Schedule
            $Trace += "Added the following Maintenance window to $($Name) $($NewMW) `r `n"


    Now lets break it down

    The following function which was written by a fellow Senior PFE based out of Sydney helps us find the actual date of Patch Tuesday for this month


    We then collect the names of the Collections excluding anything we specified in the $Exclude variable


    We then create a ForEach loop to do the following in each collection

    Split the name and adjust the Date and time for the schedule


    Get existing maintenance windows and delete any older maintenance windows


    Create a Schedule and create the monthly maintenance windows


    Before we run the script well look at the collections. I have 4 collections only one that has current maintenance windows


    When we look at the properties we can see that the collection has two current maintenance windows. An old one from last month that wed like to delete and one that in the future for the upcoming Sunday that somebody has already created on an Ad hoc basis that wed like to keep.


    After the script runs we want the Ad Hoc Maintenance windows to still be there and the old Monthly one to be removed. Along with our new Monthly maintenance window so in the script well add ‘Ad hoc* to the $Exclude variable

    Lets run the script and see what happens


    I have highlighted two areas. Firstly we can see in my trace that we have gone and removed the old Monthly maintenance windows and we then created 4 new monthly maintenance windows.


    If we go back into the console we can see that all of the collections have Maintenance windows now

    Lets go into each one and make sure we have the correct times and dates

    So this months patch Tuesday occurred this week on the 10th of November 2015. So I expect the following

    MaintenanceWindows - Patching - Day 5 08:00 to have two maintenance windows. Ad Hoc and a monthly maintenance window on the 15th of November at 8:00am

    Looking at the collection maintenance windows properties we have exactly that


    MaintenanceWindows - Patching - Day 5 21:00 to have one maintenance window. A monthly maintenance window on the 15th of November at 9:00pm


    MaintenanceWindows - Patching - Day 8 09:00 to have one maintenance window. A monthly maintenance window on the 18th of November at 9:00am


    Finally MaintenanceWindows - Patching - Day 8 22:00 to have one maintenance window. A monthly maintenance window on the 18th of November at 10:00pm


    Ensure that when you play with this script in your Dev environment that you change the variable to match your collection names maintenance windows and site code.

    So you can see that with a little bit of PowerShell you can actually save yourself a lot of time and effort. This is just a very small example of how you can automate Configuration Manager so download the latest set of cmdlets and start enjoying the power of automation.


    PLEASE NOTE this script is a sample only and should be adjusted to your unique environment and thoroughly tested in a development environment before any use.

  • Creating Intune Trial via Office 365 Portal

    Late last month we disabled the old Intune Account portal ( and replaced it with the o365 portal (

    See for the formal announcement.

    Since the change, there has been some confusion around how to create an Intune trial tenant. This guide should clear up each step required.

    First, browse to the Microsoft Intune product page ( and select the Try Now button.


    You’ll find yourself directed to the page. Enter your registration details


    Create your user ID, the tenant name ( and a strong password. Note that this tenant name cannot be changed without recreating your tenant, so choose wisely.


    You’ll get a confirmation page and email. Press the You’re ready to go… button to continue


    You’ll be presented with a Getting started with Microsoft Intune page. To begin, press the Start button to begin creating users.


    You’ll be redirected to the Office 365 admin centre. In the menu on the bottom left, you’ll see your Azure AD and Intune links, which means you’ve got your Intune trial started successfully.


    If you wanted, you could now start enrolling devices using the first created user. This is the user that you created by default during the setup phase.

    The Intune link should just automatically work, however for the Azure AD you need to activate a subscription. You’ll need to have either your EMS or AADP subscription, or enter some payment information into the signup process. I won’t do that here as I don't have either.


    And that’s it. You can now go ahead and configure your public domain names, get some Active Directory sync happening and start configuring MDM policies.

    Matt Shadbolt

  • Where is The System Center Configuration Manager Cmdlet Library




    Hi all, just a quick post today.  I found it difficult to find the location of the latest cmdlet updates for the Configuration Manager  PowerShell module while doing a general search on the web.

    What we now have is The System Center Configuration Manager Cmdlet Library which checks for library updates on a daily basis and notifies you to download the updated library when searching the web. 

    I’ve found that a lot of customers I visit when automating Configuration Manager do have older Powershell cmdlets and are not taking advantage of the latest Powershell cmdelts available to them, so If you haven't updated lately have a look at the link below

    Here is the link the TechNet reference

    and the link to the download

    Happy automating


  • So you want to test your NDES/SCEP certificate enrollment?

    SCEP (Simple Certificate Enrollment Protocol) and NDES (Network Device Enrollment Service) are the mechanisms we currently use to deploy certificates to our mobile devices via Intune and Configuration Manager. The tech is very (very) cool, but for the average ConfigMgr admin it’s got quite a steep learning curve.

    Once you (kinda) understand how it all works, you’ll begin to test your configuration. Testing NDES and SCEP is a pain in the neck, as there are so many moving parts. Worst is having to troubleshoot certificate enrollment on the tiny screens of your mobile devices.

    Luckily, we can test & troubleshoot via our Windows workstations.

    In my scenario, I’ve got an NDES server hosted in Azure. I know the NDES server is ‘up’ as browsing the URI works fine ( I want to test that the NDES certificate template is deployed correctly, and the certificate is valid.

    First, you’ll need to create an .inf file that will hold some request information. It should include the requests Subject name and the RequestType as a minimum. You can also add all the optional attributes you want or need. For example, my NDES template has a minimum key length of 2048, so I needed to add the KeyLength attribute too. (Certreq.exe INI File Structure)


    Subject = “CN=TestNDESCert”
    RequestType = SCEP
    KeyLength = 2048

    Once we have our request .inf, we need to create a certificate request. From a command line with Admin elevation

    certreq –v –config –username MYDOMAIN\Administrator –p Password –new request.inf scepRequest.req

    Lets break this down.

    certreq –v –config is my NDES server that’s publically available. The certreq documentation notes that to use https you must specify the URI instead of the FQDN, however in my testing on Windows 10 I could not get https to work. From my tracing I found certreq dropping a “http://” in-front of any URL that I passed into the command-line. SO, if you’re using https, you may have to enable http for this sort of testing.

    -username MYDOMAIN\Administrator –p Password is my test users username and password

    -new request.inf scepRequest.req is the verb calling a new request feeding my request.inf (created above) and an output file scepRequest.req

    You should get something like this back from the command


    If you now check on the CA, you should see a certificate has been issues to this client


    Now that we have our request, we need to submit it to the NDES server to receive our certificate.

    certreq -v -config -submit scepRequest.req scepCert.cer

    This is pretty straight forward. Submit the newly created scepRequest.req request file, and receive a certificate scepCert.cer from the NDES server.

    Finally, install the certificate and view it in your Certificates – Current User MMC snap-in

    certreq -accept scepCert.cer



    Happy testing!

    Matt Shadbolt

  • Where the heck are my Android Web Apps?!


    When I deploy web apps to Android devices they never show up in the Apps list. Where the heck are they!?


    Intune Web Apps are basic URL shortcuts that are delivered to Intune managed devices. They’re great for dropping links on devices to your Intranet, your favourite SaaS web portal or that website that all of your users require day-to-day.


    When you deploy a web app to an iOS device, the web app is displayed on the users home screen just like any iOS application.

    Many people expect the same to be true for Android deployments. This isn’t the case. You’ll find the deployed web app from within the Intune Widget.

    To view the web app, you’ll need to add the Intune Widget to your home screen.

    Press and hold the background of your home screen until it allows you to edit the apps/wallpapers/etc. You’ll see a Widgets option. Press that icon.


    Find the Company Portal widget


    Select and hold the widget. You’ll be prompted to drop the widget onto your preferred home screen


    Let it go in place, and you’ll now see your deployed Web Apps


    Matt Shadbolt

  • Starting NDES Services (Device Registration Service) Fails with “object does not exist”

    I ran into this issue when configuring SCEP/NDES certificate registration for an Intune tenant.

    Following all the best practice configuration steps, left me with an SCEP enrollment page returning Internal Server Error 500 instead of the expected 200.


    I found that the Device Registration Service was not starting correctly. In the event logs I found it attempting to start and then stopping


    The two most helpful event are the EventID 137


    Failed to find the Device Registration Service object at DeviceRegistrationService.

    Additional information
    Error Message: The object does not exist..
    Error Result code: NoSuchObject.

    and EventID 157


    An error occurred.

    Additional information
    Error: Failed to find the Device Registration Service object in the configuration naming context in domain

    It’s essentially saying that the DeviceRegistrationService objects have not been successfully written to AD.

    If I browse the Configuration partition of my Active Directory, I can see there is no Device Registration Configuration


    And if I run the following Get-AdfsDeviceRegistration PowerShell cmdlet, I’ll get a configuration error


    To fix this, run Initialize-ADDeviceRegistration


    You’ll then find the Device Registration Configuration objects in your Active Directory


    Start the Device Registration Service again, and all should start as expected.


    Restart the NDES server just to be sure everything is talking correctly, and test the SCEP URL again. This time we should get a 200 instead of 500


    Matt Shadbolt

  • Network Device Enrollment Service (NDES) – ERROR_SERVICE_EXISTS

    Ran into this doozy this week while trying to re-add the NDES role services.

    The specified service already exists. 0x80070431 (WIN32: 1073 ERROR_SERVICE_EXISTS)


    The fix is to ensure there are no lingering NDES configuration.

    From Regedit, delete the following key (back it up first!)


    Matt Shadbolt

  • System Center Endpoint Protection for Windows Server 2003

    A quick reminder that Windows Server 2003 is coming to end of life and will be unsupported after July 14 2015 – a mere 20 days away.

    While your Server 2003 OS will continue to run it is important to note that for people using System Center Endpoint Protection (SCEP) for antivirus – definition updates will no longer be provided.

    From the Configuration Manager Team Blog: -

    “On this same date, customers using System Center Endpoint Protection or Forefront Endpoint Protection on Windows Server 2003 will stop receiving updates to antimalware definitions and the engine for Windows Server 2003. “

    You can detect operating systems with SCEP installed using Compliance Settings in Configuration Manager and reporting on the value of the following registry key.

    HKLM\Software\Microsoft\Microsoft Antimalware\EndOfLifeState

    A value of 2 means that the operating system is nearing end of life – while a value of 3 means the operating system is no longer supported by the SCEP client.

    So what can you do – not a lot unfortunately except continue to migrate applications and services residing on legacy systems. As the team blog states: -

    “We have found in our research that the effectiveness of antimalware solutions on out-of-support operating systems is limited. Given the fast pace of technology, it has become increasingly important that customers use modern software and hardware that is designed to help protect PCs and servers against today’s threat landscape.”

    Details on how you can plan for migration and tools which can help can be found here

  • Intune and Configuration Manager UserVoice Launched

    Hello All,

    Very brief post today. The ConfigMgr and Intune team has formally released their own UserVoice pages to receive feedback and bugs from customers and the field.

    For any potential bugs, we still suggest raising a Premier Support call, as these are often the fastest and most reliable way of getting bug fixes approved.


  • Enable or Disable Incremental Collection Updates via PowerShell

    Hi Gang.

    Here is a couple of functions I’ve written to enable or disable Incremental Collection updates by Collection Name or Collection ID.

    Enable via Collection ID

    Enable-IncrementalUpdates -CollectionID PRI0000C

    Enable via Collection Name

    Enable-IncrementalUpdatesCollectionName “CU Deployment” 

    Disable via Collection ID

    Disable-IncrementalUpdates -CollectionID PRI0000C

    Disable via Collection Name

    Disable-IncrementalUpdatesCollectionName “CU Deployment” 

    I’ve also added an optional parameter to specify the Server Name, so this can be run remotely by adding the SMS Provider name to your cmdlet

    Enable-IncrementalUpdates -CollectionID PRI0000CServer PRI

    And of course it’s pipeline enabled

    Import-CSV -Path .\collections.csv | % {Enable-IncrementalUpdates -CollectionName $_.Collection}

    Here’s the code

    Edit: Thanks to our commenter below, I’ve updated the script to perform the change depending on the membership schedule setting.


    function Disable-IncrementalUpdates {

    [Parameter(Mandatory=$true,ParameterSetName="collectionID", Position=0)]
        [Parameter(Mandatory=$true,ParameterSetName="collectionName", Position=0)]
        [Parameter(Mandatory=$false,ParameterSetName="collectionName", Position=1)]
        [Parameter(Mandatory=$false,ParameterSetName="collectionID", Position=1)]

    if(!$server){ $server = '.'}
    $siteCode = @(Get-WmiObject -Namespace root\sms -Class SMS_ProviderLocation -ComputerName $server)[0].SiteCode
    gwmi sms_collection -ComputerName $server -Namespace root\sms\site_$siteCode -Filter "CollectionID = '$collectionID' or Name = '$collectionName'" | % {
    $collection = [wmi] $_.__Path 
    If($collection.RefreshType -eq 4) {$collection.RefreshType = 1}
    If($collection.RefreshType -eq 6) {$Collection.RefreshType = 2}
    $collection.Put() | Out-Null

    function Enable-IncrementalUpdates

    [Parameter(Mandatory=$true,ParameterSetName="collectionID", Position=0)]
        [Parameter(Mandatory=$true,ParameterSetName="collectionName", Position=0)]
        [Parameter(Mandatory=$false,ParameterSetName="collectionName", Position=1)]
        [Parameter(Mandatory=$false,ParameterSetName="collectionID", Position=1)]

    if(!$server){ $server = '.'}
    $siteCode = @(Get-WmiObject -Namespace root\sms -Class SMS_ProviderLocation -ComputerName $server)[0].SiteCode
    gwmi sms_collection -ComputerName $server -Namespace root\sms\site_$siteCode -Filter "CollectionID = '$collectionID' or Name = '$collectionName'" | % {
    $collection = [wmi] $_.__Path 
    If($collection.RefreshType -eq 1) {$collection.RefreshType = 4}
    If($collection.RefreshType -eq 2) {$Collection.RefreshType = 6}
    $collection.Put() | Out-Null } 

    Happy POSHing!


  • ConfigMgr 2012 R2 Service Pack 1 or Service Pack 2? Understanding Your Upgrade Options

    With the recent release of ConfigMgr 2012 Service Pack 2 and ConfigMgr 2012 R2 Service Pack 1 in preparation for Windows 10, there has been a lot of confusion arise in the community around which Service Packs are required to be applied to your environment.

    To help assist you in determining which Service Pack(s) you will need to apply in your environment, please refer to the below table.

    Before upgrading your environment please ensure you review the Planning to Upgrade System Center 2012 Configuration Manager article to ensure you meet all requirements.

    Starting Version Desired End Version Service Pack 2 Required R2 Service Pack 1 Required
    ConfigMgr 2012 RTM ConfigMgr 2012 SP2 Yes No
    ConfigMgr 2012 RTM ConfigMgr 2012 R2 SP1 Yes Yes
    ConfigMgr 2012 SP1 ConfigMgr 2012 SP2 Yes No
    ConfigMgr 2012 SP1 ConfigMgr 2012 R2 SP1 Yes Yes
    ConfigMgr 2012 R2 ConfigMgr 2012 R2 SP1 Yes No
    New install ConfigMgr 2012 SP2 Yes No
    New Install ConfigMgr 2012 R2 SP1 Yes Yes
    • If you planning on enabling R2 features as part of your upgrade by running the R2 Service Pack 1 update, please ensure you are licensed for R2 features.                
    • If you are already running R2 there is no need to run the R2 Service Pack 1 update as the R2 features will already be enabled in your environment.
    There are also a number of great post already published outlining the complete upgrade process - Installing ConfigMgr 2012 R2 SP1
    This has been a quick post and all information is provided as is.
  • I Wrote An App – Azure Status Alerts

    While studying for the 70-533 Implementing Microsoft Azure Infrastructure Solutions exam (of which I passed!), I found it very easy to get distracted. The major distraction was my attempt to write a very basic .NET Azure Web App.

    My app is a very simple one. It has three functions:

    1. Manage Subscribers

    I’m using an Azure Web App to host the .NET application. It’s a very (very) simple MVC application using scaffolding and a single controller. The controller is handling the subscribe, unsubscribe and resubscribe functions.

    The form submits the subscribers email address into an Azure SQL Database.



    2. Read Azure Status Updates

    Because I’m not a developer, I didn’t want to go too hard-core down the .NET rabbit hole. All I needed was a way to read the Azure Status Updates and insert the data into the Azure SQL database.

    I went with what I know, PowerShell.

    I wrote a very simple PowerShell script, that consumes the RSS feed.

    Then I uploaded the script and created an Azure Webjob. Webjobs are run on a schedule (or continuously, or on-demand) and can execute a bunch of different code – bash, php, .cmd and of course PowerShell. The Webjob pulls in the information from the RSS feed, compares it with what has already been sent (to ensure no duplicates) and inserts the status into my SQL database.


    3. Email Subscribers

    Once the data has been pulled from the RSS feed and inserted into my database, I then use another PowerShell Webjob to send the status alert to the subscribers list. The script uses the Send-MailMessage cmdlet, and sends the email via an Office 365 subscription I have.


    The resulting email includes the status alerts title, it’s published time/date and the content of the status alert


    So there it is, a very (very) simple Azure Web App written by a ConfigMgr engineer with very little development experience. If I can write something like this, jump into your MSDN subscription and use your free Azure compute hours to have a crack yourself!


  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (Windows 8.1)


    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    I’ve previously enrolled Windows Phone 8.1, iOS and Android devices. I finally wanted to show that you can also enrol a full Windows 8.1 installation.

    First, logon to your Windows 8.1 machine and open the Windows Store


    In the search box, search for Company Portal


    Find the Company Portal app and install it




    Once installed, launch the Company Portal app



    You’ll be prompted to enter your domain credentials


    As we’re using ADFS, the logon process will redirect you to your on-prem ADFS server


    Now enter your password



    Once you’ve logged in, you’ll be reminded to enrol your device prior to applications being made available


    Now browse back to the Desktop, and open the Change PC Settings modern settings menu


    Browse into the Network subset


    And select Workplace


    Enter your User ID and press the Turn on button to start the enrolment process


    The device enrolment will lookup your enrollment services based on the username you’ve entered


    And will prompt for your domain credentials. You can see here it’s utilizing our ADFS server for logon.


    Agree to the terms of service, and press Turn on


    Once this has been completed, the Turn on button will change to a Turn off button.


    Now launch the Company Portal from your Apps menu



    And we can now see that we’re enrolled and my current devices are listed!


    Finally, we can see the client appear in the ConfigMgr console


  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (Android)


    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    We’ll enrol a Windows Phone 8.1, an iOS Device and an Android Device.

    Android Enrollment

    Android enrollment is almost as easy as enrolling your Windows Phone 8.1 device.

    First, start by opening the Google Play Store


    Search for Company Portal, like iOS it should be the first result. Select the Company Portal app from the search


    Press the Install button and Accept the warning about what services the client can access

    image Screenshot_2015-04-09-18-07-45

    Once it’s downloaded and installed, press the Open button to launch and configure


    Press the Next button to start enrolling your device


    Enter your credentials and the logon process will redirect you to your ADFS logon

    image image image

    The Android device will begin to enrol. Select Activate when prompted to accept the Activate device administrator

    Screenshot_2015-04-09-18-09-28 image Screenshot_2015-04-09-18-09-48

    Accept the Privacy Policy for the Samsung Knox services


    And your device should now be successfully enrolled!

     Screenshot_2015-04-09-18-11-32 Screenshot_2015-04-09-18-12-27

    And to confirm, we should now have this device appearing in ConfigMgr


  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (iOS 7)


    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    We’ll enrol a Windows Phone 8.1, an iOS Device and an Android Device.

    Apple iOS 7 Enrolment

    In this scenario, an end user is going to enrol their own device. We can use the Apple Device Enrollment Program (DEP) or the Apple Configurator tool to perform this for bulk corporate-owned devices, however this guide will not describe that process. I’ll write another post explaining these two techniques.

    From your iDevice, launch the App Store app


    In the Search field, search for “Company Portal”. The first result should be the Microsoft Intune Company Portal


    Press the GET button and it will begin to download and install



    Now find the Company Portal app and launch it


    You’ll be prompted to login. Press Sign In


    As we’re using ADFS, we need to add our username and then select the password field. The login process will then redirect us to our internal ADFS server to process the logon request. Enter your password when redirected to your organizations login prompt

    image image image 20150408_000459000_iOS

    After login is successful, you’ll be asked to Enroll your device

    image 20150408_000603000_iOS

    The screen will then jump to the iOS internal management profile installation process. You can see here that the Verified profile is for Mattslabs, and it is signed by the Microsoft Intune service

    To continue, press the Install button, and confirm when asked to Install Now

    image image

    The process will setup all requirement management services and certificates

    20150408_000643000_iOS 20150408_000626000_iOS

    And will ask for one final confirmation. Press Install and Done when complete

    image image

    The Company Portal app will then re-focus, and will enrol the device

    image 20150408_000752000_iOS

    You will now have access to Apps and Device Information

    20150408_000802000_iOS 20150408_000848000_iOS 20150408_000811000_iOS

    And just to confirm, the device should now appear in Configuration Manager


  • The Ultimate Intune Setup Guide – Stage 5: Enrol Your Devices (Windows Phone 8.1)


    Now that we’ve got our ConfigMgr and Intune environments speaking nicely to each other, we can start to enrol some devices.

    We’ll enrol a Windows Phone 8.1, an iOS Device and an Android Device.

    Windows Phone 8.1 Enrolment

    On your Windows Phone, display all apps and select Settings


    Under the default System view, select Workplace


    In the Workplace settings, select Add Account


    Add your Intune synchronized account, and press Sign In



    You’ll see the sign in screen notify you “We’re looking for your settings…”


    If you’ve got your ADFS setup correctly, you’ll be redirected to your on-prem ADFS servers. If you’re using password hash sync, you’ll be redirected to the Azure AD login prompts.

    Enter your password and press Sign in

    You’ll get confirmation of the account being added. Select the box to Install company app so you can install our Windows Phone app and press done


    You’ll be presented with a screen confirming the enrolment


    Finally, lets check the ConfigMgr console and we should see our Windows Phone 8.1 device


  • The Ultimate Intune Setup Guide – Stage 4: Enable ConfigMgr 2012 R2 Management


    Now that we’ve setup our Intune cloud services, it’s time to integrate the service with our on-prem Configuration Manager 2012 R2 hierarchy.

    In my lab environment, I’ve got a single Primary Site with all roles installed on the one site server. In a multi-tier hierarchy, the Intune connector roles can only be installed at the CAS site.

    1. The first thing we’ll want to do is ensure all of our prerequisites are met. If you’ve followed my previous three posts (here, here and here) you will already have Intune setup, public domains added and user accounts being synchronized. There are some outstanding steps to get our clients to work with ConfigMgr

      Create required DNS entries

      Our enterprise Mobile Device Management (MDM) clients will automatically look for their management services via a public URL during registration. This URL is EnterpriseEnrollment.<Your Company>.com

      In my lab scenario, that would be

      As we want these devices to speak via Intune for management, we need to redirect the DNS requests via a CNAME record to the Microsoft Intune management services.
      1. Open your public DNS management tools. In my example my domain is hosted with GoDaddy, so I’m using their DNS management console


        You can see here I’ve got my ADFS A record defined and the TXT record required for domain verification from this post
      2. Create a new CNAME record, name it EnterpriseEnrollment and target it at

      3. Save your zone file and wait until the record is replicated

      4. You should eventually be able to ping which will now resolve to

    2. The second requirement is the certificates needed to push software to devices. In my lab I plan to manage Windows Phone, Android and iOS devices.

      1. Acquiring the Windows Phone certificate.

        To side-load software onto Windows Phone devices via Intune, a Symantec Code Signing Certificate is required. These certificates must be purchased directly from Symantec.

        As I’m not willing to spend a few hundred dollars on my lab, there is a handy tool available for lab scenarios called Support Tool for Windows Intune Trial Management of Windows Phone. You can download it from 

        Download this MSI and leave it for later. In the next post (Stage 5), I’ll explain how to get the Support Tool working.
      2. Acquiring the iOS Apple Push Notification certificate

        To manage and deploy to iOS devices, you must have an Apple Push Notification (APN) certificate.

        Open your Configuration Manager Console, and browse to Administration > Overview > Cloud Services

        Right-click on Windows Intune Subscriptions and select Create APNs certificate request


        Set a path for the Certificate Request to be saved to


        When prompted, add your Intune Administrator credentials and press Sign in

        Once complete, close the window and browse to the location of the saved .csr file


        Browse to the Apple Push Certificates Portal 

        Sign-in or create an Apple ID


        Click on Create a Certificate

        Accept the EULA

        On the Create a New Push Certificate page, select the Choose File button and select the .csr file previously generated


        Click Upload


        After the success confirmation dialog, click the Download button to download your APN Certificate


        Hold onto this file for later

    3. Next, we can start to configure Configuration Manager. Open the Configuration Manager Console, browse to Administration > Overview > Cloud Services

      Right-click on Windows Intune Subscriptions and select Add Windows Intune Subscription


      You’ll be prompted with the Create Windows Intune Subscription Wizard

      1. Press Next to start the Wizard

      2. Click the sign-in button and enter your Intune Administrator credentials


        You’ll be prompted to confirm the ownership of the Intune MDM capabilities. Essentially, if you want to use Intune for MDM, it either has to be via the Intune Web console, or via the Configuration Manager console. It is one or the other, never both.

        Tick the check-box and press OK


      3. In the General Configuration, configure the user Collection in which you want members to have the ability to enrol their devices, some Company Branding and also the Configuration Manager Site Code in which any devices enrolled will become a member

      4. Tick the Android and iOS support buttons, and if you have a Symantec Windows Phone certificate, select Windows Phone 8


        Note: For those who are going to use the Support Tool for Windows Intune Trial Management of Windows Phone to test the Windows Phone management, don’t enable the Windows Phone 8 management. We’ll do this via the tool in my next blog post (Stage 5)
      5. Select the Apple APN certificate created earlier

      6. Provide some contact details for your users to see in the Intune Portal

      7. Add your Company Logo (if required)

      8. Complete the wizard

    4. To complete the installation process, we finally have to add the Windows Intune Connector site system role. To do this, open the Configuration Manager Console, browse to Administration > Overview > Site Configuration > Servers and Site System Roles


      Note here we have a server in the list. This is where you apps/etc will be stored for your MDM devices when they’re synchronized in later

      Right-click on your Primary Site Server, and select Add Site System Roles


      You’ll be presented with the Add Site System Roles Wizard
      1. Leave the General and Proxy settings default (unless you need to go through the proxy to get Internet access)

      2. In the System Role Selection window, select the Windows Intune Connector and press Next

      3. Press Next on the Summary screen and wait for a successful completion screen

      4. After a few minutes the role should be up and running.
    5. Finally, lets confirm that the integration and cloud sync is working. From the Configuration Manager Console, browse to Assets and Compliance > Overview > Users

      You should see all of your users listed


      Right-click on the title column, and add the column Cloud User ID

      This will add an extra column and display all of the Cloud User ID’s which has come from the Intune service. If the Cloud User ID is empty, that user will not be able to enrol their device or access any of the Intune services.


      Finally, browse to view your ConfigMgr Intune Branding


    We’ve now successfully configured the Configuration Manager integration with Intune.

  • Enable Windows Phone management via Intune without Symantec Certificate


    As part of my mega-post The Ultimate Intune Setup Guide, we enable the Mobile Device Management capabilities in ConfigMgr. One of the supported devices that we didn’t enable was the Windows Phone 8.1 management. The reason for this is the requirement of the Symantec code signing certificate, which needs to be purchased before we can manage these devices.

    To enable the Windows Phone 8.1 management in your test and demo labs, you can use the Support Tool for Windows Intune Trial Management of Windows Phone.

    Download the executable from the site and run the installer



    Agree to the EULA and press Next


    The default installation path will be C:\Program Files (x86)\Microsoft\Support Tool for Windows Intune Trial management of Windows Phone\


    Confirm the installation was successful


    Now create a Windows Phone Application using the XAP file extracted during the MSI install.

    Browse to C:\Program Files (x86)\Microsoft\Support Tool for Windows Intune Trial management of Windows Phone\SSP and copy the SSP.XAP file into your ConfigMgr Application Source


    Open the Configuration Manager Console and browse to Software Library > Overview > Application Management > Applications

    Right-click Applications and select Create Application


    In the Create Application Wizard, perform the following

    Add the .XAP path and select the Windows Phone app package (*.xap) from the drop down menu


    The wizard should automatically pick up the Apps details and create the Application




    Now add the Application to the Distribution Point, so that the app content will be available to your clients







    Now Deploy the app to your cloud enabled users









    Next, we need to enable the management of Windows Phone devices

    Open a Command Line as Administrator and change directory to C:\Program Files (x86)\Microsoft\Support Tool for Windows Intune Trial management of Windows Phone\Support Tool\



    Run the following command, replacing with your top level ConfigMgr server

    cscript ConfigureWP8Settings_Field.vbs QuerySSPModelName


    Now run the same script using the Model Name, this time using the SaveSettings parameter

    cscript ConfigureWP8Settings_Field.vbs SaveSettings ScopeId_ACB5D0B6-FDC7-459B-9BF3-A75D7E3F5B8D/Application_73602d66-47a6-4ab2-b069-8b5201c91091


    Finally, enable Windows Phone 8.1 Support via the Extensions for Windows Intune

    Browse to Administration > Overview > Cloud Services > Extensions for Windows Intune

    Right-click on Windows Phone 8.1 and select Enable


    Refresh until the extension becomes Enabled


    The application will now be installable on your Windows Phone devices.

  • The Ultimate Intune Setup Guide – Stage 3: Sync accounts from on-prem


    So far in this series, we’ve signed up to the Intune service and configured our public domain. In this post we’ll sync our on-premises Active Directory accounts to the Azure AD instance that Intune will use. This allows our users to logon to their Intune based services with their corporate credentials. I highly suggest that you enable these features, otherwise the user experience of having a separate username and password for Intune will not be good.

    Now, just to confuse things, there are generally two scenarios in which this has to be configured in different ways. I’m going to cover both.

    1. No on-prem Active Directory sync to the cloud* is currently in place
    2. Some form of Active Directory sync to the cloud* is currently in place

    * by cloud, I mean anything that might use DirSync such as Office 365, Dynamics Online, Azure AD, etc

    To confuse things even more, we have multiple options for Single Sign-On (SSO)/Same Sign-On (SSO) end user experience. I’m going to cover both, too!

    1. Password hash sync to Azure AD enabling Same Sign-on
    2. On-prem Active Directory Federation Services (ADFS) performing the authentication for Single Sing-On

    Note: A quick word on DirSync vs Azure AD Connect vs Azure AD Sync

    DirSync and FIM (Forefront Identity Manager) have long been the tools used to sync on-prem AD with cloud based services. While both tools have been around for a long time and are well known, there are some disadvantages to using them. DirSync for example doesn’t play well in multi-forest environments. While FIM does a great job in multi-forest environments, it is a large product and has quite a steep learning curve.

    The AD team have released a two new tools which replace the DirSync functionality.

    Azure AD Sync is a supported product that performs most of the functions of traditional DirSync, but adds extra functionality such as mutli-forest support and password write back. It is recommended to use the Azure AD Sync tool. You can download the public release from here

    Azure AD Connect is currently in Connect Preview and is not supported. It has many of the same features as DirSync and Azure AD Sync (in Preview), and has plans for many other features such as non-AD LDAP support and extended writeback support. You can download the Connect Preview from here

    For a full feature comparison across all four directory integration tools, please see the following MSDN page 

    If you plan to use the Azure AD Connect or Azure AD Sync tool for your directory synchronization, just replace all of my steps that include DirSync with the new tools.

    New on-prem Active Directory sync required

    Your first decision to make is how you’d like your users to logon using their corporate AD credentials. There are two ways we can achieve this.

    1. Password hash sync to Azure AD enabling SSO

    This is by far the easiest option. By enabling password hash sync, your users can logon using their corporate AD username and password. The service works via syncing a double hashed password (hashed once in your AD database, and a second hash via the DirSync tool) into the Azure AD cloud identity service. When the user logs on, the password is hashed and compared to that stored in the Azure AD service. If the hash matches, authentication is successful.

    2. Authentication redirect via Active Directory Federation Services (ADFS)

    ADFS is a secure way to redirect an authentication request to a locally managed server. Corporations install and configure their own ADFS infrastructure which handles the authentication requests. When a user attempts to logon to their Intune service, the authentication request is redirected to the corporately managed ADFS servers which perform authentication against the on-premise Active Directory.

    While ADFS is seen as slightly more secure than password hash sync, the management and cost overhead is often outweighs the small security increase. ADFS is also the only way to provide a true Single Sign-On experience.

    1. Password hash sync to Azure AD enabling SSO

    Enable Active Directory synchronization in Intune

    Go back to the Users subheading, find the Active Directory synchronization: Set up option and click Setup


    You’ll then be given a page with six steps to enable Active Directory sync.

    I’ve done the reading, so you don’t have to! (though it probably is a good idea to read each through)

    1. Prepare for directory synchronization
      1. Review object limits – 300,000 sync objects for a verified domain
      2. Review requirements for DirSync – Windows Server 2008+, joined ot the domain, .NET 3.5 SP1 and Windows Powershell
      3. Review requirements for domain controllers – Windows Server 2003+, Windows Server 2003 forest functional mode
      4. Ensure you have administrator permissions – local admin on the sync server and sufficient AD permissions
      5. Add alternate UPN suffix to AD – your users UPN suffix needs to match the domain you’ve added previously. This wont be required in most circumstances, however it’s a major reason for issues with the Intune service. Be sure your users UPN suffix matches the activated domain or your users can’t login!
    2. Verify domains – ensure the domains are verified as previously posted
    3. Activate Active Directory synchronization



      This step will enable the AD synchronization features across the entire tenant you manage


      You’ll receive confirmation that Active Directory synchronization is enabled
    4. Install and configure the Directory Synchronization tool


      We’re now prompted to download and install the DirSync tool. This is the agent that will run on a schedule and upload your directory objects into the Azure AD cloud service. Download and install this on your designated sync server.

      1. When prompted by Internet Explorer, save the dirsync.exe file


      2. Once downloaded, run the executable. It will extract the files and give you the installation UI

      3. Click Next when prompted to start the setup


      4. Accept the EULA and select Next


      5. Target the installation to wherever you desire. I’m leaving it as the default C:\Program Files\Windows Azure Active Directory Sync. Click Next


      6. Installation will then automatically start


      7. Once complete, click Next


      8. You’ll then be given the opportunity to run the Configuration Wizard. Select it and press Next


      9. On the Windows Azure Active Directory Sync tool Configuration Wizard, start it by clicking Next


      10. Enter your Intune tenants credentials and select Next


      11. Enter your local Active Directory credentials


      12. You’ll then be asked if you would like to enable a “Hybrid Deployment”. Hybrid Deployment allows attributes to be synced BACK from Azure AD into your locally stored Active Directory.
        Intune does not require a Hybrid Deployment, so don’t select this option


        For more information, and a list of the objects that can be written back, please see these links: 

      13. As discussed earlier, the easiest way to provide an SSO experience is with Password Sync. To enable Password Sync, select the check box Enable Password Sync and press Next

        Note: If you plan on using ADFS, you want to disable this setting.


      14. The wizard will then configure your DirSync services and notify you when complete



        NOTE: I was getting the following error when running this from my Domain Controller

        System.Management.Automation.CmdletInvocationException: A constraint violation occurred

        We don’t suggest that you run the DirSync tool from a Domain Controller, however we do support it. The trick to overcome this error is to logoff and logon before running the configuration wizard.
      15. Finally, select Synchronize your directories now and select Finish


    5. Verify directory synchronization

      1. Check the event logs of the synchronization server for sync start and stop events
      2. View your synchronized users from the Users view in the Account Portal


        Note: the important part is the UPN for each user
    6. Activate Synchronized users – once you’re synced users appear, you need to activate the users on the Intune side. This is essentially assigning the users a license to use the Intune service. Note that for each activated user, a license fee may be required.

      Select all of the users in which you want to enable Intune access, and select Activate synced users


    7. Finally, test the SSO experience by logging in with a test users account. Open an new Internet Explorer sessions using InPrivate Browsing

    8. Browse to and enter your Domain credentials

    9. You should be presented with a custom Organizational Intune portal page.



    2. Authentication redirect via Active Directory Federation Services (ADFS)

    If your organization requires true Single Sign-on and does not want to sync password hash to the cloud, the second option is to use ADFS. If your organization already has ADFS configured for other services, the majority of the work is already completed. If you don’t have ADFS, you should consult your AD team as it’s likely they’d be the ones installing the service.

    For this guide though, I’m going to install the ADFS services in the most simple manner to ensure our Intune users can logon using their corporate AD credentials.

    Start by logging into the page, and selecting Users. This time we’re going to select Single sign-on: Setup


    From this page, we’ll have 10 steps involved in configuring SSO. Again, I’m going to do all the hard work for you!

    1. Prepare for Single Sign-on
      1. Ensure Active Directory is running in either Windows Server 2003 R2, 2008, 2008 R2, 2012 or 2012 R2 and has a functional level of mixed or native mode
      2. Decide on your ADFS service design – for example, are you going to have an ADFS Proxy?
      3. If you plan to use Shibboleth Identify Provider, install and prepare it
      4. Install any required Windows Updates - 
    2. Plan for and deploy Active Directory Federation Services 2.0
      1. In my environment, I wanted to have ADFS running on a separate server. As it’s an Azure Virtual Machine, it’s quite easy for me to publish a public endpoint so that the server will be publically available for the Intune service to use it for authentication.
        In your environment, it may be configured differently.
      2. Firstly, as the server is going to be publically accessible, we need to secure the communications with an SSL certificate. Our ADFS configuration later will ask us to choose the required certificate, so lets get it ready now.
        I’ve got a wildcard certificate provided by the Digicert Certificate Authority (CA)

      3. From your CA, download the public certificate. Open the Certificates MMC by going Start > Run > mmc


        File > Add/Remove Snap-in…


        Select Certificates and press Add


        Select Computer account and press Next


        Select Local Computer and press Finish

      4. In the Certificates MMC, expand Personal > Certificates

      5. Right-Click Certificates, and select All Tasks > Import

      6. In the Certificate Import Wizard, press Next to get started

      7. Browse to the CA provided certificate and press Next and then Finish

      8. You’ll then have the certificate stored in the Personal certificate store, ready for use with ADFS

      9. Now, to install the ADFS role. On the new server, open up Server Manager, select Manage and click Add Roles and Features

      10. Next, Next, Next through the wizard until you come to the Server Roles section

      11. Select the Active Directory Federation Services role and select Next

      12. Leave the Features selection as it is, and press Next. You’ll be prompted with an ADFS confirmation screen, press Next to continue. Finally, press the Install button to install the ADFS role

      13. Once the role has been installed, select the Warning message in the Server Manager console. You’ll see a button to Configure the federation service on this server. Click that to launch the configuration wizard

      14. Select the Create the first federation server in a federation server farm from the radio boxes, and select Next

      15. As I’m running the installation using my Domain Admin account, I don’t need to specify a user. If you are running this with a restricted account, you’ll need to provide an account with Domain Admin permissions to configure ADFS

      16. Select the SSL Certificate we imported earlier, set the Federation Service Name to the name of the server you’re hosting ADFS on, and set a Federation Service Display Name and press Next

      17. Specify a Service Account which will run the ADFS services

      18. In most environments, you’ll want to use a Windows Internal Database. In larger environments, you may want to store the ADFS configuration in a SQL Database instead

      19. Review Options, confirm Pre-requisite Checks were successful and press Configure to setup the ADFS services.

        image image
    3. Install the Microsoft Online Services Module for Windows PowerShell
      1. To create the trust relationship between your on-prem ADFS server and the Microsoft Intune service, you need to install the Microsoft Online Services Module for Windows PowerShell. These are a set of PowerShell cmdlets that will allow you to configure Single Sign-On
        Before installing the PowerShell module, you need to install the Microsoft Online Services Sign-In Assistant v7.
      2. Download the Microsoft Online Services Sign-In Assistant v7 from and run the installer

      3. The installer will quickly complete


      4. Now download the 32-bit or 64-bit version of the Microsoft Online Services Module for Windows PowerShell via the page

      5. Run the installer

      6. Click Next on the installer splash screen, Accept the Terms and select a location for the installation to be installed to
      7. Click Install and confirm the installation was successful

    4. Verify additional domains
      1. Browse to the Domains tab in the portal and confirm your domain is Verified

    5. For 5. Prepare for directory synchronization, 6. Activate Active Directory synchronization, 7. Install and configure the Directory Synchronization tool, 8. Verify directory synchronization and 9. Activate synchronized users, follow the steps provided when configuring the Password Hash sync above.
    6. The final step, Verify and manage single sign-on is a little vague, as we actually haven’t completed all of the steps required.


      Before our Single Sign-On is working, we need to setup a trust relationship between the on-prem ADFS server and Microsoft Online
      1. All the required information can be found at

        On your ADFS server, Open the Microsoft Azure Active Directory Module, by browsing Start > Programs > Windows Azure Active Directory and run the console as Administrator

      2. Store your Intune Administrator credentials into a variable for later use, by typing

        $cred = Get-Credential

        Supply your credentials when prompted

      3. Next, connect to the Microsoft Online Service by typing

        Connect-MsolService –Credential $cred
      4. Set the ADFS server configuration by entering (note: if your Azure AD PowerShell module is installed and running on the ADFS server, you don’t need to perform this step)

        Set-MsolAdfscontext –Computer

        You’ll be prompted for credentials. These are your domain credentials.

      5. You now have two choices. First is to setup the Federated Domain if you have not configured Azure AD SSO with password hash sync. The second option is to convert a previously configured Azure AD password hash sync into a ADFS Federated SSO
        1. If you haven’t configured Azure AD Password Sync previously, run the following commands to setup the federation

          New-MsolFederatedDomain –DomainName

          You’ll be prompted to create a DNS record to verify that you own the domain


          As per my previous steps, create the DNS TXT record.
        2. Once the domain is authorized, re-run the following command to complete the configuration
          New-MsolFederatedDomain –DomainName

        1. If you have previously configured Azure AD Password Sync, instead of setting up a new Federated Domain, we need to convert the domain from a Standard Authentication Domain into a Identity Federation Domain

          Convert-MsolDomainToFederated –DomainName

      6. Finally, you should verify that your ADFS instance is working correctly. Perform the following steps
        1. Check your ADFS server is publically available.

          From an external address, ping your ADFS server and ensure it resolves correctly


          From a web browser, browse the ADFS URL


          Browse to, enter your on-prem credentials


          If ADFS is working, when you tab to the password box it should redirect you to your ADFS instance


          And prompt for your domain credentials


          Finally, you can see the ADFS redirection and authentication happening if you watch the browser path closely

      7. And we’re in!


    Active Directory sync already configured

    If you’re using one of the many Microsoft cloud platform applications such as Office 365 or Dynamics Online, it’s likely you’ll already have DirSync configured and synchronizing your on-prem directory with the Azure AD service.

    If this is the case, the majority of the work has been done for you!

    In my Intune Users console view, there are currently no users, other than my service administrator accounts.


    1. Verify that Active Directory sync has been configured. You’ll need to speak with whoever configured the first instance of DirSync for your organization. Have them logon to their Azure AD console and display the domain configuration.
      1. Browse to
      2. In the Azure management portal, find the Active Directory node and select it

      3. In the Active Directory node, you should see your organizations domain has been synced and it’s status is Active

    2. Verify that your domain has been added to Intune. From the console, select Domains and confirm it has been added and authorized. If your organizations domain does not appear, follow the instructions from my previous post on adding your managed domain.

    3. Enable Active Directory synchronization by browsing to Users, and pressing the Set up link

    4. It’s a bit confusing here, because we’re not really setting up AD Sync, rather we’re associating a previously configured AD Sync with our Intune tenant.

      Because DirSync and/or ADFS,  has been configured previously, we can skip to step 3 and just activate the Active Directory synchronization


      When prompted, press Activate


      Step 3 will return success when this is completed

    5. Now either wait for DirSync directory synchronization to run, or force it to run using Start-OnlineCoexistenceSync (, and check the Users console. You should not have all of your synchronized users appear in Intune


    We’ve now configured the Intune service to use your on-prem Active Directory accounts for logon.

  • The Ultimate Intune Setup Guide – Stage 2: Configure Your Public Domain

    We started The Ultimate Intune Setup Guide by signing up to the Intune service in the previous post.  This post we’re going to configure the Public DNS required for your public Intune service to work for your clients.

    Step 1 – Add your public domain to the Azure Management Portal

    First, open your browser and visit providing your Intune Global Admin credentials.

    You’ll be greeted with the Account Portal. Select the Domains link under the Management subheading


    In the Domains section


    Enter your public domain


    You’ll then be prompted to Verify domain. This process is required to ensure that the public domain that you’re specifying is actually owned by you.

    The process requires you to add either a TXT Record or MX Record into your public DNS provider. Azure then checks the value that you’ve set to confirm that you do in fact own the domain, and have write access.


    In my environment, I’ve got my public DNS hosted with GoDaddy, but the process is very similar across all DNS providers.

    Step 2 – Creating DNS Verification Records and Verifying

    Login to your domain/DNS provider, and find the DNS management section. You’ll want to edit the zone of the domain your users will login via


    You’ll probably see a lot more records in your production DNS, but for my demo it’s a clean zone. We need to create the TXT Record as per the requested Intune Add a domain value


    Add the value (the @ host name just means the root of that domain, in this instance it’s just (notice the extra period .)



    And you can see the TXT Record has been created


    Step 3 – Verify your domain in Intune

    Now that we’ve created our DNS Record, we need to wait and verify! Firstly, DNS can take a while to update depending on your DNS hosting provider, as well as the DNS refresh interval in the Intune platform.

    If you want to perform a manual check of the records, use nslookup


    Once our DNS is up-to-date, click on the Verify button to get Intune to check for the TXT Record, and verify that it matches what it is expecting


    You’ll then receive a confirmation that the domain has been added successfully


    And your domain will now appear in your Domains section of the Account Portal


  • The Ultimate Intune Setup Guide – Stage 1: Sign-up


    My Configuration Manager labs have taking a massive hiding over the last 12 months, with lots of very unsupported hacks going on. I have been on some Azure training of late, and thought it would be a great idea to rebuild my Azure labs as I originally built them when Azure was in it’s infancy. Also, we now have a local Azure datacentre in Australia (yay!) so it made sense to start again with a clean slate.

    The great thing of hosting your labs in Azure, is they have public IP endpoints. This means it’s very easy for us to setup public websites/etc, and very simple to configure public services such as Microsoft Intune.

    So, as I was rebuilding my ConfigMgr and Intune environment, I thought I’d put together The Ultimate Intune Setup Guide.

    Step 1 – Sign-up for your Intune subscription

    First thing is to create your Intune subscription. For this demo, I’m going to use a trial account, but you’ll want to use an account that you plan to use long term.

    Browse to and hit the Try tab


    Select the Sign up for a free trial of Microsoft Intune


    IMPORTANT: If your organization is an Office 365 customer, or utilize Microsoft Cloud Services such as Dynamics Online, you should logon with the same account used to configure the previously created cloud service. This is to ensure your Intune service can access the already configured and synchronized Azure AD infrastructure.

    Enter your details


    You’ll then get redirected and logged into your Intune Account Portal. Add your phone number for account recovery, or skip and Remind me later


    You should now have Global Administrator access to your Intune tenant


  • Associating your Intune DirSync Directory with your Azure tenant

    Cloud identity is one of the core features and benefits of using the Azure platform. Fortunately, Microsoft Intune uses the same back end to store your users cloud identities.

    This guide is for admins who have setup and configured DirSync for Intune, and want to retroactively add that synchronized domain to their organizations Azure tenant.

    First, browse to and login using your organizations Service Administrator account.

    Note: for these steps to work, you may need to be using an MSA account (,, etc). If you don’t receive the “use existing domain” option when creating your Azure AD domain, create a co-administrator with an MSA account. Login using this account and the option should appear.

    Go to the Active Directory tab. You’ll see just the default Microsoft directory is present.


    Select the + New button in the bottom left hand corner


    You’ll receive the New blades fly-in. Select App Services > Active Directory > Directory


    The blade will expand. Select Custom Create


    This will produce a pop-up to Add directory

    Select Use existing directory, and check the box for I am ready to be signed out now. When ready, click the tick in the bottom right. You’ll then be signed out and prompted for your Intune Tenant credentials.


    Enter your Intune credentials


    You’ll automatically be asked if you want to associate the Intune directory with your Azure AD tenant. Select Continue


    Success! You can now sign out and back to your main Azure tenant


    You can now see that the Mattslabs domain has been added into my Active Directory section in my main Azure tenant


    Just to be sure it’s all working nicely, click on the new domain to view the users


    You can see my users with UPN is now in my Azure console.


    You’re now good to go. In this guide we’ve successfully associated our previously synced Microsoft Intune directory into our organizations Azure Active Directory.

    Matt Shadbolt

  • Different scenarios for using Prestaged content


    Hi All,

    Late last year I had a request from one of my customers to look into the different behaviours of prestaged content.

    I've summarised and shown examples of the results below which will hopefully be of benefit to some of you.


    Scenario 1)

    If I have content already successfully distributed to a DP and I try to extract it again what will occur ?

    As long as you use the /S switch in the command line the content will be ignored if it is the same version or above.

    See the following TechNet article for command line details.

    As an example for a single file we could use extractcontent /P:D:\PrestagedFiles\MyPrestagedFile.pkgx /S

    For all files in a location we could use extractcontent /P:D:\PrestagedFiles /S

    See an example from the PreStagecontent log below


    And again where it shows that it doesn’t send any Status message to the servers if it is skipped..


    Scenario 2) Can I extract content to a DP that isn’t marked as prestaged ?

    Yes, the content will get extracted to the DP’s content library and when you distribute that content to the DP afterwards it will simply send a message to the DP and the DP will confirm that the content sits in the content library and respond back to the Server marking it as completed.

    See logs below as an example

    We extracted the content for package PRI00030 at the DP details from the PreStagecontent log at the DP


    I then distributed the package to the DP see details below in distmgr.log at the Primary


    We can see it successfully added in smsdpprov.log at the DP


    And again in distmgr.log we can see that its sent a completed status message back to the Primary.


    Scenario 3)  What happens If I extract content that is an older version than what is available ?

    You will need to update the package at that Distribution point. See the entry below from TechNet.


    In the following scenario, you must update content that you extracted from a prestaged content file when the content is updated to a new version:

    1. You create a prestaged content file for version 1 of a package.

    2. You update the source files for the package with version 2.

    3. You extract the prestaged content file (version 1 of the package) on a distribution point.

    Configuration Manager does not automatically distribute package version 2 to the distribution point. You must create a new prestaged content file that contains the new file version and then extract the content, update the distribution point to distribute the files that have changed, or redistribute all files in the package.


    As you can see there are more scenarios than just a Prestaged Distribution point where you can make use of prestaged content.

  • ConfigMgr 2012 R2 Certificate Requirements and HTTPS configuration

    We have had a number of recent requests from our customers on the certificate requirements and configuration steps required to configure HTTPS communication in a ConfigMgr 2012 environment.

    I would like to give a massive thank you to Ravi Kalwani, a member of the ANZ Microsoft ConfigMgr Premier Field Engineering (PFE) team who put this guide together.

    This post contains the step-by-step configuration needed to successfully implement HTTPS communication in your ConfigMgr 2012 R2 environment.

    Creating Templates for Site Systems and Clients Certificates

    Create a template for ConfigMgr Clients

    On the issuing Certificate Authority go to Administrative Tools and Open Certificate Authority Console


     Right Click On Certificate Templates and Click Manage to open Certificate Template Console



    Now right-click on Workstation Authentication and click Duplicate Template


    Make sure to use Server 2003, not 2008


    We are first creating Certificate Template for ConfigMgr client Authentication Certificate, so give the Template a Name that would related to what it would generate Certificates for, I have chosen Name “ConfigMgr Client Certificate”


    Click on the Security tab, select the Domain Computers group and add permissions of Read and Autoenroll, do not clear Enroll


     Now Click on the Subject Name Tab, and Select DNS name in Build from this Active Directory information, Then click OK.


     Refresh Certificate Template console to see the new template in there.


    Create a template for Site Systems (MP, DP, SUP and/or WSUS)

    Still in Certification Authority, in the Certificate Templates list we’ll setup the next template. Right-click on the Web Server template, and click Duplicate. On the General tab, change the Template something more appropriate like ConfigMgr Web Server Certificate. 


     Next click the Security tab, and add your SCCM server to the permissions list and add the Enroll permission.

    If you were running a SCCM configuration with multiple sites and servers, it is recommended you create a SCCM Servers Active Directory Security Group. I’ve created an AD security group called ConigMgr_Servers. So I’ve added the Group with Enroll permission. 


     Now Click on the Subject Name Tab, and Select Build from this Active Directory information, and then Select DNS name. Then click OK.


    Create a ConfigMgr Client template for WinPE Images

    This step is only needed if you have all you MP/DP running in https. In this step we are creating a Client Authentication certificate that will be used to generate certificate for WinPE images, which will later contact MP and DP on Https.

    If you don’t have all MP/DPs in HTTPs you can continue to build image via Task Sequence and WinPE images will contact HTTP MP and not HTTPS

    Right-click on the Workstation Authentication template, click Duplicate. Rename the template as ConfigMgr WinPE images, I personally like to give longer validity as WinPE images can’t renew their certificate and it’s a manual process to create and Import certificates in WinPE images before the validity expires. In my lab I’ve given 5 years validity.

     On the Request Handling tab select Allow private key to be exported. 


     On the Security tab add your SCCM servers group, and give Enroll permission. Click Apply, then OK.


     Now if you look at the Certificate Templates Console you will see our three new templates. 


     We can now close the Certificate Templates Console. 

    Enable Certificates to be issued

    Open Certificate Authority Console-> Right Click Certificate Templates-> Select New-> Certificate to Issue   


    Select all three of the ConfigMgr templates we created then click OK.


     They will then show up in the Certificate Templates listing. Once you verify that, you can close the Certification Authority console. 


    Create an Auto-Enrol GPO for the Client Certificate template  

    Now we’ll need to create a Group Policy at the OU of our domain where we want client to get ConfigMgr Client Certificates and only does HTTPS with MP, DP and SUP
    Launch Group Policy Management on your Domain (Start > Administrative Tools > Group Policy Management). Right-click Group Policy Object and select New as we are going to create a new GPO and link it to OU later. Name your GPO appropriately, I have given my GPO Name “AutoEnroll ConfigMgr Client Cert“, then click OK.
    Edit your newly created GPO. Navigate to: Computer Configuration> Policies > Windows Settings > Security Settings > Public Key Policies. Right-click on Certificate Services Client – Auto-Enrollment and then click Properties. Change the Configuration Model: to Enabled, and check the Update certificates that use certificate templates. Then click Apply and OK.
    If you recall, we configured the ConfigMgr Client Certificate Template earlier and we set the permissions for Domain Computers to Read, Enroll, and Auto Enroll. Now when you run a “gpupdate /force” or in 15 minutes when GP is re-applied, any machine on the domain communicating with the DC will request and receive a client certificate automatically that will be place in the Local Computer Personal Certificate Store.

    Request Web Server Certificate on MP, DP and SUP

     Now we need to setup the appropriate certificates on our System Center Configuration Manager Management Point. The first thing you will need to do is reboot your SCCM server. This is so that it will pick up the permissions change that will allow it to register for the Web Server Certificate.

     Once the reboot completes, click Start > Run.  Type mmc.exe and click OK.  Click File > Add/Remove Snap-In, Choose Certificates and click Add.  Choose Computer Account, click Next.  Choose Local Computer, click Finish.  Click OK, and then expand the Certificates tree to the Personal > Certificates folder.

    You may notice that your SCCM server has Auto-enrolled for and received its Client Authentication Certificate we just setup. 

    Right-click in a blank space and click All Tasks > Request New Certificate, You are presented with the Certificate Enrollment wizard. Click Next

     Leave the default on this page, and click Next           

    Select ConfigMgr Web Server Certificate Template and Click Enroll. 

      Once you see Status: Succeeded, Click Finish  


      Now you will be able to see both all three Certificates on Certificate Console of Site Server  


    Now we need to export the Client Distribution Point Certificate while we are in the Certificates Management console. Right-click the certificate that shows template name as Certificate WinPE images and click Export. 


     Click next on the “Welcome to the Certificate Export Wizard


      Select “Yes, export the private key”, if you see this option greyed out, you probably have wrong certificate selected.


     Select “Personal Information Exchange – PCK #12 (.PFX)” and click Next


      Set a password in this screen and click next, you will need this certificate while importing it to Distribution point property.


      Select Destination where would you like to export the certificate, and give it a descriptive name.


    Click Finish


    Importing Certificates in IIS

    After all the certificates have been requested we need to now import the Web Server Certificate to the Default Website and WSUS Website in IIS.
    Launch IIS Manager (Start > Administrative Tools > Internet Information Services (IIS) Manager).Navigate to the Default Website, right-click it and select Edit Bindings.


     Select the https binding and click Edit

    Select the https binding and click Edit. The select the ConfigMgr Web Server Certificate and then click OK. I highly recommend viewing your certificate afterwards, checking the Details tab, to ensure you selected the correct one.


     Now do the same on WSUS Website.
    Select Appropriate Certificate (not SQL), and click OK. 


      And Click Close.

      Last Piece of configuration that we need to do is, manually configure five WSUS virtual directories to use SSL. The five Virtual directories are (APIRemoting30, ClientWebService, DSSAuthWebService, ServerSyncWebService, and SimpleAuthWebService)
    The Virtual directories has also been definied in the TechNet document          
    Putting ApiRemoting in SSL


     Check the box Require SSL and Select Ignore under Client certificates

     Now do the same for rest of four Virtual directories mentioned above.

    Configuring MP, DP and SUP to use SSL

     Now that we have completed all our certificates pre-requisites and ready to configure ConfigMgr Components to use SSL.  

    Configuring Management Point to use SSL

    Go to Management Point Property, (Open ConfigMgr console>Administration Workspace>Site Configuration>Servers and Site System Roles>Select Your Sever and Right Click on Management Point Role and Click Property.


    Select HTTPS from the Client Connections options, this will kick off Reinstallation of Management Point, and reconfigure its Virtual directories to use HTTPS communication only.  


     You can see MP Reinstallation happening in MPSEtup.log


    Configuration Distribution Point Role to SSL

    Go to Distribution Point Property, (Open ConfigMgr console>Administration Workspace>Site Configuration>Servers and Site System Roles>Select Your Sever and Right Click on Distribution Point Role and Click Property


    Select HTTPS under Specify how client computers communicate with this distribution point


    If you would like Clients to communicate back to DP on HTTPS even during Task Sequence than you would need to Select Import Certificate under Create a self-signed certificate or import a PKI client certificate


     Click Apply, This will reconfigure this Distribution Point virtual directory to Use Only HTTPS communication

    Configure WSUS/SUP to use HTTPs

    Open up command prompt in Admin Context on WSUS server and change working directory to WSUS installation path Tools directory and run following Command

    WSUSUtil.exe ConfiguresSSL <Intranet FQDN of WSUS Server>


    Go to Software Update Point Property, (Open ConfigMgr console>Administration Workspace>Site Configuration>Servers and Site System Roles>Select Your Sever and Right Click on Software Update Point Role and Click Property


    Check the box Require SSL communication to the WSUS Server and Click Apply


     This as well will reinstall Software Update Point Role with new settings.

    Site Server Settings

    Change your ConfigMgr setting to ensure client communicates with HTTPs Enabled MP when there is a client authentication cert is present.
    Launch ConfigMgr Console> Administration Workspace> Site Configuration> Sites> Right Click your Primary Site> Properties and Go to Client Computer Communication Tab.
    Check the box “Use PKI Client certificate (client authentication capability) when available”


    Review clients that have Client Authentication Cert to make
    sure they are communicating to MP in HTTPs.

    A Client that has ConfigMgr client cert installed will see changes made to ConfigMgr Server via Published information in Active Directory, and will switch to HTTPs if it detects a Valid Client Cert Present on Computer’s Personal Store.



    PKI Certificate Requirements for Configuration Manager

    System Center 2012 Configuration Manager: R.I.P. Native Mode

    Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Server 2008 Certification Authority

  • PowerShell Script to Create and Link Schedules in Azure Automation



    Hi All,

    Lately I've been playing with Azure automation and needed to create schedules to kick off Runbooks at certain times of the day. Rather than doing this manually I decided to just write a simple PowerShell script to create these for me automatically, since I may need to do this task again in the future.  To do this I need to ensure I have Azure PowerShell configured and connected . I wont go into how in this blog please use the following blog as a reference How to install and configure Azure PowerShell

    I then used the following script I wrote to create and register each Schedule



    $Days = ("Monday","Tuesday","Wednesday","Thursday","Friday")
    $StartDate = ("26/01/2015 08:30","27/01/2015 08:30","28/01/2015 08:30","29/01/2015 08:30","30/01/2015 08:30")
    $EndDate = ("26/01/2015 20:30","27/01/2015 20:30","28/01/2015 20:30","29/01/2015 20:30","30/01/2015 20:30")
    $Accountname = "yourAutomationAccountname"
    $Count = 0

    ForEach ($Day in $Days)

    New-AzureAutomationSchedule -AutomationAccountName $Accountname -Name "Start AzureVMs $($Day)" -StartTime "$($StartDate[$Count])" -DayInterval 7
    Register-AzureAutomationScheduledRunbook -AutomationAccountName $Accountname -Name Start-AllAzureVM -ScheduleName "Start AzureVMs $($Day)"
    New-AzureAutomationSchedule -AutomationAccountName $Accountname -Name "Stop AzureVMs $($Day)" -StartTime "$($EndDate[$Count])" -DayInterval 7
    Register-AzureAutomationScheduledRunbook -AutomationAccountName $Accountname -Name Stop-AllAzureVM -ScheduleName "Stop AzureVMs $($Day)"

    $Count ++




    We can see that before I run my script I have no schedules attached to my Start-AllAzureVM and Stop-AzureVM Runbooks



    we then run the script from which you should see a similar output to the one below.


    We now can see that both of our Runbooks have Schedules created and assigned.



    As always if you improve or have similar scripts to share feel free to comment below.