Redistributing failed content

When working with ConfigMgr you always end up distributing content to several DPs. This normaly goes off without a hitch but from time to time this fails. If you then have several DPs spread across a large geographical area, WAN links may be questionable. So when a package then fails most are not happy to redistribute the content to all DPs again.


So to help sort that out the following script can be used. The script will find all failed packages on a specified DP and then redistributed them to that single DP only. All that is needed is to run in on the Primary site server / server with SMS provider and specifiy your SiteCode and DP FQDN.

The script is available on Github over here: Update-ContentForSingleDP

Happy deploying!



PowerShell remoting – source vs destination

Powershell remoting, the ability to remotley manage and influence devices is a key part of PowerShell. By default PowerShell remoting is enabled on servers and one of the lazy “security” features you can use is to only allow connections from specified networks.

In a domain network this is very easy to do, all you need is a small group policy that sets the networks. There is one thing you need to note, that is not really documented.

The Group Policy

The group policy is a regular computer policy setting found under “Computer\Policies\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service” and the actual poliy item is named “Allow remote server management through WinRM”

When you enable this policy you can enter networks the server will consider trusted.  So lets say you have your server on the network, that would mean you set the filder to

The issue

What you need to consider is the following. Say you have servers on two seperate networks and one is considered management network, lets say it uses This means you now specify the management network as approved. But the servers you are accessing is on your primary server network You have to specifiy both source and destination networks for this to work as this also controls the actual listners and if you only specify the network the listners on the servers on network will not be enabled.

The solution

For the scenario above make sure to specify both networks in your GPO. So the filter will be set to,



Techdays 2017 Pre-Conf Slides

Me and Jörgen Nilsson (@ccmexec) did a pre-conf together at Techdays in sweden. And after much slacking here are now the slide deck from that pre-conf.

Here is the link to download the slidedeck!




Windows 10 1709 Reference Image

Update – 2018-03-06 – Read at the bottom

When creating a Windows 10 reference image a common issue is that the store updates will autoupdate while you are busy installing software updates and applications. This then causes sysprep to fail in giant ball of fire.

To solve this there are basically two options and for some option one doesn’t seem to work which is why I always opt for option two.

Option 1, follow the guidance for disabling auto store updates. This consists of adding a DWORD registry item to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore named AutoDownload with a value of 2. More info on how to do this check out the blog over at deploymentresearch.com

Option 2, is to use a WSUS and then disable internet access for the duration of the build. This can easily be achieved using PowerShell and a sprinkle of magic.

Here is how! Lets start with creating a small PowerShell Script.

