Tag: ConfigMgr

SCCM 1806 – News and features

Once more it was time to upgrade our SCCM environment to the newest release that is 1806. As it was not released for everyone yet, I had to run the Fast-Ring script to allow the update to present itself. I found this update very interesting as it comes with some exciting new features, and there are alot. These are the ones that I am most excited about.

  • Ability to PXE boot without WDS
  • CMTrace installed as default on clients
  • Ability to exclude Active Directory containers from discovery
  • High availability on Site Server
  • CMPivot
  • Boundary group for peer downloads
  • Enhanced HTTP site system
  • Improvements to OS deployment
  • Software Updates for third-party

…and much more. You can read about all the new features here on Microsoft docs.

Since there are a lot of news, I have chosen to cover the two that I am most excited about in this new release.


Configuration Manager is a very helpful tool when gathering information, CMPivot now allows you to take it to the next step by real-time querying clients. This allows you to gather a lot of information instantly. This feature uses Azure Analytics Language, .

CMPivot is located under Asset and Compliance > Overview > Device Collection, you can find this new feature in the top ribbon bar.

Location of CMPivot

An example is to find BIOS-information about the Dell computers that are currently online. From this output you easily create a collection (the members of the collection will be added as Direct Members) or export to both CSV and Clipboard.


PXE Without WDS

It is exciting to have a new way of deploying over PXE. Since Windows Deployment Services has been available for a long time, it feel suitable to have an updated way of deploying clients. By replacing WDS, the distribution point will create the service ConfigMgr PXE Responder. If you have plans of using Multi-Cast, you are for now stuck with WDS.

This setting can be found under Administration > Overview > Distribution Point, right click on the distribution point you would like to modify with the setting shown below.

After applying this setting, Windows Deployment Services will automatically be disabled. Be advised that if you are monitoring this service, it will be report as stopped. SCCM PXE Without WDS

If you have questions, thoughts or anything you would like discuss? Send an email to Johan.Nilsson@xenit.se and I will be more than glad to talk about these topics.

Use PowerShell & Windows Update to force drivers to be downloaded from the Internet in a Task Sequence

Working with client driver packages for me is related to a never-ending story. Drivers are frequently being updated and results in manually handling updates of Driver Packages in Configuration Manager. But since some computer manufacturers are releasing updates through Windows Update, so we thought; What if you can use a Task Sequence to force Windows Update to look for updates and drivers over the Internet instead of using manually handled Driver Packages? So I decided to try with a Surface Book.

With help from the PowerShell Module PSWindowsUpdate, created by Michal Gajda (downloaded from TechNet), and with a post from Waingrositblog, I had all the necessary bits forcing a Surface Book to download drivers from Windows Update, over the Internet, while running a Task Sequence. I started by modifying the steps, created by Waingrositblog, in the Task Sequence steps a bit. I found having one step running a PowerShell script instead of three steps, two of which was running cmd lines, more suitable.

This image illustrates the Task Sequence step.

I added the update step just after applying Windows- and Network Settings, where we usually apply driver packages.

The RPS (Run PowerShell) – Microsoft Update step is running the following script:

To verify the success of the script I went through the WindowsUpdateLog.Log and found that during the Task Sequence, a lot of drivers were installed. Here I would like to use PCI drivers as an example. As shown in the image below, the WindowsUpdateLog successfully downloaded and applied the drivers.

This is the WindowsUpdateLog.Log generated after successfully running the Update Drivers sequence.

I also tried the running the Task Sequence without the Windows Update / Driver script and found out the device had conflicts with the PCI drivers. These drivers is just used as an example in this process, there are several conflicts and other drivers missing as shown in the image below.

This image illustrates conflicts with, among others, the PCI drivers after not running the Update Drivers sequence.

This image illustrates when the drivers are applied.

As shown in these images, the Install Driver step running in the Task Sequence finds the correct and necessary drivers. After a Task Sequence successfully has gone through no exclamation marks are found in the Device Manager.

Some computer manufacturers are using Windows Update as a secondary source for updates, and because of this some drivers can be out of date. This is a reason why the Surface is a great example of using Windows Update for drivers since Microsoft release their updates, up to date.

If you have any questions, opinions or improvements, feel free to email me at Johan.Nilsson@Xenit.se

Reducing the network impact of Windows 10 Feature and Quality Updates

During Microsoft Ignite I got some great tips of how you can reduce the network impact of Windows 10 Feature and Quality Updates. I would like to share them with you in this blog post.

Since Microsoft changed their strategy to Windows as a service concept with continuously Feature Updates instead of releasing new versions every few years, we have to accept and adapt our way to update our systems. A quick review about the difference between these updates:

Quality Updates – A single cumulative update each month with no features.
Feature Updates – Twice per year with new capabilities.

This means that we need to push out a larger amount of updates to each and every PC in our organization which will impact the network. On average the Quality Updates are 1GB per month which means 12GB traffic per PC per year. The Feature Updates are 3.5GB twice per year, which gives us 7GB traffic per PC per year. The total amount of traffic for these updates to each PC each year will be around 19GB multiplied with the number of PCs in your environment.

So how to we reduce the network impact for these updates? This could be solved by a number of methods.

  • Express packages
  • Peer-to-peer distribution
  • Bandwith thottling
  • Scheduled distribution
  • Express packages are a way to significant reduce the amount of data that each Cumulative Quality Update. The way these Express Updates work is that when a new update comes out, only the CAB file “chunks” for components that need to be updated are downloaded to each client instead of the whole package, like a delta download. To is easiest to view in a graph.

    This can be enabled in WSUS and it’s now also supported by Configuration Manager 1702 and above. The one thing you must know when using Express Updates is that you need to ensure that you got sufficient disk space on your WSUS server. The recommended amount is five times the current space and that’s because the full updates are kept on the server for fallback scenarios and must be stored locally.

    The same idea with Express Feature Updates. Determine what files have changed since the last feature update and will only download those. This could potentially save about 35% over current ESD sizes. Note that this is only available with Windows Update and Windows Update for Business with Windows 10 1709, but it’s coming for WSUS, ConfigMgr and third-party tools next year. The end user experience will be unchanged where the update is deployed and Windows performs an in-place upgrade which normally takes around 30-90 minutes depending on hardware. It’s also important to know that this will not work if you skip versions.

    Microsoft said that they are working on reducing the amount of time it takes to deploy Feature Updates with each release, as the updates continuously getting better and smarter.

    Peer-to-Peer distribution is something that Microsoft recommends using when dealing with Quality and Feature Updates. Approximately 90% or more of the traffic can be shifted from servers to the edges of the networks using this technology. Multiple tools are available for implementing this in your environment. BranchCache, which is supported by WSUS and ConfigMgr makes the clients an available source for distributing the updates around the local network. ConfigMgr Peer Caching is another method and there are also third-party alternatives to choose from.

    BITS Throttling is another way to control the network impact of the updates. When activated you limit the amount of network bandwidth that each PC can consume. In this way you can distribute content to PCs over a period of time, like days or weeks. If you combine this with BranchCache you can determine that a client can throttle traffic from the servers but go full speed from the peers in the local network. Note that implementing BITS could be challenging if BITS is already being used for other purposes in your environment.

    Scheduled distribution is a way to control how content is distributed from server to server and server to client. Bandwidth usage can be limited/throttled and restrictions can be set up based on time of the day. Servers or PCs can often be used to hold content, like distribution points around the network.

    I want to summarize this post with a picture of the updating tools I’ve been talking about and where they are supported or not.

    More information about the technologies described above can be found on technet.microsoft.com. You can also learn more about Windows as a service here.