The Sysadmins

Tips and tricks from the Sysadmins

Category: SCCM

SCCM 2012 – SCEP UNC Definition Updates Automation with Powershell

One of the choices for SCEP (System Center Endpoint Protection) definition update sources in SCCM 2012 is from a UNC file share, however in typical SCCM fashion there is a bit of leg work required to use this method. This post will explain the steps involved to make this happen.

1. Create a Folder Structure and Share

Create a folder structure to share the SCEP definition update files, the top level folder name does not matter, in this example I’m using SCEPUpdates. Within this folder create two folders, one named x86 for x86 machines and one named x64 for x64 machines. Share the SCEPUpdates folder. Ensure the client computers and the domain users connecting to the share have read permissions to the share. During an automatic update, the client computer account is used to authenticate to the share. When a user manually updates their definitions by clicking Update, that user account is used to authenticate to the share. You will want to use DFS or similar if you have multiple locations to distribute the files.


2. Powershell Script to Automate Definition File Downloads

There are 6 files in total to download, 3 for x64 machines and 3 for x86 machines.

  • Mpam-fe.exe – Full Definitions
  • Mpam-d.exe – Delta Definitions
  • Nis_full.exe – Network-based exploit definitions

For more information and direct links to the definition files see here (or refer to the Powershell script below).

I’ve put together a Powershell script to download the 6 definition update files to a UNC path.

$x64S1 = "//"
$x64D1 = "\\server\SCEPUpdates\x64\mpam-fe.exe"
$x64S2 = "//"
$x64D2 = "\\server\SCEPUpdates\x64\mpam-d.exe"
$x64S3 = "//"
$x64D3 = "\\server\SCEPUpdates\x64\nis_full.exe"
$x86S1 = "//"
$x86D1 = "\\server\SCEPUpdates\x86\mpam-fe.exe"
$x86S2 = "//"
$x86D2 = "\\server\SCEPUpdates\x86\mpam-d.exe"
$x86S3 = "//"
$x86D3 = "\\server\SCEPUpdates\x86\nis_full.exe"
$wc = New-Object System.Net.WebClient
$wc.DownloadFile($x86S1, $x86D1)
$wc.DownloadFile($x86S2, $x86D2)
$wc.DownloadFile($x86S3, $x86D3)
$wc.DownloadFile($x64S1, $x64D1)
$wc.DownloadFile($x64S2, $x64D2)
$wc.DownloadFile($x64S3, $x64D3)

This is great for one off downloads, but we want to automate the task. The next step is to create a schedule task to the run the script every x hours. The action should point towards the Powershell script above, you can simply use powershell -file “script.ps1” as the action.


This schedule kicks the first download off every day at 12:05am and updates the definition files every 4 hours.


Confirm the scheduled task is running every 4 hours and updating the files correctly before moving onto the next step.

3. Configure Definition Update Sources

Open the System Center 2012 Configuration Manager console and browse to Assets and Compliance -> Endpoint Protection -> Antimalware Policies and select the policy you would like to configure.

SCEP Set Sources

From the left hand menu choose Definition Updates and choose “Set Source”. Tick “Updates from UNC File Shares” and move to the top of the list, un-tick other sources if necessary. Click OK.

SCEP Updates from UNC File Shares

Choose Set paths, add the UNC path and OK.

Configure Definition Update UNC Paths

To confirm the clients are pointing to the right location and using the UNC share configured above, wait (or manually) update the client’s policy and browse to the following registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Signature Updates (or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Microsoft Antimalware\Signature Updates) and review DefinitionUpdateFileSharesSources.


SCCM 2012 – Failed to Resolve Selected Task Sequence Dependencies


When PXE booting and deploying a task sequence you receive the error “Failed to resolve selected task sequence dependencies” and no dependency or package IDs are displayed.


1. Press F8 when in the WinPE environment to open the command prompt – Click here if you have not enabled the command support console.
2. You can view the SMSTS.log file on the live system, or move it to another machine to interrogate. To open the SMSTS.log which is responsible for deployment and task sequence log events type notepad X:\Windows\Temp\SMSTS\SMSTS.log (the task sequence dependency check happens prior to any formatting of the HDD, hence the location of the log file). At this stage you can also plug in a USB drive and copy/save the log onto it.

Open Command Prompt in SCCM 2012 WinPE Environment

3. Open the log file with the Configuration Manager Trace Log Tool aka CMTrace.exe, this will make it a lot easier to view and find the offending errors. If you do not have CMTrace, you can grab it from the SCCM media under SMSSETUP\TOOLS. It’s a single executable so can be copied and moved around as necessary.

CMTrace SMSTS.log

4. Near the bottom of the log file you should observe similar errors:

Failed to find CCM_ApplicationCIAssignment object for AdvertID=”12003A”, ModelName=”ScopeId_59CA012F-1C99-45CD-9184/Application_64ff713e-87d1-40dc-8d24-16961ccff5bb

Failed to resolve selected task sequence dependencies. Code(0x80040104)

ThreadToResolveAndExecuteTaskSequence failed. Code(0x80040104)

The part we’re interested in is the second part of the ScopeId, in this case: Application_64ff713e-87d1-40dc-8d24-16961ccff5bb. To find out which application this refers to open the System Center 2012 configuration manager console. Browse to Software Library, Operating Systems, Task Sequences and select the required task sequence. At the bottom choose “References”, this will show you all applications assigned to the task sequence and their Object IDs. Match this up with the error found from the SMSTS.log.

Find ScopeIE from the SCCM Console

In my case the offending application was Sage Accounts 2014. Things to check:

  • Make sure the application has been distribution to the required distribution point(s).
  • Try removing it from the distribution point(s) and re-distributing.
  • If the above fails, simply remove the application from the task sequence and re-add it (this was my issue!).

SCCM 2012 SP1 – Enable Command Support Console in WinPE

Troubleshooting SCCM Operating System Deployments can be tough, to ease the pain you can enable the command support console for use within the Windows Preinstallation Environment. Doing so will give you access to the command prompt, the SMSTS.log and the ability to launch various other applications to aid in troubleshooting. I will show you how to enable the console, then give a couple of examples.

Enabling Command Support Console (F8)

1. Open the System Center Configuration Manager Console.
2. Browse to Software Library -> Operating Systems -> Boot Images and select the boot image you would like to add command support to.
3. Right Click the boot image and select properties.
4. Head to the Customization Tab and tick “Enable command support (testing only)”.

SCCM WinPE F8 to Enable Command Support Console

You will then be prompted with “You have made changes that require you to update distribution points with a new version of this package – Do you want ConfigMgr to update the distribution points now?”.

5. Click Yes.
6. Work will then be done on the Boot.wim, which will in turn be re-distributed. Current size of the boot.wim without any additional drivers added is around 160MB so distribution shouldn’t take too long- even with slow links. Next, next until the process is completed.

Once the updated boot.wim has been distributed, PXE boot into WinPE. You will now be able to access the command prompt by pressing F8.

Press F8 once booted into WinPE

Open the SMSTS.log

The SMSTS.log is the main log file for diagnosing OSD and Task Sequences client side. The location of this file changes through various steps of the task sequence.

WinPE Before HDD is formatted: x:\windows\temp\smstslog\smsts.log
WinPE After HDD is formatted: x:\smstslog\smsts.log
Windows, SCCM agent not installed: c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Windows, SCCM agent installed: c:\windows\system32\ccm\logs\Smstslog\smsts.log
Windows x64, SCCM agent installed: c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log

1. Press F8 when in the WinPE environment to open the command prompt.
2. You can view the SMSTS.log file on the live system, or move it to another machine to interrogate. To open the SMSTS.log type notepad X:\Windows\Temp\SMSTS\SMSTS.log (in this case this is the SMSTS.log prior to formatting the HDD). At this stage you can also plug in a USB drive and copy/save the log onto it.

Open Command Prompt in SCCM 2012 WinPE Environment

Taking a screenshot

It can be useful to have the ability to take screenshots from within WinPE. To do so, you can map a drive (or use a USB stick) and use a utility called nircmd.

Here we map a drive with net use j: \\server\share password /user:user then run nircmd from the mapped drive.

Savescreenshotwin will only capture the command prompt window, whereas savescreenshotfull will capture the entire environment (probably more useful).

Map drive in SCCM WinPE Command Console

Hopefully this post will have improved your ability to troubleshoot OSD and task sequence issues, and open up the possibility of running other applications (e.g. process monitor) from within WinPE.

SCCM 2012 – Creating Device Collections

Device collections in System Center 2012 Configuration Manager represent a logical container for a grouping of devices. These collections can then be used to perform a number of tasks, such as deploying software, compliance settings or task sequences. I’ve outlined 4 of the most common collection types below.

Device Collection based on OU

1. Browse to Assets and Compliance, right click on Device Collections and select “Create Device Collection”.

Create Device Collection

2. Give the collection a meaningful name, and set the limiting collection.

Give the collection a meaningful name

3. Add a Query Rule.

Select Query Rule

4. Edit Query Statement.

Edit Query Statement

5. Head to the criteria tab, and click on the new star item.

Select new query on the criteria tab

6. Click on Select, and set the attribute class to System Resource and attritube to System OU Name.

Enter the required criteria properties

7. Operator should be set to is equal to, click on values to choose the desired OU. It should read Domain/OU/ChildOU.

