Reboot notifications

May 9, 2016


Reboot notifications , we all hate to reboot. Normally the less the better but as … an admin you want to pursuade your users into rebooting the device from time to time. Keeps it healthy and running smoothly.

Now in sccm we have several options for rebooting. In this particalur case we supress the reboot for the update deployment. So the user gets notified but not forced to reboot.

Unfortunately the result was this :


That’s odd the windows update reboot notification was not wat we wanted. If we check the notifications area we see 2 notifications : one for sccm client and one for windows update.


The setting required to modify this behavior was the following :

· System -> Windows Components -> Windows Update -> Configure Automatic Updates :Disabled

· Re-prompt for restart : Disabled.


After modification of these policies the result was better ! Just one notification.


And if the user presses the Open restart button :


Or select the restart now option :


In the software center applet you can see detailed info about which update requires a reboot.


Now the behavior is different for software installations requiring a reboot. For example this IE11 installation returns a 3010.


The user will be notified about a required reboot on the device , the settings are be configured by the sccm client settings for “Computer Restart”


The user will recieve a popup :


If ignored the restart icon will stay in the notification area.


Now according to the settings there is a permanent message shown as soon as there is only 15′ left on the clock. The color of the progress bar will change and the hide button will become unavailable.



Gino D


SCCM Distribution point down !

December 17, 2015

Ho ho ho,

Almost merry Christmas everyone ! Enjoy the holidays .

Until then, here’s some useful information about fallback locations in sccm 2012.

As you all know there are lots of different options for redirecting a client to a specific distribution point for downloading content. The most common setup involves “preferred” distribution points linked to a specific boundary group. By specifying the option “allow fallback source location” on the distribution point we can allow clients to use a fallback option when content is not available.


Now there is a great blog going through the option in detail :

Here’s the catch however. These scenario’s all work when the DP is online but the content is unavailable.

But , if the DP is offline the deployment will fail as the MP will continue to present these DP’s to the clients even while unavailable. The client will retry the unavailable DP for 8 hours until switching to the next.

You can find detailed info about the behavior here :


So what can we do ?

Well we can remove the DP from our boundary group and then the MP will no longer present it to the client.


Nice ! But that’s a manual action. No, not really as we can use orchestrator to run a simple ping test on our DP and when it’s unavailable just run a powershell script to remove it from the boundary group and add some alerting ( in our case we create an alert in SCOM ).

Some good examples can be found here :

Enjoy !

Gino D

Configuration Manager 2012 R2 SP1 IBCM WSUS #RDPROUD

August 5, 2015

Hi all,

For some time I’ve been busy configuring Internet Based Client Management (IBCM) at a customer of mine. The infrastructure consists of System Center 2012 Configuration Manager R2 SP1 and has one primary site. One management server was already present for the intranet clients and I wanted to add the necessary means to support IBCM.

The most straightforward method was to add an additional management server which would be occupied with everything related to internet clients.

The general setup can be found here: and is quite straight forward.

Now the tricky part: How to make sure the infrastructure can be reached from the internet? First of all I needed a public IP adress which I could use for the CNAME eg. Then I needed to add the necessary components in the reverse proxy solution available (in this case: Citrix NetScaler). There I added a virtual server on port 443 configured using Protocol SSL_BRIDGE. This makes sure the connection gets passed through the NetScaler directly to the backend server.

When this was configured deploying software, requesting policies, etc. worked like a charm.

Additionally I wanted to make sure internet client could also use SCCM to check for updates (not directly to Windows Updates).

Therefore some extra configuration was needed:

  • Install WSUS on the new management server (sharing the same database as the WSUS that is already present in the Configuration Manager infrastructure.
  • Install SUP on the new management server (with SSL enabled + Internet only traffic allowed)
  • Configure IIS to use the SSL certificate (additional information here)
  • Make sure URL can be resolved on the internet ( therefore an additional virtual server can be added to the NetScaler: port 8531 protocol TCP)

Now when a computer is connected to the internet, the SCCM agent will detect that and will replace the existing WSUS URL (eg. http://sccminternal.customer.local:8530) by the one available from the internet ( One of the places to check this is in registry: HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate. This should point to the internet available FQDN. Also the Locationservices.log should show some information.




When the computer checks for updates it will connect to the published URL to see what updates are missing. Afterwards the deployment of updates will be checked to see what updates are “Actionable” (see UpdatesDeployment.log)


For the download itself the agent will use Windows Update. These downloads are done over HTTP and can be followed in the DataTransferServices.log on the computer.


The user experience is the same. Everything is listed properly in the Software Center


If Windows Update isn’t available then a fallback will happen to But because HTTP traffic isn’t redirected through the reverse proxy this will fail. Nevertheless I prefer the direct download from Windows Update as this minimizes bandwidth constraints in the customer infrastructure.


Hope this helps.


Best regards,



SCCM 2012 DCM #rdproud

July 31, 2015


Today I created a sccm2012 dcm rule for verifying if all services set to automatic are effectively started. Sound easy but there are some catches.

For a walkthrough see

The interesting part is however :

-> As soon as you add a remediation script to your CI it will allways show up compliant.

Baseline 1 without remediation


Shows up as non compliant ( which is correct )

As you can see the output presented by the script is “Incompliant” and it needs to be “Compliant” so we’re in an error state.


Now if we add the remediation script.


And perform the exact same thing ( after policy refresh )


And you’ll see that the rule reports as compliant because it automatically assumes the remediated value is “Compliant”

Since there was logging attached to the ps we can see the following. First of all I use the scriptname as logfile and apparently the powershell script name is regenerated each time the dcm rule is evaluated so take a hardcoded log file.


Now the remediation script logs the same output : Incompliant


So my guess is the detection rule is not re-evaluated after repair so state is assumed compliant.

Solution could be to add the same rule twice :

-> Once with remediation reporting no issues when non compliant

-> Once without remediation reporting Critical severity


Hmm.. This is not working still Compliant after evaluation. So I added 2 settings and created a set of 2 Comliance Rules



Much better, now I have an incompliant state but my repair script has executed.


We can see the Rule1 is evaluated and remediated but has not made a change in compliancy state.


Wow, this should have been easier to do no ?


Gino D

Add a password to task sequence ConfigMgr #rdproud

May 19, 2015



Say you want to add a password to a task sequence ?

Yes, you can do that starting from PXE but not starting from the OS (out-of-the-box) so let’s modify.

First create a simple posh Script ,

# Script can be used in order to ask a password in SCCM task sequence

# Requries vPassword to be created in TS , if input equals then vContinue will be set to OK


# Gino D’hoker


# 4/05/2015

$password = Read-host “Please enter the password.” -AsSecureString

# Prompt for input

$password = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password))

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

If ($password -eq $tsenv.Value(“vPassword”))





This will ask for input, check if the answer is identical to a ts variable called vPassword and then set a variable called vContinue to OK.

Now let’s create the ts, you’ll need the MDT package for Serviceui.exe in order to allow interaction with the ts


Step 1 will only be applied if not in WinPE


Now use the mdt package and perform a custom action for asking input


Because we’ll use the same ts from PXE and from OS we’ll need to set the vContinue to OK if started from PXE



And now just continue the rest of the ts only of the vContinue is OK


So what does this look like ? Step 1 you receive the default warning


Step 2 the script asks for the password.


If incorrect it will not perform the reinstallation.

P.S I know the dos box isn’t state of the art, I’ll check into the Powershell forms the next time to get a more fancy request for input

The rest you know.


Gino D

Rename and set password for local admin using configmgr #rdproud

May 19, 2015



As you all know 🙂 -> Modification of local user password no longer possible using preference. When did this happen ?

You can find additional info here

Solution could be to reuse a sccm task sequence in order to rename the local admin and set the password.

We will use a task sequence variable as the password that should be applied.

We’ll create a powershell script.

# Change_passwords.ps1



# Author = Gino D’hoker


# Will be used in SCCM task sequence for renaming and setting password of local admin

# requires task sequence variable named vPassword with the required password



# Version 1.0

$computerName = $env:COMPUTERNAME

$computer = [ADSI] “WinNT://$computerName,Computer”

foreach ( $childObject in $computer.Children ) {

# Skip objects that are not users.

if ( $childObject.Class -ne “User” ) {



$type = “System.Security.Principal.SecurityIdentifier”


$childObjectSID = new-object $type($childObject.objectSid[0],0)


if ( $childObjectSID.Value.EndsWith(“-500”) ) {

“Local Administrator account name: $($childObject.Name[0])”

“Local Administrator account SID: $($childObjectSID.Value)”

$username = $($childObject.Name[0])




$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

$strPassword = $tsenv.Value(“vPassword”)

$user = [ADSI]”WinNT://./$username”




Now create a task sequence in order to deploy the task.

First create the required variable


Second run a posh script


Now deploy in on a scheduled base


And you have a worthy replacement of your preference !



Gino D

Update Configuration Manager 2012 SP1 client with Cumulative Update 3

October 2, 2013

Hi all,

Today I’m going to talk about the Cumulative Update 3 of Configuration Manager 2012 SP1 and how to install the updated client to all Configuration Manager Clients. As you all might know this CU3 fixes some issues with Configuration Manager. For a detailed list, I recommend you to read the following Microsoft documentation:

First of all the CU3 should be installed on the primary site server.

The installation generates a couple of packages that should be appropriately deployed:

–          Package to update the console
–          Package to update the server
–          Package to update clients (x86)
–          Package to update clients (x64)

The focus today is on  the client update and how to get it installed throughout the environment.


We first have to look at the different deployment scenario’s:

–          Upgrade existing Configuration Manager Client (example for x86 clients)

1. Create a collection called All x86 Systems with client using the following query:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.SystemType = “x86-based PC”

This collection has a limiting collection called “All Systems with Client”, this collection was created previously

2. Deploy the x86 client update to the “All x86 Systems with Client” collection using a required deployment

The same can be done for x64 clients

–          Integrating CU3 client with Operating System Deployment

In previous versions of SCCM when a cumulative update was installed, the update was added to the client installation source. Which means that the original client package only needed an update distribution points to include the update + add an additional parameter to the Setup Windows & Configmgr step in the task sequence.

Now the update is stored elsewhere, so a new client package should be created which contains the original client installation source and the cumulative update (.msp file)

1. Create an empty folder in your datastore where packages, applications, etc. are stored (eg. \\[fileserver]\DSL\Microsoft\SCCM_Client\2012_CU3\ML\MSI)

2. Copy the content from the installation folder of SCCM (eg. D:\Program Files\Microsoft Configuration Manager\Client into the new folder

3. Create an extra folder. Eg. Patches

4. Copy the contents of the folder where the update was installed (eg. D:\Program Files\Microsoft Configuration Manager\hotfix\KB2882125\Client) into the Patches folder

5. Create a package in Configuration Manager with the newly created folder as source (\\[fileserver]\DSL\Microsoft\SCCM_Client\2012_CU3\ML\MSI), No need to create a program for this package.

6. Copy the package to the distribution points available within your environment

7. Edit the task sequence where you want to apply the updated version of the Configuration Manager Client. Edit the existing “Setup Windows & Configuration Manager “ step and point it to the newly created package

8 Fill in the following command line at the installation properties field:



This is for the x86 client Operating Systems being deployed, for the x64 operating systems this is the right command line:


From now on clients being deployed with the edited task sequence will receive the latest version of the Configuration Manager Client

For future updates, the same way of working can be used.

Hope this helps!