Reboot notifications

May 9, 2016

Hello,

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 :

clip_image002

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.

clip_image004

The setting required to modify this behavior was the following :

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

· Re-prompt for restart : Disabled.

clip_image006

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

clip_image008

And if the user presses the Open restart button :

clip_image010

Or select the restart now option :

clip_image012

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

clip_image014

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

clip_image016

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”

clip_image018

The user will recieve a popup :

clip_image020

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

clip_image022

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.

clip_image024

Enjoy

Gino D

Advertisements

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.

clip_image002

Now there is a great blog going through the option in detail : http://blogs.technet.com/b/neilp/archive/2013/01/03/on-demand-content-distribution-fallback-distribution-points-a-2012-configuration-manager-micro-depp-dive.aspx

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 : http://blogs.technet.com/b/wemd_ua_-_sms_writing_team/archive/2008/11/25/clarifying-retry-behavior-for-distribution-points.aspx

clip_image004

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.

clip_image006

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 : http://cm12sdk.net/?p=513

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: https://technet.microsoft.com/en-us/library/gg682023.aspx#BKMK_webserver2008_cm2012 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. sccm.customer.com. 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 https://sccm.customer.com:8531 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 (https://sccm.customer.com:8531). 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.

20150805_2

 

20150805_4

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)

20150805_1

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.

20150805_3

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

20150805_5

If Windows Update isn’t available then a fallback will happen to http://sccm.customer.com. 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,

B

 


SCCM 2012 DCM #rdproud

July 31, 2015

Hello,

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 http://blogs.msdn.com/b/scom_2012_upgrade_process__lessons_learned_during_my_upgrade_process/archive/2012/09/21/compliance-settings-sccm-2012.aspx

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

clip_image002

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.

clip_image004

Now if we add the remediation script.

clip_image006

And perform the exact same thing ( after policy refresh )

clip_image008

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.

clip_image010

Now the remediation script logs the same output : Incompliant

clip_image012

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

clip_image014

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

clip_image016

clip_image018

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

clip_image020

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

clip_image022

Wow, this should have been easier to do no ?

Enjoy.

Gino D


Add a password to task sequence ConfigMgr #rdproud

May 19, 2015

 

Hello,

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”))

{

$tsenv.Value(“vContinue”)=”OK”

}

clip_image002

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

clip_image004

Step 1 will only be applied if not in WinPE

clip_image006

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

clip_image008

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

clip_image010

clip_image012

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

clip_image014

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

clip_image016

Step 2 the script asks for the password.

clip_image018

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.

Enjoy.

Gino D


Rename and set password for local admin using configmgr #rdproud

May 19, 2015

 

Hello,

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

You can find additional info here https://support.microsoft.com/en-us/kb/2962486

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” ) {

continue

}

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

#CALLOUT A

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

#END CALLOUT A

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

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

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

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

break

}

}

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

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

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

$user.psbase.rename(“xxx.localadmin”)

$user.SetPassword($strPassword)

clip_image002

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

First create the required variable

clip_image004

Second run a posh script

clip_image006

Now deploy in on a scheduled base

clip_image008

And you have a worthy replacement of your preference !

clip_image010

Enjoy.

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: http://support.microsoft.com/kb/2882125/en-us

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.

02102013_1

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

02102013_2
3. Create an extra folder. Eg. Patches

02102013_3
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

02102013_4
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.

02102013_7
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

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

PATCH=”%_SMSTSMDataPath%\OSD\[PKGID]\Patches\i386\configmgr2012ac-sp1-kb2882125-i386.msp”

02102013_6

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

PATCH=”%_SMSTSMDataPath%\OSD\[PKGID]\Patches\x64configmgr2012ac-sp1-kb2882125-x64.msp”

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!

Cheers,

B