SCCM Workstation Patching

·       Every month 2^nd Tuesday Microsoft will release the patches for operating systems and Microsoft products.

·       All patch details metadata will sync in WSUS. Then it will sync into SCCM via SUP.

·       Once the sync completed, we will create a Software update group based on our criteria (What are the OS and Microsoft products). Then we will download the patches.

·       Once the patches downloaded, we will distribute the Software update package to Distribution points.

·       We will raise the UAT change request for Monthly patching. Once the change approved, we will start the deployment on UAT device collection.

·       We will drop a mail to the respective counterparts from the client. Based on the feedback we will proceed with the production deployment.

·       For production deployment we will raise another set of change requests and once the change approved will start the deployment batch-wise.  And provide the patching compliance report.

SCCM Workstation Patching Issues:

We may experience 3 types of issues.

1.       WSUS sync Issues

2.       WSUS Scan Issues

3.       Update installation Issues

1. WSUS sync Issues:

WSUS (Metadata)                         SCCM PS

Logs:

1.       WSUSSynchmgr.log – Synchronisation status

2.       WCM.log – Configuration stats (WSUS server, SUP, and primary site)

3.       WSUSCtrl.log – WSUS and SUP Health

Checks:

1)      Internet connection in servers, WSUS account Permissions, proxy settings and firewall settings.

2)      In SCCM console daily we will monitor the WSUS_SYNC_MANAGER – component Healthy or not

3)      Port configuration – Update source permissions

4)      WWW and Update services running or not

5)      WSUS account should have Sysadmin role

6)      If we get http error 503, check Application pool in IIS is in running state or not and increase provide memory in the advance settings.

7)      If SUP installed in remote server check connectivity.

8)      If we use SSL – need to check certificates are active or expired

9)      Review IIS logs in c:\Inetpup\logfiles

 

 

2. WSUS Scan Issues: (End User Machine and PS)

SCCM clients must run a software updates compliance scan. We recommend that you allow enough time for clients to complete the scan and report compliance results so that you can review the compliance results and deploy only the updates that are required on the clients.

When Scan not happening for compliance client side.

Logs:

1.       WUAHandler.log

2.       WindowsUpdate.log

3.       Verify the LocationServices.log to which WSUS server machine connecting

Troubleshooting/Issues:

1.       Check Windows update service running or not

2.       Check machine for any pending reboot

3.       Stop Windows update service and rename “c:\Windows\Softwaredistribution” folder, then start the update service.

4.       Check you have active intranet connection

5.       Check Any proxy settings - on the client if any proxy settings configured

6.       Verify connectivity of client with WSUS server while scanning happened.

7.       Check Port configuration in client computer

Telnet (WSUSServername):8530

8.       No communication error ccmmessaging.log

9.       Finally, the maintenance window have more time than software update installation time.

 

3. Update installation Issues (End User Device side):

              Once any software update deployment happens below log files need to check.

Logs:

1.       PolicyAgent.log – Any new policies applied on device

2.       UpdateDeployment.log – Any applicable patches deployed on the device

3.       UpdateStore.log – Application installation status we can see in this log

4.       CAS.log – We can see download status of required patches

5.       UpdateHandler.log – We can see installation process of each patch

6.       RebootCoordinater.log – Any pending or required restart of the device.

Resetting SCCM Agent if patch installation fails

From time to time, a ticket will be created in regards to System Patches failing in an SCCM environment. To fix this, there are really only two major steps:

 

1.       Rename the C:\Windows\SoftwareDistribution folder to SoftwareDistribution.old (stop Windows Update service before renaming, then restart the service).

2.       Rename C:\Windows\System32\catroot2 to catroot2.old (stop the Cryptography service before renaming, then restart the service).

After this is done, run these actions from the configuration manager:

 

1.       Discovery Data Collection Cycle

2.       Software Updates Deployment Evaluation Cycle

3.       Software Updates Scan Cycle

The procedure above has taken care of the issue pretty reliably. If the updates still don’t install properly, you may have to download the specific updates and install them manually.

SCCM CLIENT INSTALLATION

                                            SCCM Client installation

Prerequisites for deploying clients to Windows computers
Prerequisites for computer clients

•Windows Installer version 3.1.4000.2435

•KB2552033 (Install these hotfix on-site servers that run Windows Server 2008 R2 when client push installation is enabled.)

•Microsoft Background Intelligent Transfer Service (BITS) version 2.5

•Microsoft Task Scheduler

•Windows Fire WALL [should be stopped]

•Microsoft Policy Platform 1.2.3514.0

•Windows Update Agent version 7.0.6000.363

•Microsoft Core XML Services (MSXML) version 6.20.5002 or later

•Microsoft Remote Differential Compression (RDC)

•Microsoft Visual C++ 2013 Redistributable version 12.0.21005.1

•Microsoft Visual C++ 2005 Redistributable version 8.0.50727.42

•Windows Imaging APIs 6.0.6001.18000

•Microsoft Silverlight 5.1.41212.0

•Microsoft .NET Framework version 4.5.2

•Microsoft SQL Server Compact 3.5 SP2 components

•Microsoft Windows Imaging Components

•Microsoft Intune PC software client

Prerequisites for  Configuration Manager dependencies

•Management point

•Distribution point

•Fall back status point

•Reporting services point

Client installation methods

1.Client push installation

2.Software update point-based installation

3.Group policy installation

4.Logon script installation

5.Manual installation

6.Microsoft Intune MDM installation

1. Client push installation

Client push installation dependencies :

•Client push installation accounts are must be a member of the local administrator's group on the destination computer.

•If you don't specify a client push installation account, the site server computer account is used.

•The computer must have been discovered by at least one Configuration Manager discovery method.

