OK, this is probably one of these articles that only a few people are interested in, but hey why not. The Internet is a mish-mash of information, so let’s add another piece to it ;-)

As some of you might know, the Deployment webservice is able to identify the SCCM site code and assigned site code for a computer by querying Active Directory which is actually a nice feature as this is easier to query than the SCCM SLP. Anyway since SP2 there has been (at least) one change in the way SCCM is storing the boundary information for IP Ranges in Active Directory.

SCCM Boundaries in Active Directory

All SCCM related information is stored in the “System Management” container that can be found within the “System” container in Active Directory. If you are using the “Active Directory Users and Computers” mmc you need to enable the “Advanced Features” to be able to view them. I recommend using a tool like ADExplorer from SysInternals for this.

SCCM boundaries can be defined in 4 different ways:

Active Directory Site

The Active Directory site boundary is stored in an object of the objectClass “mSSMSSite”. There should be one of this object per SCCM Site defined and is typically named “SMS-Site-{SiteCode}” where {SiteCode} is the SCCM Site Code. The Active Directory site boundaries for each SCCM Site are stored in an attribute called “mSSMSRoamingBoundaries”

IP Subnet

Typically an IP subnet is defined as the IP Address with an associated subnet mask. SCCM calculates the Subnet ID from this which is the lowest IP Address in that range. This works quite well and is easy to manage if you use standard C-Class Subnets. Using a different subnet mask will work but sometimes behaves a bit “flaky”. Anyway, in Active Directory only this Subnet ID is stored. So to get the appropriate subnet ID of a specific IP Address you would need to make some assumptions on it. As said, this works well with C-Class subnets.

This Subnet ID is also stored in the same “mSSMSRoamingBoundaries” attribute as the Active Directory Site.

IPv6 prefix

It’s also possible to define the boundary with an IPv6 prefix. In case of having a prefix with IPv6 zero compression it will automatically be translated into the full IPv6 subnet format. So if you search for it depending on the IPv6 prefix of a computer make sure to also extend it to the full IPv6 subnet format.

The IPv6 prefix is again stored in the same “mSSMSRoamingBoundaries” attribute as the Active Directory Site and the IP Subnet. And yes, all of them can be mixed in this attribute

IP address Range

Here we finally have the boundary that changed with SP2. IP address ranges are defined by the lowest and highest IP address of a continuous range. They are stored in an Active Directory object with objectClass “mSSMSRoamingBoundaryRange”. You will find one object per IP address range and it typically has a name of “SMS-{SiteCode}-{LowestIPAddress}-{HighestIPAddress}. Where {SiteCode} is the SCCM Site code and {LowestIPAddress}/{HighestIPAddress} are the Lowest/Highest IP addresses of the IP address range in its decimal format. The lowest and highest IP Address are also stored in two attributes of this object called “mSSMSRangedIPLow” and “mSSMSRangedIPHigh”. The IP addresses are stored again in decimal format.

So far so good. With SCCM SP2 the values of the Attributes have changed (but this change applies only if you create an new IP address range boundary after you installed SP2). Before they were identical to the {LowestIPAddress}/{HighestIPAddress} values used in the name. Now they suddenly turned into negative values and don’t seem to have any reference to the original IP Address. So what happened?

For some reason, SCCM now sets a 255.255.255.255 in front of each IP Address. Binary these are all 1’s now. The value in the Active Directory is stored as a Long value which means it can store a number of 8 Byte. Now we have the 4 Byte of the IP Address and another 4 Byte for the 255.255.255.255 what makes it a quite “huge” number. But as it is interpreted as a signed number, the first bit of the whole sequence will identify if it is a positive or negative number. And as we have a 1 at the very beginning (we actually have at least 32 ;-) ) it is now a negative value.

How do we get around this? The easiest way is probably to just use the IP Value stored in the name. The second option is to add 4,294,967,296 if the value is negative to get the real value. (You can calculate this number as your homework :-) )

SCCM Site information

With the above information we are now able to get the appropriate boundary entry. And the object found should have an attribute called “mSSMSSiteCode”. With the Site code you can now look for the object named SMS-Site-{SiteCode} and this stores all the available information about the SCCM Site.