Patch Install failed with Error 0x800706BE

we can see the error 0x800706BE in “%Windir%\WindowsUpdate.log” also in the Updates deployment.log and patch install got failed on the server.

workaround :

we need to make sure RPC is started. Background Intelligent Transfer Service (BITS) and Windows Installer Service are dependent on Remote Procedure Call  service and if RemoteProcedure Call is not started BITS and Windows Installer will fail and eventually the updates are not installed.

Somehow RPC service was hung or temporary memory was not available and a server reboot helped to start the service or memory availability automatically and updates installed successfully.

SUS client rebooted the servers though the reboot is suppressed in SCCM deployment:

SUS client rebooted the servers though the reboot is suppressed in SCCM deployment:


In one of our client we had an issue that few servers ( Windows Core 2008 R2 servers) were rebooted on its own though the reboot is suppressed from SCCM deployment and strangely the reboot has happened on the next day around 3 AM after the reboot only the advertised patches were applied on it i.e. as per SCCM reports its installed on the scheduled date but as per the machines Status its installed on next day after reboot the patches were cached on the machine and it got installed after the reboot only.


Same group policy is applied to all other servers but the issue was happened on few servers.


Root cause:

The local machines Windows update agent is initiating the reboot, though the machines WUA is handled by SCCM it still communicated with the WSUS server and it requested for the updates.



This can occur if the Configuration Manager clients have Automatic Updates enabled for the Windows Update client.  If an update is delivered to a client that has Automatic Updates enabled, the Windows Update agent may ultimately manage the reboot of that client depending on the schedule used.  By default, the Windows Update agent schedules updates to be installed daily at 3:00am.

Solution Applied:

To resolve this issue disable the Automatic Updates policy on the Configuration Manager Client computers.  To do this, apply a Group Policy to disable Automatic Updates.  This setting is located in the following location:

Computer configuration>Administrative Templates>Windows Components> Windows update> Configure Automatic updates


Client   settings:

Note: This policy does not prevent the Windows Update service from functioning; it merely disables the Windows Update agent behavior described above. This will allow only the Configuration Manager Client to manage updates and thus the reboot schedule.

It is also recommended that you disable the Action Center so that the user will not be prompted to configure Automatic Updates.

The machines which are applied with the above policy – In the windows Update log after the resolution applied  it’s initiated the install exactly at the scheduled time (ccmexec- SCCM client) started the schedule and then the machines downloaded the updates once its downloaded the windows update handler initiated the install as per the below screen shot once the install completed it notified for the reboot.

SUS client rebooted the servers

System Center Configuration Manager Duplicate GUID for Clients

One of the most common (and painful) issues in SMS/SCCM is the presence of duplicate guids. Each and every SMS/SCCM client generates a unique identifier upon installation known as a GUID or Globally Unique Identifier. This is completely different than the SID of the machine in Active Directory and is used only by SMS/SCCM for managing clients. If two machines are reporting into the server with the same GUID, the server is no longer able to accurately target or report on these machines. As such, getting this issue resolved is critical to the successful operation of your environment.

The first step is to ensure this situation does not happen again or get worse while you are trying to rectify it. The single most common reason for this issue is when disk imaging is used to replicate computers from one machine to another. The critical change to your imaging/provisioning process that needs to be implemented is either:

A) The SMS/SCCM client should be removed from the source images before it is used to provision new machines.

B) If you wish you can leave the client on the image but prepare it for imaging using the methods below.

Depending on which client is on the source image (SMS or SCCM), you will want to use one of these methods:

For SMS 2003 please see: or to uninstall the client you can use ccmclean from the SMS 2003 toolkit #2 found here:

For SCCM 2007 please see: or simply remove the client completely by running ccmsetup /uninstall from the system32\ccmsetup folder on the imaging machine.

As for remediation of machines currently affected by this issue, here are the steps you can use.

1)    Identify the systems with a duplicate GUID

2)    Delete the c:\windows\smscfg.ini file from the client

3)    Run CCMDELCERT on the client (*)

