Author: Jeremy Griffith

I recently ran into an issue when trying to use the Run Command Line step during a SCCM 2012 R2 SP1 task sequence on a VMware Virtual Machine.

A while back, I wrote a simple PowerShell script that will clear the cache on a SCCM client machine (I will post this script for your reference at the end of this blog).

I mostly used this script during a large Task Sequences (ie. during a build and capture task sequence that installs a lot of software), since the cache would fill completely and then fail the Task Sequences (it appears that SCCM will not override any items in cache during the task sequence). This never presented an issue since I always ran the script directly from the Distribution Point.

Update: I can confirm that this issue is fixed in Visual Studio with Update 1.

I recently ran into an issue where after pushing out new Visual Studio 2015 installs (with SCCM), new users could not log into those machines. When trying to log in with a new user, the following error occurs: “The User Profile Service failed the logon. User profile cannot be loaded.”

When looking at the Event Logs, I saw access denied errors related to failing to copy some files to the users new profile from C:\Users\Default. (This hidden default profile is what all new user profiles are based from.)

I recently ran into a problem where my Software Update point stopped working after performing a Site Recovery of my System Center Configuration Manager Site Server. In my scenario, I was performing a Site Recovery in order to upgrade my OS from Windows Server 2008 R2 to Windows Server 2012 R2 and SQL Server 2008 R2 to SQL 2014 SP1. After the upgrade was completed, all post-recovery steps were done, and all other functions were validated; I found my Software Updates were still not working. When checking Compliance on all updates, they simply reported back “Compliance Unknown”.

If you are running production load on an IIS server that is also running Windows Server 2016 and you are running Windows Defender/Endpoint Protection with Real-Time Protection enabled on this server; you may find that MsMpEng.exe (Windows Antimalware service) is taking a lot of CPU and causing IIS performance issues.

Because workgroup computers can’t read Active Directory, AD Integration should to be disabled on these systems. For some reason, the SCOM interactive agent setup will not allow the option “Use Management Group Information from Active Directory” to be disabled (it is grayed out). However, this setting can be disabled by installing the agent from the command line, or editing a registry key on an existing agent.

To disable during setup:
Install the SCOM agent with the following command line: MOMAgent.msi USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=“” MANAGEMENT_SERVER_DNS= /qb

To disable in the registry:
Open registry editor and nagivate to: “SYSTEM\CurrentControlSet\Services\HealthService\Parameters\ConnectorManager“.
Set the EnableADIntegration in the registry to ‘0′
Restart the HealthService (System Center Management)

If one of the above steps is not completed, you will see the following entry in your Operations Manager event log:

Log Name: Operations Manager
Source: HealthService
Date:
Event ID: 2010
Task Category: Health Service
Level: Error
Keywords: Classic
User: N/A
Computer:
Description:
The Health Service cannot connect to Active Directory to retrieve management group policy. The error is Unspecified error (0x80004005)

I ran into an issue when upgrading SCOM to 2012 (from 2007 R2 CU5). The installer stated that the upgrade was successful, but no activity was taking place in my management group. I had one error in my event logs (see below).