64-bit versions of these tools are also installed in the OSD\Bin\x64 folder. |
| Open C:\Program Files\Microsoft Configuration Manager\bin\x64\osdinjection.xml in Notepad |
| Search for any of the files listed above and confirm they have been added |
| Close the XML file, ensuring no changes were made. If asked to save the file, click Don't Save |
This manifest defines the files that are to be added into the Windows PE boot image when it is updated on a DP. Note that the files listed above, except the .PDB files, have been added to this manifest, ensuring that they will be added to all boot images that are updated on a DP from this point on. |
|
The Nomad Dashboard – First Look
Nomad 6.x introduced the Nomad Dashboard that provides a graphical summary of how Nomad is configured and operating within your estate. Accessible within the CM console or via a Web browser, it has a set of tiles that provide you with a view of all your Nomad related activities.
The Nomad client health tile will no longer populate, client health should be checked using Guaranteed State within Tachyon. |
The Nomad Dashboard
| Open the Monitoring workspace in the ConfigMgr console and expand the 1E Nomad folder at the bottom of the left-hand pane. Note the two items: Dashboard and Pre-caching Jobs. Pre-caching Jobs will be empty right now |
| Select Dashboard and observe the tiles presented in the main pane. There won't be much to look at right now, but we will come back to the Dashboard at different times to observe the data presented here |
| Hover over the different bars in the Content by type tile to see status of Nomad across the different content |
| Use [CTRL +] and [CTRL -] to adjust how the tiles are displayed in the dashboard |
Make sure you click in the dashboard prior to using [CTRL -] as it will lower the display size (zoom) percentage of the browser hosting the VM and shrink it down. |
This allows access to the Nomad dashboard without provisioning rights within the ConfigMgr console. |
|
Understanding IIS Request Filtering on DPs
IIS 7 introduced IIS Request Filtering. This security feature allows administrators to configure IIS to block requests for specific file types and URL paths that include specific folder names or special characters. By default, IIS Request Filtering will block a number of file extensions and folder paths that may occur in distribution of content (Packages, Applications and Software Updates).
Although the Microsoft documentation highlights this issue (http://technet.microsoft.com/en-gb/library/gg712264.aspx#BKMK_RequestFiltering), the ConfigMgr client actually bypasses this security measure by using a custom method when querying for the file rather than a standard HTTP GET for the file directly. 1E has developed Nomad per Microsoft security best practice, which means that we do a standard HTTP GET for the file that will be filtered by the IIS Request Filtering security feature. It is therefore necessary when using Nomad to follow the guidance in the Microsoft documentation and configure the IIS Request Filter on all Distribution Points to allow any file extensions, paths and special characters that may occur in your ConfigMgr content.
In this exercise, you will learn how to modify the filters to accommodate different scenarios.
View default restrictions
In this task, you will observe the file extensions and URL path elements that IIS Request Filtering blocks by default.
| On 1ETRNCM start Internet Information Services (IIS) Manager from the Start screen |
| Select the 1ETRNCM server in the tree view on the left, then double-click the Request Filtering icon in the panel on the right (grouped under IIS) to view the Request Filtering properties page |
| Select the File Name Extensions tab. This shows all the file extensions that are blocked by default. Note that by default, any file extensions not listed here are allowed. Nomad will fail to download any content that includes any of these file types |
| Select the Hidden Segments tab. This shows all the folder names that are blocked by default. Nomad will fail to download any content where the URL path includes and of these Hidden Segments |
|
Allowing restricted file extensions
In this task, you will learn how to reconfigure the Request Filtering to allow specific file extensions (in this case .config) to be served by the DP by removing the File Name Extension from the filter.
| Copy the CommandLinesAndQueries.txt file into c:\temp. This will ensure no changes are made mistakenly to the master copy of the file! |
The 'appcmd.exe' command lines used in the upcoming Tasks are available From the SkyTap Shared Drive shortcut on the desktop and browsing to 1E Nomad - Course Content\Nomad 7.0 Course Content\CommandLinesAndQueries.txt file. You may prefer to copy and paste the command lines into the command prompt to avoid typing errors. |
| Start a command prompt (run as administrator) and change directory to C:\Windows\System32\inetsrv |
| Run the following command |
appcmd set config /section:requestfiltering /-fileExtensions.[fileextension='.config'] |
Although for optimal security you should only allow the specific file types that are included in your various packages, applications and software updates, practically you will probably want to remove all of the file extension filters on your DPs. |
|
Allowing restricted folders (Hidden Segments)
In this task, you will learn how to reconfigure the Request Filtering to allow the \bin path segment that is blocked by default.
| From the command prompt, run the following command |
appcmd set config /section:requestfiltering /-hiddensegments.[segment='bin'] |
|
Allowing special characters (Double Escaping)
The third filtering option that may prevent Nomad from downloading content is allowDoubleEscaping. By default, any path or filename that includes special 'escape' characters are blocked by default. In this task, you will learn how to allow files with these special characters in their name to be downloaded.
| From the command prompt, run the following command |
appcmd set config /section:requestfiltering /allowdoubleescaping:true |
| Repeat the steps in the exercise View default restrictions to view the effects of the changes you have made. The .config file extension should no longer be listed, nor should the bin folder in the Hidden Segments tab. (You may need to refresh the screen if IIS Manager was already open on the Request Filtering page) |
|
Preparing for 1E Client Deployment
The Nomad agent functionality has been moved into the 1E Client Nomad Module in version 7 of Nomad. The 1E Client needs to be installed on all ConfigMgr Distribution Points and all clients. In this exercise, you will use the 1E Client Deployment Assistant to prepare for the installation of the 1E Client on the distribution point and clients in the lab.
Run the 1E Client Deployment Assistant
| On 1ETRNCM, logged on as 1ETRN\SCCMAdmin, open the SkyTap Shared Drive shortcut on the desktop and navigate to 1ETools\ClientDeploymentAssistant.v1.4.0.27.zip copy the file to C:\Temp then right click and extract all |
| Double-click the 1EClientDeploymentAssistant.exe file in C:\Temp\1EClientDeploymentAssistant.v1.4.0.27 to launch the wizard interactively |
| On the Welcome page, click Next to begin |
| Accept the license terms on the License Terms page and click Next |
| On the ConfigMgr Connection page, with the Local ConfigMgr Site Server option selected, click the Connect button. When the status says "Connected", click Next |
| On the 1E License File field click browse and select our licenses.txt file |
We could pre-populate these fields by editing the values in the AppImport.xml file in the 1E Client Deployment Assistant folder. |
| On the Application Content Source and the Package Content Source fields type in \\1ETRNDC\ConfigMgrSource\Software |
The Application and Package content locations may be different in some production environments, but this training environment uses a common content location. |
| Check the Distribute Content box and ensure that All Distribution Points is selected by default for the Distribution Point Group. Click Next on the General Settings page |
| On the Agent Selection page, uncheck everything except PXE Everywhere 3.2.0.56 and 1E Client 4.1.0.267 and note that the license key for PXE Everywhere is imported from the licenses.txt file. Click Next |
| On the PXE Everywhere 3.2.0.56 page check the Create Application and Create Package boxes. We do not need to create a deployment as we will deliver PXE Everywhere in a Task Sequence in order to stage our boot image. Uncheck the Create Application Deployment. Click Next |
| On the 1E Client 4.1.0.267 page, ensure that both Create Application and Create Application Deployment are selected along with Create Package. Ensure that the limiting collection is set to All Desktop and Server Clients and click Next |
The Client Deployment Assistant allows for the creation of packages and applications. Certain environments prefer one over the other. You can deselect either one, however, we will create both for this lab. We will deploy the client via the application, however use the package in a Task Sequence later in the labs. |
| On the Tachyon and other client Settings page, uncheck the Enable Tachyon, and Enable Inventory checkboxes. We are not using these features in this class. Click Next |
| On the Nomad Client Settings page, check the Enable Nomad checkbox, and accept the defaults for Log Path and Log Size. Ensure that only Hidden Nomad Share and Prevent Failing Over to BITS are selected. Click Next |
We will be enabling Single Site Download, Fanout and Peer Backup Assistant in later lab exercises. |
| On the Summary page, wait for the summary to be compiled. Review all the actions that will be performed based on the settings selected in the wizard. When finished reviewing the summary, click Create |
| The progress will be displayed as each task is completed. When the status is displayed as Successful, click Next |
| On the Completionpage, note that all tasks completed successfully. Click Finish |
|
Observe the results of running the 1E Client Deployment Assistant Wizard
In this task, we will observe the ConfigMgr objects created by running the 1E Client Deployment Assistant wizard.
| Open the ConfigMgr console, select the Assets and Compliance node and click on Device Collections |
| Note that the 1E Client 4.1.0.267 – Required collection is created with All Desktop and Server Clients as the limiting collection and that there are no members |
| Click on the Deployments tab for the collection and note that the 1E Client 4.1.0.267 Application is deployed to this collection |
| Click on the Software Library node and select Applications in the Application Management section |
| Click on the 1E Client 4.1.0.267 application and select the Deployment Types tab at the bottom of the console |
Note that the application has two Deployment Types created – 1E Client x86 and 1E Client x64
|
When the 1E Client Deployment Assistant wizard is run, the deployment types that are created have been limited (using prerequisites) to workstation operating systems for the Nomad x86 deployment type and workstation and server operating systems for the Nomad x64 deployment type. This behavior is defined in the AppImport.xml file in the: C:\Temp\1EClientDeploymentAssistant.v1.4.0.27 folder. |
| Right-click the 1E Client x64 Deployment Type and select Properties |
| Click on the Requirements tab, select the Operating system Requirement Type and click Edit |
| In the list of operating systems, scroll down, and select the Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019. Click OK |
| Click OK to close the 1E Client x64 Properties |
| Select Packages under Application Management and note that there are two packages created – one for x86 and one for x64 and that each Package has two programs – one for install and one for uninstall |
|
Deploy the 1E Client
In this exercise, we will use the collection and application created by the Endpoint Agent Installation wizard to deploy the 1E Client to all workstations.
Deploy 1E Client to Workstations and Distribution Point
| On 1ETRNCM, select the Assets and Compliance node of the ConfigMgr console and click on Devices |
Ensure all workstations have been powered on in SkyTap. |
| Select the following machines from the device list (You may hold the CTRL key down and use multi-select) |
1ETRNCM
1ETRNW71
1ETRNW72
1ETRNW73
1ETRNW101
1ETRNW102 |
| Right-click on any of the selected devices and choose Add Selected Items > Add Selected Items to Existing Device Collection |
| Select 1E Client 4.1.0.267 – Required and click OK |
| Under Assets and Compliance, select Device Collections and observe the 1E Client 4.1.0.267 – Required collection. If the member count is still zero, you may need to refresh the collection to see the member count display six members |
|
Monitor the progress of the installation
| In the ConfigMgr Console, select the Assets and Compliance workspace, select the Device Collections node then right-click 1E Client 4.1.0.267 – Required and select Client Notification > Download Computer Policy. A dialog box will pop up indicating there are six resources in this Collection. Click OK |
This process will cause each of the ConfigMgr clients to download the new deployment policy you have just created rather than waiting for them to do it on their regular schedule. In the lab environment, this interval is only 5 minutes rather than the default value of 60 minutes. |
| Select the Monitoring workspace and select the Deployments node |
| Right-click the 1E Client 4.1.0.267 deployment and select View Status monitor the progress (refresh periodically to view updated status information) |
Please note that this may not be updated very quickly because this information is provided by status/state messages sent up from the individual ConfigMgr client. Take a 5 minute break, and if it has still not updated, proceed to the next task – you will likely find that the agent has already been installed. |
|
Review the Installation on the Workstations
| Log on to 1ETRNW71 as 1ETRN\User |
1ETRN\User is a member of the Workstation Admins group and will be able to perform administrative tasks on the Lab Workstations. |
| Double-click the services.msc shortcut on the desktop |
| Note the 1E Nomad Branch and 1E Client services are running |
| Leave the Services interface open and from the Start menu, right-click Computer and select Manage |
| In the Computer Management interface, expand the Local Users and Groups node and click on the Users folder |
| Note that the local user SMSNomadP2P& has been created |
| In the Computer Management interface, expand the Shared Folders node and click on Shares |
| Note that the NomadSHR$ share has been created. This is the Nomad cache |
| Right-click the NomadSHR$ and select Properties from the context menu |
| In the NomadSHR$ properties dialog, on the General tab, note the path to the share, and the 6 user (connection) limit |
| Select the Share Permissions tab and note the permissions applied to the share |
| Cancel the NomadSHR$ properties dialog to return to the Computer Management interface |
| Leave the Computer Management interface open and return to the Services interface |
| Right-click the 1E Nomad Branch service and select Stop |
| Return to the Computer Management interface and refresh the Shares node. Note that the NomadSHR$ share is deleted when the service is stopped |
| Switch to the Services interface and start the 1E Nomad Branch service |
| Return to the Computer Management interface and refresh the Shares node. Note that the NomadSHR$ share is recreated when the service starts |
The Nomad share is deleted every time the Nomad service is stopped. The content in the Nomad share will still reside on the machine but won't be shared unless the service is running. If the P2P protocol is changed to HTTP(S), the share no longer plays a role in content sharing. The share will still exist, but will not be required, because we are no longer using SMB to connect to a share to copy content. |
| Close the Services interface and the Computer Management interface |
| Start Windows Explorer and browse to C:\ProgramData\1E\NomadBranch. This is the folder that is shared as NomadSHR$, and is the root of the Nomad cache |
| Browse to the ConfigMgr Logs folder on the desktop and double-click the NomadBranch.log to open it. You will use this log file in future exercises to follow Nomad processing a distribution |
| Observe the Nomad service startup activity at the beginning of the log. Note that the agent has created a hidden share, and has automatically set the option to use HTTP and SMB because it has detected an installed CM client |
|
button on either tile to get more details