•The computer has an ADMIN$ share.

•Enable client push installation to assigned resources must be selected in the Client Push Installation Properties dialog box if you want to automatically push the Configuration Manager client to discovered resources.

•The client computer must be able to contact a distribution point or a management point to download the supporting files.

•Firewall is not blocking the SMB traffic

The ports used when you are doing a client push is

We must have the following security permissions to install the Configuration Manager client by using client push:

•To configure the Client Push Installation account: Modify and Read permission for the Site object.

•To use client push to install the client to collections, devices, and queries: Modify Resource and Read permission for the Collection object.

The Infrastructure Administrator security role includes the required permissions to manage client push installation.

Supported client platform: Windows

Advantages

•Can be used to install the client on a single computer, a collection of computers, or to the results from a query.

•Can be used to automatically install the client on all discovered computers.

•Automatically uses client installation properties defined on the Client tab in the Client Push Installation Properties dialog box.

Disadvantages

•Can cause high network traffic when pushing to large collections.

•Can only be used on computers that have been discovered by Configuration Manager.

•Can't be used to install clients in a workgroup.

•A client push installation account must be specified that has administrative rights to the intended client computer.

•Windows Firewalls must be configured with exceptions on client computers.

•You can't cancel client push installation. Configuration Manager tries to install the client on all discovered resources. It retries any failures for up to seven days.

Configuring the Client push for Site Process:

1.Open the System Center Configuration Manager console.

2.Click the Administration node, expand the Site Configuration node, and then click Sites.

3.Select the site you want to configure for automatic Client Push installations.

4.On the ribbon, click Settings, click Client Installation Settings, and then click Client Push Installation. This is a bit tricky to find, and is shown in Figure.

4. This will open the Client Push Installation Properties dialog box as shown in Figure

INSTALLING CLIENT VIA CLIENT PUSH IN A MACHINE

1. Click on Assets and Compliance, click on Devices, click on All Systems, right Click on one of the computers and click on Install Client (hold Ctrl and select multiple computers if you want to install it on more than one computer). 

2. On the Install Configuration Manager Client wizard click on Next. (SMSProv.log)

3.If you are pushing the configuration manager client to a domain controller machine click on Allow the client software to be installed on domain controllers. While configuring the client push installation If you have enabled the automatic installation of clients on domain controllers then the first option will not be available. Click on Install the client software from a specified site and click on Next.

4. After few minutes, in user machine, we see that ccmsetup.exe process is running in the task manager.

5. You can view the ccmsetup.log file on the domain controller to check the log messages and also to monitor the client installation process. (c:\windows\ccmsetup\logs)

 BACK END PROCESS CLIENT PUSH:

1.Once we run the client push installation from the console SMS Provider will create the “.ccr*” file for every system and this file store in ccr.inbox (“C:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box”)

2.CCR = Client configuration requests

3.CCM triggers and reads the ccr file and it will try to connect to client machines with help of Client Push Installation account.

4.Once connecte to the client machine CCM copies the client binary to c:\windows\ccmsetup folder in Client machine.

5.Finaly CCM start the CCMSetup.exe to start CPI.

6.CCMSetup.exe tries to contact MP and downloads the other required dependencies. Then CCMSetup.exe start the installation.

7.Once Installation done , the client installation service run with  name « SMS Agent Host »

SERVER:

Automatic Client Push installation:

1.SMS_AD_SYSTEM_DISCOVERY_AGENT –> adsysdis.log –> C:\Program Files\Microsoft Configuration anager\inboxes\auth\ddm.box\*.ddr  –> SMS_DISCOVERY_DATA_MANAGER –> ddm.log –> Primary site Database.

2.Once the system is discovered, *.ccr file will be created and placed under “C:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box”

3.SMS_CLIENT_CONFIG_MANAGER reads the *.ccr file and Process the installation.

4.Monitor the ccm.log file

Manual Client Push installation:

1.Right click on the machine in SCCM console and install client.

2.SMSProvider(SMSProv.log) creates a *.ccr file under “C:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box”

3.SMS_CLIENT_CONFIG_MANAGER reads the *.ccr file and Process the installation.

4.Monitor the ccm.log file

Ccm.log file:

•Connect to administrative share on client PC using Client Push installation account

•Copies the below client installation files to the client (\\CM-CLIENT\admin$\ccmsetup)

C:\Program Files\Microsoft Configuration Manager\bin\I386\MobileClient.tcf to client

C:\Program Files\Microsoft Configuration Manager\bin\I386\ccmsetup.exe” to the client.

Checking Client Health:-

Client:

1.Creates ccmsetup service for installation.

2.Looks into AD for MP details and MP provides the DP location based on client boundary group where it’s mapped.

3.Copies the client installation files from DP and install the ConfigMgr client.

4.Monitor ccmsetup.log file on the client machine (C:\Windows\ccmsetup).

Info:

•/MP switch used for ccmsetup.exe to check MP directly during the installation instead go for AD.

•SMSMP: switch used for Client.msi to check MP assignment after the installation complete.

ConfigMgr Client Registration:

Client:

1.Once ConfigMgr client is installed, ClientIDManagerStartup.log Creates and maintains the client SMS GUID and identifies tasks performed during client registration and assignment.

2.Client Registration request send to MP. You can find MP communication in ccmmessaging.log on client machine.

Server:

1.MP_RegistrationManager (MP_RegistrationManager.log, C:\Program Files\SMS_CCM\Logs) process the registration request from client and complete the validation.

2.MP_RegistrationManager writes the *.rdr file for client under “C:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box\regreq\” on the Site Server.

3.SMS_Discovery_DATA_MANAGER (ddm.log) process the *.rdr file and update into Primary database.