Troubleshooting Configuration Manager: Parsing client logs using Powershell and Configuration Items

Introduction

This particular post and topic, originates from me troubleshooting the Office 365 updating issue, where updating Office 365 through Configuration Manager failed and generated error 80070057.

The issue got some attention on both on reddit as well as on Twitter, as the issue on the affected devices, was breaking the ability to apply subsequent Office 365 updates.

The updates which introduced the said issue was quickly pulled, but some devices obviously managed to install the updates anyway.

So how do we fix that and how do we know which devices that are affected? This specific issue produced a specific error in some of the ConfigMgr Client Side Logs, so I came up with a solution involving Powershell and a Configuration Item.

Powershell

The script I’m using within Configuration Manager, is available on my GitHub page as well as down below: https://github.com/imabdk/Powershell

The script is available in 2 editions, as I prefer to strip the script for comments and whatnot, when using it with a Configuration Item. Another edition of the script with logging to the screen, for when testing manually, to more clearly see what’s happening.

The script does following in headlines

  • Create function for locating path to CCM Log Directory
  • Create function for parsing CM log files
  • Formats date and time to match local culture
  • Define how far back in the log the parsing is done
  • Parse the actual log, searching for the string provided in $errorReason
  • Return either COMPLIANT or NON-COMPLIANT

Configuration Manager

Configuration Item

Using the script with ConfigMgr and a Configuration Item is straightforward. Create a new Configuration Item in your ConfigMgr console, in the Assets and Compliance work space, in the Compliance Settings node.

For your convenience, here’s a few snippets of my CI taken directly from my production environment:

  • The CI is configured with a Powershell script (above Powershell script).

  • And the Compliance Rule to your CI is configured like below. This will make sure that, if the CI returns anything but COMPLIANT, the CI will signal noncompliance.

Configuration Baseline

The CI needs to be attached to a Configuration Baseline. Attach it to an existing CB or simply create a new CB.

Deployment

The Configuration Baseline is being deployed, and when done so, you have the option to Create New Collections based on this deployment. This is where I typically create 2 new collections respectively for Compliant and Non-compliant devices.

Now that the NON-COMPLIANT devices are gathered in a collection, this enables us to quickly deploy a fix or anything similar to the affected devices.

Again, below a snippet of the 2 collections, also taken directly from my production environment:

Resolving the Issue

Resolving the specific issue at hand, obviously involves locating the affected devices. When the Powershell script is run manually on a device affected by the issue, you will see the script correctly return NON-COMPLIANT.

In this scenario, because the CMBITSManager.log contains following errors, which translates into the issue I described in the introduction:

Solution

The only solution that worked for me in this scenario, considering that my Office 365 build was out of scope for the official fix to work, was to copy the entire ClickToRun folder from a working device, and copy that onto the affected device.

I did so with a simple batch script, also making sure to stop and start the ClickToRun (some files being locked if not doing this) service in the process.

ENJOY 🙂

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.