Simplify removing of distributed content with the help of Powershell


TLDR; Go to the Process block.

Ever since I first got introduced to Powershell, I have always tried to come up with ways to include, facilitate and apply it to my my everyday tasks. But for me, using Powershell in combination with SCCM has never been the ultimate combination, the built in cmdlets doesn’t always do it for me, and the gui is most of the times easier to understand.

So when I got a request to simplify removal of distributed content on all distribution points or all distribution point groups, it left me with two options. To create a script what did the desired job, or to create a function that would cover all the possible scenarios. So I thought; “Why don’t I take these matters in my own hands and create what I actually desire?” That is why I created a script that helped to find the content wanted for removal, and to have the distributed content removed from every Distribution Point or Distribution Point Group.

Lets say that you have 10 Distribution Points, and you have distributed content to 5 out of 10, and you have not been using a Distribution Point Group, the way to go would be to repeatedly proceed with the following steps:

And to do these steps for every distribution point would just take forever. Of course, using one Distribution Point Group would of course be more effective and the ideal way to go, but you might have distributed it to multiple Distribution Point Groups? That is something that already has been thought of, and that is why this script is created. Even if you have distributed it to some distribution points, and some distribution point groups, it will all be removed.


But how does it work? In this demonstration, I will have two packages distributed with similar names. One of them will be sent to a Distribution Point Group, and the other one to 2 Distribution Points. And I would like to have both of them removed from whatever they have been distributed to. 
1. Start by launching Powershell, and import the script by running “. .\Remove-CMAllSiteContent.ps1”

2. Run the script with the required parameters. As shown in the picture below, I searched for ‘TestCM’, but it resulted in showing multiple results. The search is done with wildcard, so everything similar to the stated PackageName will be found. All the parameters have a more detailed description in the script below.

  • The search can either be done with the parameter -PackageName or -PackageID,
  • The parameter -PackageName is searching with wildcards both at the beginning and the end of the stated name. This should be used when you are not sure of the PackageID, or want to remove multiple packages, 
  • The parameter -PackageID is the unique ID for the specific package you want to remove from the distribution point(s) or group(s). This should be used when you are sure of what you would like to remove,
  • The parameter -CMSiteCode is mandatory and must be specified. 

3. In this case, I would like to remove both of the displaying packages, so I choose 0 for ‘All’, followed by a confirmation (Y / N is not case sensitive)

4. After it has been confirmed, the script will check the following:

  • If the content is distributed to Distribution Point Group(s) as an Application,
  • If not, check if it distributed to Distribution Point Group(s) as a Package,
  • If none of these is correct, the script will check if the content is distributed on each Distribution Point as an Application,
  • If not, it will check if the content is distributed to each Distribution Point as a Package.

At the beginning of the script, the content is validated as distributed. If not, it will not be shown. These four steps above covers all distributed scenarios.

5. When finished, we can see that the Distributed content successfully has been removed.

Please read the comment based help to get a better understanding of what is actually running in the background.


This can of course be modified with more choices in every step, but at the moment I did not see the need for it.

If anyone have any questions or just want to discuss their point of view regarding this post, I would be more than happy to have a dialogue. Please email me at johan.nilsson@xenit.se or comment below.

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: