High CPU usage by the Sytem Process

Recently, we faced this situations where on Server2012 R2, the System process was causing high CPU. Around 40-60%.
Normally, it uses only 5%.

How do you troubleshoot?
Use Procmon.
Filter by Process Name like System. By default it is set to not include in the filter.

You will find that it is reading some files/folders in a loop. Delete those files.

Also, check you AV exclusions.

WMI error 0x8004106C smsprovider log

Symptoms: Sometimes, you get this error in SMS Provider log, in CM2012.
This is generally due to load on the server and WMI, during temporary processing of queries.

Resolution: This error can be fixed by increasing the quota values in __ProviderHostQuotaConfiguration WMI class.

Check out: http://blogs.technet.com/b/askperf/archive/2008/09/16/memory-and-handle-quotas-in-the-wmi-provider-service.aspx

Changing values of Memory perhost and Memory allhosts is enough.

Method is described here: http://babaus.azurewebsites.net/2015/08/14/wmi-fine-tuning-for-config-mgr/

Another way is to run this script:

$WMIProviderConfig = Get-WmiObject @WMIHT            
$WMIProviderConfig.MemoryPerHost = 1024MB            
try {            
  $WMIProviderConfig.Put() | Out-Null            
  Write-Verbose -Message "Successfully changed the WMI provider settings" -Verbose            
} catch {            
  Write-Warning "Failed to modify the WMI provider because $($_.Exception.Message)"            
}

 

SCCM2012 - Applications stuck in state "Installing"

Problem
Some Packages when started, or when there is Mandatory Deployment, start and get stuck in state - "Installing". Due to this other Deployments also have to wait.

They never complete. Even if SCCM client is repaired/reinstalled, the state remains.
Only solution is - Remove the Deployment for that computer.

Reason
It is caused because when the Deployment is running (usually TS Deployment), the machine rebooted before the SCCM agent can finish updating all the WMI classes, but after the actual advertisement is completed. Root/ccm/clientsdk:ccm_program class isn't updated

Resolution
You can delete the instance of the policy for the deployment with powershell:

foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter "ADV_AdvertisementID='<advertID>'"){$i.delete()}

Another script does same thing, and sets smstsmgr dependency to ccmexec/wmi

$ccmProgram = Get-WmiObject -Namespace ROOT\CCM\ClientSDK -Class CCM_Program | Where-Object {$_.EvaluationState –eq 14}
If ($ccmProgram -ne $null)
    {
        $ccmExecutionRequestEx = Get-WmiObject -Namespace ROOT\CCM\SoftMgmtAgent –Class CCM_ExecutionRequestEx | Where-Object {$_.RunningState -eq "NotifyExecution" -and $_.AdvertID -gt "" -and $_.ContentID -eq $ccmProgram.PackageID}
        If ($ccmExecutionRequestEx -ne $null)
            {
                $ccmExecutionRequestEx | Remove-WmiObject
                Start-Process sc.exe -ArgumentList "config smstsmgr depend= winmgmt/ccmexec" -Wait
                Restart-Service -Name CcmExec -Force
            }
     }

SCCM2012 - Applications stuck in "past due-will be retried"

Problem


Many times some Applications get stuck in the state - Past Due - Will be retried. This is seen in the Software Center-Installation Status.


Reason

This usually occurs for Deployment which have date in the past, and the status in CCM class is actually installed, but not updated.


Resolution

Simply changing the Deployment deadline time fixes this. There is also a script, which changes the times for all Deployments of past.


Syntax

.\IncrementCMDeploymentStartTime.ps1 –SiteCode <EnterYourSiteCode>

Code

Param(           
    [parameter(Mandatory=$true)]           
    $SiteCode
    )

Write-Host "SCCM 2012 SP1 Deadline Time Increment Script"
Write-Host "Version 1.0"
Write-Host "Parameters"
Write-Host "  SiteCode: "$SiteCode -ForegroundColor Green

function GetCMSiteConnection
{
  param ($siteCode)

  $CMModulePath = Join-Path -Path (Split-Path -Path "${Env:SMS_ADMIN_UI_PATH}" -ErrorAction Stop) -ChildPath "ConfigurationManager.psd1"
  Import-Module $CMModulePath -ErrorAction Stop
  $CMProvider = Get-PSDrive -PSProvider CMSite -Name $siteCode -ErrorAction Stop
  CD "$($CMProvider.SiteCode):\"
  return $CMProvider
}

