Hi all I'm setting up my boundaries (IP subnets). Fo example, one subnet is 10.10.0.0 with a subnet mask of 255.255.252.0 which should limit it to 10.10.0.1 to 10.10.3.254. However, when I click OK to confirm the change and then go back into the properties, SCCM just puts the subnet ID to 10.10.0.0. Does SCCM take into account the subnet mask and limite the boundary between 10.10.0.1 - 10.10.3.254 or does it ignore it a service all address starting with 10.10.x.x? Thanks, Jesmat.

Use IP Ranges. The IP Boundary implementation in ConfigMgr is unaware of VLSMs and CIDR.Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys

That's what I feared. Thanks! Jesmat.

Jason, Isn't the IP Subnet automatically calculated on the client? For example, if I am on subnet 10.1.2.0/23, this covers a range of 10.1.2.0 - 10.1.3.255. I have a client whose IP address is 10.1.3.41, but when I looking at the general tab of the Configuration Manager Properties panel, it states that the IP Subnet is 10.1.2.0. Doesn't this mean that if I create a boundary type IP subnet, with a subnet ID of 10.1.2.0 that this will fully satisfy the boundary requirement for the range 10.1.2.0 - 10.1.3.255? If so, this would mean that Jesmat and myself would not have to use IP Ranges. Thanks for the clarification.

That's the logical way to think about but no, that's not what ConfigMgr is doing. If you look at the boundary in ConfigMgr, it is actually calculating the Network ID -- even though it's called a subnet it's not, it is clearly labeled and used as a Network ID. This is also calculated on the client and if they don't match, which is often the case because it doesn't really use the subnet mask like one would expect, you get weird results. Also, supernets are not supported for this reason. IP Ranges offer zero ambiguity and aren't any more difficult to use of configure so that's why I always recommend their use.Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys

In my experience as long as "IP subnet" on the client has matched the "Subnet ID" in the boundary configuration, I haven't found the need to configure IP ranges, no matter what the subnet mask is. I haven't come across many situations where these weren't matching up either.

My experience aligns with elgwhoppo's. I've never had a problem using IP Subnets regardless of customers with a very wide range of masks.Steve Bobosky - www.systemcentertools.com - systemcentertools.blogspot.com

Hi Steve, From what I have seen unless the client PCs also use the same subnet mask as the boundary. Ie. Boundary are /22 and the client use /22 everything is find but if the clients use a /24 then only the 10.10.0.x client will automatically assign to site but client in the 10.10.2.x range will no automatically assign due to the miss match in subnets. IP Ranges are a better option than subnet, as a matter of fact a few of the MVPs ask the product team to remove subnet from boundaries due to this being one of the hottest topic and no one ever seem to fully understand the issues. BTW here is a excerpt from an old myITforum mailing list post on the subject that you might have seen. To quote from one of my old myITforum mailing list post. http://technet.microsoft.com/en-ca/library/cc754697.aspx “Domain controllers and other servers that use sites publish server objects in AD DS to take advantage of the good network connectivity that sites provide.” “Server objects are created in AD DS by applications or services, and they are placed into a site based on their IP address. When you add the Active Directory Domain Services server role to a server, a server object is created in the AD DS site that contains the subnet to which the server's IP address maps.” “For a client, site assignment is determined dynamically by its IP address and subnet mask during logon.” “Locating domain controllers by site Domain controllers register service (SRV) resource records in Domain Name System (DNS) that identify their site names. Domain controllers also register host (A) resource records in DNS that identify their IP addresses. When a client requests a domain controller, it provides its site name to DNS. DNS uses the site name to locate a domain controller in that site (or in the next closest site to the client). DNS then provides the IP address of the domain controller to the client for the purpose of connecting to the domain controller. For this reason, it is important to ensure that the IP address that you assign to a domain controller maps to a subnet that is associated with the site of the respective server object. Otherwise, when a client requests a domain controller, the IP address that is returned might be the IP address of a domain controller in a distant site. When a client connects to a distant site, the result can be slow performance and unnecessary traffic on expensive WAN links.” So basically if you don’t setup you AD correctly, then your client will authentic with a random DC and it could be over a WAN link.http://www.enhansoft.com/