边界、边界组和站点系统 - 3
本篇文章主要讨论ConfigMgr客户端资源发现过程
为陇西等地区用户提供了全套网页设计制作服务,及陇西网站建设行业解决方案。主营业务为成都做网站、成都网站建设、陇西网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!
边界组
当前边界组
指客户端当前网络位置对应的ConfigMgr边界所在的边界组,例如:
客户端Client A的网络地址为:10.0.0.0/24
ConfigMgr边界Boundary A:10.0.0.0 -10.0.0.255
- 边界Boundary A属于边界组BG A
则对于Client A来说,他的当前边界组是BG A
邻居边界组
在ConfigMgr 1610及之后,边界组可以定义一个单向链接指向其他边界组,此单向链接称之为边界组关系,而所指向的其他边界组称之为当前边界组的邻居边界组,例如可以为BG A定义多个邻居边界组BG B、BG C等;
边界组关系
在定义边界组关系时,可以配置退回时间,默认为120分钟,回退时间具体的含义在下文中会解释。
默认站点边界组
每一个ConfigMgr站点在安装时都会创建一个默认站点边界组
ConfigMgr会为每个边界组创建一个隐式链接指向默认站点边界组
隐式链接中所定义退回时间为120分钟,且无法修改
- 客户端如果所在网络位置不落在任何其他边界组内的话,那此客户端会被划分到默认站点边界组内
回退
上一篇中已经介绍了,当客户端需要请求ConfigMgr的各类服务时,会向其首选管理点发送资源定位请求,而管理点会基于客户端当前边界组信息返回对应的站点系统列表;
如果管理点返回的这些站点系统都不可用时,客户端可以使用那些被定义为当前站点边界组的邻居边界组中的站点系统;
分发点回退
当前边界组中的所有分发点都不可用时,客户端会根据当前边界组与其邻居边界组对应的边界组关系中定义的退回时间分别进行计算,当到达退回时间后,客户端会将邻居边界组中的分发点加入分发点列表,并尝试联系每一个分发点
软件更新点
在ConfigMgr 1702中邻居边界组加入了对软件更新点的支持,其回退时间为120分钟,无法修改;
在ConfigMgr 1706中,可以对软件更新点的退回时间进行自定义修改;
软件更新点的回退行为需要注意以下几点:
客户端默认始终使用上一次成功连接上的软件更新点,这是因为软件更新点的切换对于软件更新点和客户端来说都是一个相对较为消耗资源的过程,因为客户端会向新的软件更新点同步软件更新元数据及汇报更新可用性信息;
无论软件更新点的回退时间修改为多少,客户端始终会在当前软件更新点可不用到达120分钟后才选择新的软件更新点
当客户端首次尝试联系上一次成功连接的软件更新点失败后,并到达邻居边界组中的软件更新点退回时间后,将其加入软件更新点列表
- 当客户端无法与上一次成功连接的软件更新点联系到达120分钟之后,客户端会使用更短的循环时间与软件更新点列表中的其他软件更新点通信,确保可以快速地在列表中余下可用的软件更新点
管理点
在ConfigMgr 1802,邻居边界组加入了对管理点的退回支持,并且首选管理点的选择行为也依赖于边界组机制来定义;
具体可以通过在客户端的LocationService.log中观察到新添加的Locality属性标识:
- 0:代表未知
- 1:表示此管理点近与默认站点边界组关联
- 2:表示此管理点位于远程或者邻居边界组中
- 3:表示此管理点位于本地或当前客户端所在边界组中,如果在ConfigMgr层级中没有启用首选管理点功能,则管理点永远标识为3,而无视其位于哪个边界组中
客户端使用管理点的顺序如下:3 > 2 > 1
为读者提炼SCCM涉及的基础知识、注意事项、运行机制以及排错方法等信息是本系列文章的初衷,对于SCCM各组件及功能部署步骤方面的信息,网络中已有较多文章可以参考,因此本系列文章并不侧重于提供类似Step-by-Step的部署指南,还请见谅。同时由于个人能力和知识水平的限制,文中不免有纰漏和出错的地方,还望大家可以指正,非常感谢。
分享题目:#10#SCCM规划-边界、边界组和站点系统-3
分享网址:http://scyingshan.cn/article/jcpcde.html