Part 9: Boundaries & Boundary Groups

Boundaries have got to be one of the most overlooked and difficult to grasp concepts in ConfigMgr. While not overly complex a lot of people don’t really understand how they work, particularly IP Subnets which are unfortunately not an accurate representation of what they are.

What are they

The short answer is a boundary is a network location that a client can identify as being on. These are in turn grouped together so that resources like Distribution Points and site systems can be associated with them.

Why you need them

Without boundaries clients don’t know where to go to get content or what site they should connect to (only if you have multiple sites in your environment). When you configure a boundary, lets call it Boundary A and associate it with Boundary Group ‘Sydney’, Clients that identify as being on Boundary ‘A’ will go to the Distribution Point associated with Boundary group ‘Sydney’.

It’s critical for networks that boundaries be configured so that content distribution can be managed in a way that does not saturate WAN links. This can be particularly a problem for links that are small like 2Mb.

Types

  • IP Subnet – This is a bit of a misnomer, these boundaries are actually subnet ID’s NOT subnets. There is quite a bit of confusion around how these work, suffice it to say that you want to only use /24 subnets when using this type of boundary.
  • Active Directory Site – Imported directly from AD Sites and Services. Requires Forest discovery to be configured.
  • IPv6 Prefix – Like IP Subnets but for IPv6.
  • IP Address Range – Explicit range of IP addresses. Not recommended to be used due to the high SQL performance impact.

Bulk creation

Kaido Järvemets has written an excellent script for completing this, for all the details check it out here.

[Threading.Thread]::CurrentThread.CurrentCulture = 'en-US'
$XLSX = New-Object -ComObject "Excel.Application"

$BoundariesXLSXFile = "C:\Users\Administrator\Desktop\CM_Boundaries.xlsx"
$Path = (Resolve-Path $BoundariesXLSXFile).Path
$SavePath = $Path -replace ".xl\w*$",".csv"

$WorkBook = $XLSX.Workbooks.Open($Path)
$WorkBook.SaveAs($SavePath,6)
$WorkBook.Close($False)
$XLSX.Quit()

$Boundaries = Import-Csv $SavePath

foreach($Item in $Boundaries)
{
Switch($item.'Boundary Type')
{

"IP Subnet" {$Type = 0}
"Active Directory Site" {$Type = 1}
"IPv6" {$Type = 2}
"Ip Address Range" {$Type = 3}

}

$Arguments = @{DisplayName = $Item.'Display Name'; BoundaryType = $Type; Value = $Item.Value}

Set-WmiInstance -Namespace "Root\SMS\Site_PRI" -Class SMS_Boundary -Arguments $Arguments -ComputerName Server100
}

My Recommendation

There’s much to be said about using IP Subnets and how they’re evil. My experience is that if you’ve got them defined and you’re only using /24 addresses then you’ll be fine. Where this is not the case leverage IP Ranges.

Further reading:
ConfigMngrFTW – IP Subnet Boundaries Are Still Evil
TechNet – Planning for Boundaries and Boundary Groups in Configuration Manager

Advertisements

SCCM Compliance – PowerShell version

One of the first things I always like to setup in compliance is a CI which checks for a minimum version of PowerShell. This is especially helpful when you’re writing advanced compliance scripts in PowerShell and they’re not running as expected across some of your environment. In my experience this is usually because some of the devices have an old version of PowerShell.

Compliance Settings:

Setting Type:

 Script

Data Type:

 Integer

Discovery script:

$PSVersionTable.PSVersion.Major

Remediation script:

I’m not using a Remediation script, better to just deploy Windows Management Framework across you’re environment and use compliance as validation.

Make sure that Run scripts by using the logged on user credentials is ticked.

Compliance Rules:

Rule Type:

Value

The value returned by the specified script:

Greater than or equal to

The following values:

 3

Report noncompliance if this setting instance is not found

Yes

Noncompliance severity for reports

 Critical

SCCM Compliance: Where to start

Compliance in SCCM is one of the most powerful and overlooked features, ultimately your imagination is the only limit to what it can do. There’s a whole range of ways you can use compliance but the most powerful is PowerShell. There’s a few things you want to do before you start building any Configuration item’s or baselines though.

  1. Change your PowerShell execution to Bypass in SCCM client settings
  2. Deploy Windows Management Framework 4.0 – Don’t reinvent the wheel just deploy it as an application using scripts ‘ wusa.exe Windows6.1-KB2819745-x64-MultiPkg.msu /quiet /norestart’
  3. Check PowerShell version across the board using compliance

To get started some great things to use compliance for include:

  1. SOE related settings
  2. Are core apps installed and healthy?
  3. Is AV running?
  4. Are your certificates installed on all systems?