Attribute Class System Resources Attribute System OU Name

8. Next, Next through the rest of the wizard.

Rule is complete

9. The device collection has now been created.

Query Language

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.SystemOUName = "THESYSADMINS.LOCAL/LONDON/LAPTOPS"

Device Collection based on an Active Directory Security Group
Continue reading

SCCM 2012 – Allow End User to Run Application As Administrator

I’ve been spending a bit of time recently, working around various constraints of working in an environment where UAC is enabled and end users have no local administrative rights over their machines. This especially becomes a problem when applications are written badly, don’t provide any means to be packaged or simply touch the system in a way that needs administrative rights. Essentially, what I wanted to provide was the ability for an end user to run x app, as an administrator- be that a particular software update or simply a program that wants to set itself as the default PDF reader.

Scenario 1

We run Sage Accounts, and fairly often they’ll release a small update. This update is provided as an .exe, has no silent switches, requires administrative rights and prompts the user to confirm the path to update. I’ve spent a fair amount of time trying to dissect this installation, capturing the process with an MSI packager (2 actually) with no luck. I even brought out the big guns and watched the installation with Sysinternals Process monitor. It gets to the point where you’re essentially re-writing the entire update, and quite frankly it’s just a massive time drain… not only that but it becomes a much riskier process and requires more testing. “Did I get everything”.

Scenario 2

PDF readers. We run two flavours, and users are generally given the choice to which one they choose. Of course, changing the default programs associated with PDFs requires administrative access. So, we may get a support call that requires us to remote in, fire up the “other” applications with admin credentials, and set it as the default reader. This becomes an unnecessary interruption for both the end user and admin. You could go ahead and create a GPO that writes the required registry keys, but it’s a bit messy and again requires a fair bit of initial effort to configure.

Allowing users to launch applications with administrative rights

To make this possible, we’ll be using the Software Catalog provided with SCCM 2012. This application is automatically deployed as part of the agent, so shouldn’t require any additional work client side.

I’ll give you two examples, one running a local executable on a system and the second running an executable on a file share. When using this method, the executable is loaded with the “system” account.

Local Executable

Browse to Software Library -> Packages, right click and select create package.


Give the package a name, this is the title displayed in the software catalog, so you’ll want to make it user friendly!


This is a standard program.


The name field is tagged onto the package name, so append with run/setup/launch, whatever best describes the action. I’ve given the path and executable, and changed the run mode to run with administrative rights. You must tick “allow users to view and interact with the program installation” otherwise it’ll hide the application.


Here you can specify some additional options, it’s worth changing the estimated disk space, as this is displayed in software centre and I normally bring the run time down from 120 minutes to 15.


After this, next, next yourself through the end of the wizard. As this is running a local application there is nothing to distribute, you simply need to deploy the package to a device collection. This is a bit beyond the scope of this article, but I’ll look to write a post in the new future covering that.

Fire up the Software Catalog from the start menu and the package should be available for install.


“Installing” this package, will launch the application under the system account and allow the user to set as default (it prompts on launch). Obviously the users mapped drivers will not be present in this session, but when was the last time you opened a PDF viewer and opened the file from within?

There is a security risk when launching a full application this way, as the application is elevated a user could open other applications from within with elevated privileges. This method is more suited to allowing the end user to run scripts, or applications that do not allow the user to open applications from within.

Executable on UNC Path

The process is essentially the same, except you provide the UNC path for the startup folder. If this is going to be launched on multiple sites, I’d recommend you use something like DFS to replicate the installation files around your particular locations.


When this package is installed, it launches the accounts2013update2.exe under the system context and allows the users to confirm the update path and update the application. This particular application does not allow for any additional interaction bar allowing the user to confirm the update path, so the security concerns outlined above do not apply.

How Administering SCCM Feels…

SCCM 2012 – Stop “Your Computer is About to Restart”

So… I popped onto a server the other day to check something and I see this in the corner. Your computer is about to restart. xx:xx:xx remaining before your computer restarts automatically. Your computer must restart to complete the installation of applications and software updates.


Not good! It’s the middle of the day, on pretty much the busiest month of the year so I need to find a way to stop this. Dug around and couldn’t find any clean documented way of suppressing the reboot so had to get dirty.

I fired up Process Explorer with the long shot of finding the process that was counting down and automating the restart. Luckily I see SCNotification under CcmExec and kill it, the countdown and tray icon disappear and I go and make myself a coffee. Good job Tom…

As it happens the process just respawned and the countdown continued. In the end I had to kill the SCnotifications process and pause CcmExec, which worked.


CcmExec is now paused, so you will want to schedule a reboot. Expect to see a few of these in the event log until you do: