Just another WordPress.com site


Automatically or Manually Update your Configuration Manager Agent/Client

So here’s an interesting finding. You know how Cumulative Update 1 of ConfigMgr 2012 SP2 or ConfigMgr 2012 R2 SP1 has the ability to push out clients with the latest version including the cumulative update hotfix? Well there is one catch though that most people might have missed, including myself. For a person like me who does so many of this upgrades (either in the lab or at the customer’s environment), you may have realised that the setup page is slightly different depending on which environment you run in but can’t just quite able to put my finger on exactly what the difference is. I’m gonna relief you of trying to remember and tell you that it is exactly what I just mentioned above, the ability to install the latest version of the client during either a client push or an auto-upgrade, and is exactly like the below screen shots.


Right after you choose to upgrade the Site database, you click Next and you get this. Here you can choose either you want it to behave just like how it has been behaving (Manually apply) or you want it to go to the latest version Automatically apply


Once you come to the progress page you’ll also realise the additional Action of Configuring automatic client update.



At the end of the installation, you’ll notice an additional sub-folder in the path where you client is, called ClientUpdate.



And that’s where you’ll find the .msp file that you would normally execute.



So what triggers this different setup pages I was talking about? It is at the Automatic Client Upgrade tab of the Hierarchy Settings of your site.

Checked = You get the option to choose Automatically apply or Manually apply

Unchecked = You do not get that additional option to choose.






Creating a Collection of Computers with Old Configuration Manager Console Version

You might have upgraded your Configuration Manager environment to the latest service pack 1 of 2012 R2 and suddenly realise your console installed on your local computer (not the Site Server) has stopped working and couldn’t connect to your Site Server. You could manually upgrade all your consoles by running the install or you could get ConfigMgr to do that for you. To do that you need a collection of computers that have the older version of the console. Just go ahead and use the collection query statement below to do that. The below queries for the 2012 R2 (non-SP1) version of the console.

Note that if you are trying to query the 2012 SP1 version, it is called “Microsoft System Center 2012 Configuration Manager Console” without the quotes instead of what’s used below. The names will defer slightly from one version to another.


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_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = ‘System Center 2012 R2 Configuration Manager Console’





Creating a Collection of Computers with Old Clients Agent Version

So you might wanna do this when you want to upgrade older versions of the ConfigMgr agent to a later version. This scenario is common in a Service Pack upgrade or even a Cumulative Upgrade. In my case, I’m trying to upgrade all my clients to ConfigMgr 2012 R2 Service Pack 1 and therefore in my query I’m looking for all client version that are not equal to the version I’m planning to deploy. You might want to do this just to keep track of your client upgrades.

So if you’re looking at gathering clients of another version, go ahead and change the ClientVersion. You can find out the client version number from the Configuration Manager icon in the Control Panel. So to create that collection, use my exported collection query statement below.


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 where SMS_R_System.ClientVersion != ‘5.00.8239.1000’






Deploying or Upgrading System Center Configuration Manager Administrator Console

This is a fairly simple one to do. You may have to do this either because you’ve got a group of users that require access to the Configuration Manager Console where you do not want them to RDP to the Site Server or you’re upgrading the console as part of a service pack upgrade.

First off, get the installer files. And this is typically located at your ConfigMgr installation path C:\Program Files\Microsoft Configuration Manager\tools\ConsoleSetup. I’d recommend that you make a copy of these files to a location where you normally put all your package source.

Next, create an Application. Use the Windows Installer type but we’re not actually going to kick off the .MSI. You’ll see what I mean later. THen click Next.



Click Next here.



Leave the defaults or change the name if you like, then click Next.



Click Next at the Summary page.



Click Close. You’re almost there.



Now, go back to your application Deployment Types tab and right-click on it. Select Properties.



Go to the Programs tab and change the Installation Program to execute the ConsoleSetup.exe instead of the .MSI file. Reason for this is the .EXE will bootstrap the .MSI file which may do a number of other things like checks before it runs and that’s why it is better to use the executable instead. Also it allows you to specify a couple of other things like your Site Server that you want the console to connect to instead of prompting the user during the first time he/she launches the console, install missing prereqs like ReportViewer or specifying the install location.

Uninstallation is also supported using the /uninstall switch. Replace the Site Server FQDN with your own Site Server Name. You can change the EnableSQM option to either 0 (disable) or 1 (enable) to toggle the experience feedback. Obviously you can also specify a different path where you want it to be installed as TargetDir.

Installation program:

ConsoleSetup.exe /q DefaultSiteServerName=<Site Server FQDN> EnableSQM=0 TargetDir="C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole"


Uninstall program:

ConsoleSetup.exe /uninstall /q



Now, in a console upgrade scenario, you would want ConfigMgr to deploy this out to computers that have the previous version of the console.

To create a collection for targeting this deployement go to: https://weikingteh.wordpress.com/2015/08/14/creating-a-collection-of-computers-with-old-configuration-manager-console-version/





Installing/Applying ConfigMgr 2012 R2 SP1 (SP2)

Now before I go on, you should know there are two files available for download but I’m still getting the same question regarding it. https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-2012-configuration-manager-and-endpoint-protection

  • System Center 2012 Configuration Manager and Endpoint Protection SP2
  • System Center 2012 R2 Configuration Manager and Endpoint Protection SP1

Just looking at it you’ll see that it is the first service pack for ConfigMgr 2012 R2 and the second service pack for ConfigMgr 2012. Hence this is where the confusion lies. Even though the above statement is true but when deciding which files to use for the installation is where most people get caught by surprise. Even though you’ve read some FAQs about it some of you might still be unclear about it. So let me share an easy way of understanding how it all works. Microsoft has brought the two versions of ConfigMgr (2012 and 2012 R2) up to the same level of functionality. So it makes sense to release only one file that will be applicable to both versions of ConfigMgr. They did…except that there is a second file. And trust me the names used here is not obvious and that’s probably why you’re reading this now.


Think of it that Microsoft has released SP2 for ConfigMgr 2012 but the same file used will also upgrade a ConfigMgr 2012 R2 to SP1 level. Remember they are now essentially the same now. It is a full media which allows you to install a complete ConfigMgr environment from nothing. So if you used that file to install ConfigMgr from scratch, you will end up with a ConfigMgr 2012 SP2 installation.

Here’s where the second file comes in. After you’re already on ConfigMgr 2012 SP2 and want to bring it to ConfigMgr 2012 R2 SP1, is when you use the second file. It is a mere 5MB file after extraction. If you are on ConfigMgr 2012 R2, this file will NOT install SP1 for you. Remember you should be using the first file which is about 1.1GB.

I hope that was a short one to clear the understanding before I proceed to show you how to go about backing up, restore, test and then upgrade your ConfigMgr environment to SP2 or SP1 if you were on ConfigMgr 2012 R2.

On to actually performing the upgrade. First you would want to be safe so you should make a backup of your ConfigMgr database. The best way is to protect your ConfigMgr environment is to schedule your backups. To do this is simple using the SQL Management Studio.

You should remember that executing the setup.exe /TESTDBUPGRADE not only runs a simulation or a pre-req test, it actually upgrades the database. That is why you should always make a backup of your ConfigMgr database, restore it to another SQL server and then run the /TESTDBUPGRADE on it. So don’t run setup.exe /TESTDBUPGRADE by mistake!



Go to Management > Maintenance Plan. Right-click on it and select Maintenance Plan Wizard.



Click Next on the SQL Server Maintenance Pla Wizard page.



Enter a name for your maintenance plan. Click the Change button on the bottom right.



Configure the schedule you want the backups to run then click OK. Then back at the Select Plan Properties page, click Next.



Click to select the three checkbox as below then click Next.

  • Clean Up History
  • Back Up Database (Full)
  • Maintenance Cleanup Task



In the Select Maintenance Task Order page, accept the defaults or change the order then click Next.



Most of the time you do not need to keep more than a week so change to remove historical data older than one week.



In the Define Back Up Database (Full) Task page, click on the Database drop-down box and select the database you want to backup. Configure the Folder location you want to store the backup file and select the backup compression to Compress backup. Click Next.



In the Define Maintenance Cleanup Task page, configure the location where you store the backup file and enter bak as the file extension. Change to delete files more than 1 week of age. Click Next.



In the Select Report Options page, accept the defaults or change to e-mail report if desired, then click Next.



In the Complete the Wizard page, click Finish.



In the Maintenance Plan Wizard Progress, click Close once the process is complete.



Back to the SQL Management Studio console, right-click on the Maintenance Plan you just created and click Execute to run the backup task out of schedule.



Click Close once the task is completed.



This is what you’ll end up with after the backup task is complete. Note the file size after compression from an original size of 5GB! Impressive.




Now to restore the database so that you can test the upgrade. You have to remember that you cannot restore the ConfigMgr DB to another SQL server that has a ConfigMgr DB. That means you would need another SQL server that is not another ConfigMgr server.

In my case I’ve got another SQL server in my environment and using the SQL Management Studio, right-click on Databases and select Restore Database.



In the General node of the Restore Database screen, select Device and then browse to locate the .bak file that was generated from the backup process.



In the Select backp devices, click Add.



Browse to the location of the .bak file then click OK three times.



Test DB Upgrade

Now that you’ve got the database restored to another SQL server, we can begin to test the DB upgrade. Remember, the setup.exe /TESTDBUPGRADE runs an actually database upgrade.

Using a command prompt or PowerShell window, navigate to the location of ConfigMgr 2012 SP2 media. Then simply execute “setup.exe /TESTDBUPGRADE <database name>



You can check the progress and status of the upgrade from the ConfigMgrSetup.log file which is normally located in your C:\ root. Now that you’ve successfully upgraded your ConfigMgr database in a separate server, you can now be more confident of it also succeeding in your production ConfigMgr environment.



Installing SP2

The rest of it is easy. Go ahead and install SP2 into your production environment.

Click Install.



In the Before You Begin page, click Next.



In the Getting Started page, make sure Upgrade this Configuration Manager site is selected then click Next.



In the Microsoft Software License Terms page, select the checkbox to accept the license terms then click Next.



In the Prerequisite Licenses page, select all the checkboxes to accept the license terms and then click Next.



In the Prerequisite Downloads page, choose either to Download required files or Use previously downloaded files then click Next.



In the Server Language Selection page, leave the defaults and click Next.



In the Client Language Selection page, leave the defaults and then click Next.



In the Settings Summary page, click Next.



In the Prerequisite Check page, click Begin Install.



Click Close when the process is complete.




Installing ConfigMgr 2012 R2 SP1

Now to get it up to ConfigMgr 2012 R2 SP1. Just so that you know you using the correct file, it is the smaller size of the two which is only about 5MB so this will be a really quick one. Click Upgrade to proceed.



Click Next.



In the Software License Terms page, select the I accept the license agreement checkbox and then click Next.



In the Ready to Install page, click Install.



In the Setup Complete page, click Finish.



The Experience

Before ConfigMgr 2012 Service Pack 2 Installation


After ConfigMgr 2012 Service Pack 2 Installation


After ConfigMgr 2012 R2 Service Pack 1 Installation






Setting the SMSCacheSize During OSD Task Sequence (PowerShell)

So you just want to configure the cache size of the Configuration Manager agent to something else other than the default size of 5120MB for whatever reason. Easy right? Since the cache size is set during the installation of the ConfigMgr client you go to the “Setup Windows and ConfigMgr” task and just add the SMSCACHESIZE parameter as the installation properties and it’ll work right? Not so fast.

The installation properties will only work if you’re installing the ConfigMgr client and will not work if you’re re-installing the client. So why this might not work in your task sequence? Really it is because if you’ve got the ConfigMgr client installed in your reference image (which is pretty common when creating a sysprep’ed reference image to get the things like core apps or software updates installed), then running the “Setup Windows and ConfigMgr” task in your task sequence is actually re-installing the ConfigMgr client and that’s why this method wouldn’t work.



So how do you work around it? Run a PowerShell script. Below is the contents of the script. Copy and paste it into Notepad and save it as a .ps1 file. Change the $Cache.size to whatever you want in MB.

$Cache = Get-WmiObject -namespace root\ccm\SoftMgmtAgent -class CacheConfig
$Cache.size = 20480
$Cache.InUse = "True"
Restart-Service ccmexec

After you create a package for your PowerShell script, it is time to add it as a task in your deployment task sequence. So I use the Run PowerShell Script task and reference the package I’ve just created for it. Obviously the Script name is the file name I saved the above content as. Set the PowerShell execution policy to “Bypass”. You would want to run this script after the “Setup Windows and ConfigMgr” task but anything lower will work as well like how I’ve done it. And that should be it!






PowerShell Script to Insert Branding, OEM and Custom Wallpaper

As part of a Windows deployment whether or not using SCCM, MDT or other methods, one thing you probably want to do is customise Windows in such a way that incorporates a corporate image. This script includes customised Lock Screen image, custom wallpaper image and OEM information like logo, support contact, support URL etc.

One requirement is to set a default corporate wallpaper but still allow the user to change it. Although we can address the custom wallpaper using Group Policy, but that will prevent the users from changing it. This is why Group Policy is not used for custom wallpaper like how it is most commonly done. Also preferably we do not want to replace the img01.jpg file which comes with Windows for the wallpaper (which may be another solution to assigning a custom default wallpaper) so that users still have the ability to change it to that if the user wishes.

Important thing to note is, make sure you have your BMP and JPG file is saved in the same location where this script is sitting in. Create all these files as a package and then call the .PS1 file using the Run PowerShell Command task in SCCM/MDT task sequence.

The script first copies the images BMP and JPG to their respective locations then starts to set the OEM information using the Set-ItemProperty cmdlet, followed by making changes to the registry for the default lock screen and default wallpaper.


===Start Script===

$Wallpaper = "backgroundDefault.jpg"

# copy the OEM bitmap
If (-not(Test-Path c:\windows\system32\oobe\info\backgrounds)){New-item c:\windows\system32\oobe\info\backgrounds -type directory}

copy-item $PSScriptRoot\OEMlogo.bmp "$OSDISK\windows\system32"
copy-item $PSScriptRoot\user.bmp "$OSDISK\ProgramData\Microsoft\User Account Pictures"
copy-item $PSScriptRoot\OEMLogo.BMP "$OSDISK\windows\system32\oobe\info\"
copy-item $PSScriptRoot\$Wallpaper "$OSDISK\windows\system32\oobe\info\backgrounds\"
copy-item $PSScriptRoot\$Wallpaper "C:\Windows\Web\Screen\$wallpaper"
copy-item $PSScriptRoot\$Wallpaper "C:\Windows\Web\Wallpaper\Windows\$wallpaper"

# make required registry changes
$strPath = "HKLM:\Software\Microsoft\Windows\CurrentVersion\OEMInformation"
$strPath2 = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background"
$strPath3 = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Personalization"
$strPath4 = "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"

Set-ItemProperty -Path $strPath -Name Logo -Value "C:\Windows\System32\OEMlogo.bmp"
Set-ItemProperty -Path $strPath -Name Manufacturer -Value "My IT Services"
Set-ItemProperty -Path $strPath -Name SupportPhone -Value "(02)9876-1234"
Set-ItemProperty -Path $strPath -Name SupportHours -Value "7:00am to 7:00pm"
Set-ItemProperty -Path $strPath -Name SupportURL -Value http://example.intranet.myitservices.com/internal_services/IT_services
Set-ItemProperty -Path $strPath2 -Name OEMBackground -value 1

New-Item -Path HKLM:\Software\Policies\Microsoft\Windows -Name Personalization –Force
Set-ItemProperty -Path $strPath3 -Name LockScreenImage -value "C:\Windows\Web\Screen\$wallpaper"

New-Item -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies -Name System -Force
Set-ItemProperty -Path $strPath4 -Name Wallpaper -value "C:\Windows\Web\Wallpaper\Windows\$wallpaper"
Set-ItemProperty -Path $strPath4 -Name WallpaperStyle -value "2"

write-host "End of Script"

===End Script===






Get every new post delivered to your Inbox.

Join 81 other followers