#Main

#Connect to SCCM, must have SCCM Admin Console installed for this to work
#If this fails then connect with the console to the site you want to use, then open PowerShell from that console
$CM = GetCMSiteConnection -siteCode $SiteCode
Write-Host "Connected to:" $CM.SiteServer
Write-Host
Write-Host "---Updating Deployments---"

foreach ($Deployment in (Get-CMDeployment))
{
  if (($Deployment.EnforcementDeadline -lt (Get-Date).ToUniversalTime()) -and ($Deployment.EnforcementDeadline -ne $null))
  {
    Set-CMApplicationDeployment -Application (Get-CMApplication -Id $Deployment.CI_ID) -CollectionName $Deployment.CollectionName -DeadlineDate ($Deployment.EnforcementDeadline).AddMinutes(1) -DeadlineTime ($Deployment.EnforcementDeadline).AddMinutes(1)
    Write-Host "  "$Deployment.AssignmentID"CI Deadline Updated" -ForegroundColor Green
  }
  else
  {
    Write-Host "  "$Deployment.AssignmentID"CI Skipped, deadline time occurs in the future or not specified" -ForegroundColor Red
  }
}






Reference-https://blogs.msdn.microsoft.com/rslaten/2013/11/26/past-due-applications-not-installing-in-sccm-2012/

Windows restart / shutdown history

Problem

Many times we need to find find out the reasons for Shutdowns/Unexpected restarts of Servers/Workstations. These event are logged in Evenlog with specific EventIDs.

Solution

By checking the specific EventIds, we can find out the time/source of Shurdown/Restarts.
Open Eventvwr and go to System log.
Filter the System log for these EventIds:
6008(The previous system shutdown was unexpected)
1074(The process X has initiated the restart / shutdown of computer...)
1076(he reason supplied by user X for the last unexpected shutdown of this computer is: ....)

Related articles

http://serverfault.com/questions/702828/windows-server-restart-shutdown-history

Info - PXE Boot and DHCP communications

DHCP Guide

This document describes common scenarios for implementing DHCP in relation to PXE boot with particular focus on Configuration Manager.
Assumptions and audience

Audience must familiar with basic IP networking principles.

The background

In order for a client to perform a PXE boot, there must be a DHCP service available, this is not required to be a Microsoft DHCP service. Any DHCP server is good.
The following diagram shows a typical network setup

In this case the client and the server is on the same network, which is the simplest setup you will come across, normally the setup will be more advanced, but in order to explain the basics, we will start with this simple model.

The DHCP Process

During a normal DHCP process the following happens:

1. The client sends out a DHCP broadcast on the network
2. The broadcast is picked up by the server
3. The server replies with a broadcast containing the MAC address of the client and a suggested IP address
4. The client replies back to the server, indicating that it will use the provided address

The PXE Boot process

When a client initiates a PXE boot (often by pressing a key of selecting a particular boot option during start-up) the process changes a little bit:

1. The client sends out a DHCP broadcast on the network, with a flag stating that it needs to PXE boot
2. The broadcast is picked up by the server
3. The server replies with a broadcast containing the MAC address of the client and a suggested IP address
   1. If the server configuration has any information on how to PXE boot, this information is included in the reply to the client.
4. The client replies back to the server, indicating that it will use the provided address
5. The client then contacts the PXE boot server (is this case the same server) and requests the bootfile specified in the boot information sent back from the server
6. The file is loaded and launched.

PXE Configuration on the DHCP server

Traditionally the PXE configuration has been made on the DHCP by setting either server or scope options, typically Option 66 and 67 are used, option 66 specifies the server to contact, 67 is the name of the file to request.
Another method of providing the boot information is to have a service listen for the DHCP request coming from the client and then send an additional reply back to the client. This is commonly known as dynamic PXE boot.

PXE booting from Configuration Manager Distribution Point

Configuration Manager provides dynamic PXE boot using the WDS service (available in Windows Server)
A typical simple setup could look like the following

The PXE server is installed on the SCCM DP (the WDS service).
Now the boot process is as follows:

1. The client sends out a DHCP broadcast on the network, with a flag stating that it needs to PXE boot
2. The broadcast is picked up by the server
3. The server replies with a broadcast containing the MAC address of the client and a suggested IP address
4. The WDS service also replies back to the client with information on how to PXE boot
5. The client replies back to the server, indicating that it will use the provided address
6. The client then contacts the PXE boot server (is this case the SCCM DP server) and requests the bootfile specified in the boot information sent back from the server
7. The file is loaded and launched.

This method has the great advantage that it is dynamic and therefore it can send back information based on the type of client requesting a PXE boot, whereas a setup using options configured on the DHCP cannot.
Why is this important in this case?
A PXE boot on a BIOS based system is using one method, whereas UEFI based systems are using another, therefore the PXE server must be able to dynamically provide different information according to the client type.
Also note: For UEFI PXE boot to work correctly with SCCM DPs the underlying OS must be Windows Server 2012 R2 or later.

Additional scenarios

Given that a typical network setup today is a lot more complex than the examples given above I will go through some of these to illustrate how to successfully implement PXE boot in such environments

Multiple subnets

The common method of setting up networks today is to have multiple subnets connected by routers or switches providing router-like functionality.
A typical setup could look like the following:

In this setup the DHCP server is in one subnet, the SCCM DP in another and the client is connected to a third network.
Given that DHCP traffic is based primarily on broadcasts, and broadcasts are normally contained within a subnet (in order to control spamming of the network). As such DHCP and also PXE will not work in a setup like this.
The way to fix this is to implement IP Helpers.
IP Helpers is a function implemented in routers to allow broadcast traffic to pass between networks in a controlled manor. It is important to note that IP Helpers typically forwards a specific type of traffic to a specific target (IP address).
In the given example an IP Helper must forward DHPC requests from subnet 10.10.30.0 to 10.10.10.10 to allow the client to obtain an IP address from the DHCP server.
For PXE boot requests to be answered correctly by the SCCM DP server, an additional IP Helper must also forward the request to 10.10.20.10.
The resulting setup looks like this

Note that in the case where the DHCP Server and the SCCM DP is on the same subnet, there must still be two IP Helpers implemented as IP Helpers are directed to a specific IP Address.

Special cases: 1E Nomad with PXE Everywhere

In some scenarios special features like 1E Nomad and PXE Everywhere may be implemented, and that may change the way you should implement DHCP and PXE boot.
There are two typical setups for this approach.

Central DHCP Server

A typical setup for Nomad with PXE Everywhere would be like to following:

The DHCP Server is placed in a central location, and will provide DHCP addresses to clients, using an IP Helper. However, the PXE functionality is provided by local clients running the PXE Everywhere component. In this case there must not be an IP Helper that forwards the DHCP request to the SCCM DP, as we intend for PXE boot requests to be serviced locally. If the IP Helper was setup the client would attempt to contact the SCCM DP to PXE boot.
So but not having the additional IP Helper the DHCP request is forwarded only to the DHCP which provides an IP Address to the client, and the PXE Everywhere service will reply to the same DHCP request to provide PXE boot information.
For this to work successfully the DHCP Server should not provide any PXE information either dynamically or using static option as that will cause confusion for the client trying to PXE boot.

Local DHCP Server

In some Nomad scenarios there may not be a central DHCP server to provide IP addresses to clients. The can be done by the local router, maybe a SOHO (Small Office Home Office) router. These routers are typically not able to provide any PXE boot information, which in this case is a good thing. The client will follow the normal process to obtain an IP address and the PXE Everywhere service will reply to the DHCP with the required PXE Boot information.
The following shows a setup for this case:

Conclusion

• Never use DHCP options, BIOS and UEFI based devices require different replies from PXE Server
• In routed networks use IP Helpers to both the DHCP server and the PXE server
• Do not install DHCP and PXE service on the same server unless it REALLY makes sense
• It is safe to rely on local DHCP functionality but may require an IP Helper pointing to the PXE Server if this is not local
• Windows Server 2012 R2 or later is required for UEFI boot to work correctly

Page source: http://blog.coretech.dk/rja/dhcp-guide/

OnSearchComplete - Failed to end search job. Error = 0x80244010

Problem: In SCCM 2012 SP1 clients, you see this error in  wuahandler.log
Scan does not complete and patches dont install.

Also,
OnSearchComplete - Failed to end search job. Error = 0x80244010. 

Solution:
1.Check if the WSUS Pool is not stopped.
2. Delete the Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
3. Restart ccmexec

or,

reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /f
net stop wuauserv
net start wuauserv