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


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


Manage Windows RT with Windows Intune

January 31, 2013

Hi all,

As you might have seen in the previous post it is possible to manage iOS devices using Windows Intune.

In this post I’ll describe how to enroll and manage a Windows RT device.

To start, logon to the Intune Admin Page:

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=2&ct=1359573844&rver=6.1.6206.0&wp=MCMB

Open the admin console and go to Administration, select Mobile Device Management, Windows RT Management

31012013_01

A Sideloading key can be added to install line of business apps on Windows RT devices.

On the Windows RT device open the charms bar and search for company applications.

31012013_02

The Company applications setting opens in desktop mode

31012013_03

Login using the credentials known in the Windows Intune Console.

Also fill in the serveraddress enterprisenrollment-s.manage.microsoft.com (this is the serveraddress that can be seen in the Windows RT Mobile Device Enrollment Setup). If there was a domain name provided earlier enter it again here (possibly this will not be needed if the Windows RT device is connected to a corporate WLAN network).

31012013_04

Wait until connection succeeds

31012013_05

Click Install the management application

31012013_06

You will be redirected to Internet Explorer, from there you can can choose to view the application in the Windows Store.

From there the application can be installed.

31012013_07

31012013_08

Open the application and sign in with the Windows Intune account

31012013_09

31012013_10

After being logged in the company portal shows an overview off all available applications. They can be ordered using categories. Some information about the devices is also present and contact details which can be useful for support. These contact details are provided in the Windows Intune Admin Console.

31012013_11

The complete enrollment procedure shown here, can also be found on http://technet.microsoft.com/en-us/library/hh441723.aspx. This website also describes the enrollment of other mobile devices.

An additional device is shown in the Intune console.

31012013_12

Now you can enforce all kinds of items like :

-> Remote wipe

-> Allow picture password

-> …

A full list is available at http://onlinehelp.microsoft.com/windowsintune/jj738616.aspx

In the next post I’ll show you how an app from the Windows Store can be made available in the company portal.

Cheers,

B


SCCM 2007 + MDT 2010: Application in multiple roles

December 13, 2012

Hi,

Today I had a little discussion about how MDT handles duplicate applications within roles. The environment consists of SCCM 2007 and MDT 2010 where MDT is used to store the configuration of client computers mainly to use MDT roles for software installation during task sequences.

The situation at that customer is that some applications can be member of multiple MDT roles which (I thought) would result in the fact that the application would also be installed multiple times. Let’s put this theory to the test.

Testscenario:

–          3 roles:

  • Role 1: contains 23 applications
  • Role 2: contains 1 application
  • Role 3: contains 3 applications. All 3 applications are already member of Role 1 or Role 2

If MDT reacts to duplicate applications as I except I would see during the task sequence that all 27 applications will be installed. To see how many applications would be installed the ZTIGather.log can be checked on the client device during the execution of the task sequence.

MDT_13122012_4

When we open the logfile and check for the array containing all applications we expect to see PACKAGES001 up to PACKAGES027. But surprise was great when we only saw PACKAGES001 up to PACKAGES024. The difference is 3 which means that MDT has filtered out the 3 duplicate applications from role 3.

When checking the ZTIGather.log we can also see that the returned records count of the SQL query for all Packages in the Roles associated to the computer is 27.

MDT_13122012_5

This means that MDT detects that there are 27 applications in the 3 roles but at some point sees that there are a number of duplicates which are ignored while filling up the packages array.

Nothing can be found int the ZTIGather.log which states that the duplicates are ignored. That’s why I went deeper into investigating the ZTIGather.wsf script which contains all intelligence in processing the MDT data.

After some digging in the script I’ve found a function called QuerySQL which obviously will be used to get the right information from the SQL database and put it in the BDD.log. In that function there is a routine that processes the output of the SQL query.

MDT_13122012_2

While looking in more detail at the above code I noticed there is a line which has been put in comment stating:

“oLogging.CreateEntry “Value ” & oRS.Fields(cStr(sColumn)).Value & ” already found for ” & sElement, LogTypeInfo”

The statement ‘already found for’ made me suspicious so I’ve put this line of code out of comment and when I ran the script another time the ZTIGather.log showed the following output:

MDT_13122012_3

So basically the ZTIGather.wsf has the intelligence to detect duplicate applications, packages,… but doesn’t show this in the various logfiles, which is rather weird in my opinion.

I hope this gives you guys a better insight in how MDT handles applications.

Cheers

B