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.

Upgrade Task Sequence (1803) with BitLocker active

With the new 1803 feature update for Windows 10 we got some new and exciting commands for the Windows Setup that we can use in a upgrade task sequence in SCCM to be able to upgrade without suspending BitLocker. For more information about the 1803 feature update, please see this blogpost.

With these new Setup commands you can set a specific value in your task sequence that will try to keep BitLocker active or force it to be active during the upgrade. You can also use the AlwaysSuspend option but as the word explains this will actually suspend BitLocker and that’s not what we want in this post. The different commands are as follows:

  • /BitLocker TryKeepActive
  • /BitLocker ForceKeepActive
  • /BitLocker AlwaysSuspend

In your upgrade task sequence you need to set the variable OSDSetupAdditionalUpgradeOptions to one of the options above depending on how you want the upgrade to handle BitLocker. In this scenario we are using the /BitLocker TryKeepActive value that will attempt to do the upgrade without suspending BitLocker, but if the upgrade fails, Windows Setup will suspend BitLocker and complete the upgrade.

Please note that there are some requirements to get this setup to work.

  • The device being upgraded should be Windows 10 1709 or higher.
  • The Windows device needs to be using Secure Boot and have a TPM.
  • BitLocker needs to be using a TPM protector only.
  • The user profile folder can’t be on a separate volume that is also BitLocker protected.


If setup correctly you will find that the command line for the Windows Setup upgrade will add the /BitLocker TryKeepActive to it, as shown below. This can be viewed in the smsts.log.


If you have any questions, feel free to email me at tobias.sandberg@xenit.se.

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.

    Whats new in Configuration Manager Technical Preview 1708

    Microsoft recently released Technical Preview 1708 and with it came some new cool features.


    Add a custom logo, change color in software center and hide tabs. Its all done through the Client Settings for Software Center.

    In my example i added a logotype changed the color scheme and disabled the operating system, device compliance and options tab.

    The outcome using the Client Settings above.


    This is made through the Client Notification tab
    Note This option is only visible when selecting a Collection (Show members) and selecting a single computer.

    What the user notification looks like


    The ability to create Powershell scripts in the console has been around since 1706, in 1707 Microsoft introduced the ability for Configuration Manager to read parameters from the script.
    Now in 1708 they expanded the script parameters even further and are now able to detect which parameters are mandatory as well as optional.


    Gives you the ability to see:

    • Empty collections
    • Applications without deployments

    Head over to Administration > Management Insights > All Insights to check it out.


    For more information and documentation: https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1708


    SCCM – Shrink the SQL Server Reporting Services log and change the maxsize

    The default maxsize value of the ReportServer logfile (ReportServer_log.ldf) is 2 TB. If you haven’t changed that value and your disk size is lower then 2 TB (which is very common) you will eventually fill up that entire disk space. When that happens you need to shrink the logfile before you are able to reduce the maxsize value so it fits your disk size better. In a couple of steps you can easily do this as I will describe below.

    1. Shrink the log file.
    Go into Microsoft SQL Server Management Studio, expand Databases and locate the ReportServer. Rightclick the database, go to Tasks, Shrink and choose Files as shown in the pictures below.

    Task > Shrink > Files

    Change File type to Log and select the Released unused space under Shrink action before pressing the OK button. It will now shrink down the log file to a couple of megabytes (instead of gigabytes) and you can go ahead to step two. If it doesn’t work please read below first.

    Change File type: Log

    If you experience trouble with shrinking the file (like it will only shrink a couple of megabytes or it won’t shrink at all) you need to change the recovery model from Full to Simple before doing the shrink step. To do that you need to go to the Properties of the ReportServer database and choose Options. Here you can change Recovery model to Simple.

    ReportServer > Properties > Options

    2. Change the maximum file size from the default 2 TB down to a size that fits your environment.
    Rightclick the ReportServer database and choose Properties. Select Files in the list and go to the Autogrowth/Maxsize column for the ReportServer and press the button marked in red on the picture below.

    ReportServer > Properties > Files

    Change the maximum file size limit in megabytes so it suits your environment. Finish it by pressing the OK button.

    Change maxsize

    SCCM – Application installation summary report

    This post will describe how to create an application installation summary report in SCCM. This is a great tool to have when you’re for example doing a health check of your applications and different versions of them. The report is built in Microsoft SQL Server Report Builder and you can see the final result on the pictures down below (press on the pictures to maximize).

    I will now describe the different pieces of the report so you can make it fit in your environment:

    Add the following datasets to the report, just make sure it is applicable to your environment:




    Next step is to create the layout as shown in the picture below. When the layout is done put in the data from the datasets and the two expressions you can see under the picture.

    View of the report in Microsoft SQL Server Report Builder.

    In the first expression we get the application name from the list search or the wildcard search:

    In the second expression we join the computers within each software version result:

    Last step is to save the report and try it out.

    The report gives you a choice of choosing an application from a drop-down list (where all the applications in your environment will show up) or through a wildcard search. It will then show the selected application (and/or the specific version of your choice) in a list with parameters such as how many computers the application is installed on and the names of the computers.

    List of all the applications in your environment.

    Wildcard search that overrides the application list search.

    A list with the computers that have the application installed.

    The view of the report run in Internet Explorer.

    OS deployment using same MAC address for multiple clients

    OS deployment using the same staging dock for multiple clients is a bit of an issue, and there are many different solutions to the problem but all have their downsides.

    I did a quick search and found two probable candidates to tackle.

    1. UUID staging
      The idea is to exclude staging docks using a registry value (new in 1610) and stage using only UUID. This way the MAC address is totally irrelevant and OSD is handled using only UUID. The downside is that many Prestage tools use MAC and the UUID Guid is longer and therefore more prone to mistakes.
    2. Ethernet MAC release/Wifi renew
      This method prompts the user at the end of the task sequence to disconnect the ethernet adapter and then resumes using Wifi. The downsides here is that the task sequence no longer becomes unattended and therefore can take longer time. This also requires the use of extra filtering in task sequences and therefore extra maintenance.

    With that said I came to the following solution.
    On the Site create a SQL job that runs every 30/60 minutes and removes the MAC association and clears the PXE flag.

    This allows users to stage their clients using the same Ethernet adapter (USB or docking station) without changing the current pxe routine/application or task sequence.
    As with all staging dock solution some consideration must be taken of when the job is scheduled to run so that MAC address association is not wiped before PXE is initated.
    If staging is done once a day/week the schedule can be configured to a daily job and thus the afforementioned consideration becomes a non-issue.

    UUID staging

    Ethernet MAC Release/Wifi renew

    Convert SCCM schedule to readable format

    Reading SCCM Maintenance Windows is not an easy thing to do from WMI as they are stored as 16 char hex values

    To get the schedule hex values simply run the below line, but the result might not be easy to understand

    A server might return the following values.

    Now, how do we read this? The easiest thing is to run Convert-CMSchedule but that unfortunately only works if the configuration manager console is installed.
    Another way to do is to invoke a wmi method from a site server using the SMS_ScheduleMethods class.

    None of these are portable, so I created my own function to decode these. The below function returns the same data as Convert-CMSchedule but is free from any module as it converts the hex to a readable format.

    The function also accepts valuefrompipeline


    The script is reverse engineered from https://msdn.microsoft.com/en-us/library/cc143505.aspx

    SCCM source cleanup inventory

    As applications are retired in SCCM the source tend to build up due to human error or retention policy. Either way admins should perform cleanup of the source directory from time to time.
    The below script lists all files and folders in the source directory that does not have any active connection in SCCM.

    To run the script first open Configuration Manager Console and press ”Connect via Windows Powershell”