How to deploy .Net 3.5 with Intune


  1. Introduction
  2. Prereqs
    1. .Net 3.5
    2. Microsoft Win32 Content Prep Tool
  3. Creating our application and deployment
    1. Creating our Installation script
    2. Creating our .wintunewim file
    3. Deploy our application with Intune

This is the introduction

Welcome back to another blog post and today I will cover how to deploy .Dot 3.5 from Intune.
There could be many reason for why we want to deploy any version of .Net to our Windows devices but the most frequent one I encounter is that there’s still a lot of applications requiring version 3.5 and Windows 10 does not come with that pre-installed.

Togehter with the new feature in Intune to set dependencies on Win32 apps we are now able to
deploy .Net as a dependency so we no longer have to include .Net in all of our applications that requires it.


To make this all happen we have few things, first of all .Net 3.5 then we need a custom Installation script which is provided below and then we need to convert it to a .Intunewim file.

.Net 3.5

We have 2 ways of getting the .Net 3.5 content to the client In this scenario. We will be using the Enable-WindowsOptionalFeature powershell cmdlet and we can either specify a source path for the .cab files. Instead of adding the source files to the installation package we can also just let each machine get the content directly from Microsoft.

Downloading the content before hand and included it in the Win32 app has its benefits, if you want to use Delivery optimization (DO). Win32 apps supports DO for Win10 1709 and newer and lets the clients share content between each other and helps them save bandwith from the internet. More info here

If you have a Win10 ISO you can get the .NET 3.5 cab-files from the SXS folder. Mount the Win10 ISO and navigate to sources\sxs and copy the 2 files that contains netfx3 in the name.



You could also download the .Net 3.5 from Microsoft and that will get you the .EXE installer. But in this post I wont cover installing the .EXE mainly because I have had mixed result using the .EXE.


Microsoft Win32 Content Prep Tool

the Win32 content prep tool is needed to create our .Intunewim file that we will upload to Intune later.
Start with heading over to github and download the tool

To download the Win32 content prep tool head over to



Creating our application and deployment

The next step is to start putting it all togheter.

Creating our Installation script

Here’s the powershell Installation script we will use, this will invoke the installation or uninstall depending on what we parameter we call the script. This will make us be able to both do Install and uninstall with Intune.

Im also including logic In the script to check if the .Net content already exist in the Win32 app package, if the folder sxs exist and inside at least one NetFx3 cab-file is present it will run the DISM command and point to that source. If the files and folder does’t exist it will run Enable-WindowsOptionalFeature withouth the /source parameter which means that the computer will go to Windows update and get the files needed.

More info about DISM here–dism–command-line-options


    [ValidateSet("Install", "Uninstall")]

If ($Mode -eq "Install")

    if (Test-path .\sxs\Microsoft-Windows-NetFx3-OnDemand-Package*.cab)
    #Offline Installer
    Enable-WindowsOptionalFeature -Online -FeatureName 'NetFx3' -Source .\sxs\ -NoRestart -LimitAccess

        #Online installer 
        Enable-WindowsOptionalFeature -Online -FeatureName 'NetFx3' -NoRestart


If ($Mode -eq "Uninstall")


Disable-WindowsOptionalFeature -Online -FeatureName 'NetFx3' -Remove -NoRestart



Creating our .wintunewim file

Create a new folder called dotnet35 and copy in the script Install.ps1 and also include the SXS folder with the .Net 3.5 cab-files if you want to use local source installation and be able to take advantage of Delivery Optimization otherwise
skip the SXS folder.




Run the IntuneWinAppUtil.exe from the Microsoft Win32 Content Prep Tool that you downloaded earlier, follow the instructions and create the .Intunewim file



Deploy our application with Intune

If you havent deployed a Win32 app before in Intune I recommend you check out the documentation from Microsoft here
I won’t go through all the steps in detail in this post on how to create a Win32 app but instead I’ll just go through the most important parts of Install / Uninstall and detection method.



The installation and uninstall command we will be using looks like this

powershell.exe -ExecutionPolicy Bypass -file Install.ps1 -Mode Install

powershell.exe -ExecutionPolicy Bypass -file Install.ps1 -Mode Uninstall


And for detection method I’m just looking for a registry key


We have now created our Win32 app and can set other Win32 apps having .Net 3.5 as a dependency or assign it directly to any user or device we want.

On the client side, if we have toast notification turned on for the deployment we will see that the Win32 app get installed.


Leave a comment or question in the comment section below.


That’s all for now and until next time, cheers !

Don’t forget to follow me on twitter


And you can also find me blogging over at

#offline, #online

Intune – Invoke sync to all devices in Intune with the Intune powershell SDK


Continuing the series where I cover how to use the powershell SDK for Intune and some real world use cases. Today we will cover how to invoke a sync from Intune to one or several devices.

If you haven’t installed the SDK you can either go to and you can also check out my earlier post on how to get started and use the SDK:


Intune Powershell SDK

Intune – Show VPP account Information directly from the client apps view for easier management 

Intune – Rename iOS devices with Intune Powershell SDK 


Syncing a device from the Intune Portal


The manual way of invoking a sync to a device from Intune is to go to Intune -> Devices -> (Select the device you want to sync) -> Sync 




But what we instead want to do is to invoke a sync with the help of the Intune Powershell SDK. The specific use case here is that you might need to run a sync to multiple devices and instead of needing to go in to the UI and click “Sync” as shown in the picture and for that we can use the Intune Powershell SDK and Graph API to do the work for us.


Sync one device


Lets get started, I assume you’ve Installed the SDK by now and the first thing we are going to look at is how to run a sync against a single device.


First we need to authenticate towards the tenant we are going to use and we do that with the Connect-MSGraph cmdlet.





Once connected we need to use the Get-IntuneManagedDevice cmdlet and then use the -Filter parameter to get the specific device we want. I’ll do a more in depth post on filtering and how you can search and filter when using the Graph API later so stay tuned for that.

In this example I’m just filtering on the deviceName property, you should replace ‘DESKTOP-G0HGUP’ for the device name you are looking for.




Get-IntuneManagedDevice -Filter "contains(deviceName,'DESKTOP-G0HGHUP')" 


When we retrieved the device we need to invoke the sync request and for that we will use the Invoke-IntuneManagedDeviceSyncDevice cmdlet. If you want to make a one liner we just need to pipe the result and its super easy.




Get-IntuneManagedDevice -Filter "contains(deviceName,'DESKTOP-G0HGHUP')" | Invoke-IntuneManagedDeviceSyncDevice 


Sync multiple devices


Now to the more exiting part, how can we leverage the power of the Intune Powershell SDK to sync multiple devices. We need to start just like we did when we tried to sync one device to get all the devices we want to invoke a sync on.

Side note. If you want to sync more than 1000 devices you need to do something called Paging. The Intune Powershell SDK uses Graph API which is a REST API and returns pages containing 1000 objects at the time, if you exceed 1000 you need to get the next page containing the next 1000 objects and so on until you got all the objects. This can be done by using the cmdlet Get-MSGraphAllPages.


Again we need to use the Get-IntuneManagedDevice cmdlet to get all the devices we want to invoke a sync on and we are using the -Filter parameter to get perhaps all the windows, iOS or Android devices. Here’s a few examples


$Devices = Get-IntuneManagedDevice -Filter "contains(operatingsystem, 'iOS')"

$Devices = Get-IntuneManagedDevice -Filter "contains(operatingsystem, 'Windows')"

$Devices = Get-IntuneManagedDevice -Filter "contains(operatingsystem, 'Android')"


As mentioned earlier, if you have more than 1000 objects returned you need to use the Get-MSGraphAllPages like this


$Devices = Get-IntuneManagedDevice -Filter "contains(operatingsystem, 'Windows')" | Get-MSGraphAllPages




Running the $Devices = Get-IntuneManagedDevice -Filter “contains(operatingsystem, ‘Windows’)” in my lab tenant will get me 5 devices



Next step is to invoke a sync towards all of those devices and I’m also adding a Write-host just to make it more visible that the script is actually doing something.


Foreach ($Device in $Devices)

Invoke-IntuneManagedDeviceSyncDevice -managedDeviceId $Device.managedDeviceId
Write-Host "Sending Sync request to Device with DeviceID $($Device.managedDeviceId)" -ForegroundColor Yellow




That’s it and below you will find the a complete script template you can use which will make sure the Powershell module is Installed and that you have an authentication token and if not it will run Connect-MSGraph where  you need to authenticate towards the tenant you want to run the script against. Stay tuned for more content in regards to Graph API and the Intune Powershell SDK.


$IntuneModule = Get-Module -Name "Microsoft.Graph.Intune" -ListAvailable
if (!$IntuneModule){

write-host "Microsoft.Graph.Intune Powershell module not installed..." -f Red
write-host "Install by running 'Install-Module Microsoft.Graph.Intune' from an elevated PowerShell prompt" -f Yellow
write-host "Script can't continue..." -f Red
# Importing the SDK Module
Import-Module -Name Microsoft.Graph.Intune


#### Insert your script here

#### Gets all devices running Windows
$Devices = Get-IntuneManagedDevice -Filter "contains(operatingsystem,'Windows')"

Foreach ($Device in $Devices)

Invoke-IntuneManagedDeviceSyncDevice -managedDeviceId $Device.managedDeviceId
Write-Host "Sending Sync request to Device with DeviceID $($Device.managedDeviceId)" -ForegroundColor Yellow




Leave a comment or question in the comment section below.


That’s all for now and until next time, cheers !

Don’t forget to follow me on twitter


And you can also find me blogging over at

Intune – Rename iOS devices with Intune Powershell SDK

This will be the first post in a series where I will cover Graph API and in this specific post how we can rename iOS devices that’s being managed by Intune in a more automatic way then going in to the Intune portal and manually renaming them. There’s several levels of automation that can be achieved ranging from manual automation (Manually running a script) to full blown automation with the help of either schedule task running on a computer or using Azure automation and there’s a few challenges along the way that needs to be taken under consideration and ironed out.


A couple of weeks ago Microsoft announced bulk renaming of devices with DEP (Deployment enrollment program) and you can now configure the DEP profile to rename the device during enrollment.


Bulk device naming when enrolling corporate iOS devices

When using one of Apple’s corporate enrollment methods (DEP/ABM/ASM), you can set a device name format to automatically name incoming iOS devices. You can specify a format that includes the device type and serial number in your template. To do so, choose Intune > Device enrollment > Apple enrollment > Enrollment program tokens > Select a token >Create profile > Device naming format. You can edit existing profiles, but only newly synced devices will have the name applied.


This is a great feature but won’t solve the issue for already enrolled devices. These you still need to either manually rename or factory reset to re-enroll once the configuration is set.


In this post we will take a look at using the Intune Powershell SDK to rename iPad’s which in my opinion has the lowest barrier for entry and the least amount of work/complexity to rename iPad’s in Intune on a large scale without needing to do manually rename every iPad within the Intune portal (See picture below). To do this we are going to use the Intune Powershell SDK and for more info about that and how to get started with it check out my post here:




The script is fairly simple due to the fact that we are using the Intune Powershell SDK that handles all the webrequest to Graph API “behind the scenes” with the help of the cmdlets thats been created for this powershell module.


Once you downloaded and Installed the Intune Powershell SDK module (If you dont know how to do this check out my other blog post here Then you can to use the sample script provided below.


Side note.

When you start an iPad for the first time or do a factory reset the default name will be “iPad”. Some organization doesn’t want to use that name for different reasons and if you would like to have another name then serial number of the device then you need to be able to get that information and map that to a unique iOS device.


Rename one specific iOS device


If you want to change the name of one specific iOS device you can use the sample below. We need to identify the device we want to change and the easiest way is to do that by serial number. Change the serial number between the single quotation mark from XXXXXXXXXX to the specific serial number for the iPad you want to change as seen in the picture below. Remember that we are only able to rename iOS devices which are supervised thats why we are only filtering on Serial number and if the device is supervised.


In this example we are changing the name from iPad or iPhone to the serial number of the device.


Important Note. 

As per today there’s a bug in the SDK which causes the Update-IntuneManagedDevice cmdlet not to work as intended when trying to rename a deivce using the cmdlt. Microsoft is aware of the problem and an issue has been raised on githib


The good thing is that there’s a work around and that’s to use the Invoke-MSGraphRequest cmdlt from the SDK.




$Device = Get-IntuneManagedDevice -Filter "contains(serialNumber,'XXXXXXXXXX')"

$DeviceID = $
$Resource = "deviceManagement/managedDevices('$DeviceID')/setDeviceName"
$graphApiVersion = "Beta"
$uri = "$graphApiVersion/$($resource)"

$JSONName = @"

Invoke-MSGraphRequest -HttpMethod POST -Url $uri -Content $JSONName


Once we ran the script and go back in to the Intune console, we can find the device and see that there’s a client action pending to rename the device




Rename all company owned and supervised iOS devices


The script will start with importing the module then connect to Graph API and here you will need to enter your credentials to your tenant. Then we will get all iOS devices that’s being managed by Intune and is company owned and supervised.  Once that’s done we will go through each devices that got collected and check to see if the current name is equal to the Serial number of the device, if it is nothing will happen and if it’s not we will rename that devies and set the new name to be the serial number of the device.




$AlliOSDevices = Get-IntuneManagedDevice -Filter "(contains(operatingsystem, 'iOS')%20and%20isSupervised eq true)"

Foreach ($AlliOS in $AlliOSDevices)

$DeviceID = $
$Resource = "deviceManagement/managedDevices('$DeviceID')/setDeviceName"
$graphApiVersion = "Beta"
$uri = "$graphApiVersion/$($resource)"

$JSONName = @"

if ($AlliOS.deviceName -ne $AlliOS.serialNumber)

Invoke-MSGraphRequest -HttpMethod POST -Url $uri -Content $JSONName







Leave a comment or question in the comment section below.


That’s all for now and until next time, cheers !

Don’t forget to follow me on twitter


And you can also find me blogging over at

Intune – Show VPP account information directly from the Client Apps view for easier management

One challange I hear from customers and other IT Pros working with VPP (Volume purchase program) applications from Apple in Intune is that it if you have multiple VPP accounts and need to manage the application deployment for those in Intune there’s no way of seeing which app is linked to a specific VPP account from the Client App -> App overview pane without clicking on the specific app and in the Overview see which VPP account this application was bought with.



Since there’s no column in the Client app -> App overview for showing the VPP account it can be tedious if one application has been bought by several accounts but you need to deploy the app from a specific VPP account or if you just want to have an easy overview.




To solve this I came up with the Idea of using the Owner column and to populate the VPP account information there so we can see it from the App overview pane. And Instead of manually inputting this information for all the VPP apps I turned to our beloved friend Powershell to help us out. There are several levels of automation that can be done but in this post I’m just going to focus on one of the simplest way to get started in my opinion.


Tools to our disposal – Intune Powershell SDK


If this is the first time you hear of the Intune Powershell SDK i recommend you check out my earlier blog post on what it is and how to get started here:


The Intune Powershell SDK is an easy way of doing administrative tasks with the help of all the cmdlets that the SDK includes. And if you don’t want to use the SDK and still do the same things that’s also possible since the SDK uses the power of Graph API and invoke-restmethod so you can create your own functions and cmdlets if you feel the need for that but to keep it simple I will not cover that in this post but let me know if that’s something that interest you for a future post.


The script and execution


Here’s the script we’re going to use after the fact that you have Installed the Intune Powershell SDK that’s covered in my post

The first thing thats going to happen is that we need to import the module and then we call the Connect-MSGraph cmdlet that will make prompt for a logon to your tenant. From there we will get all the VPP apps that’s been synced with Intune and store that in a variable.

Once we have all the apps the script will go through all the apps one by one and check if the Owner property of the app object is either Null or empty and if it is we will then update the Owner property with the same information the vppTokenAppleId property currently have.


Import-Module .\Microsoft.Graph.Intune.psd1
$AllVPPApps = (Get-DeviceAppManagement_MobileApps | Where-Object { ($_.'@odata.type').contains("#microsoft.graph.iosVppApp") })

Foreach ($AllVPPApp in $AllVPPApps)
        if ([string]::IsNullOrEmpty($AllVPPApp.owner))
            $AllVPPApp | Update-DeviceAppManagement_MobileApps -owner $AllVPPApp.vppTokenAppleId


Once the script succesfully finish we can now see that the owner property have been updated on all the VPP apps by running the following command


Get-DeviceAppManagement_MobileApps | Where-Object { ($_.'@odata.type').contains("#microsoft.graph.iosVppApp") } | Select-Object displayName, owner, vppTokenAppleId 



What we can do now is to head back to the Intune portal and Client App – Apps click on Columns and select Owner and click Apply. 



From the list of all applications we can now see which which VPP account each VPP application have been bought with.



Leave a comment or question in the comment section below.


That’s all for now and until next time, cheers !

Don’t forget to follow me on twitter


And you can also find me blogging over at

MDM join an already Azure AD joined Windows 10 PCs to Intune with a provisioning package


When working with a client the other day an Interesting situation came up where they had already used Azure AD for a while and now were ready to start using Intune for managing their Windows 10 PC’s. Prior to that they haven’t had any device management like ConfigMgr or Intune before. They also didn’t have any on-prem Active Directory and were only using cloud services like Azure AD and Office 365.


The question that came up was:

How do we enroll existing Windows 10 machines in Azure AD in to Intune and how can we do that with the minimum amount of effort from the end-user?


One of the ways to do it is by enabling the Enable automatic MDM enrollment using default Azure AD credentials policy but the client didn’t want their end-users or admins manually going in and enable that policy on each machine. So the discussion continued on how could me make it easier for the end user to do the things needed to enroll their device. In this post I will cover both the manual of doing it by enabling the policy but this is mainly to give it some context and from their I will show you how it can be done with the help of a provisioning package.

Once you have the provisioning package in place it’s just a matter of delivering it to the end-user in the most simple way possible and let the end-user run the provisioning package.



Enable automatic MDM enrollment using default Azure AD credentials


On all Windows 10 1703 and newer version of Windows there’s a local group policy that can be set to enroll in to MDM using logged on Azure credentials, this comes in handy in a 1 to 1 scenario where the end-user has their dedicated devices. If you have on-prem AD you can create a GPO for this policy but in this example we don’t have an on-prem AD.

Microsoft documentation can be found here:



On the local machine, go to the Windows 10 start menu and search for “Edit group policy” and open it up with Administrative privileges.



Navigate to to Computer Configuration -> Administrative Templates -> Windows Components -> MDM and open up Enable automatic MDM enrollment using default Azure AD credentials and choose “Enable” and click on “Apply” and “Ok”



Once’s this is done 2 things happens,


This registry key gets created

HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM\AutoEnrollMDM = 1


And a schedule task gets created by the name of “Schedule created by enrollment client for automatically enrolling in MDM from AAD” which can be found in the task scheduler under

Microsoft -> Windows -> EnterpriseMgmt




Logs and Monitoring


Once the everything is in place you can monitor the process in Event Viewer


From my own testing and experience you will see the following Error message “Auto MDM Enroll Failed (Unknown Win32 Error code 0x8018002b)” for a couple of hours but that’s totally normal and nothing to worry about.



In this specific example it took about 5 hours before it succeeded to do the MDM join and during this time a user was logged on to the machine. If the machine has no user logged on to it or its put to sleep or turned off the MDM join won’t happen.



Windows 10 provisioning package and Windows Configuration Designer


As mentioned earlier in this post if you have on-prem AD you can create a GPO for this policy an roll out it that way. But if you have no on-prem infrastructure at all to we have to find a easy way for the end-user so we can MDM join them without having to manually go in to local policy and enable the policy.


Microsoft documentation on Provisioning package and Windows Configuration Designer can be found here:


Side note.

In Windows Configuration Designer you are able to something called ADMXIngestion where you can inject ADMX files and configure their settings however I haven’t been able to get that to work when it comes to the MDM policy and its ADMX file. I’m not exactly sure why and while I’m trying to solve that I will instead focus this post on how to get around it and create the same settings as the policy does but with a powershell script instead.


Once you installed Windows Configuration Designer from either the Windows ADK or Microsoft Store it’s time to create the provisioning package we are about to use but to make this work.

We also need a powershell script and a .bat file that calls the powershell script within the provisioning package because there are some challenges when it comes to running powershell scripts directly.


The scripts


In this example we will be using MDMPS.ps1 as our powershell script and MDM.bat

With powershell we create a registry key and a Schedule task which is the same schedule task that runs if one manually enables the MDM join policy on the local computer.


     Created on:    12/12/2018 
     Modified on:   12/12/2018 
     Created by:    Timmy Andersson
     Twitter:       @TimmyITdotcom
     Blog: &
        MDM Join script. Creates a registry key and a schedule task to start the process to MDM join a computer. 


$RegKey ="HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\"
$RegKey1 ="HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM"
$ScheduleName = "Schedule created by enrollment client for automatically enrolling in MDM from AAD"
$Date = Get-Date -Format "yyyy-MM-dd"
$Time = (Get-date).AddMinutes(5).ToString("HH:mm:ss")

$ST = @"
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="">
<Author>Microsoft Corporation</Author>
<URI>\Microsoft\Windows\EnterpriseMgmt\Schedule created by enrollment client for automatically enrolling in MDM from AAD</URI>
<Principal id="Author">
<Actions Context="Author">
<Arguments>/c /AutoEnrollMDM</Arguments>



New-Item -Path $RegKey -Name MDM
New-ItemProperty -Path $RegKey1 -Name AutoEnrollMDM -Value 1

(Register-ScheduledTask -XML $ST -TaskName $ScheduleName -Force) | Out-null



Bat file executing the powershell script from the provisioning package


powershell.exe -noprofile -executionpolicy bypass -Command "& '%~dpn0PS.ps1'"



Putting it all together


Start with saving the powershell script and the .bat file. Once’s thats done open up Windows Configuration Designer and under the create section click on “Advanced provisioning” 


Select “All Windows desktop editions



In the next step just click on “Finish” there’s no need to import a provisioning package.




Navigate to Runtime Settings -> ProvisioningCommands -> DeviceContext -> CommandFiles

Click on “Browse” and find the .PS1 script file and click on “Add” repeat this for the .Bat file as well.


You should now see the 2 added files under CommandFiles. In this example the MDMPS is the powershell script and MDM is the .Bat script.




Next thing is to click on “CommandLine” and add write “cmd.exe /c MDM.bat” this will tell the provisioning pack to run the .bat file and the .bat file will run the powershell script.


Now we just need to export the provisioning pack and to do so you click on “Export -> Provisioning package” in the top left corner



Give the provisioning package a name and click on “Next



You can encrypt the package or sign it with a certificate if you want, but since there’s no unique/sensitive or secret information in this specific package you don’t need to do this. Click “Next



Choose the path where you want to save your provisioning package to and click on “Next” 



Click “Build 



On the last page click on “Finish



Go the file location where you save the file and grab your newly created provisioning package




Applying provisioning package


When it comes to distribution there’s not much we can do without any prior management or on-prem AD so with this one solution is to just email the package to the end-users and just write a small guide on how they apply it.


There’s a few different ways of applying a provisioning package but in this example we will cover one way.


The file needs to be present on a Windows 10 1703 or later PC where the end user is logged on with their Azure AD credentials.


Double click on the provisioning package


If UAC is turned on and gives you a popup, click “Yes


a provisioning package warning will appear if its not signed, Click on “Yes, add it



And that’s it.


The powershell script will now create the schedule task and create the registry key needed to do the MDM Join. A few hours later the machine will be MDM Joined in the same way if you enabled the policy. For logs for the MDM join see the section Logs and Monitoring in this blog post.


If you want to make sure the provisioning package has been applied you can go to Windows start menu -> Settings -> Account -> Access Work or School  -> Add or Remove provisioning package 




That’s all for now and until next time, cheers !

Don’t forget to follow me on twitter


And you can also find me blogging over at

Intune Powershell SDK



For those who want to administrate Intune with the help of powershell there’s been a good source of sample scripts over at for quite some time now. If you want to interact with Intune, Azure, O365 and more you need to use Microsofts Graph API. To get started with Intune and Graph API I recommend you take a look at Niall Brady’s post on how to get started


During Microsoft Ignite 2018 in Orlando there was a session about a Powershell SDK for Intune which was very intressting because it removes some of the barriers for people who are used to Powershell but not might have the time to dive in to Graph API specifially. The SDK contains cmdlets that communicates through Graph API behind the scenes but you as the adminstrator doesnt have to think about doing webrequest to the API and so on.


I highly recommend wathing the session “Learn how to leverage Intune support for Microsoft Graph and Powershell to enable powerful automation and IT security” from Ignite 2018 about the SDK.




Here’s just a quick walkthrough on how to get started and use the SDK.


Download the SDK from


Once downloaded, extract it and import the module in to Powershell


Import-Module .\Microsoft.Graph.Intune.psd1


Run Connect-MSGraph and logon to the tenant





You are now connected and are able to use all the cmdlets against your tenant.

For example




Will get all applications under MobileApps (Client Apps is the new name in the Intune console)




To list all available cmdlets in the Powershell module just do the following in powershell. As of this post there’s 1311 cmdlets which is pretty impressive I have to say for something
thats just a preview.


Get-Command -Module Microsoft.Graph.Intune 


That’s all for now and until next time, cheers !

Don’t forget to follow me on twitter


And you can also find me blogging over at

ConfigMgr Current Branch 1802 – Phased deployments


Late January Microsoft introduced something they called phased deployment in the technical preview 1801 for ConfigMgr and I went through the feature in a blog post here:


2 months later we now have a new ConfigMgr current branch release version 1802 and with that we now have the phased deployment as a pre-release feature in latest version of ConfigMgr Current Branch.

Here’s a blogpost from Miocrosoft talking about some of the new features in this release:

Where they mention this new feature:

  • Phased deployments – Phased deployments automate a coordinated, sequenced roll out of software without creating multiple deployments.


Activating Phased deployment


Since this is a pre-release feature you need to specify that you want to activate this feature before you can use it, this can be done either during the upgrade process or from the ConfigMgr console as soon as you have updated to version 1802.


Recommend you also check out this doc about pre-release features from Microsoft


First you need to make sure you have activated the option to use pre-release features, this how you do it:

  1. Go to “Administration”
  2. Expand “Site Configuration” and click on “Sites”
  3. Choose the site you want to configure and click on “Hierarchy Settings”
  4. Under “General” make sure you have checked the “Consent to use Pre-release features”



Once that’s done you need to activate the Phased deployment feature it self

  1. Go to Administration
  2. Expand”Update and servicing” and click on “Features”
  3. Find the Phased deployment feature and right-click on it and choose “turn on”
  4. Reopen the ConfigMgr Console




Creating a Phased deployment


Microsoft Docs:


Let’s take a quick look at this and head over to a task sequence and in this particular case we will try to do a phased deployment with the “Awesome task sequence” and from there we will right-click on the Task sequence and choose ” Create Phased deployment” (We also have an icon for to do this see picture 2)



A wizard will appear were we need to specify a name and choose our pilot collection and production collection



Once we clicked “Next” we get some options to configure


  • Criteria for success of the first phase
    • Deployment success percentage – Were we can specify a critera between 0-100 %


  • Conditions for beginning the the second phase of deployment after success of the first phase
    • Automatically begin this phase after a deferral period in days – Pick how many days after the success of the first phase the production deployment should start. (From my own testing if you choose 0 days it will start within minutes once the the deployment success percentage has been reached)
    • Manually begin the second phase deployment – Determine if we want to start it manually or not


  • Once the device is targeted, apply the upgrade
    • As soon as possible
    • Deadline time (relative to the time the device is targeted) – Choose between hours, days, weeks, months



Click “next” and you will get an overview of the different deployment phases, you can reorder them, Add and Edit.



Continue to the end of the wizard and once done you will find the phased deployments



As we can see in the previous pic there’s one Phased deployment and at this time we only have 1 deployment because that deployment haven’t reached the success percentage we configured in the wizard.



You also have a few options on the Phased deployment to either manually move it  to the next phase or if you want to suspend the phases by right-clicking on the phased deployment or by selecting it and do it from the bar at the top.



Once the first phase has reached the success percentage we configured and the clients have reported back to ConfigMgr within a few minutes ( Becasue we configured the “Automatically begin this phase after a deferral period in days” to 0, if we would have gone with 1 day deferral it would wait until that time to kick off phase 2 )



There’s a bunch more settings we could have gone through but I will leave at this as for now and probably do a video showcasing it more in depth.


I didn’t touch on troubleshooting in this post but if you want to look at the log files these are the ones that you should look to over at the primary site server.




That’s all for now and until next time, cheers !

Don’t forget to follow me on twitter


And you can also find me blogging over at



#configmgr, #features, #phased-deployments