param (

If (!$Disable) {
Write-Output “Adding internet block”
New-NetFirewallRule -DisplayName “Block Outgoing 80, 443” -Enabled True -Direction Outbound -Profile Any -Action Block -Protocol TCP -RemotePort 80,443

if ($Disable) {
Write-Output “Removing internet block”
Get-NetFirewallRule -DisplayName “Block Outgoing 80, 443” | Remove-NetFirewallRule


Save that into as Invoke-InternetAccess.ps1 and place the file into the MDT deployment share script folder.

Now time to set the sequence.
Add two “Run PowerShell script” steps as shown below.


For the first one just set the script name to Invoke-InternetAccess.ps1
For the second one set the script name to Invoke-InternetAccess.ps1 and parameters to –Disable

All done! Now you can run your sequence and not worry about any store updates during your build.

Update – 2018-03-06
There has been some discussion around this and there is an alternative to the way below which will work if you use MDT. The solution is a simple as it is elegant and requires very little configuration.

All you would need is to set HideShell=YES in your customsettings.ini. This will not load a full explorer and hence store will not start and there will be no store updates downloaded.


Happy deploying



ADFS Single Sign on with Edge

I usually don’t blog about ADFS but since I recently had to solve this issue for a customer I thought someone else might find it usefull as well.

When you use Edge or Chrome as your primary browser and using a machine that should have SSO with Office 365 and Sharepoint you still get a login page. This happens because by default ADFS have a set of trusted browser strings and others will be prestend with a form authentication.

To fix this on your ADFS server you need to use a couple of simple powershell commands.

Let’s start with just getting what browser strings are trusted currently.

Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents


As you can see there browser agent for Edge and Chrome are missing. To fix this we run the following powershell command.

Set-AdfsProperties –WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain","MSIE 6.0","MSIE 7.0","MSIE 8.0","MSIE 9.0","MSIE 10.0","Trident/7.0", "MSIPC","Windows Rights Management Client","Mozilla/5.0","Edge/12")

Then restart the ADFS service

Restart-Service ADFSSrv

That is, you can verify the settings by getting the ADFS properties again


All done and Single Sign On will should now work using Edge or Chrome as well!




ConfigMgr 1703 Technical Preview

ConfigMgr 1703 TP has just been released and I am really exited by all the new features! Three of the ones you should check out are the Collapsible task sequence groups, the ability to control Windows Analytics and the direct links to applications in software center

Collapsible Task Sequence Groups

MDT has had this for a long while but now ConfigMgr gets it as well. This will help out while editing a task sequence. And it looks a bit like this


Windows Analytics

There is now a new settings group in the client settings that’s called Windows Analytics and there you can enter your Commercial ID (found in the settings of OMS) and select the type of telemetry data sent to Windows Analytics.

It looks a bit like this


When you get data back you can connect Windows Analytics with ConfigMgr and then get collections based on the data in Windows Analytics. For instance a collection with all machines that are ready for the next version of Windows without known upgrade issues.


Create direct links to applications in Software Center

So one request that has been around for a while is the ability for admins to give end users a direct link to the install section of an app in software center. This has previously been done with a workaround and calling the WMI methods involved. Starting with 1703 you can now easily deploy your own link as URL links.

Its pretty straight forward, create a URL link specify the link to be Softwarecenter:SoftwareID=<ApplicationID>

To find the ID either use powershell and the Get-CMApplication command or use the gui end show the column named “CI Unique ID”

You will then end up with a URL looking something like this


Note that this new feature requires the new agent version available with 1703 and does not work with previous agent versions.

Below is a short script that can help you easily create these shortcuts. Just run it on your CM Server or a machine with the console installed. Select the applications you want and it will create the shortcuts on your desktop ready for distribution to other machines.

Created:     2017-03-31
Version:     1.0
Author :     Peter Lofgren
Twitter:     @LofgrenPeter
Blog   :     https://syscenramblings.wordpress.com

This script is provided "AS IS" with no warranties, confers no rights and
is not supported by the author

1.0 - Initial release

# Import the ConfigurationManager.psd1 module
Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1"
# Set the current location to be the site code.
Set-Location "$((Get-PSDrive -PSProvider CMSite).Name):"

#Get Application Name
$AppName = Get-CMApplication | Select LocalizedDisplayName | Out-GridView -PassThru
foreach ($App in $AppName) {
  $Application = Get-CMApplication -Name $App.LocalizedDisplayName

  #Get Application ID
  $ID = ($Application.CI_UniqueID -split "/")[0] + "/" + ($Application.CI_UniqueID -split "/")[1]

  #Create URL Link on desktop
  $Shell = New-Object -ComObject ("WScript.Shell")
  $Favorite = $Shell.CreateShortcut($env:USERPROFILE + "\Desktop\$($App.LocalizedDisplayName).lnk")
  $Favorite.TargetPath = "SoftwareCenter:SoftwareID=$ID";
  $Favorite.IconLocation = "C:\Windows\ccm\SCClient.exe, 0";


If you want to read more about the other new features check out the post by the team here https://blogs.technet.microsoft.com/enterprisemobility/2017/03/30/update-1703-for-configuration-manager-technical-preview-branch-available-now/



Keeping Track of PowerShell versions

In today enterprises many are faced with the challenge of managing both Windows 7, 8, 8.1 and 10. This means that most have a multitude of PowerShell versions out there which in turn does not ease the management tasks faced.

If you are running ConfigMgr 2012 or later you have access to one of my favorite features called Compliance Settings. Use this feature you can easily keep track of your environments different settings and measure compliance. One of the things I like to measure is the current running PowerShell version. I do this for two reasons. Number one, I want to now that my systems are running the version set out as a baseline. Number two is that if they are not running the correct version I get an easy way of finding them all and hence an easy way of correcting it.

So the tasks including creating a Configuration Item, linking it to a Configuration Baseline, deploying said baseline to a collection of workstations and creating a collection of devices that are not running the correct version.

Step 1 – Creating the Configuration Item

In your ConfigMgr console find the Assets and Compliance workspace and then under Compliance Settings you will find Configuration Items.

Create a new one and give it a name, I will be using “PowerShell Version”. Make sure that Settings for device managed with ConfigMgr Client is set to “Windows Desktops and Servers (custom)”.

In the next pane select the appropriate Operating Systems that this can be run on. Hint, Windows XP does not support PowerShell.

On the settings pane, hit New and in the configuration set a Name, again “PowerShell version” works just fine. Set the Setting type to “Script” and the datatype to Integer. Hit the “Add Script” button for Discovery script and paste in the following script and then hit OK.

[int]$Version = $PSVersionTable.PSVersion.Major
return $Version

On the Compliance Rules pane hit New and give the Rule a name. I’m calling it BaselineVersion. Hit the browse button and select your Current CI and the Version setting we just created. The rule type should be set to Value and in the comply part set the value returned must “Equal” and then set your desired baseline version. 4 will give you an OK on Windows 8.1 and Windows 10 and 5 will only give you an OK on Windows 10 (this assumes you have not previously upgraded your WMF versions). Hit OK and then Next.

Review your setting on the summary pane and hit next when ready to create the Configuration Item

Step 2 – Creating a Configuration Baseline

Head over to the Configuration Baselines workspace and create a new baseline. Please note this can both be included in previously created baselines but I prefer a separate for this so I can later use the non compliance feature. Give the Baseline a name, “PowerShell”. Hit Add, Select Configuration Item and select your previously created CI.

Step 3 – Deploying the Baseline

This should feel very normal to most of you since it’s the same procedure as deploying any application or client setting. Right click your baseline and select deploy. The wizard will not look like the usual deployment wizards but all you have to do is select a collection to deploy to. I recommend avoiding deploying it to the built-in collections and instead do two deployments if you want to monitor both servers and clients. Before you hit OK change the Schedule to suite your response times. Default is 7 days which in a small environment can be forever but in a large environment it just around the corner.

Step 4 – Creating the non compliant collection

The last step is to create that all needed collection which you can deploy the new Windows Management Framework too. select your newly created baseline, look for a tab named Deployments a the bottom of the console. In this view you can see the collection the baseline has been deployed to.

Now right click the collection, select “Create New Collection” and then select “Non-Compliant”. Follow the new Collection wizard and not that the rule for membership is premade.


Last notes

Now all that remains is waiting for the devices to report back status and then end up in the Non-Compliant collection so you can remedy them.

For your Windows 7 machines please note that if you have not previously upgraded Windows Management Framework you will need to install both WMF4 and WMF5. WMF4 is a prerequisite for WMF4 and both require a reboot to complete. This might be a good time for a small custom task sequence.