Fix SCCM/MECM Devices showing as Unknown in Deployment Status

Date Created: Nov 19, 2022 (UTC)
Last Updated: Nov 19, 2022 (UTC)

The Problem

Devices are showing as Unknown under Deployment Status with a category of 'Client check passed/Active' when they should be showing Success. This is affecting the metrics being reporting for deployments.

Problem Identification

While performing health checks and verifying all the devices in my lab are patched, I found a problem. If I navigate to Software Library -> Software Updates -> Software Update Groups, it shows 100% compliance on all my SUG's. This is the correct metric and what I always check.



But when I navigate to Monitoring -> Deployments, some of my SUG's are not showing 100% compliance. For the ones that aren't at 100%, it is showing multiple devices in an Unknown State. Everything in this post is focused on the workstation SUG's, but the issue was also appearing on Application, Program and Baseline deployments.



If I check the status of the Unknown devices, it shows them with a category of 'Client check passed/Active', which means the client is Online and the last health check passed.



All of the Unknown devices that are showing 'Client check passed/Active' are working. I can deploy updates and software to them without issue, and they are reporting back metrics, just not on every deployment.


Troubleshooting Steps

The first thing I did was Run Summarization to see if the metrics would update. They didn't.

Then I checked the WUAHandler.log, ScanAgent.log and the UpdatesDeployment.log. There were no errors.

I thought maybe the state messages never made it back to the console. So I forced the client to resend all state messages using the following PowerShell commands

$UpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$UpdatesStore.RefreshServerComplianceState()

   Source: Description of state messaging in Configuration Manager

After running the script, the Unknown devices remained the same.

The next thing I did was to delete the Deployment and recreate it using the same exact settings. After doing that, all devices reported back to the console with Success and the status for the SUG was 100%

On another device, I reinstalled the SCCM/MECM Client via a client push. I checked 'Always install the client software' and 'Uninstall existing Configuration Manager client before the client is installed'. After reinstall, the device reported Success for all SUG's.

Based on the above, I determined the problem is with the machine policy or WMI since a new deployment on the same exact SUG worked, and a full client reinstall worked.

I ran the following commands on another machine that was showing as Unknown to force it to perform a full policy refresh on the next cycle by setting uFlags=0. I also had it run a Machine Policy Retrieval & Evaluation Cycle along with sending unsent state messages.

# Reset Policy
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "ResetPolicy" -Arguments @{ uFlags = [uint32]0}

# Machine Policy Assignments Request
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "TriggerSchedule" -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000021}'}

# Machine Policy Evaluation
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "TriggerSchedule" -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000022}'}

# Send Unsent State Message
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "TriggerSchedule" -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000111}'}
        

   Source: ResetPolicy Method in Class SMS_Client
   Source: TriggerSchedule Method in Class SMS_Client

After running the script, I ran a Software Updates Deployment Evaluation Cycle

Back in the SCCM/MECM console, the Unknown devices remained the same.

The last thing I did was completely purge all policies from the machine by running the same commands, but this time setting uFlags=1

# Reset Policy
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "ResetPolicy" -Arguments @{ uFlags = [uint32]1}

# Machine Policy Assignments Request
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "TriggerSchedule" -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000021}'}

# Machine Policy Evaluation
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "TriggerSchedule" -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000022}'}

# Send Unsent State Message
Invoke-CIMMethod -Namespace root\ccm -ClassName SMS_CLIENT -MethodName "TriggerSchedule" -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000111}'}

After the script finished, I checked the SCCM/MECM console and the device was no longer Unknown, and instead was reporting Success.

I decided to run the script to purge all policies on the rest of the devices that were Unknown. I waited an hour and when I checked, everything in Monitoring -> Deployments is now showing 100%



As per the link I supplied above for the ResetPolicy method, Microsoft states "Indiscriminate calling of this method could have adverse effects. For example, if you purge the existing policy (uFlags = 1) software distribution programs could be run more than once. If the request is for full policy (uFlags = 0), you could generate unnecessary network traffic."

Reinstalling the client should have the same effect as running ResetPolicy with uFlags = 1, so I don't see it as an issue. I mention it here so you are aware of the impact when running the script.

Note: During the entire troubleshooting process, after running a script, or making any change, I waited 30 minutes before checking the console to give the device enough time to send state messages. I also made sure to run a Summarization so the metrics would update.

Conclusion

There are three fixes for this problem

  1. Reinstall the SCCM/MECM Client
  2. Delete the Deployment and redeploy it using the same settings
  3. Purge all policies from the device

The choice is yours. Do what is best in your environment.

As always, test, test, test before running in production.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


Share this post:

Comments:

UserPic

G santhanakrishnan

11/20/2022 1:05:36 AM (UTC)

Very informative Thank you