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: https://timmyit.com/2018/10/22/intune-powershell-sdk/

 

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 https://timmyit.com/2018/10/22/intune-powershell-sdk/

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
Connect-MSGraph
$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 http://blog.ctglobalservices.com/

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:

https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy

 

 

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:

https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-packages

https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-install-icd

 

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.

 

<#   
    .NOTES
    ===========================================================================
     Created on:    12/12/2018 
     Modified on:   12/12/2018 
     Created by:    Timmy Andersson
     Twitter:       @TimmyITdotcom
     Blog:          www.timmyit.com & https://blog.ctglobalservices.com/author/tan/
    ===========================================================================
    .DESCRIPTION
        MDM Join script. Creates a registry key and a schedule task to start the process to MDM join a computer. 
#>

Begin{

$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="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Author>Microsoft Corporation</Author>
<URI>\Microsoft\Windows\EnterpriseMgmt\Schedule created by enrollment client for automatically enrolling in MDM from AAD</URI>
<SecurityDescriptor>D:P(A;;FA;;;BA)(A;;FA;;;SY)(A;;FRFX;;;LS)</SecurityDescriptor>
</RegistrationInfo>
<Triggers>
<TimeTrigger>
<Repetition>
<Interval>PT5M</Interval>
<Duration>P1D</Duration>
<StopAtDurationEnd>true</StopAtDurationEnd>
</Repetition>
<StartBoundary>$($Date)T$($Time)</StartBoundary>
<Enabled>true</Enabled>
</TimeTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>S-1-5-18</UserId>
<RunLevel>LeastPrivilege</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>Queue</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>true</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>true</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>false</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
<UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT1H</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>%windir%\system32\deviceenroller.exe</Command>
<Arguments>/c /AutoEnrollMDM</Arguments>
</Exec>
</Actions>
</Task>

"@

}
Process
{

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 http://blog.ctglobalservices.com/

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 https://github.com/microsoftgraph/powershell-intune-samples 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

https://www.niallbrady.com/2017/08/23/getting-started-with-microsoft-graph-and-using-powershell-to-automate-things-in-intune/

 

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.

 

https://github.com/Microsoft/Intune-PowerShell-SDK

 

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 https://github.com/Microsoft/Intune-PowerShell-SDK

 

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

 

Connect-MSGraph 

 

 

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

For example

 

Get-DeviceAppManagement_MobileApps

 

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 http://blog.ctglobalservices.com/

ConfigMgr Technical Preview 1710 – Run script update

 

Last night for us Europeans there was another ConfigMgr Technical Preview release and this time its version 1710. There are many new great features indroduced to this Technical Preview and the full overview you can find over at Microsoft.

https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1710

 

In this post I will focus on one of the things that i find the most exciting in regards to the Run Script feature which is a way to almost in real-time execute powershell scripts directly on clients.

See my other posts on this feature if you need to get up to speed on what it is and how to use it:

 

http://blog.ctglobalservices.com/powershell/tan/how-to-activate-the-new-feature-run-powershell-scripts-from-the-configmgr-console-on-current-branch-1706/

http://blog.ctglobalservices.com/powershell/tan/create-and-run-scripts-with-the-new-feature-run-powershell-scripts-from-the-configmgr-console-on-current-branch-1706/

https://timmyit.com/2017/09/18/baseline-evaluation-with-run-script-feature-in-configmgr-1706/

 

 

 

The Wizard

 

One of the big updates here is the wizard and the ability to get realtime output to show up in the wizard during execution of the script.

When executing the script you will see a green statusbar that indicates that somethings i happening and under that you know have box that will populate with data onces the client have runned the script and reported back which just takes a few seconds.

 

(Side note, The script I’m running below is just a Ping to localhost on each client)

 

 

One of the options you have is the “Script details” found in the botton left corner and here you will se information like “Script name, Script Version, Last modified Time, Collection ID”

 

 

In the middle you have “Summary” which is the default one you will see and from here you can change how you want to view the data.

The data you can view is

  • Script output
  • Script Exit code

and you can view them as

  • Bar Chart
  • Pie Chart
  • Data table

 

 

You can also view this information on scripts you ran histroically if you go to Monitoring -> Script Status and right-click and than click on Show status (You will also able to preview the some information in the lower part of the console)

 

 

After clicking on Show Status you will get prompted by this windows containing all the info we saw in the Wizard when executing the script and can sort the data in the same way.

 

Parameters

The next thing i want to showcase is the Parameter functionallity which gives us the ability to specify a parameter when executing the script towards a collection. Here we are creating a new script which is called “Ping Parameter”

and in this script we will add a parameter and then do a ping with a variable based on that parameter.

 

 

Once clicking “Next” we get option to Edit the Parameter

 

 

From here we can change a few options like Data Type, required true or false etc. Also able to add a Description that will show up later when executing the script.

 

 

Once configured click next and then you have to approve the script as always. Next step is to run the script and when we do that we get the following option now to enter a parameter. In this case we need to enter the computer name we want to ping with the ping script we just created.

The description box shows the information we wrote earlier telling the user who executes the script some information about the parameter and what they need to enter.

 

 

We run the script and gets prompted with information as expected

 

 

but if we check under “Script Details” we find additional information on the parameter we entered

 

 

 

These are really cool additions to this great feature and I’m really happy that the ConfigMgr team just keep on working on it and add functionallity. Hopefully we can see some of these changes to the pre-release feature in the next ConfigMgr CB build.

 

 

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 http://blog.ctglobalservices.com/

 

 

#configmgr, #powershell, #run-script, #technical-preview, #technical-preview-1710

Baseline Evaluation with Run script feature in ConfigMgr 1706

 

One of the new pre-realease features in ConfigMgr 1706 is the Run Script function which makes it possible to run Powershell scripts directly from the ConfigMgr console towards clients. This is a huge benefit to be able to do so because this means as long as the client is active in ConfigMgr console it will execute the script you triggered almost in real time and without going through the process of making sure that WinRM is active on the client and configuring firewall and all the other things that can be an issue when you deal with clients on different subnets, physical locations, behind different firewalls etc. As long as you have your ConfigMgr infrastructure in place and the clients are active you are all good to go.

 

What you could do and as I will showcase in this post is to invoke Configuration baseline evaluation on demand with the Run script function. I have an old blog post on how to to it with Powershell remotely ( https://timmyit.com/2016/07/26/sccm-and-powershell-trigger-baseline-evaluation-on-client/ ) but that means you have to have everything in place to remote access clients with Powershell which isn’t always the case in a lot of environments for many reasons.

The reason for creating this script in the first place is because there’s no built in function to evaluate baselines on demand in ConfigMgr. I have also created an uservoice to add that function in the UI console here: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/18652852-console-ui-function-to-invoke-evaluation-of-baseli

Give that uservoice a vote if you find it useful and in the mean time we can use the run script function to achieve the same result.

 

If you want to know in detail how to active the run script feature in ConfigMgr 1706 and how to create a script and run it in detail check out my blog posts about that over at CTGlobalservices blog:

 

http://blog.ctglobalservices.com/powershell/tan/how-to-activate-the-new-feature-run-powershell-scripts-from-the-configmgr-console-on-current-branch-1706/

http://blog.ctglobalservices.com/powershell/tan/create-and-run-scripts-with-the-new-feature-run-powershell-scripts-from-the-configmgr-console-on-current-branch-1706/

 

Baseline Evaluation with Run script feature

 

Here’s the Powershell script we want to use to evaluate all of the baselines deployed to the machines in a device collection. If you just want to evaluate a specific one you need to modify the script.

 

Note,

When testing this script as a Run script I wasn’t able to run the original Powershell script as a function, it returned Exit code 0 but didn’t execute the evaluation method on the client for some reason through ConfigMgr but it did work when I ran it manually on the client. I’m currently troubleshooting that and will probably file a bug report when I have more info and do a separate blog post on that later. But in the meantime we will just have to skip function part. And just to emphasis this is still a prerelease feature.

 


$Baselines = Get-WmiObject -ComputerName $env:COMPUTERNAME -Namespace root\ccm\dcm -Class SMS_DesiredConfiguration
$Baselines | % {

([wmiclass]"\\$env:COMPUTERNAME\root\ccm\dcm:SMS_DesiredConfiguration").TriggerEvaluation($_.Name, $_.Version)

}

 

First off all, lets create a script

 

Copy the or import the powershell script

 

Approve the script you just created.

 

 

Over at the client you can see that we have a Baseline that hasn’t been evaluated yet

 

Jumping back to the ConfigMgr console we find the device collection we want to run the script against and then right click and choose “Run Script” and go through the wizard

 

 

Under Client operations we can see that the operation has started

 

And under monitoring and “Script Status” we see that the evaluation has completed on the client.

 

 

and finally over at the client we see that the Baseline has been evaluated.

 

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 http://blog.ctglobalservices.com/

Import boundaries to SCCM with powershell

 
This is the second blog post in a series of two where the first one was about exporting boundaries from ConfigMgr to .CSV files and you can check out that post here: https://timmyit.com/2017/04/25/export-boundaries-from-sccm-with-powershell/

Now its time for us to import it to ConfigMgr and it’s very simple to do, all you need is the powershell script listed below (it’s also available over at technet for download https://gallery.technet.microsoft.com/Import-boundaries-from-46b9a894 )

 

What do we want to achieve?

We want to be able to import the boundaries we exported in to .CSV files from the https://timmyit.com/2017/04/25/export-boundaries-from-sccm-with-powershell/ guide and have them to show up in ConfigMgr. There’s no built in feature to export and import boundaries as of now in ConfigMgr so that’s why we turn to powershell to help us out with this process.

 

 

The Script

 

<#   
    .NOTES
    ===========================================================================
     Created on:    4/10/2017 
     Modified on:   4/21/2017 
     Created by:    Timmy Andersson
     Twitter:       @TimmyITdotcom
     Blog:          www.timmyit.com
    ===========================================================================
    .DESCRIPTION
        Import Subnet an IPRange Boundries to CSV files. This script needs to run on the siteserver to work. 
        Specify source path with the parameter -SourcePath
#>
[CmdletBinding(DefaultParameterSetName = 'SourcePath')]
param
(
[Parameter(Mandatory = $true,
Position = 1)]
$SourcePath
)

Begin{
$SiteCodeObjs = Get-WmiObject -Namespace "root\SMS" -Class SMS_ProviderLocation -ComputerName $env:COMPUTERNAME -ErrorAction Stop
	foreach ($SiteCodeObj in $SiteCodeObjs)
	{
		if ($SiteCodeObj.ProviderForLocalSite -eq $true)
			{
			$SiteCode = $SiteCodeObj.SiteCode
			}
	}
$SitePath = $SiteCode + ":"
Import-module ($Env:SMS_ADMIN_UI_PATH.Substring(0, $Env:SMS_ADMIN_UI_PATH.Length - 5) + '\ConfigurationManager.psd1')
}
Process
{
	$Subnets = (Import-csv "$SourcePath\BoundariesIPSubnet.csv") 
	$IPRanges = (Import-csv "$SourcePath\BoundariesIPRange.csv" )


Set-Location $SitePath
			If ($Subnets -ne $null)
			{
				Foreach ($Subnet in $Subnets)
					{
					 New-CMBoundary -Type IPSubnet -Value "$($Subnet.Value)" -Name "$($Subnet.Key)"
					}
			}

		If ($IPRanges -ne $null)
			{
				Foreach ($IPRange in $IPRanges)
					{
					 New-CMBoundary -Type IPRange -Value "$($IPRange.Value)" -Name "$($IPRange.Key)"
					}
			}
}


 

 

Example

  •  Save the script and run it from your site server
  • Call the script and specify the parameter -SourcePath for where you saved the .csv files that was created with the Export-Boundaries.ps1 script
    • Import-Boundaries.ps1 -SourcePath C:\temp\boundaries
  • Once the script finished the boundaries should be imported to your ConfigMgr environment.

 

 

Remember that you still need to create boundary groups and link them to your boundaries once your done with the import.

 

Until next time, cheers !

You can find me over at

Export boundaries from SCCM with powershell

This blog post is the first in a series of 2 where i will showcase how to export iprange and subnet boundaries and then how to import them with the help of a powershell script. I’m a big proponent for automating task to increase productivity and I believe in the mindset of always trying to improve what ever you are doing, regardless if that’s improving your workflow or learning something new to improve yourself. Invest time now to save time later but lets get back to the topic of this post and that’s about exporting boundaries from SCCM.

 

Part 2, Importing boundaries can be found here: https://timmyit.com/2017/05/02/import-boundaries-to-sccm-with-powershell/

What do we want to achieve?

For example If you are in the process of setting up a new ConfigMgr environment and there’s an existing ConfigMgr environment that’s getting decommissioned but you aren’t performing a site migration and there’s still information like boundaries that
will be reused then here’s a script that will help you export IPRange and Subnet boundaries to .csv so you later can import them in the new environment because there’s no built in function in ConfigMgr to do that at the moment.

In the picture below we have our boundaries we want to export in to a file (in this case a .csv) and then later be able to import them back in to ConfigMgr.

 

 

 

The script


<#   
    .NOTES
    ===========================================================================
     Created on:    4/10/2017 
     Modified on:   4/21/2017 
     Created by:    Timmy Andersson
     Twitter:       @TimmyITdotcom
     Blog:          www.timmyit.com
    ===========================================================================
    .DESCRIPTION
        Export Subnet an IPRange Boundaries to CSV files. This script needs to run on the siteserver to work. 
		Specify Destination path with the parameter $DestinationPath
#>
[CmdletBinding(DefaultParameterSetName = 'DestinationPath')]
param
(
[Parameter(Mandatory = $true,
Position = 1)]
$DestinationPath
)
BEGIN
{
 
$SiteCodeObjs = Get-WmiObject -Namespace "root\SMS" -Class SMS_ProviderLocation -ComputerName $env:COMPUTERNAME -ErrorAction Stop
	foreach ($SiteCodeObj in $SiteCodeObjs)
	{
		if ($SiteCodeObj.ProviderForLocalSite -eq $true)
		{
		$SiteCode = $SiteCodeObj.SiteCode
		}
	}

$SitePath = $SiteCode + ":"
 
Import-module ($Env:SMS_ADMIN_UI_PATH.Substring(0, $Env:SMS_ADMIN_UI_PATH.Length - 5) + '\ConfigurationManager.psd1')
 
}
PROCESS
{
	 
    Set-Location $SitePath
	$BoundriesSubnet = (Get-CMBoundary -BoundaryName * | Where-Object {$_.BoundaryType -like "0"})
	$BoundriesRange = (Get-CMBoundary -BoundaryName * | Where-Object {$_.BoundaryType -like "3"})
    $ErrorActionPreference = 'Continue'
    $IPrange = $null
    $IPrange = @{}
    $IPSubnet = $null
    $IPSubnet = @{}

	If ($BoundriesSubnet.count -gt "0")
	{
		foreach ($Boundry in $BoundriesSubnet)
			{
				$IPrange.Add($($Boundry.DisplayName),$($Boundry.Value))

			}
				$IPrange.GetEnumerator() | export-csv "$DestinationPath\BoundariesIPSubnet.csv" -NoTypeInformation -Encoding Unicode
	}
	If ($BoundriesRange.count -gt "0")
	{
		foreach ($Boundry in $BoundriesRange)
			{
				$IPSubnet.Add($($Boundry.DisplayName),$($Boundry.Value))

			}
				$IPSubnet.GetEnumerator() | export-csv "$DestinationPath\BoundariesIPRange.csv" -NoTypeInformation -Encoding Unicode
	}
		
}
END
{
	Invoke-Item $DestinationPath
}




Example

 

  •  Save the script and run it from your site server
  • Call the script and specify the parameter -DestinationPath for where you want to output the .csv files that gets created to.
    • Export-Boundaries.ps1 -DestinationPath C:\temp\boundaries
  • Once the script finished the destinationPath you specified will open up in explorer and you will find 1 files for iprange boundaries and one for subnet depending on what you have in your environment.

 

There you have it, its pretty simple and saves a lot of time if there’s a lot of boundaries to manually create in the new environment.

Next blog post will be about how to import the exported boundaries to ConfigMgr with the help of powershell.

Part 2, Importing boundaries can be found here: https://timmyit.com/2017/05/02/import-boundaries-to-sccm-with-powershell/

 

Until next time, cheers !

You can find me over at