Microsoft System Center Configuration Manager (ConfigMgr or SCCM) has the option to use Microsoft’s BranchCache technology in order to enable clients to obtain content from local clients that have a current cache of the content. When a BranchCache-enabled client computer first requests content from a distribution point configured with BranchCache, the client will usually download the content and cache it in the BranchCache cache. This ConfigMgr content is then made available to other BranchCache-enabled clients on the same subnet that request it, and these clients also cache the content.
The key reasons that BranchCache is not suitable for ConfigMgr content distribution are that it:
Uses Background Intelligent Transfer Service (BITS), which has poor WAN bandwidth throttling, which is one of the key problems that most ConfigMgr-using organizations struggle with. BITS throttles based on worst-case pre-configurations that you set and bases its throttling on what it sees at the client NIC and first router. Activity at higher hops is not accounted for, leading to network congestion at those higher levels of the network
Has very limited operating system deployment (OSD) support. BranchCache cannot be used in WinPE, and it offers no solution to the need for supporting PXE boot methods or state migration servers
Has no centralized status reporting. You cannot readily verify or demonstrate that it is working as intended, nor can you find problems in order to correct them
Caches content only for 28 days, though much of your ConfigMgr content will be needed for long after that, such as for OSD, patching new computers, or providing software to users as they change roles
Is not enabled by default to run on computers running on battery power. A significant number of your computers are probably laptops, and most of the time when they’re available on your corporate network they may be in meetings or other scenarios where they are running on batteries
Has no options to control the selection of the best (and never inappropriate) computers to serve content to peers.
To elaborate on those points respectively:
1. BITS is used by BranchCache as the transport protocol when obtaining the original content from a ConfigMgr distribution point. BITS has known limitations in both configuration and its capabilities when assessing network utilization.
a. BITS determines network utilization from the Network Adapter (NIC) of the client and usually from the router it connects to. Beyond that BITS has no awareness of the network activity levels to the distribution point and therefore is likely to aggravate network congestion on higher hops to the DP. This is a common network scenario in almost every modern enterprise network.
b. The throttling capability of BITS can only be specified by placing fixed percentage rate limits as the kbps level. This requires detailed knowledge of the network link speed end-to-end, estimating the worst case traffic usage scenario to reduce the risk of impact to other traffic, and then using that worst case scenario as a physical setting for all traffic. Even when network capacity becomes available, BITS can only utilize the set amount pre-configured for the worst case scenario and cannot make use of this spare capacity. As circumstances in a network change those settings must be revisited and requires considerable operational overhead for any sizable environment. Weekends have the same limits applied as weekdays restricting network traffic at an optimal time.
2. BranchCache has very limited support for OSD scenarios. WinPE does not include support for BranchCache. Provision of large WIM image files and driver packages that are required in the WinPE phase of an OSD build cannot be supplied using BranchCache and these large packages would require downloading at build time from a distribution point.
3. BranchCache does not generate ConfigMgr status messages, or provide any other means of reporting that can be viewed centrally from the Configuration Manager console or any other reporting interface. BranchCache only writes events to the local Windows event log. Administrators therefore cannot centrally verify the effectiveness or success of BranchCache in facilitating ConfigMgr deployments.
4. The default maximum client cache age is 28 days. This setting is applied to all content in BranchCache and content will only be removed when this age is reached. This is likely to cause the premature deletion of very large content that will require downloading again to the location after it has been removed.
5. By default BranchCache does not serve content when on battery power (for example, laptops at meetings).
a. There are NETSH and PowerShell commands to override this on Windows 8 or newer.
6. There is no weighting or similar mechanism, based on either system type or configuration options, to determine the most appropriate BranchCache system to download and serve requested content.
a. As a consequence the most appropriate client will not necessarily be used to serve content. A laptop is as likely to be selected as a desktop computer or a server.
b. Organizations may want to prioritize certain computers to be more likely to serve content, and for other computers to never serve content. As there is no mechanism to specify preferences for determining the BranchCache system allocated, this level of flexibility is not possible.
7. Not every BranchCache client has, or retains, the full package that has been requested.
a. This places increased risk that the complete amount of content requested is not available at a location when being required by subsequent client systems, and therefore there is an increased risk that duplication of content download will be necessary.
b. This is especially the case when the following occurs:
i. Multiple clients originally needed the package at once. The content BranchCache metadata is often not calculated as fast as the content is downloaded. Therefore some of the content is downloaded with BranchCache and some just with BITS.
ii. The first client that needed the package. May also suffer from that problem but possibly less so since the DP may be able to keep up with the metadata calculation more successfully.
iii. Subnets including both Windows 7 and Windows 8 clients. This causes the metadata to be calculated in two formats.
8. The BranchCache cache is entirely independent from the ConfigMgr cache, so the content must be physically stored on disk for both. The content thereby takes up twice as much disk space on each system. Nomad uses hard-links so that the ConfigMgr cache appears to have the content but the only copy is actually in the Nomad cache.
9. Microsoft does not recommend using BranchCache on subnets with 100 or more clients. See the BranchCache design guide: http://www.microsoft.com/en-us/download/details.aspx?id=2559
10. BranchCache is not offered as a Windows XP feature. Though most organizations have replaced or are replacing Windows XP machines, any that remain must download all content from a distribution point and cannot make use of the BranchCache technology.
11. ConfigMgr only offers PXE support for distribution points, and they must have WDS for PXE, so that means the DPs must be running on Windows Server. The functionality of a State Migration Point also requires a server and without this user data backups with USMT cannot be integrated into the OSD build scenarios being utilized. The net result is that BranchCache doesn’t address the core OSD issues around content management.
12. BranchCache cannot support clients located across multiple subnets. Therefore content must be downloaded once per subnet in locations where multiple subnets exist. This increases the amount of data that must be downloaded to the location and increases network utilization. In scenarios where multiple clients in multiple subnets all require the content at the same time, the limitations of BITS causes a cumulative effect as they are not aware of each other, greatly increasing the risk of causing network congestion and impacting other network traffic. Nomad has the Single Site Download feature
13. Mixed environments of Windows 7 and Windows 8 cannot work together. This increases the amount of content to be downloaded as they are not able to share content
a. Windows 8 can be configured for compatibility mode with Windows 7, however this removes the availability of new features and improvements to the Windows 8 version.
b. This is true as long as the DP is Windows Server 2012 or better. It can be overridden by turning off Windows 8 features and improvements (such as hash precalculation, or that cache retention can be increased)
14. BranchCache does not have any multicast capabilities to minimize deployments when large content must be delivered to many clients simultaneously.
15. Does not help with files less than 64KB in size. The impact of this issue will vary by package but can possibly account for about 5% of the overall package size.
16. Cache management is limited to a percentage of total disk space. Thus it will vary depending on disk size (a small 120GB SSD could have only 6 GB, for example), and could cause a user to run out of disk space if they use a large fraction of the disk (95%). The percentage can be adjusted via group policy with Windows 8, but it’s still a percentage.
17. BranchCache elections are done for every file or file segment in the package, as opposed to for the package as a whole. This could add LAN network congestion.
18. Non-domain-joined (workgroup) clients are not supported by BranchCache.
19. HTTP must be enabled for client-to-client transfers. This might be a security concern for some organizations.
BranchCache can use BITS, SMB or HTTP, for content retrieval. SMB and HTTP support seem to require Windows Enterprise version. BranchCache uses WSD (WS-Discovery protocol) for peer discovery.
BranchCache does not download files smaller than 64KB - the requesting client will receive these directly through normal BITS/SMB/HTTP transfer).
The key reasons that BranchCache is not suitable for ConfigMgr content distribution are that it:
Uses Background Intelligent Transfer Service (BITS), which has poor WAN bandwidth throttling, which is one of the key problems that most ConfigMgr-using organizations struggle with. BITS throttles based on worst-case pre-configurations that you set and bases its throttling on what it sees at the client NIC and first router. Activity at higher hops is not accounted for, leading to network congestion at those higher levels of the network
Has very limited operating system deployment (OSD) support. BranchCache cannot be used in WinPE, and it offers no solution to the need for supporting PXE boot methods or state migration servers
Has no centralized status reporting. You cannot readily verify or demonstrate that it is working as intended, nor can you find problems in order to correct them
Caches content only for 28 days, though much of your ConfigMgr content will be needed for long after that, such as for OSD, patching new computers, or providing software to users as they change roles
Is not enabled by default to run on computers running on battery power. A significant number of your computers are probably laptops, and most of the time when they’re available on your corporate network they may be in meetings or other scenarios where they are running on batteries
Has no options to control the selection of the best (and never inappropriate) computers to serve content to peers.
To elaborate on those points respectively:
1. BITS is used by BranchCache as the transport protocol when obtaining the original content from a ConfigMgr distribution point. BITS has known limitations in both configuration and its capabilities when assessing network utilization.
a. BITS determines network utilization from the Network Adapter (NIC) of the client and usually from the router it connects to. Beyond that BITS has no awareness of the network activity levels to the distribution point and therefore is likely to aggravate network congestion on higher hops to the DP. This is a common network scenario in almost every modern enterprise network.
b. The throttling capability of BITS can only be specified by placing fixed percentage rate limits as the kbps level. This requires detailed knowledge of the network link speed end-to-end, estimating the worst case traffic usage scenario to reduce the risk of impact to other traffic, and then using that worst case scenario as a physical setting for all traffic. Even when network capacity becomes available, BITS can only utilize the set amount pre-configured for the worst case scenario and cannot make use of this spare capacity. As circumstances in a network change those settings must be revisited and requires considerable operational overhead for any sizable environment. Weekends have the same limits applied as weekdays restricting network traffic at an optimal time.
2. BranchCache has very limited support for OSD scenarios. WinPE does not include support for BranchCache. Provision of large WIM image files and driver packages that are required in the WinPE phase of an OSD build cannot be supplied using BranchCache and these large packages would require downloading at build time from a distribution point.
3. BranchCache does not generate ConfigMgr status messages, or provide any other means of reporting that can be viewed centrally from the Configuration Manager console or any other reporting interface. BranchCache only writes events to the local Windows event log. Administrators therefore cannot centrally verify the effectiveness or success of BranchCache in facilitating ConfigMgr deployments.
4. The default maximum client cache age is 28 days. This setting is applied to all content in BranchCache and content will only be removed when this age is reached. This is likely to cause the premature deletion of very large content that will require downloading again to the location after it has been removed.
5. By default BranchCache does not serve content when on battery power (for example, laptops at meetings).
a. There are NETSH and PowerShell commands to override this on Windows 8 or newer.
6. There is no weighting or similar mechanism, based on either system type or configuration options, to determine the most appropriate BranchCache system to download and serve requested content.
a. As a consequence the most appropriate client will not necessarily be used to serve content. A laptop is as likely to be selected as a desktop computer or a server.
b. Organizations may want to prioritize certain computers to be more likely to serve content, and for other computers to never serve content. As there is no mechanism to specify preferences for determining the BranchCache system allocated, this level of flexibility is not possible.
7. Not every BranchCache client has, or retains, the full package that has been requested.
a. This places increased risk that the complete amount of content requested is not available at a location when being required by subsequent client systems, and therefore there is an increased risk that duplication of content download will be necessary.
b. This is especially the case when the following occurs:
i. Multiple clients originally needed the package at once. The content BranchCache metadata is often not calculated as fast as the content is downloaded. Therefore some of the content is downloaded with BranchCache and some just with BITS.
ii. The first client that needed the package. May also suffer from that problem but possibly less so since the DP may be able to keep up with the metadata calculation more successfully.
iii. Subnets including both Windows 7 and Windows 8 clients. This causes the metadata to be calculated in two formats.
8. The BranchCache cache is entirely independent from the ConfigMgr cache, so the content must be physically stored on disk for both. The content thereby takes up twice as much disk space on each system. Nomad uses hard-links so that the ConfigMgr cache appears to have the content but the only copy is actually in the Nomad cache.
9. Microsoft does not recommend using BranchCache on subnets with 100 or more clients. See the BranchCache design guide: http://www.microsoft.com/en-us/download/details.aspx?id=2559
10. BranchCache is not offered as a Windows XP feature. Though most organizations have replaced or are replacing Windows XP machines, any that remain must download all content from a distribution point and cannot make use of the BranchCache technology.
11. ConfigMgr only offers PXE support for distribution points, and they must have WDS for PXE, so that means the DPs must be running on Windows Server. The functionality of a State Migration Point also requires a server and without this user data backups with USMT cannot be integrated into the OSD build scenarios being utilized. The net result is that BranchCache doesn’t address the core OSD issues around content management.
12. BranchCache cannot support clients located across multiple subnets. Therefore content must be downloaded once per subnet in locations where multiple subnets exist. This increases the amount of data that must be downloaded to the location and increases network utilization. In scenarios where multiple clients in multiple subnets all require the content at the same time, the limitations of BITS causes a cumulative effect as they are not aware of each other, greatly increasing the risk of causing network congestion and impacting other network traffic. Nomad has the Single Site Download feature
13. Mixed environments of Windows 7 and Windows 8 cannot work together. This increases the amount of content to be downloaded as they are not able to share content
a. Windows 8 can be configured for compatibility mode with Windows 7, however this removes the availability of new features and improvements to the Windows 8 version.
b. This is true as long as the DP is Windows Server 2012 or better. It can be overridden by turning off Windows 8 features and improvements (such as hash precalculation, or that cache retention can be increased)
14. BranchCache does not have any multicast capabilities to minimize deployments when large content must be delivered to many clients simultaneously.
15. Does not help with files less than 64KB in size. The impact of this issue will vary by package but can possibly account for about 5% of the overall package size.
16. Cache management is limited to a percentage of total disk space. Thus it will vary depending on disk size (a small 120GB SSD could have only 6 GB, for example), and could cause a user to run out of disk space if they use a large fraction of the disk (95%). The percentage can be adjusted via group policy with Windows 8, but it’s still a percentage.
17. BranchCache elections are done for every file or file segment in the package, as opposed to for the package as a whole. This could add LAN network congestion.
18. Non-domain-joined (workgroup) clients are not supported by BranchCache.
19. HTTP must be enabled for client-to-client transfers. This might be a security concern for some organizations.
BranchCache can use BITS, SMB or HTTP, for content retrieval. SMB and HTTP support seem to require Windows Enterprise version. BranchCache uses WSD (WS-Discovery protocol) for peer discovery.
BranchCache does not download files smaller than 64KB - the requesting client will receive these directly through normal BITS/SMB/HTTP transfer).
No comments:
Post a Comment