The distribution point role has been expanded in Configuration Manager 2012 R2. In previous versions this site system was nothing more than a glorified file server, storing files for access by clients requiring content.
The role of the distribution point is still to store file content and make it available to clients, but the way in which it does this has been updated. The first thing that we should mention is that the distribution point is designed to support both classic package distribution and the new application distribution mechanism introduced in Configuration Manager 2012 R2.
The legacy style distribution point, which is noted by a file folder named SMSPKG<driveletter>$, remains but is used only for packages set to Run from Distribution Point, and this is the only deployment mechanism that bypasses the requirement to use Background Intelligent Transfer Service (BITS). Beyond that, the updated distribution point structure is used universally. While the function of the distribution point in Configuration Manager 2012 R2 remains the same, making content available to clients, the structure and function of the distribution point to provide its service have been substantially updated.
There is no option to use the distribution point without making use of BITS.
◆ The distribution point structure is no longer just a file store. Now, files are stored in a cache that takes advantage of single-instance storage, supports automated integrity checks, and more.
◆ The branch distribution points are gone and replaced with the fact that a standard distribution point is now fully supported on a supported Windows 7 workstation system, no client required. The workstation system is still subject to the connection limitation for a given operating system. In Windows XP administrators were accustomed to a connection limit of 10. In Windows 7 the connection limit increased to 20.
◆ The distribution point structure is no longer just a file store. Now, files are stored in a cache that takes advantage of single-instance storage, supports automated integrity checks, and more.
◆ The branch distribution points are gone and replaced with the fact that a standard distribution point is now fully supported on a supported Windows 7 workstation system, no client required. The workstation system is still subject to the connection limitation for a given operating system. In Windows XP administrators were accustomed to a connection limit of 10. In Windows 7 the connection limit increased to 20.
Bottom line, this isn’t your grandpa’s distribution point anymore! First things first—the distribution point must be installed.
It may be that the distribution point role is already installed. One of the default settings when installing a primary or secondary site is to also add the distribution point and management point roles. If the role has not yet been added or if an additional distribution point is needed, then this component won’t yet be present on the server and will need to be added.
1. In the Create Site System Server Wizard, and as shown in Figure ,
3. Once you’ve configured all options on this page as needed, click Next to proceed to the Drive Settings page, shown in Figure
Also, since there is only a single drive on the server, it doesn’t make sense to set a secondary content location, so that option is grayed out. If multiple drives are available and the setting is left at Automatic, then the system will pick the drives to use the same way it has done historically—using the NTFS drive with the most available space as a first choice and so on.
Configure the distribution point to be a pull distribution point by selecting Enable This Distribution Point To Pull Content From Other Distribution Points, as shown in Figure
◆Click Add, and then select one or more of the available distribution points to be source distribution points.
◆ Click Remove to remove the selected distribution point as a source distribution point.
5. Once the settings are configured as needed, click Next to proceed to the PXE Settings page of the wizard, shown in Figure
The PXE Settings page of the wizard lets you choose whether the distribution point being configured should also act as a PXE server for operating system deployment. Because of the dependency the PXE server has on the distribution point to deliver boot images, having this setting as part of the distribution point makes sense. For the example we won’t install a PXE point; it can be added later as needed.
6. Review the settings on this page and click Next to proceed to the Multicast page of the wizard, shown in Figure
Boundary groups are new in Configuration Manager 2012 R2 and serve two purposes: client assignment and content access. The latter item is the one of concern for distribution point access. We mentioned earlier that on the Create Site System Server Wizard’s General page, the option to specify a site system as protected was removed. In Configuration Manager 2012 R2, when a distribution point (or state migration point in operating system deployment) is added to a boundary group, by definition the distribution point is protected
and only those clients that are within the boundaries defined by the boundary group are able to retrieve content from the distribution points that have membership in the boundary group. Further, a distribution point can have membership in multiple boundary groups. By taking this new approach, administrators are afforded additional control to easily specify which distribution points are available to service clients depending on which subnets the clients happen to be located near.
But what if a client requires access to content but is not within boundaries defined by any boundary group, such as a laptop in a hotel room? That scenario is also addressed. Boundary groups can be flagged as accessible to systems when the system is in a location where no other distribution point can be resolved. This is known as fallback and is enabled by default for the boundary group, as noted at the bottom of the Boundary Groups page. For the example, the distribution point has been added to a boundary group that was previously created for the example primary site.
9. Once the boundary group configuration is complete, click Next to review the Summary page of the wizard.
10. After confirming all settings, click Next to finish the wizard and implement the distribution point deployment. The successful completion is shown in Figure
The same folders you might expect from previous versions are still present to support distribution of classic software packages configured to Run From Distribution Point: SMSPKG, SMSPKG<driveletter>$, SMSSIG$, and SMSPKGSIG. In addition to these folders another is present called SCCMContentLib. This folder contains the new structure for the distribution point and is worth further discussion.
Historically, opening the distribution point folder will reveal a list of folders named with package IDs and, within the folder, the contents of the package. That still is the case, but the structure is far different. Remember that the new distribution point structure in Configuration Manager 2012 R2 is designed to take advantage of single-instance storage and also to be a bit more stable. Looking inside the SCCMContentLib folder reveals three additional folders, DataLib, FileLib, and PkgLib, shown in Figure
In the DataLib folder there are two entries that match; the first is a folder and the second is a configuration file. Looking at the GUID folder first, it looks like the location of the package content. But not so fast! The filenames here will match the filenames from the source file folder, but a quick glance at the file sizes and file extension will show that these are just configuration files. Taking a look at the client.msi file reveals details about the actual file, including file size, in this case 30625792 bytes, and the hash value for the file. The first four characters of the hash value here are key to finding the actual file. In the example, the hash value of interest is 709E. More on this shortly.
In addition to the source file structure there is another configuration file matching the GUID in question; it is at the root of DataLib. Opening it shows a hash value for the folder itself. Armed with information gained from this folder, it’s time to visit the FileLib folder, shown in Figure
2. On the Distribution Point page of the wizard, configure a few options:
◆ The first option, Install And Configure IIS If Required By Configuration Manager, is not selected by default, but you must select this option prior to proceeding. This option highlights the fact that with Configuration Manager 2012 R2 it is not possible to create a non-BITS-enabled distribution point. This fact may influence distribution point placement but is a welcome modification for sure. Also in this section you can select Enable And Configure BranchCache For This Distribution Point. BranchCache is a feature introduced with Windows Server 2008 R2 that allows systems within the same subnet and separate from a content source to share downloaded content locally rather than each system having to download them. You can also enter any information as a description of this distribution point; it’s a good idea to configure this to verify what this distribution point is for.
◆ Next on the page is the choice of whether clients should communicate with the distribution point using HTTP or HTTPS traffic. When clients use BITS to pull information from the distribution point, as is required by Configuration Manager 2012 R2, the clients do not directly connect to the distribution point structure but rather initiate a BITS session through IIS.
◆ The first option, Install And Configure IIS If Required By Configuration Manager, is not selected by default, but you must select this option prior to proceeding. This option highlights the fact that with Configuration Manager 2012 R2 it is not possible to create a non-BITS-enabled distribution point. This fact may influence distribution point placement but is a welcome modification for sure. Also in this section you can select Enable And Configure BranchCache For This Distribution Point. BranchCache is a feature introduced with Windows Server 2008 R2 that allows systems within the same subnet and separate from a content source to share downloaded content locally rather than each system having to download them. You can also enter any information as a description of this distribution point; it’s a good idea to configure this to verify what this distribution point is for.
◆ Next on the page is the choice of whether clients should communicate with the distribution point using HTTP or HTTPS traffic. When clients use BITS to pull information from the distribution point, as is required by Configuration Manager 2012 R2, the clients do not directly connect to the distribution point structure but rather initiate a BITS session through IIS.
◆ Other options on this page allow the administrator to decide whether the distribution point will use self-signed certificates or certificates imported from a different source, such as a certificate authority. If the installation supports Internet scenarios, a certificate would be imported at this step.
◆ The last option on the page allows configuration of a distribution point to support prestaged media. Prestaged media is a new feature of Configuration Manager 2012 and addresses scenarios where administrators would prefer to deliver content in bulk to a distribution point rather than having it copied over the network. In previous versions of Configuration Manager this was not supported natively, although there were tools available to help at least partially address this need, such as PreLoadPkgOnSite.
◆ The last option on the page allows configuration of a distribution point to support prestaged media. Prestaged media is a new feature of Configuration Manager 2012 and addresses scenarios where administrators would prefer to deliver content in bulk to a distribution point rather than having it copied over the network. In previous versions of Configuration Manager this was not supported natively, although there were tools available to help at least partially address this need, such as PreLoadPkgOnSite.
3. Once you’ve configured all options on this page as needed, click Next to proceed to the Drive Settings page, shown in Figure
Also new to Configuration Manager 2012 R2 is the ability to control distribution point drive selection and allocate reserved storage when configuring the distribution point. Mechanisms did exist in previous versions of Configuration Manager to make similar configurations effective, notably the use of the no_sms_on_drive.sms flag file, but having these options in the console allows more effective and granular administrator control. A couple of options are presented here:
◆ First is the ability to preconfigure the amount of drive space that should be reserved for the distribution point.
◆ The next set of options, which are perhaps more important, let you choose which drives should be used for the content libraries and package share locations. In our example, there is only a single drive on the site server, so leaving the options set to Automatic makes sense.
◆ The next set of options, which are perhaps more important, let you choose which drives should be used for the content libraries and package share locations. In our example, there is only a single drive on the site server, so leaving the options set to Automatic makes sense.
Also, since there is only a single drive on the server, it doesn’t make sense to set a secondary content location, so that option is grayed out. If multiple drives are available and the setting is left at Automatic, then the system will pick the drives to use the same way it has done historically—using the NTFS drive with the most available space as a first choice and so on.
4. Select the Pull Distribution Point page of the wizard if you need this option for your distribution point. The use of pull distribution points can help reduce the processing load on the site server when you deploy content to a large number of distribution points at one site.
Configure the distribution point to be a pull distribution point by selecting Enable This Distribution Point To Pull Content From Other Distribution Points, as shown in Figure
◆ Click Remove to remove the selected distribution point as a source distribution point.
5. Once the settings are configured as needed, click Next to proceed to the PXE Settings page of the wizard, shown in Figure
6. Review the settings on this page and click Next to proceed to the Multicast page of the wizard, shown in Figure
The Multicast page of the wizard allows administrators to specify whether the distribution point being configured should support multicast or not. Multicast is used with operating system deployment and is a very efficient protocol for delivering images to multiple systems simultaneously. The example distribution point will not be used for multicast support for now, so this option will not be selected. It can be added later as needed.
7. Review the settings on this page, and click Next to proceed to the Content Validation page, shown in Figure .
The Content Validation page of the wizard allows administrators to specify whether content should be periodically validated on the distribution point and, if so, on what schedule and at what priority. When Validate Content On A Schedule is selected, the default evaluation period is once per week and at a low priority, to ensure other activities on the server are not disrupted.
The Content Validation page of the wizard allows administrators to specify whether content should be periodically validated on the distribution point and, if so, on what schedule and at what priority. When Validate Content On A Schedule is selected, the default evaluation period is once per week and at a low priority, to ensure other activities on the server are not disrupted.
This is a significant feature update for Configuration Manager! Most readers who have used distribution points in previous versions of Configuration Manager will have encountered a scenario where content will be distributed to distribution points, work fine for a period of time, and then start to show errors, typically a hash mismatch problem. This might happen for several reasons, often due to on-demand virus scanning of the distribution points, but when encountered, the problem is disruptive until fixed. The ability to do content validation and proactively identify problems is a welcome change indeed! Further, the updated structure of the distribution point should help keep content in a good state as well. More on the distribution point structure shortly.
8. Once you’ve configured these settings, click Next to proceed to the Boundary Groups page of the wizard, which allows the administrator to choose the boundary group(s) of which the distribution point should be a member. While it is not a strict requirement that a distribution point be a member of any boundary group in order to be created, the distribution point may not be accessible by any client until it is added to the appropriate boundary group(s). Detailed discussion of boundary groups is beyond the focus of
this chapter, but based on the tight dependency between distribution point function and boundary groups, a bit of discussion is appropriate here.
this chapter, but based on the tight dependency between distribution point function and boundary groups, a bit of discussion is appropriate here.
and only those clients that are within the boundaries defined by the boundary group are able to retrieve content from the distribution points that have membership in the boundary group. Further, a distribution point can have membership in multiple boundary groups. By taking this new approach, administrators are afforded additional control to easily specify which distribution points are available to service clients depending on which subnets the clients happen to be located near.
But what if a client requires access to content but is not within boundaries defined by any boundary group, such as a laptop in a hotel room? That scenario is also addressed. Boundary groups can be flagged as accessible to systems when the system is in a location where no other distribution point can be resolved. This is known as fallback and is enabled by default for the boundary group, as noted at the bottom of the Boundary Groups page. For the example, the distribution point has been added to a boundary group that was previously created for the example primary site.
9. Once the boundary group configuration is complete, click Next to review the Summary page of the wizard.
10. After confirming all settings, click Next to finish the wizard and implement the distribution point deployment. The successful completion is shown in Figure
As mentioned earlier, the Configuration Manager 2012 R2 distribution
point structure has changed. After installation is complete and after a
couple of applications have been deployed, open the drive hosting the
distribution point and check for a few folders, as shown in Figure
Historically, opening the distribution point folder will reveal a list of folders named with package IDs and, within the folder, the contents of the package. That still is the case, but the structure is far different. Remember that the new distribution point structure in Configuration Manager 2012 R2 is designed to take advantage of single-instance storage and also to be a bit more stable. Looking inside the SCCMContentLib folder reveals three additional folders, DataLib, FileLib, and PkgLib, shown in Figure
The PkgLib folder is the starting place to examine the new structure, and it contains files
with names that match the package ID from the site, shown in Figure
with names that match the package ID from the site, shown in Figure
Note that these files are INI files. Looking inside reveals the packages that are
associated with the package ID. From here, copy and paste the two Content_ GUIDs
and navigate to the DataLib folder, shown in Figure . For the example, use
Content_3b898e35-9ecc-45e2-9231-ee3f30b2a3aa.1.
associated with the package ID. From here, copy and paste the two Content_ GUIDs
and navigate to the DataLib folder, shown in Figure . For the example, use
Content_3b898e35-9ecc-45e2-9231-ee3f30b2a3aa.1.
In addition to the source file structure there is another configuration file matching the GUID in question; it is at the root of DataLib. Opening it shows a hash value for the folder itself. Armed with information gained from this folder, it’s time to visit the FileLib folder, shown in Figure
Within the FileLib folder is a series of other folders with names that at first appear cryptic— only four characters. Aha! Remember that we just mentioned that the first four characters of the hash value for the client.msi file were important. In this folder there is a subfolder named 709E. A quick look inside that folder reveals a file with the exact size of the client.msi file— 30,626,792 bytes. Bingo! This is the location of the actual client.msi file, simply renamed and placed into this single-instance storage format.
No comments:
Post a Comment