Wednesday, December 6, 2017

SCCM Software Update - Job error 0x80004005 Failed to Add Update Source for WUAgent

SCCM Software Updates - Failed to Add Update Source for WUAgent 

Today I have been looking at a range of servers (Server 2008 /R2 2012 /R2) that were failing to communicate with the Software Update Point (SUP) in SCCM and retrieve deployment policy.

The UpdateDeployment.log was reporting the Job error 0x80004005
Job error (0x80004005) received for assignment ({af7a48e6-d550-4070-dd9b-ecc234567584}) action UpdatesDeploymentAgent 12/6/2017 10:32:27 AM 2096 (0x0830)

The WUAHandler.log  was reporting "Unable to read existing WUA Group Policy object" and "Failed to Add Update Source for WUAgent "

Unable to read existing WUA Group Policy object. Error = 0x80004005. WUAHandler 12/6/2017 3:41:00 AM 2828 (0x0B0C)Failed to Add Update Source for WUAgent of type (2) and id ({3AAB6A76-CE2D-4E8A-9F11-123AE69612A1}). Error = 0x80004005. WUAHandler 12/6/2017 11:03:31 AM 2276 (0x08E4)

Until the agent can report back to the SUP, SCCM will not be able to summarize Software Update status and offer the appropriate updates via Software Center. 

The resolution was to stop the "Windows update" service and remove the Registry.pol file and the comment.cmtx file if present as well as the SoftwareDistribution folder.

After restarting the "Windows update" service the SoftwareDistribution folder is created.
After the next SCCM "Update Deployment Cycle" the Registry.pol is created.

The WUAHandler.log will now state the scan completed successfully.

Waiting for 2 mins for Group Policy to notify of WUA policy change...Waiting for 30 secs for policy to take effect on WU Agent.
Added Update Source ({abc123abc123abc123abc123}) of content type: 2
Async searching of updates using WUAgent started.
Async searching completed.
Successfully completed scan
I have scripted the process to help others deploy a solution. If you think there is a better way to address this problem please leave a comment.

Friday, November 17, 2017

Windows 10 - UE-V Deployment Guide

Windows 10 - UE-V Deployment Guide

UE-V in Windows 10 is setup pretty quickly but the documentation for Group Policy and expected outcomes is all over the place.  In order to help other IT Pro's navigate their UE-V implementation I have documented my configuration with observations.

Folder and Executable Reference Table
Templates folder                    = C:\ProgramData\Microsoft\UEV\Templates
InboxTemplates folder           = C:\ProgramData\Microsoft\UEV\InboxTemplates
Scripts Folder                         = C:\ProgramData\Microsoft\UEV\Scripts
SettingsStoragePath                = Central UNC Share i.e \\ServerName\UEVData\%UserName%
SettingsTemplateCatalogPath = Central UNC Share i.e \\ServerName\UEVCatalogPath

UEVAppMonitor.exe                        = Scheduled Task "Monitor Application Settings"
ApplySettingsTemplateCatalog.exe = Scheduled Task "Template Auto Update"
Microsoft.Uev.SyncController.exe   = Scheduled Task "Sync Controller Application"

The UEV Templates folder is located within ProgramData folder and contains various sub-folders  containing scripts, Templates and compiled Templates (depending on the Windows 10 branch).

In 1607 there are two folders (InboxTemplates and Templates).  The InboxTemplates contains the standard Templates used to capture user configurations such as Themes, desktop settings, and MS applications.  The Template folder contains the Compiled settings files that
UEVAppMonitor.exe will monitor and Sync to the "SettingsStoragePath".

These Standard Templates can be registered individually or all at the same time via PowerShell. In 1709 there is the additional folder called "Scripts" containing the script RegisterInboxTemplates.ps1. See below for contents of script to register all Templates within the folder InboxTemplates.

