Audit Local Administrators Group with SCCM - access denied


Followed the article https://www.itninja.com/blog/view/audit-local-administrator-group-with-sccm

When I run script locally it work fine, but if it is running from baseline it getting error access denied.


I don't know where can I look for more logs.

0 Comments   [ + ] Show comments

Answers (1)

Posted by: rileyz 9 months ago
Red Belt

Humm, hard to tell what is wrong.


Update the script for verbose, when the scripts runs from SCCM it should show the error in the above screen shot - I think.

$VerbosePreference = 'Continue' #SilentlyContinue|Continue

Next, delete the WMI class manually and then Evaluate the Compliance Item from the SCCM control panel.

  • We are trying to figure out if the script ran and populated WMI correctly.
  • If it populated WMI correctly, but you got the error above, then its something to do with SCCM detecting that it did not run correctly.
    SCCM is quirky on what it considers a successful run of a compliance item. In my setup it expects a 0 returns, if it detects anything else, even extra console output before the 0, it will marked it as failed.


  • Hi,

    First thank you for answer.
    I did all steps that You mentioned but I get nothing new.
    With verbose option on in the script, only list of accounts is written in log, nothing else.
    WMI class ins not populated.
    When I run script manually on PC in console show verbose output like this:

    PS C:\Windows\system32> D:\skrypty\localAdminSCCM.ps1
    VERBOSE: Clearing error variable.
    VERBOSE: Get members of Local Security Group 'Administratorzy'.
    VERBOSE: Get-LocalGroupMember ran OK, and didnt run into orphaned SID problems.
    VERBOSE: Report output to WMI which will report up to SCCM.
    VERBOSE: Creating LocalSecurityGroupInventory WMI class.....success
    VERBOSE: Writing Domain Admins instance to LocalSecurityGroupInventory class.....Success
    VERBOSE: Writing SCCM_Client_install instance to LocalSecurityGroupInventory class.....Success
    VERBOSE: Writing SEC-ADM # HD Account Control instance to LocalSecurityGroupInventory class.....Success
    VERBOSE: Writing SEC-ADM Admini Tier1 instance to LocalSecurityGroupInventory class.....Success
    VERBOSE: Writing 840 instance to LocalSecurityGroupInventory class.....Success
    VERBOSE: Writing asd instance to LocalSecurityGroupInventory class.....Success
    VERBOSE: Writing azadmin instance to LocalSecurityGroupInventory class.....Success
    VERBOSE: Report WMI entry to SCCM.
    VERBOSE: Found CCM Agent, performing Hardware Inventory.
    VERBOSE: Writing to file location 'c:\windows\logs'
    VERBOSE: Delete old log file if it exists.
    VERBOSE: Deleting Inventory-LocalAdministratorsGroup.log.....Success
    VERBOSE: Writing local admins to Inventory-LocalAdministratorsGroup.log.....Success
    VERBOSE: Display members Local Security Group 'Administratorzy'.
    PrimaryKey SID LocalSecurityGroup Domain User
    ---------- --- ------------------ ------ ----
    1 S-1-5-21-443245116-2925183723-4037825526-512 Administratorzy AZPL Domain Admins
    2 S-1-5-21-443245116-2925183723-4037825526-9535 Administratorzy AZPL SCCM_Client_install
    3 S-1-5-21-443245116-2925183723-4037825526-13600 Administratorzy AZPL SEC-ADM # HD Account Control
    4 S-1-5-21-443245116-2925183723-4037825526-13582 Administratorzy AZPL SEC-ADM Admini Tier1
    5 S-1-5-21-3634018766-283992249-1728233549-1001 Administratorzy BUILTIN 840
    6 S-1-5-21-3634018766-283992249-1728233549-1004 Administratorzy BUILTIN asd
    7 S-1-5-21-3634018766-283992249-1728233549-500 Administratorzy BUILTIN azadmin

    VERBOSE: Return true to SCCM, to notify compliance script ran OK.

    and WMI class is added.
    There are any errors in powershell event log, even after enable logging, based on article that You send.
    Do You know what permissions must have sccm to run this script properly? I have high security policies and I suppose to some of them can have impact to run powershell scripts . - jamot 9 months ago
    • >With verbose option on in the script, only list of accounts is written in log, nothing else.
      Was this written by SCCM running the script? or you running the script? I'm trying to figure if the script executed as SCCM (and wrote the log but not the WMI) with this question.

      By log, do you mean the script log output? Or do you mean log, as in the verbose output?

      Have you setup SCCM agent to run PowerShell scripts?
      https://social.technet.microsoft.com/Forums/en-US/951b8821-6540-4726-93d4-a65d4316b94c/bypassing-execution-policy-for-sccm-server-for-powershell-detection-method?forum=configmanagerapps - rileyz 9 months ago
      • Ok it is my fault I mixed everything.
        Verbose output is from manually run the script in powershell window, same as logs.
        When script is running from sccm (baseline) it won't work. Class is not added, no logs and I get error in sccm deployments (Access Denied).
        I setup powershell permission in administration client settings but it not helped.
        I don't know what can I do more :( - jamot 9 months ago
      • I wouldnt worry about my script at the moment.

        I would start looking into you SCCM setup and getting scripts and Compliance Items to run correctly. Create a new compliance item with a simple script, for example create a text file and append a line in the file with the timestamp every time the Compliance Item is run. With the this simple setup, you can start resolving the SCCM scripts issue.

        Once you have resolved the SCCM issue, you can try the local admin a script again. - rileyz 9 months ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

View more:


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