Tuesday, December 5, 2017

SystemCenterBlog.co.uk

All New posts are placed on:

http://www.SystemCenterBlog.co.uk

Monday, August 14, 2017

ScanAgent.log reports OnScanComplete with error=0x87d00692

ScanAgent.log reports OnScanComplete with error=0x87d00692


Scenario:

Clients are not receiving Software Updates for both Microsoft OS updates and Windows Defender.  The SCCM concole resports that the system does not summaries any required updates. We have a Group policy in place applying a specific update service location; this location is applied in several policies over several OU's. Only one policy when applied results in the error 0x87d00692.

ScanAgent.log

ScanJob({BAA53BE2-9FE1-48B6-89A7-0D60BC07ED50}): CScanJob::OnScanComplete -Scan Failed with Error=0x87d00692

ScanJob({BAA53BE2-9FE1-48B6-89A7-0D60BC07ED50}): CScanJobManager::OnScanComplete- failed at CScanJob::OnScanComplete with error=0x87d00692


Conclusion:
We have a Group policy in place applying a specific update service location; this location is applied in several policies over several OU's. The single policy that was resulting in  0x87d00692 has had the update service location removed and handed management over to the SCCM client. The error has been been removed from the log and the client updated almost instantly.

"Specify intranet Microsoft update service location"

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:

ScanAgent.log

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       

WUAHandler.log

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 (http://CMSUP.domain.co.uk:8530), skipping Group Policy registration.        

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

WindowsUpdate.log

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 'http://CMSUP.domain.co.uk:8530/ClientWebService/client.asmx'.
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


Conclusion
 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.


AppDiscovery.log

   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.


Resolution
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##)

HKLM\Software\Microsoft\SMS\Components\SMS_Discovery_Data_manager
Key:
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.
https://support.microsoft.com/en-us/help/4019926/update-rollup-for-system-center-configuration-manager-current-branch-v

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

https://support.microsoft.com/en-us/help/4010155/update-rollup-for-system-center-configuration-manager-current-branch-v 
  • 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.
Conclusion
Install all hotfixes
https://support.microsoft.com/help/4010155
https://support.microsoft.com/help/4016483