4)    Restart the SMS Client agent (SMS Agent Host)

5)    A new GUID will be generated

(*)Ccmdelcert.exe wasn’t included in the System Center Configuration Manager 2007 Toolkit, but you can still use the version in the SMS2003 Toolkit 2.
You can download that here:

To maintain/review duplicate GUIDs going forward you should monitor the built in SCCM report called: Computers that may share the same SMS Unique ID each day as well as the membership of the duplicate guid collection you can create using the three queries below. Once both of these show 0 results, you will know that the issue is resolved but they should both still be monitored daily for any possible recurrence. (This collection should be updated several times per day (4-6) while we work this issue)

Query to find out the issue:

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 join SMS_G_System_System on SMS_R_System.ResourceID = SMS_G_System_System.ResourceID where SMS_R_System.Name <> SMS_G_System_System.Name

WQL query for h/w inventory report for a collection

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 ResourceId in (select SMS_R_System.ResourceID from SMS_R_System inner join SMS_G_System_WORKSTATION_STATUS on SMS_G_System_WORKSTATION_STATUS.ResourceID = SMS_R_System.ResourceId where DATEDIFF(dd,SMS_G_System_WORKSTATION_STATUS.LastHardwareScan,GetDate()) > 25) or ResourceId not in (select ResourceID from SMS_G_System_WORKSTATION_STATUS)

Computers with heartbeat timestamp

SELECT v_R_System.Netbios_Name0 AS Name, v_R_System.Client0,Min(A.AgentTime) as ‘Time Stamp’,
v_R_System.Operating_System_Name_and0 AS [AD Operating System]
v_FullCollectionMembership ON v_FullCollectionMembership.ResourceID =v_R_System.ResourceID
inner join v_AgentDiscoveries A ON A.ResourceId=dbo.v_R_System.ResourceID
WHERE (v_FullCollectionMembership.CollectionID = @CollectionID) and A.AgentName like ‘Heartbeat Discovery’

group by Netbios_Name0,Client0,AgentTime,
order by Netbios_Name0 desc

ConfigMgr 2012 Application Deployment

Problem with VSS when Backuping SCCM Site


SMS Writer status = STABLE.  $$<SMS_SITE_BACKUP><mar. sept. 28 12:53:22.356 2010 Romance Daylight Time><thread=10876 (0x2A7C)>
Starting to clean and prepare the backup location.   $$<SMS_SITE_BACKUP><mar. sept. 28 12:53:22.356 2010 Romance Daylight Time><thread=10876 (0x2A7C)>
Cleanup and/or preparation done.  $$<SMS_SITE_BACKUP><mar. sept. 28 12:53:22.356 2010 Romance Daylight Time><thread=10876 (0x2A7C)>
~Info: Sending message to start the SQL Backup…  $$<SMS_SITE_BACKUP><mar. sept. 28 12:53:22.356 2010 Romance Daylight Time><thread=10876 (0x2A7C)>
Starting to create the snapshot set.   $$<SMS_SITE_BACKUP><mar. sept. 28 12:53:22.388 2010 Romance Daylight Time><thread=10876 (0x2A7C)>
m_pBackupComponents->StartSnapshotSet(&m_SnapshotSetId) failed. Error code = 0x80 042 316.Error description = VSS_E_SNAPSHOT_SET_IN_PROGRESS.  $$<SMS_SITE_BACKUP><mar. sept. 28 12:53:22.388 2010 Romance Daylight Time><thread=10876 (0x2A7C)>
Error: CreateSnapshotSet failed…  $$<SMS_SITE_BACKUP><mar. sept. 28 12:53:22.388 2010 Romance Daylight Time><thread=10876 (0x2A7C)>


Root cause:

One of the site component was stuck at starting state which leads to the backup failure.

Solution applied:

1.Restarted vss and sql services no success.

2.manually killed the process for it and restarted the SMS component services no success.

3.As always a reboot did the trick and post reboot the state system component was started and backup completed successfully.

still the issue is not resolved its good to use the below hot-fix.