# Enumerate the Inbox UE-V Templates and register those templates
$inboxTemplates= Get-ChildItem -Path $env:PROGRAMDATA\Microsoft\UEV\InboxTemplates -Filter *.xml
for ($count = 0; $count -lt $inboxTemplates.Count; $count++) {
    Register-UevTemplate -Path $inboxTemplates[$count].FullName -ErrorAction SilentlyContinue

Within the latest Group Policy templates (Administrative Templates (.admx) for Windows 10 Fall Creators Update (1709) ) There is the option to Enable UE-V and Auto-Register InboxTemplates. This led me to believe the Register-UEVTemplates script was not necessary and Group Policy would automatically register these InboxTemplates.  During testing this action was not occurring and I started to think there was a problem within my environment.  However, this options appears to be only available if you exclusively run domain controllers 2012/R2 and above. See Documentation here.

"Group Policy ADMX templates configure the synchronization settings for the UE-V service and enable the central management of common UE-V service configuration settings by using an existing Group Policy infrastructure.
Supported operating systems for the domain controller that deploys the Group Policy Objects include:
Windows Server 2012 and Windows Server 2012 R2"

If your environment is like mine with Domain Controller Functional Level 2008, there are several ways in which you can register these Templates automatically. An SCCM Baseline can be used to check for the compiled file/s and if non-compliant be resolved by remediation, i.e. Register-UevTemplate '\\SERVER\SHARE\UEV\Templates\*.xml'.

Alternatively you can copy all the InboxTemplates (C:\ProgramData\Microsoft\UEV\InboxTemplates) over to the UNC Share "SettingsTemplateCatalogPath"; then within group policy you can specify the Template Catalog path and tick the box to "Replace the Default Microsoft Templates". This will copy all the InboxTemplates (and Custom Templates) over to the Computer and register within the "Templates" folder as originally intended.

Windows Components/Microsoft User Experience Virtualization\Settings template catalog path

Once the UEV Service has started (Enable-UEV) the SettingsTemplateCatalogPath value will be evaluated every 30 minutes. New templates discovered are registered and compiled.

Once the Template has been registered and compiled to the "Templates folder" will be read by the process UEVAppMonitor.exe and detect all defined configuration changes. These changes are then copied to the "SettingsStoragePath" as a central location.  The copy occurs every time a users logs out of a computer or every 5 minutes by default.

If the "SettingsStoragePath" is not defined in Group Policy or manually by PowerShell the UE-V agent will read your Active Directory Home Folder path and set as default. The value can be changed via PowerShell or defined specifically within Group Policy to another UNC share location i.e. \\ServerName\UEVData\%UserName%.


We had an extra registry setting for UEV that could not be removed by the ADMX templates; this settings was possibly left over from a previous revision of ADMX and had to be removed via PowerShell. Technet procedure documented here.

Remove-GPRegistryValue -Name "GPO Name" -key "HKLM\Software\Policies\Microsoft\Windows\UEV\Agent

To configure the UE-V Agent by using Windows PowerShell

Scheduled Tasks 
Runs daily and will sync the TemplateCatalog directoy specified.

Monday, November 13, 2017

Windows 10 - Feature Upgrade using SCCM Servicing (13/06/2019 Updated)

Software Updates - Feature Upgrade - Windows 10

Software updates within an Enterprise organisation has been fairly straight forward until you attempt to use it for Feature Upgrades of Windows 10.  SCCM is very reliable at delivering the updates (Rollups, Updates, Upgrades) and as i have previously proved is UWF aware in Windows 10.
However, the Feature Upgrade does require a bit of prep work if you do not want the new Appx Applications installed as part of the Upgrade.

Moving between the 1507-1703 branches each Feature upgrade would reinstall the Appx Applications that you previously removed. Microsoft has addressed this in the 1703 - 1709 feature upgrade and if you removed an application it will not come back.  However, if the new branch has a new application this will get installed.

Uninstalled in-box apps no longer automatically reinstall
Starting with Windows 10, version 1703, in-box apps that were uninstalled by the user won't automatically reinstall as part of the feature update installation process.
Additionally, apps de-provisioned by admins on Windows 10, version 1703 machines will stay de-provisioned after future feature update installations. This will not apply to the update from Windows 10, version 1607 (or earlier) to version 1703.

 By using the SetupConfig.ini file for an OOBE after the Feature upgrade, you will be able to ensure unwanted Appx applications are not provisioned and made available to the user; in addition to any other post action script you need to run.

Location of the SetupConfig.ini
Before the Feature Upgrade is deployed/installed via Software Center the SetupConfig.ini must be created and place locally on the system. Place the SetupConfig.ini file in the WSUS directory below; the WSUS folder does not exist by default. The Feature upgrade via SCCM will look in the WSUS folder and read the SetupConfig.ini


Content of the SetupConfig.ini
In the ini file i have referenced the location of a file called "SetupComplete.cmd" that will be copied from this location to the hidden Feature Upgrade folder on the root of the C drive.  c:\$WINDOWS.~BT\Sources\Scripts\SetupComplete.cmd 


Within the Setupact.log you will see the /PostOOBE switch detailed with the contents of the SetupConfig.ini file appended to the Feature Upgrade Command Line used to run the Software update.

SCCM Software Update / Feature Upgrade Command Line 

[/PreDownload /Update /Quiet  /progressCLSID 71212340-ea4e-4e40-a0ee-a26312345baf /ReportId {A81239C5-8127-4352-1234-6CE01234531F}.200 "/ClientId" "fed1234-612d-40dd-123a-cd1234ee12d" "/CorrelationVector" "/oCGdL3nj012344.7.2"   /PostOOBE C:\ProgramData\OSConfig\setupcomplete.cmd]

Content of the SetupComplete.cmd
This command file calls several command lines for post Upgrade customization.

powershell.exe -executionpolicy bypass -file C:\ProgramData\OSConfig\Start\Set-StartLayout.ps1
powershell.exe -executionpolicy bypass -file C:\ProgramData\OSConfig\Background\Set-Background.ps1
MsiExec.exe /X {F14000BE-0001-6400-0000-074957833700} /qn

Here is the cool bit.  

The script below will create the SetupConfig.ini and SetupComplete.cmd files for you dynamically.  I use this in an SCCM Baseline to create and ensure they are upto date with my modifications.

In addition to the post custom scripts to set Background wallpapers and Start menu layouts I use the baseline to set 'Deprovisioned' regsitry keys so the Appx Applications are not provisioned for new users.

Example PowerShell command to create key. See Microsoft for additional details

New-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\Microsoft.Messaging_8wekyb3d8bbwe' -Force

I have scripted the process to create the keys using the PackageFamilyName. Remember do not Deprovision SystemApps otherwise you may experience issues with Applications you do want to use i.e. Photos.  See Microsoft for the different categories .  Makes reference to this his blog (Thanks).

Next Line

Thursday, September 21, 2017

Windows 10 Overlay for Unified Write Filter (UWF)

Windows 10 Overlay for Unified Write Filter (UWF)

This entry is to document my experience with the Windows 10 feature Unified Write Filter (UWF); with the intention to replace DeepFreeze on shared computers.

"Unified Write Filter (UWF) protects the contents of a volume by redirecting all write operations on that volume to the overlay, which is a virtual representation of the changes to the volume. Conceptually, an overlay is similar to a transparency overlay on an overhead projector. Any change that is made to the transparency overlay affects the projected picture as it is seen by the viewer. However, if the transparency overlay is removed, the underlying picture remains unchanged.
In a UWF protected system, UWF creates a single overlay, which contains information about writes to all protected volumes on a system. The overlay supports up to 16 terabytes of protected volumes."
(extract from

How to install the UWF feature ?

The Windows 10 feature can be installed in several ways; the offline Wim file via DISM, PowerShell, Manually via Control Panel GUI, Provisioning package or WMI. All methods are detailed here.

PowerShell Method
Enable-WindowsOptionalFeature -Online -FeatureName "Client-UnifiedWriteFilter" -All #NoRestart

SCCM and MDT Method
If you use the SCCM with the MDT this OS Feature can be enabled during the Task Sequence with the step "Install Roles and Features".

This can be taken further and applied to an MDT Database Role that is "Gathered" during the task sequence; far more dynamic and less steps/logic involved within the Task Sequence.

The ID for each Role and Feature can be found in the ServerManager.xml file located within the Microsoft Deployment Toolkit folder.
C:\Program Files\Microsoft Deployment Toolkit\Bin\ServerManager.xml)

Exactly like the PowerShell Feature name you will find the ID "Client-UnifiedWriteFilter" within this XML. This ID can be added to the MDT Database under the OS Roles> OSFeatures.  If you need to apply multiple Features simply separate the ID's with the use of commas. The end result will provision Windows 10 with the UWF feature installed.

NOTE: The UWF feature must be installed prior to the SCCM client being installed.
For Windows 10 computers that you plan to protect with Unified Write Filter (UWF), you must configure the device for UWF before you install the client. This enables Configuration Manager to install the client with a custom credential provider that locks out low-rights users from logging in to the device during maintenance mode.

How to Enable the UWF feature ?

After the Feature is installed and the computer rebooted there will be a utility called "uwfmgr" within the System32 folder. To enable the feature on the command line, call this utility with the following commands.

uwfmgr filter enable
uwfmgr volume protect c:

Through trial and error we have established a list of file, folder, and Registry Exclusions that should be exempt from UWF to maintain GPO, logs, and SCCM activity.

uwfmgr file add-exclusion "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft System Center"
uwfmgr file add-exclusion "c:\windows\ccm"
uwfmgr file add-exclusion "c:\windows\ccm\UserAffinityStore.sdf"
uwfmgr file add-exclusion "c:\windows\ccm\InventoryStore.sdf"
uwfmgr file add-exclusion "c:\windows\ccm\CcmStore.sdf"
uwfmgr file add-exclusion "c:\windows\ccm\StateMessageStore.sdf"
uwfmgr file add-exclusion "c:\windows\ccm\CertEnrollmentStore.sdf"
uwfmgr file add-exclusion "c:\windows\ccm\ServiceData"
uwfmgr file add-exclusion "c:\windows\ccmssetup"
uwfmgr file add-exclusion "c:\windows\ccmcache"
uwfmgr file add-exclusion "c:\_TaskSequence"
uwfmgr file add-exclusion "c:\windows\bootstat.dat"  This caused a Boot failure in Windows 1709
uwfmgr file add-exclusion "C:\Windows\wlansvc\Policies"
uwfmgr file add-exclusion "C:\ProgramData\Microsoft\wlansvc\Profiles\Interfaces"
uwfmgr file add-exclusion "C:\ProgramData\Microsoft\dot3svc\Profiles\Interfaces"
uwfmgr file add-exclusion "C:\Windows\dot2svc\Policies"
uwfmgr file add-exclusion "C:\Program Files\Windows Defender"
uwfmgr file add-exclusion "C:\ProgramFiles(X86)\Windows Defender"
uwfmgr file add-exclusion "C:\ProgramData\Microsoft\Windows Defender"
uwfmgr file add-exclusion "C:\Windows\WindowsUpdate.log"
uwfmgr file add-exclusion "C:\Windows\Temp\MpCmdRun.log"
uwfmgr file add-exclusion "C:\ProgramData\Microsoft\Windows Defender"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender"
uwfmgr file add-exclusion "c:\Windows\System32\Microsoft\Protect"
uwfmgr file add-exclusion "c:\ProgramData\Microsoft\Crypto"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\SMS\Certificates"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Antimalware"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\BITS\StateIndex"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\dot3svc"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\StateSystem"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WiredL2\GP_Policy"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Wireless\GPTWirelessPolicy"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Wlansvc"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WwanSvc"
uwfmgr registry add-exclusion "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\dot3svc"
uwfmgr file add-exclusion "C:\ProgramData\Microsoft\Network\Downloader"
uwfmgr file add-exclusion "c:\windows\System32\Winevt\Logs"

Source reference  for Exclusions

How to Service UWF enabled Windows 10 computers?

SCCM is UWF aware and when Software Updates are deployed the SCCM client will reboot the system with UWF disabled, and lockout the system to non admins.  Once the Updates are installed the system will reboot again enabling UWF.

The "Write Filter handling for Windows Embedded devices" when enabled will trigger the Client notification to restart with UWF disabled.

Update: 13/03/2018

After a while Windows 10 was producing security notifications for 'Disk Scan Errors'  and 'Firewall disabled' toast notifications.  I was able to suppress these toast notifications with Group Policy by setting the Key Windows.SystemToast.SecurityAndMaintenance\Enable = 0

reg add "HKEY_LOCAL_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Windows.SystemToast.SecurityAndMaintenance" /v Enable /t REG_DWORD /d 0 /f

Friday, August 25, 2017

Windows PE and Cisco ISE authentication 802.1x

Windows PE  and Cisco ISE authentication

This blog entry is intended to assist you when implementing a Cisco ISE next generation network across the organisation.  Without ISE profiles the SCCM Task Sequence will fail to connect to Distribution Points and the MDT database.  UNC paths are blocked and network access is restricted.
Cisco ISE by design will restrict network access to prevent unauthorized clients from simply plugging their equipment into the network and being routed like a authorised client.
Computer and User Authentication (explain in detailed section)
Cisco ISE profiles should be implemented in two ways; Cisco ISE profiles via Group Policy for domain joined systems, and to bake ISE profiles into the SCCM Boot Image.  The guide below will explain how to implement both configuration setups.

Tutorial - WinPE

Microsoft has detailed the two XML files required to achieve User Authentication when in WinPE here

Create an XML called "EthernetLANProfile.xml" containing the following. The Thumb Print detailed within <TrustedRootCA> should reflect a trusted Third Party Cert; This ISE certification should also be deployed to all Domain Joined systems for GPO ISE Profiles (see below Tutorial - OS)

<?xml version="1.0"?>
<!-- Sample LAN profile: EthernetLANProfile.xml" -->
<LANProfile xmlns="">
      <OneX xmlns="">
          <TrustedRootCA>1a 2b 3c 4d 56 78 90 aa bb cc dd ee ff 1a 2b 3c 4d 5e 6f</TrustedRootCA>

Create another XML file called "EAP_UserData.xml" containing the Service Account User Credentials.

<?xml version="1.0"?> <!-- Sample EAP user data: EAP_UserData.xml" --> <EapHostUserCredentials xmlns="" xmlns:eapCommon="" xmlns:baseEap=""> <EapMethod> <eapCommon:Type>25</eapCommon:Type> <eapCommon:AuthorId>0</eapCommon:AuthorId> </EapMethod> <Credentials xmlns:eapUser="" xmlns:xsi="" xmlns:baseEap="" xmlns:MsPeap="" xmlns:MsChapV2=""> <baseEap:Eap> <baseEap:Type>25</baseEap:Type> <MsPeap:EapType> <MsPeap:RoutingIdentity>onex\administrator</MsPeap:RoutingIdentity> <baseEap:Eap> <baseEap:Type>26</baseEap:Type> <MsChapV2:EapType> <MsChapV2:Username>SVC-Account-Name</MsChapV2:Username> <MsChapV2:Password>SVC-Account-password</MsChapV2:Password>
</MsChapV2:EapType> </baseEap:Eap> </MsPeap:EapType> </baseEap:Eap> </Credentials> </EapHostUserCredentials>

The SCCM Boot image will need to contain the WinPE-Dot3Svc Optional Component.  However, from my experience this component doesnt work in Windows 10 version 1607 or 1703.
The component wizard completes without errors however, the Dot3Svc cannot start in WinPE. Micrsoft have detailed the issue here

The component will need to be manually installed; download the KB4025632 MSU file from Windows Update Catalog- ##

The following two command will mount the Boot.wim Image and inject the Dot3Svc component.

Dism /Mount-Image /ImageFile:"C:\temp\WinPEx64\sources\boot.wim" /index:1 /MountDir:"C:\temp\WinPE_amd64-mount"

Dism /Add-Package /Image:"C:\temp\WinPE_amd64-mount" /PackagePath:"C:\temp\WinPEx64\windows10.0-kb4025632-x64_af86717e4eec306948b23cd1e82ff95640e51f5e.msu"

Before the Boot image is dismounted and copied to SCCM we also need to bake the ISE XML profiles into the Boot image.

Copy the EthernetLANProfile.xml & EAP_UserData.xml created earlier into the folder  "windows\system32"


Dism /Unmount-Image /MountDir:"C:\temp\WinPE_amd64-mount" /commit

After installing the component copy the wim to your Boot image source location.
Add a custom prestart command.  Open the Properties of the Boot image and go to the customization tab, enable the prestart command and type the following three commands (enable Dot3svc, import Ethernet Profile , import User Auth Profile"

cmd /c powershell -noninteractive -command net start dot3svc & cmd /c netsh lan add profile filename=%SYSTEMDRIVE%\windows\system32\EthernetLANProfile.xml interface=*  & cmd /c netsh lan set eapuserdata filename="%SYSTEMDRIVE%\windows\system32\EAP_UserData.xml" alluser=yes Interface=*

 Within the SCCM console update the distribution point to inject the SCCM binaries and distribute the WIM to your PXE enabled distribution Points.

Once the Boot image is loaded and you have typed your WinPE password (if present) the Prestart command will launch (Custom Hook).  WinPE will run the commands in the TSConfig.ini file located on the root of the X drive.

Before the list of Task Sequences (if available) are presented you will see a command window appear starting the dot3svc service and configure the User Authentication ISE profiles created earlier.

If you wanted to check that ISE is running before kicking off the Task Sequence then you can:-

Hit F8 for a command prompt (if enabled in the boot image)
 PowerShell -command Get-Service dot3svc 

You should see the service status as running

Running       dot3svc            Wired AutoConfig

Thursday, August 3, 2017

SCCM SUP WSUS Pool keeps stopping or the server is unresponsive

SCCM SUP WSUS Pool keeps stopping or the server is unresponsive

Scenario: Our WSUS/SUP had become unresponsive and the decision to reinstall the server role was made. After the Site server had been reinstalled  I became aware that Windows Defender updates were failing to update (3 days old) and even though the updates were sync'd, downloaded, and deployed in SCCM the client was still unable to receive them.

Client Log analysis:


ScanJob({999C9FFA-A463-4BE8-8771-67EE96D4140B}): CScanJob::OnScanComplete -Scan Failed with Error=0x80240440
ScanJob({999C9FFA-A463-4BE8-8771-67EE96D4140B}): CScanJobManager::OnScanComplete- failed at CScanJob::OnScanComplete with error=0x80240440

Update Deployment.log

Job error (0x80240440) received for assignment ({bf7a48e6-d220-4070-bb9b-ecc239107584}) action        UpdatesDeploymentAgent       
Updates will not be made available       


Async searching of updates using WUAgent started.       
Async searching completed.       
OnSearchComplete - Failed to end search job. Error = 0x8024401c.        
Scan failed with error = 0x8024401c.        
Its a WSUS Update Source type ({3AAB6A76-CE2D-4E8A-9F11-741AE69677A2}), adding it.        
OS Version is 6.3.9600   
Existing WUA Managed server was already set (, skipping Group Policy registration.        

Added Update Source ({3AAB6A76-CE2D-4E8A-9F11-741AE69677A2}) of content type: 2        


Report WARNING: CSerializationHelper:: InitSerialize failed : 0x80070002
AU        WARNING: Failed to get Wu Exemption info from NLM, assuming not exempt, error = 0x80070032
WS        WARNING: Nws Failure: errorCode=0x803d0006
WS        WARNING: Original error code: 0x80072ee2
WS        WARNING: There was an error communicating with the endpoint at ''.
WS        WARNING: There was an error receiving the HTTP reply.
WS        WARNING: The operation did not complete within the time allotted.
WS        WARNING: The operation timed out

Analysis Results:
Since I removed the role and put it back it was like the role had been installed for the first time.  Every client within SCCM (9k+) would need to do a Full Software Update & scan cycle. This would generate a heavy load on the ISS pool on the SUP server.  It is very important to configure the pool correctly otherwise the server will stop responding to clients as the client will receive "Service Unavailable" responses similar to DOS.

WSUS Pool Config
Queue Length: 25000
Limit (Percent) 70
Limit Action Throttle
Maximum workers (0 Numa) (1 Default) (2 if you have the server resource, not NUMA)
"Service Unavailable" Response TcpLevel
Failure Interval (Minutes) 30
Maximum Failures 60
Private Memory Limit (KB) 0

 Once we had the SUP role reinstalled synchronizing with SCCM (see WCM.log, Wsyncmgr.log) as well as the correct WSUS pool settings, we notice the server was still spiking CPU with ISS workers taking the full 70% limit without breaks.
Upon reviewing the Client Policy (within SCCM Client Settings) for the estate the "Software Update Scan schedule" was set to 1 day (not the recommended 7 days). This had the affect of overloading the WSUS server with 503 errors in the IIS log "service unavailable". As the schedule was every day the server could not get through the backlog before the whole process began again.
After setting the scan schedule to 7 days, and as clients were checking for policy every hour we notice a steady decline in CPU activity within the hour and all clients were able to complete there scan Software Update & scan cycle  and all clients were able to download Software updates.

Thursday, June 29, 2017

App-V 5X application not discovered. A supported App-V 5X client is not installed

SCCM Task Sequence with App-V application "A supported App-V 5X client is not installed"

Scenario: Windows 10 (1607) Task Sequence with various MSI and App-V applications. During an SCCM Task Sequence I am attempting to install an App-V application however, at the end of the build MSI installations have installed but App-V application has not been installed.


   Performing detection of app deployment type MathWorks_MATLAB-R2014a_8.3.0.532_001A - Download.....
+++ App-V 5X application not discovered. A supported App-V 5X client is not installed.

Resolution: With Windows 10, version 1607, the App-V client is installed automatically however, it needs to be enabled before you can installations App-V packaged within a Task Sequence.  This can be achieved by adding a command line to you Task Sequence to run Windows PowerShell command.

powershell -executionpolicy bypass -command Enable-Appv

Tuesday, June 20, 2017

Windows 10 Creates 4 New Folders

Scenario: On the root of the C drive you right click and select New "Folder".  Windows will then create 4 New folder i.e. New Folder, New Folder (2), New Folder (3), New Folder (4).  To delete or open these folders you need to elevate permissions on each one.

We have seen this issue only occur on Windows 10 systems applying Group Policy.

Cause: In our environment a specific Group policy was filtered to Windows 10 only.  Within this policy the following security setting was set to modify C: drive file permissions:

Computer> Policies> Windows Settings>File System

The policy specifically was allowing Administrators Full Control and Users Read and Execute permissions to "This Folder" only.  This had the affect of preventing sub-folders from  inheriting Administrator / Users permissions.

If this policy does not exist or is set to "This folder, Sub-folders, and files" then the additional Folders are not created.

I believe this issue is a bug in the way Windows attempt to create the folder and inherit permissions; by default the folder will inherit from above but with this policy in place it fails to inherit and tries 4 times before timing out.  Each attempt results in a restricted folder.

Friday, June 9, 2017

SCCM Unknown computer not able to see Task Sequences after installing Current Branch 1702

Soon after installing SCCM CB 1702 we were unable to see Task Sequences deployed to the unknown collection.

This issue was identified as a random system taking the GUID of the 'x64 Unknown Computer (x64 Unknown Computer)' record. As a result it was now a known GUID; as we were only deploying Task Sequences to the Unknown collection none were made available.

'x64 Unknown Computer (x64 Unknown Computer)' record
'x86 Unknown Computer (x86 Unknown Computer)' record

To get the GUID of your unknown systems open SQL management studio and run the following command:

--Sql Command to list the name and GUID for UnknownSystems record data
select ItemKey, Name0,SMS_Unique_Identifier0 from UnknownSystem_DISC

Using the returned GUID (SMS_Unique_Identifier0) we can find the hostname that has been assigned the 'x64 Unknown Computer (x64 Unknown Computer)' GUID by running the query below.

--x64 Unknown Computers
select Name0,SMS_Unique_Identifier0,Decommissioned0 from System_DISC where System_DISC.SMS_Unique_Identifier0 = '##Enter-GUID-Here##'

The query returned the hostname GUID and whether it is present within the SCCM database.  A '1' implies the record is deleted and will be purged from the database. We saw a '0' imply the opposite.

Deleting the 'x64 Unknown Computer (x64 Unknown Computer)' record and recreating the record through the steps below had limited success.  The issue was resolved until the new GUID created for 'x64 Unknown Computer (x64 Unknown Computer)' was used again.

delete from UnknownSystem_DISC where ItemKey in (##ItemKey##)

CreatedUnknownDDR      Change the entry to 0

Restart SMS Executive  this then recreates the Default x86 and x64 unknown collections

Microsoft has since release a Update Rollup KB4019926 which other sources were hailing as the fix.

After applying the Rollup we were still receiving reports of the Unknown GUID being assigned to systems.  It was identified that when a build used the "Previous" button within WinPe (after a dependancy failure or simply to refresh task sequence policy) the task sequence would take the Unknown GUID still.

What was not highlighted in the documentation for the Rollup was the requirement to either recreate or update distribution points with the current Boot Image and then if you use USB boot media recreate this.

Friday, March 24, 2017

Office 365 Update Restarts my Apps in SCCM

Office 365 Update Restarts my Apps in SCCM

Pushing Office 365 C2R updates through SCCM 1610 causes Office applications to close unexpectedly on client PCs

This is a known bug since the release of ConfigMgr CB 1610. and was resolved with Hotfix KB4010155 
  • After you start installation of Office updates from Software Center, users do not receive a notification message to exit all open Office 365 applications. This behavior occurs even with the forceappshutdown=False switch in the Configuration.xml file for Office 365.
Install all hotfixes

Wednesday, March 22, 2017

Dell E5450 Bricked after applying CCTK.exe command

Dell E5450 Bricked after applying CCTK.exe command

Dell E5450 with i3 Processors a CCTK.exe warning

We recently had our E5450 Latitude failing to post following a stand SCCM Window Task Sequence.  It was collected for diagnosis and motherboard swap out.  While no diagnosis was performed (pointless sending away) we was returned within a few days with a new motherboard.

Upon receiving it I cautiously rebuilt it with success with a cut down version of the task sequence; I have simply installed the Windows Image (WIM) and driver package.  Upon introducing additional steps to the SCCM task sequence I see a complete failure of the BIOS as previously experienced.

The failed post was the result of CCTK.EXE modifying BIOS settings.

We are using the latest version of CCTK 3.2 with the following commands; 

cctk --secureboot=enable --valsetuppwd=PASSWORD
cctk --wakeonlan=enable --valsetuppwd=PASSWORD
cctk --uefinwstack=enable --valsetuppwd=PASSWORD
cctk --embsataraid=ahci --valsetuppwd=PASSWORD
cctk --tpm=on --valsetuppwd=PASSWORD
cctk --tpmactivation=activate --valsetuppwd=PASSWORD
cctk --virtualization=enable --valsetuppwd=PASSWORD
cctk --vtfordirectio=on --valsetuppwd=PASSWORD
cctk --trustexecution=on --valsetuppwd=PASSWORD
cctk --autoon=disable --valsetuppwd=PASSWORD 

After analysis and discussion with Dell product groups they found that CCTK is forcefully arming TrustExecution in a way that conflicts the chain of trust. The basis of this is because the i3 CPUs within that unit model do not fully support Trust Execution which has been causing the NO POST via the CPU failure.

When this happens its driving the first measurement of the CPU to validate the signed module which isn’t supported (PCR 0 which holds the Core Root of Trust Measurement (CRTM). The issue was not replicated on any i5 or i7 systems we have in our lab.

Moving Forward; Dell recommend any units in a failed state have the motherboard replaced and to remove TrustExecution Command from your CCTK.ini 

Monday, March 20, 2017

Sharepoint documents will not open in Word/Excel

Sharepoint documents will not open in Word/Excel

Today I have been dealing with a very interesting Office 365 / SharePoint issue. It was reported that the Edit in Application button within SharePoint i.e. “Edit in Excel” “Edit in Word” is not working correctly and results in an empty Spreadsheet or empty Word document.

Viewing and Editing within the browser is fully functional and the behaviour varies depending on computers within specific OU in active directory.  It is worth noting at this point the estate consisted of Office 2013 ProPlus installations running on Windows 8.1.

The fact that identical systems with identical software versions patch to the same level, resulted in different behaviour could only mean Group Policy was different between them.

I was quickly able to find the offending policy; "Block signing into Office: Enabled". The screen shot above details a systems policy with the issue.

With the Standard Workstation GPO's the policy "Block signing into Office: Enabled" is not configured and Office applications can see the Sign-In option and can login to Office 365. 

Upon logging into a domain joined system Microsoft Office will login by default with the same account used to login to the computer.  If the account used to login to the computer ( i.e. SA_U1234567) is different from the account used to login to Office 365  (i.e. U1234567) the application Excel will fail to authenticate.  The Application will attempt to open the SharePoint URL intended for U1234567 and authenticate site/file; it will attempt to authenticate against the locally log on user ( i.e. SA_U1234567) who does not have permission and fail. 

For example the SA_U1234567 will need to have permissions to the resource U1234567 has selected within the Office 365 portal to "Edit in Excel". If the account SA_U1234567 does not have rights Excel will present, the user with the following Information message.  "Sorry, we couldn't open HTTPS://…../Document.XLS"

It will follow up with a Warning message explaining:
Microsoft Excel cannot access the file 'HTTPS://…../Document.XLS".  There are several possible reasons:

The message clearly explains that excel cannot access the file. Without an authenticated account the file will not be accessible; the first “possible reasons”, “The File name or path does not exist” is true from the perspective that Excel cannot find the file request.

If the account used to login to the computer is U1234567 and Office 365 /SharePoint is authenticated with the account U1234567 then the “Edit in Excel” will pass the MS-Excel Protocol a site URL that can be authenticated; resulting in success.

The Workstation that was unable to “Edit in Excel”  was applying the policy "Block signing into Office : Enabled". This configuration blocks the ability for the Microsoft Application to Sign-in; Excel was not able even attempting to authenticate against Office 365. 

Within Office 365/SharePoint when the button is clicked to "Edit in Excel" essentially the user is  initiating a hyperlink calling the protocol MS-Excel with the full URL to the resource.


In the case of the Workstation that was unable to “Edit in Excel” the protocol for ms-excel opens Excel (set through File Association) and the URL is ignored. As the Sign-In is block Excel does not even attempt to find the SharePoint site and the user simply see a blank Excel spreadsheet.  It is unfortunate that the User does not get a dialogue box explaining the Sign-In is block and is left to believe the operating failed. 

It is worth noting that If you are seeing the Information and Warning dialogue boxes your issue will most likely relate to Authentication and access to the resource.  If you are presented with an empty Excel or Word document then Policy is a root of investigation.

Thursday, January 19, 2017

Office 365 Management with System Center Configuration Manager – Current Branch 1606

This section describes the Office 365 application implemented.

1.1       Observations

The current estate contains a range of Office suite and standalone products (Standard, ProPlus, Outlook, Lync, Visio, and Project) as well as a range/mix of versions on each system; from 2007- 2016.

1.2       Application Deployment

An Office 365 application has been created in English.  Each application source directory is about 1.2GB in size and has been distributed to all corresponding DP’s.  Note: it is possible to install multiple languages of Office 365 on a single system however, the first installation will take ownership of the UI Shell i.e. Menus, drop –downs etc.

1.3       Office 2016 Deployment Tool for Click-to-Run

The source files for Office 365 can be downloaded via the Click-To-Run URL here. This will download and extract two files (setup.exe and Configuration.xml). A download.xml and install.xml can be extrapolated from the accompanied configuration.xml; see below.
“The Office 2016 Deployment Tool allows the administrator to customize and manage Office 2016 Click-to-Run deployments. This tool will help administrators to manage installations sources, product/language combinations, and deployment configuration options for Office Click-to-Run.”
Product IDs that are supported by the Office Deployment Tool for Click-to-Run 

1.4       Download.xml

The download.xml within the source files is kept as reference but is no longer required as part of the application deployment. A custom download.xml was created for the initial download. The Language tags (language IDs), and LCIDs available in Office 2016 can be found here
The command line to download content is: setup.exe /download download.xml
  <Add SourcePath="" OfficeClientEdition="32" >
   <Product ID="O365ProPlusRetail">
       <Language ID="en-us" />

1.5       Example.xml

The install.xml file within the source files controls the installation behaviour during the SCCM deployment i.e. language, product, logging etc. The Language tags (language IDs), and LCIDs available in Office 2016 can be found here
Microsoft 365 ProPlus 
The command line to install is: setup.exe /configure Installation.xml
 <Add OfficeClientEdition="32" Channel="Current" OfficeMgmtCOM="True">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
 <Updates Enabled="TRUE" />
<Display Level="None" AcceptEULA="TRUE" />
 <Logging Path="%Windir%\Temp\" />
 <Property Name="AUTOACTIVATE" Value="1" />

i.e. <Updates Enabled="TRUE" UpdatePath=”\\ServerName\Share$\ />

Microsoft Office Deployment Tool volume licensed editions of Visio 2016 and Project 2016 
The command line to install is: setup.exe /configure Installation_ProjectProXVolume.xml
 <Add OfficeClientEdition="32" Channel="Current" OfficeMgmtCOM="True">
  <Product ID="ProjectProXVolume">
      <Language ID="en-us" />
 <Updates Enabled="TRUE" />
 <Display Level="none" AcceptEULA="TRUE" />
 <Logging Path="%Windir%\Temp\" />
 <Property Name="AUTOACTIVATE" Value="1" />

The command line to install is: setup.exe /configure Installation_VisioProXVolume.xml
 <Add OfficeClientEdition="32" Channel="Current" OfficeMgmtCOM="True">
  <Product ID="VisioProXVolume">
      <Language ID="en-us" />
 <Updates Enabled="TRUE" />
 <Display Level="none" AcceptEULA="TRUE" />
 <Logging Path="%Windir%\Temp\" />
 <Property Name="AUTOACTIVATE" Value="1" />

SourcePath indicates the installation source path from which to install Office when you run the Office Deployment Tool in configure mode. If you do not specify SourcePath in configure mode, Setup will look in the current folder for the Office source files. If the Office source files are not found in the current folder, Setup will look on Office 365 for them. SourcePath indicates the location to save the Click-to-Run installation source when you run the Office Deployment Tool in download mode.
OfficeClientEdition specifies the edition of Click-to-Run for Office 365 product to use.
Product ID specifies the products to install. (Check here for a complete list of Product IDs that is supported by the Office Deployment Tool for Click-to-Run)
Language ID specifies which product languages to install. (Check here for a complete list of available Language IDs)
Updates Enabled=”TRUE” specifies that the Click-to-Run update system will check for updates.
UpdatePath specifies the path where Click-to-Run installations obtain updates. Optional. If UpdatePath is not set, Click-to-Run installations obtain updates from the Microsoft Click-to-Run source (Content Delivery Network or CDN). This is by default. If UpdatePath is set to empty (""), updates are obtained from the Microsoft Click-to-Run source, CDN.
UpdatePath can specify a network, local, or HTTP path of a Click-to-Run source. Environment variables can be used for network or local paths. If you use Group Policy with the Office 2016 or Office 2016 Administrative Template files (ADMX/ADML), you can set UpdatePath by using the Update Path policy setting. You can find this policy setting under Computer Configuration\Administrative Templates\Microsoft Office 2016 (Machine)\Updates.
OfficeMgmtCOM specifies that the client is managed and Updates are controlled from a central system; SCCM. This option effectively makes the UpdatePath option redundant.
Display Level=”None” specifies that the user sees no UI. No progress UI, completion screen, error dialog boxes, or first run automatic start UI are displayed.
AcceptEULA=”TRUE” specifies that user does not see a Microsoft Software License Terms dialog Box.
Logging Path specifies the path of the folder that is used for the log file. (Name is no longer a supported attribute to use for setting the name of the log file)

1.6       previous versions of Office

Update: 03/07/2018 - If using the latest Setup.exe you can make use of the switch <RemoveMSI All="True" /> and these Office Scrub scripts are note required.
Office 365 installation files will not automatically remove or upgrade previous versions; it is recommended to remove previous versions prior to deploying Office 365. Microsoft have provided uninstallation VBS scripts to remove all or selective Office products i.e. Standard, ProPlus, Outlook, Visio, Project, ALL etc.
The VBS scripts have been extracted from the MSI’s; the process is it run the MSI accepting the EULA and once the FixIt tool is ready (see the screen below) asking you click Next; open Windows Explorer to navigate to: C:\Users\%USERNAME%\AppData\Local\Temp\Fixit

Click on the hyperlinks below to direct you to the site in which you can download the MSI.

These scripts have been incorporated into the source files for Office 365 and can be called as follows:
cscript //B %~dp0Offscrub07.vbs ProPlus,Standard,Outlook /quiet /nocancel
cscript //B %~dp0Offscrub10.vbs ProPlus,Standard,Outlook /quiet /nocancel
cscript //B %~dp0OffScrub_O15msi.vbs All /quiet /nocancel
cscript //B %~dp0OffScrub_O16msi.vbs All /quiet /nocancel

1.7       Install.cmd

The Install CMD command calls a PowerShell script to provide the user with feedback during installation.
powershell -ExecutionPolicy Bypass .\AppDeploy.ps1
The AppDeploy.ps1 script is based on the “PowerShell App Deployment Toolkit”
The extract below highlights some of the key sections:
1.       Check to see if any of the applications are running and allow the User to defer the installation 3 times.
2.       Check and record whether the device has Visio and/or Project installed
3.       Remove all Previous versions of Office 2003-2016
4.       Install Office 365 ProPlus and Volume Licensed Click to Run versions of Visio and/or Project if previously installed.
If ($deploymentType -ne "uninstall") { $installPhase = "Pre-Installation"

 # Show Welcome Message, close Internet Explorer if required, allow up to 3 deferrals, and verify there is enough disk space to complete the install
 Show-InstallationWelcome -CloseApps "iexplore,PWConsole,excel,groove,onenote,infopath,onenote,outlook,mspub,powerpnt,winword,communicator,lync" -BlockExecution -AllowDefer -CloseAppsCountdown 600 -DeferTimes 3 -CheckDiskSpace

# Check whether anything might prevent us from running the cleanup
 If (($isServerOS -eq $true)) {
 Write-Log "Installation of components has been skipped as one of the following options are enabled. isServerOS: $isServerOS"

 # Display Pre-Install cleanup status
 Show-InstallationProgress "Performing Pre-Install cleanup. This may take some time. Please wait..."

# Remove any previous version of Office (if required)
 $officeExecutables = @("excel.exe", "groove.exe", "onenote.exe", "infopath.exe", "onenote.exe", "outlook.exe", "mspub.exe", "powerpnt.exe", "winword.exe", "winproj.exe", "Visio.exe")

 If (Test-Path (Join-Path $dirOffice "Office12\Visio.exe")) {$InstallVisio=$TrueWrite-Log "Office12\Visio.exe was detected. To be updated."}
 If (Test-Path (Join-Path $dirOffice "Office12\winproj.exe")) {$InstallProject=$TrueWrite-Log "Office12\winproj.exe was detected. To be updated."}
 If (Test-Path (Join-Path $dirOffice "Office14\Visio.exe")) {$InstallVisio=$TrueWrite-Log "Office14\Visio.exe was detected. To be updated."}
 If (Test-Path (Join-Path $dirOffice "Office14\winproj.exe")) {$InstallProject=$TrueWrite-Log "Office14\winproj.exe was detected. To be updated."}
 If (Test-Path (Join-Path $dirOffice "Office15\Visio.exe")) {$InstallVisio=$TrueWrite-Log "Office15\Visio.exe was detected. To be updated."}
 If (Test-Path (Join-Path $dirOffice "Office15\winproj.exe")) {$InstallProject=$TrueWrite-Log "Office15\winproj.exe was detected. To be updated."}
 If (Test-Path (Join-Path $dirOffice "Office16\Visio.exe")) {$InstallVisio=$TrueWrite-Log "Office16\Visio.exe was detected. To be updated."}
 If (Test-Path (Join-Path $dirOffice "Office16\winproj.exe")) {$InstallProject=$TrueWrite-Log "Office16\winproj.exe was detected. To be updated."}

 ForEach ($officeExecutable in $officeExecutables) {
 If (Test-Path (Join-Path $dirOffice "Office12\$officeExecutable")) {
 Write-Log "Microsoft Office 2007 was detected. Will be uninstalled."
 Execute-Process -FilePath "CScript.Exe" -Arguments "`"$dirSupportFiles\OffScrub07.vbs`" ALL /S /Q /NoCancel" -WindowStyle Hidden -IgnoreExitCodes "1,2,3"
 ForEach ($officeExecutable in $officeExecutables) {
 If (Test-Path (Join-Path $dirOffice "Office14\$officeExecutable")) {
 Write-Log "Microsoft Office 2010 was detected. Will be uninstalled."
 Execute-Process -FilePath "CScript.Exe" -Arguments "`"$dirSupportFiles\OffScrub10.vbs`" ALL /S /Q /NoCancel" -WindowStyle Hidden -IgnoreExitCodes "1,2,3"
 ForEach ($officeExecutable in $officeExecutables) {
 If (Test-Path (Join-Path $dirOffice "Office15\$officeExecutable")) {
 Write-Log "Microsoft Office 2013 was detected. Will be uninstalled."
 Execute-Process -FilePath "CScript.Exe" -Arguments "`"$dirSupportFiles\OffScrub_O15msi.vbs`" ALL /S /Q /NoCancel" -WindowStyle Hidden -IgnoreExitCodes "1,2,3"
  ForEach ($officeExecutable in $officeExecutables) {
 If (Test-Path (Join-Path $dirOffice "Office16\$officeExecutable")) {
 Write-Log "Microsoft Office 2013 was detected. Will be uninstalled."
 Execute-Process -FilePath "CScript.Exe" -Arguments "`"$dirSupportFiles\OffScrub_O16msi.vbs`" ALL /S /Q /NoCancel" -WindowStyle Hidden -IgnoreExitCodes "1,2,3"

$installPhase = "Installation"

# Installing Office 365 Pro Plus
 Show-InstallationProgress "Installing Office 365 Pro Plus. This may take some time. Please wait..."
 Execute-Process -FilePath "$dirFiles\Office365ProPlus\setup.exe" -Arguments " /configure `"$dirFiles\Office365ProPlus\Installation.xml`"" -WindowStyle Hidden -IgnoreExitCodes "3010"

 # Installing Office 365 volume licensed edition of Visio 2016
 If ($InstallVisio -eq $true) {
 Show-InstallationProgress "Installing Office 365 volume licensed edition of Visio 2016. This may take some time. Please wait..."
 Execute-Process -FilePath "$dirFiles\Office365ProPlus\setup.exe" -Arguments " /configure `"$dirFiles\Office365ProPlus\Installation_VisioProXVolume.xml`"" -WindowStyle Hidden -IgnoreExitCodes "3010"

 # Installing Office 365 volume licensed edition of Project 2016
  If ($InstallProject -eq $true) {
 Show-InstallationProgress "Installing Office 365 volume licensed edition of Project 2016. This may take some time. Please wait..."
 Execute-Process -FilePath "$dirFiles\Office365ProPlus\setup.exe" -Arguments " /configure `"$dirFiles\Office365ProPlus\Installation_ProjectProXVolume.xml`"" -WindowStyle Hidden -IgnoreExitCodes "3010"

2          updates for Office 365

Automatic updates is a servicing model built into Office 365 ProPlus, and provides the ability to be always up to date, or “evergreen”, with security and functionality enhancements. 
A default install of Office 365 ProPlus is configured to update automatically from the cloud.  Separately, each month a new build of Office 365 ProPlus is released in the cloud.  When a computer with Office 365 ProPlus detects that a new build is available, the difference – or delta – between the new build and the existing one is streamed down in the background.  Updates are then installed when Office apps/processes aren’t running. So, with the default configuration Office 365 ProPlus, you will always be up-to-date.
Some environments may prefer to use their existing software distribution tool to manage updates for Office 365 ProPlus, and this can be facilitated using the Office Deployment Tool.  IT Pros can customize the configuration by controlling if updates are managed. For example you can pass full management over to SCCM via the initial install.xml, via GPO or SCCM client policy. Office 365 ProPlus updates are provided by Windows Update and incorporated into SCCM Software updates Groups. 

The way that the users in your organization receive the updates for Office depends on where you've configured Office 365 ProPlus to get updates.
·         From the Internet   If you've configured your users to get updates directly from the Office Content Delivery Network (CDN) on the Internet.
o    If you don’t want these users to be updated automatically you can configure this either by using the Office Deployment Tool or by using Group Policy and the Update Path policy setting.
·         From SCCM /WSUS This will be the obvious choice for Enterprises as patching integrates into current processes.

Office 365 Management with System Center Configuration Manager – Current Branch 1602
Assumptions: SCCM CB 1606 has been installed with the SUP site system role installed successfully.

The default behaviour of the client will check for updates every time an Office 365 application is run.  Previously the administrator was unable to manage which branch the client would have installed using WSUS.  Thankfully this has been addressed; in the 1602 onwards current branch of Configuration Manager it is now possible to manage Office 365 updates natively without the clients going to either the Internet or a network share as described above. 
Within System Center Configuration Manager the ability to enable is very simple.  Select the Classification “Updates” and the Product “Office 365 Client”.  Then the next time Software updates Synchronize the current branch will be available to download and deploy as a normal Windows Update.

wsyncmgr.log extract The log will detail the selections made when it attempts to synchronize

Requested categories: Product=Office 365 Client, UpdateClassification=Updates

Office 365 Client Management
When Office 365 is initially installed it is possible to instruct the agent to use SCCM for updates.  The install XML can be set as below with the line (OfficeMgmtCOM="True") instructing the management of the client. 

  <Add OfficeClientEdition="32" Channel="Current" OfficeMgmtCOM="True" >
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
  <Updates Enabled="True"  />

Updating Existing Clients:

To change the management and update mechanism there two options available. The necessary settings (OfficeMgmtCOM) can be changed by modifying the registry, GPO, or via Client Policy.  The Office COM interface (OfficeMgmtCOM) will leverage BITS service to download updates from local distribution point.


The ADMX/ADML for Office 2016 Administrative Template files include the ability to enable the “Office 365 Client Management”. Once enabled, System Center Configuration Manager can manage the Office 365 client. 

The ADMX/ADML files can be downloaded here  and should be copied to your central store to be accessible from any GPO editor: %logonserver%\sysvol\%Domain.local%\Policies\PolicyDefinitions