PENDING SCCM Boundaries IP ranges with servers in them

[Phil the systems guy]

We have a lot of VPN users that are suddenly offsite using corporate devices, and we want to revise our SCCM boundaries.

I would like to do a giant IP range, rather than individual subnet IP ranges.

A colleague of mine is concerned that these ranges include servers.

My understanding is that boundaries and boundary groups don't automatically push or install anything, and can only help SCCM clients (which servers are not) find a site system or which distribution point to use.

We want to simplify our boundaries and boundary ranges.

Servers are in OUs that are not part of SCCM discovery.

We are not trying to manage servers with SCCM, and are not trying to create boundaries for servers.

Am I missing something? Should servers always exist outside of IP ranges defined in SCCM, when SCCM is not managing them?

Thanks, phil

 

[Youssef Saad]

Hi Phil,

If you are managing the servers with ConfigMgr, you must have a dedicated Subnet for the servers.

The client uses the boundary groups as configured to get it's DP/MP/SUP location, configuring the boundaries as IP Address range is recommended than using IP Subnet or Active Directory site.

 

[Phil the systems guy]

Hi Phil,

If you are managing the servers with ConfigMgr, you must have a dedicated Subnet for the servers.

The client uses the boundary groups as configured to get it's DP/MP/SUP location, configuring the boundaries as IP Address range is recommended than using IP Subnet or Active Directory site.

Thank you. None of our servers are managed by SCCM.

None of our servers have an SCCM client installed.

Based on this, we should not be worried about servers being in the SCCM boundaries.

 

[Gokul]

Thank you. None of our servers are managed by SCCM.

None of our servers have an SCCM client installed.

Based on this, we should not be worried about servers being in the SCCM boundaries.

Hello Phil

If servers are not managed by MEMCM, its not required to create boundary for the same. Better remove the OU of servers from discovery.

 

[Phil the systems guy]

Hello Phil

If servers are not managed by MEMCM, its not required to create boundary for the same. Better remove the OU of servers from discovery.

Perhaps you have misunderstood. There are no server OUs in the discovery.

We want to include all of our IP space in SCCM boundaries. One admin is concerned because there are servers in some IP ranges.

I don't believe this matters, and won't be an issue.

SCCM boundaries won't affect servers (or any computer) that don't have the SCCM client installed, which is all of our servers.

We are not trying to set up boundaries for servers.

 

[Gokul]

Hello Phil,
If servers are not part of discovery , why worries ?

 

[Phil the systems guy]

Hello Phil,
If servers are not part of discovery , why worries ?

I am not worried at all. I don't share that opinion.

One admin on our SCCM admin is worried, not me personally.

I don't know why. Apparently based on a misunderstanding of how SCCM boundaries work.

 

[Gokul]

Perhaps you have misunderstood. There are no server OUs in the discovery.

We want to include all of our IP space in SCCM boundaries. One admin is concerned because there are servers in some IP ranges.

I don't believe this matters, and won't be an issue.

SCCM boundaries won't affect servers (or any computer) that don't have the SCCM client installed, which is all of our servers.

We are not trying to set up boundaries for servers.

Yes you are correct it wont affect your servers. I really appreciate your question

 

[Gokul]

I am not worried at all. I don't share that opinion.

One admin on our SCCM admin is worried, not me personally.

I don't know why. Apparently based on a misunderstanding of how SCCM boundaries work.

Ok

 

[Edy]

IMHO, you should properly define your boundary per subnet range. The reason being that it is cleaner and down the track if you have more DPs or Cloud Management Gateway, you can easily modify a specific boundary instead of a boundary with a giant ip range. as an example, users on VPN subnet may want to connect to Cloud Management Gateway instead of On-Prem Infrastructure.

On another note, how can you manage something that is not being managed. in this case your servers without sccm clients.

 

[Phil the systems guy]

IMHO, you should properly define your boundary per subnet range. The reason being that it is cleaner and down the track if you have more DPs or Cloud Management Gateway, you can easily modify a specific boundary instead of a boundary with a giant ip range. as an example, users on VPN subnet may want to connect to Cloud Management Gateway instead of On-Prem Infrastructure.

On another note, how can you manage something that is not being managed. in this case your servers without sccm clients.

We currently have hundreds of IP range boundaries defined, and 7 distribution points geographically dispersed.

The giant IP range is triage. We did not design our infrastructure to support remote devices.

Existing SCCM clients have been taken offsite and using VPN, and on IP ranges that are outside of our boundaries. Resulting in computers not getting patched or updated or new deployments.

We also are implementing a next generation network with all new IP space, and new IP ranges are implemented without SCCM admins being notified.

So after getting content delivery working again, I'm also creating a boundary group for all VPN connections and not allowing peer sharing, because we are seeing computers on VPN trying to use branch cache and delivery optimization to other computers behind the same NAT, but at geographically different locations.

The next step I plan after stopping the bleeding, is to properly define subnets in Active Directory Sites and Services, and using that in SCCM to automatically create boundaries and cleaning up our boundaries to have the least amount possible.

I don't share the opinion that servers will be impacted. My understanding is that it will have no impact on any computer, workstation or server, unless they have an SCCM client installed, in which case it can basically tell the SCCM client things like what is the site server and which distribution point to use.

 

[Edy]

do you mind if i ask why your servers are not being managed by sccm? are they being managed at all? i also like the idea of using sites instead of subnet because you also need to define those subnets to reach particular DCs etc.

 

[Phil the systems guy]

Of course our servers are all managed. Why they are not managed by SCCM is beyond the scope of this discussion.

 

[Edy]

ok, thanks. I thought we are sharing information here. i was just curious as to why are you not using SCCM to manage your servers.

 

[Phil the systems guy]

ok, thanks. I thought we are sharing information here. i was just curious as to why are you not using SCCM to manage your servers.

Ok fair enough. I work for a county in california and we support every department within the county. Some servers have database considerations that need to be deliberated with the assigned DBA, some have various departmental applications which run scheduled batches and require coordination for any downtime, and other various similar scenarious where a one size fits all windows updates solution won't work for our servers by default.

There may have been some territorial reasons as well, because when we started using SCCM it was for endpoint workstations and handled by our desktop team, not our enterprise team.