Deploying Computers with BranchCache
The OSD Toolkit integrates seamlessly with your existing task sequence deployments in Configuration Manager. All options in Configuration Manager remain available without any need for modifications or changes.
If there is something that you feel is missing, then please let us know by email info@2pintsoftware.com
To Cache or not to Cache?
There is no requirement to Pre-Cache content before deploying a computer however the download process will be shorter and can also allow for deployment to take place during business hours when there may be policies in place limiting WAN bandwidth use at these times.
Keep in mind that all Task Sequences executed by users are run under the "Foreground" BITS policy, which is not, by default, bandwidth limited from Configuration Manager. There are other reasons why you shouldn’t use the built-in policy for BITS in Configuration Manager such as local peer network sharing is also capped by this policy.
When it comes to download, there are two choices for the way that you can deploy a task sequence the names of which explain what they’re about:
Download content locally when needed by running task sequence
or:
Download all content locally before starting task sequence
Both options are explained in detail below.
Deploy using "Download all content locally before starting task sequence"
This setting is typically used only when pre-caching, as it downloads all the content locally. This means that every applications and package referenced by the task sequence will be downloaded locally. Usually a task sequence will have conditions to control which packages apply, these variables are not evaluated under this setting and therefore all data is downloaded.
Why can’t I set the Deployment Option to download all content before executing?
This is because these Deployments are for targeting PXE and Media. Since there is no need to "Precache" or deploy to PXE/Media with the setting you can divide it into 2 separate deployments. One for Pre-caching/Deployment and one for Deployment for Full OS/PXE/Media.
The default setup for a TS deployment created to target PXE & Media as well as the full client is to: "Download content locally when needed by running task sequence".
The following screen shots show the default settings:
Figure 10 The default values of the Deployment Settings.
With this setting the Distribution Point settings cannot be changed:
Figure 11: Deployment Options cannot be changed when the PXE & Media target flag has been set.
If you want to pre-cache content, you need to change this flag. The recommended method is to add a second Deployment, which is solely used for pre-caching tasks.
Deploy with "Download content locally when needed by running task sequence"
This is the recommended setting when you are deploying live systems as each task sequence step is evaluated and only the required data is downloaded. This speeds up the process when the TS is running, and since most data should be available locally the process is usually fairly quick. In order to avoid loading all driver packages on all machines you must filter them out by using the deployment variables as conditions.
The default setup for a TS deployment created to target PXE & Media as well as the full client is to "Download content locally when needed by running task sequence". In order to change this, you must change the Deployment option "Make available to the following:" in the deployment properties. Change it to "Only Configuration Manager Clients" and click Apply.
Figure 12 The available values – change to "Only Configuration Manager Clients".
Once you have changed the value (Don’t forget to hit the Apply button before switching tab) you can then go to the Distribution Points tab and change the Deployment options setting.
Figure 13 Available options have changed as PXE & Media is not set.
With this configured as above you can now pre-cache the entire content. Please make sure you have a valid condition on the Task Sequence (shown below) that will prevent the sequence from actually running. In the example below the PreCache variable is checked on the top folder, causing the underlying TS to not be executed. Since the download is initiated before the task sequence starts it will download all content, start the task sequence and then exit out as the PreCache variable is set.
Figure 14 How the PreCache variable should not exist for the TS to run.
You can use whatever mechanism of your liking to set the PreCache variable, as an example either use a Machine Variable or a Collection variable. The best way is probably to have a collection of your "best targeted" desktop systems with one or two machines per branch selected with a dynamic query.
Figure 15 How to set the PreCache variable on a collection.
What happens to the Cache Data during a push of the OS?
Content that is downloaded into the old Windows platform will not be saved by default. This is due to the fact that the process does not know whether or not the disk will be reformatted. Most packages will however be downloaded from other peers and then injected into the cache again, ensuring that many machines have the majority of the packages cached. If you require the cache to be migrated there are few simple steps needed.
Ensure that WinPE is of the right version, read more below about:
Hash Versions and WinPE
Cache Versions and WinPE
Ensure that the Format & Partition step has conditions on it
Ensure that the new OS supports the upgrade (You cannot go back in Cache format)
In place OS upgrade, can my cache come for the ride?
Yes: BranchCache Cache can be upgraded from 7 to Windows 10. The main rule is that the client content can only be upgraded or the left at the same version. If the disk is not reformatted during an upgrade the cache simply persists throughout.
Hash Versions and WinPE
The BranchCache for OSD components in WinPE can use the same feature as the full OS, and the downgraded Hash Version to V1 (Windows 7 & Server 2008). This means that Windows 7 machines can serve the WinPE downloads with content. Choosing V1 Hashes however removes the Data Deduplication functionality in BranchCache. Since De-Dupe and other V2 features greatly enhance BranchCache efficiency it’s worth skipping V1 if you can. Remember that you only need one V2 machines to service the branch during OSD. Therefore, for as long as the OSD process goes, you should always try to use V2. For regular deployments and in order to avoid 2x downloads over the wire it might be worth going with V1if needed but 2Pint Software recommends going with V2 directly wherever possible.
Note: For more information on the awesomeness of Data Deduplication head over to the 2PintSoftware website "All about BranchCache" section. Here’s the link to the Microsoft page that explains this worthwhile technology:-
https://technet.microsoft.com/library/hh831602
Hash upgrade path is generally the same as for cache content discussed below.
Cache Versions and WinPE
Most people use Windows 10 WinPE to deploy their desktop systems today. It's also very likely that, for your future deployments, WinPE will be of a higher version than the operating system being deployed. With that in mind it’s good to know that Cache information can be migrated to the same or higher versions of the OS.
This means that if you are using WinPE of build 9600 (Windows 8.1) to deploy Windows 7 (Build 920/1) the Cache that is generated under WinPE cannot be successfully migrated to the new OS. Even though you run the Cache Enabler tool with the Move command, the new OS will not understand the new Cache format and re-initiate the Cache. This is the case even if you are using the V1 Hash format. Cache format and Hash format are not the same.
To avoid this situation, you must deploy your Windows 7 machines using a Windows 7 version of WinPE. The WinPE Generator tool will create Windows 7 Boot .wim files. If you are deploying Windows 8.1 with an 8.1 WinPE then the cache is updated.
The following WinPE Versions are available and work with BranchCache for OSD:
Version
Comment
Build
3.0
9200
3.1
9201
4.0
5.0
9600
5.1
Windows ADK (Windows Kits 8.1 Update) includes 5.0 and user applies update 5.0 to 5.1 manually.
6.0
Is the release version of WinPE for Windows 10.
10240, 16063 etc.
The following upgrade paths in green work, and the ones in red do not work.
Note: Windows 10 is a fast moving beast and you should test yourself for all scenarios that include Windows 10 upgrades :-
Old Operating System
WinPE Version
New Operating System
Windows 7
3.0
Windows 7
Windows 7
3.0
Windows 7 SP1
Windows 7 SP1
3.0
Windows 7 SP1
Windows 7 SP1
3.1
Windows 7 SP1
Windows 7 SP1
4.0
Windows 7 SP1
Windows 7 SP1
5.0
Windows 8
Windows 8
3.0
Windows 8
Windows 8.1
5.0
Windows 8.1
Windows 8.1 Update
5.0
Windows 8.1 Update
Windows 8.1 Update
5.1
Windows 8.1 Update
Windows 7 SP1
5.0
Windows 8.1
Windows 7 SP1
5.1
Windows 8.1
Windows 7 SP1
6.0
Windows 8.1
Windows 7 SP1
6.0
Windows 10
Windows 7 SP1
5.1
Windows 7 SP1
Windows 8.1
6.0 1511
Windows 10 1511
Windows 10 1511
6.0 1511
Windows 10 1511
Windows 10 1607
6.0 1607
Windows 10 1703
Windows 10 1703
6.0 1703
Windows 10 1703
Windows 10 1703
6.0 1703
Windows 7 SP1
Windows 10 1607
6.0 1607
Windows 10 1703
Windows 10 1511
6.0 1703
Windows 10 1607
Table 1 Upgrade scenarios. Typically you can only upgrade the cache to the same or higher versions of Windows, i.e. 1607 to 1703 will work but 1703 to 1607 will not.
Working around Cache Versions
There are 3 ways of dealing with a Cache version mismatch:
Create a saved copy that will be used in the new full OS after it has been deployed.
Do a "Download all content before..." - The Configuration Manager client will keep the Cache during the OSD process it can then be used to inject into the new full OS.
Do nothing and hope for the best - Most machines are likely to have bits and pieces of the OSD packages and it might just work ok.
One way of dealing with the Cache Version mismatch is to create 2 copies of the Cache. If you start in Windows 7 and end up with a new Windows 7 you can save that cache in 2 copies. One for the WinPE part (which will be upgraded but still used and thrown away after the PE phase) and then one copy for the new OS. It is planned to streamline this functionality in future releases so make sure that you subscribe to the 2Pint mail and media lists to get up to the minute functionality.
Can I re-use my already Distributed Content?
If you have already deployed/distributed lots of packages/applications/images out there then the answer is "Yes". Instead of clearing out the Configuration Manager Client Cache you can inject all of that data into the BranchCache Cache. This also applies to other third-party caching software or hardware. On the proviso that you have physical access to the files directly in a readable format, you can inject them into the cache.
The same applies if you have a Distribution Point that you would like to remove, simply inject the data into the caches instead.
Note: In order to inject data into the BranchCache Cache you need to have the server secret available, otherwise data will not be able to be shared with other clients on the subnet. Contact 2Pint Software for more information on this subject and we can point you in the right direction. Remember – we know this technology inside out and are always happy to help.
Setting up Pre-Caching
Setting up Pre-Caching is not a complex procedure. You should just keep the following in mind:
All content of the Task Sequence will be downloaded to the Configuration Manager client cache as well
This means that a Task Sequence referencing 20 GB of data will take up 40GB of disk space without de-dupe taken into consideration. This is due to the fact that content will be stored in both the Configuration Manager cache as well as the BranchCache cache.
The Task Sequence will run, so ensure that you have set a Variable Condition to stop actual execution.
The Configuration Manager client will start caching as soon as the policy has been received for a run time in the future providing the task sequence policy has not been received before.
Note: Setting up a TS to download all content before starting is not recommended for OSD deployments.
Setting Up Cache-Injection
Cache Injection is a technique where content that is already available on a remote machine is injected into the cache. There are many options available for Cache Injection actions.
The following injections can be done:
Injecting the Configuration Manager client cache into the BranchCache Cache
Injecting the Office Offline installation media into the Cache
Creating a .wim of the local machine and injecting it into the cache
Injecting the entire hard drives, every file, into the drive
The last two ones are obviously great for de-dup. Contact 2Pint Software if you are interested in this as we are working on some upcoming tools to enable these actions.
Last updated
