Remediating local administrators with proactive remediations

Like last week, this week is all about proactive remediations, a feature of Endpoint Analytics. As mentioned last week, proactive remediations are script packages that can detect common issues and remediate those issues if needed. All of that before the user even realizes that there is an issue. Those remediations can help with reducing support calls. The strength is that the remediations can be anything to address potential issues, as long as it can be addressed by using PowerShell. Each script package contains a detection script and a remediation script and that script package is deployed through Microsoft Intune. For deploying script packages, Microsoft Intune relies on the Intune Management Extension (IME).

To show the real power of proactive remediations, I’ll further develop the local administrators example of last week. Even in this modern world, local administrators are still a hot item. Last week the focus was on the detection part of proactive remediations and in this post I’ll focus on the remediation part of proactive remediations. I’ll start this post by constructing the remediation script, followed by creating the script package. I’ll end this post by verifying the results. Last week the focus for the results was locally on the device and in this post I’ll focus on the results in Microsoft Intune. This week I’ll skip the important requirements, as I’ve already documented them last week.

Constructing the remediation script

The first step is constructing the remediation script. That script should remediate the faulty configuration that was detected by the detection script. In this example, which is shown below, the remediation script is focused on a scenario in which the user of the device is a local administrator and should remain a local administrator. To fulfill that scenario the remediation script will remove all accounts, with exception of the default Administrator and the currently logged-on user, from the Administrators group. After removal of the accounts from the Administrators group, the script will add the correct accounts to the Administrators group. That will make sure that only the verified and correct accounts are members of the Administrators group and are configured on the local device. When the adjustment to the members of the Administrators group was successful, the script will return an exit code of 0 and when the adjustment to the members of the Administrators was a failure, the script will return an exit code of 1. The last line of output, before the exit code, will be displayed in the logs and can be useful information when verifying and troubleshooting the remediation script. Before using the script, make sure to adjust the array with administrator accounts to the correct list of administrators. That required adjustments is mentioned in the script example below.

[gist https://gist.github.com/pvanderwoude/3c68ad1a77632f8b9b8aab0c901a5ed7 /]

Note: Just like last week I’m relying on ADSI for making the required adjustments.

Creating the script package

The second step is creating the script package. The script package can be created by using the proactive remediations functionality of Endpoint Analytics. That functionality can be used to schedule scripts to detect specific configurations and when that configuration is faulty, it can run scripts to remediate the configuration. The following six steps walk through the process of creating a script package, with a detection script and a remediation script. That will create a script package to detect the currently configured accounts from the Administrators and to remediate any faulty configuration that is detected. That script package can be scheduled to either perform the detection and remediation only once, or on a recurring schedule. The latter will make sure that it can actually be used for creating some baseline configurations, which might sound familiar when previously, or still, using Configuration Manager. The idea is the same, just a bit more simplistic and easier to use.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Reports Endpoint analytics (Preview) > Proactive remediations to open the Endpoint analytics (Preview) | Proactive remediations blade
  2. On the Endpoint analytics (Preview) | Proactive remediations blade, click Create script package to open the Create custom script wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom script package
  • Description: (Optional) Provide a valid description for the custom script package
  • Publisher: Provide a valid publisher for the custom script package
  • Version: [Greyed out]
  1. On the Settings page, provide the following information and click Next
  • Detection script file: Select the previously week created detection script
  • Detection script: [Greyed out]
  • Remediation script file: Select the created remediation script
  • Remediation script: [Greyed out]
  • Run this script using the logged-on credentials: No
  • Enforce script signature check: No
  • Run script in 64-bit PowerShell: No

Important: This configuration will run these scripts with bypassing the execution policy. Together with the information of my previous post, this could enable an administrative user to edit the script before running (and without the script being checked before running).

  1. On the Assignments page, provide the following information and click Next
  • Assign to: Select the assigned group and when selecting multiple groups, multiple lines will appear with all separate schedule configurations
  • Schedule: Click on the three dots to open the schedule configuration. This enables the administrator to configure a recurrence frequency for the script package. This can be Once, Daily, or Hourly.
    • When selecting Once, a specific date and time should be configured
    • When selecting Daily, a frequency and daily time should be configured
    • When selecting Hourly, a frequency should be configured
  1. On the Review + create page, verify the information and click Create

Verifying the results

When verifying the results, in Microsoft Intune, the first place to look is the proactive remediations overview. That provides an overview of all the different script packages that are deployed within the organization. That overview provides an easy first method to monitor the detection and remediation results of all the different deployed script packages. That overview is shown below and is available via Reports > Endpoint analytics > Proactive remediations.

When more details are required about a specific script package, the script package overview is the best place to look. That provides an overview that is specifically related to the status of a specific script package. That overview provides a clear bar chart for the status of the detection and remediation script of the script package. Besides that it also shows a nice daily remediation trend. That daily trend provides an overview of how often that specific situation is remediated. That overview is shown below and is available via Reports > Endpoint analytics > Proactive remediations > [Specific script package] > Overview.

When even more details are required about a specific script package on a specific device, the script package device status overview is the best place to look. That provides a clear overview about status details of a script package on the different devices. That overview includes standard information about the device and the last sync time, but also includes useful information that was part of the output of the detection script. That overview is shown below and is available via Reports > Endpoint analytics > Proactive remediations > [Specific script package] > Device status.

More information

For more information about Endpoint Analytics and Proactive Remediations, refer to the following docs

11 thoughts on “Remediating local administrators with proactive remediations”

  1. Hello Peter,

    Thanks for Blog and sharing good information.

    I have deployed couple of script through proactive remediation which shows 2 entry for each device one is with Primary user UPN and second with No user account.

    Do you have idea why it is coming 2 entry for each device? how to over come this behaviour?

    Regards,
    Varsha

    Reply
  2. Wow this is fantastic! Thanks for posting. I have been looking for a script that would find the local administrator user ID (hopefully regardless of name) and rename to something like COM-EP-ADMIN. Is this something that you would be interested in demonstrating in an upcoming post?

    Reply
  3. Hello Peter,

    I hope you can assist. I am struggling to get his to work as expected. I am not an Intune or PowerShell Guru and rely on posts like these to make things work.

    I created the remediation with both your detection and remediation script. The script is assigned to a test group with one test user in the group. The test user is currently not in the administrators group.

    In the detection script, I have the following configured:

    #Define variables
    $localAdministrators = @()
    $memberCount = 0
    $numberLocalAdministrators = 4 #Adjust to your number of administrators (I have 4, 1default admin, the two S-1-12
    accounts and then the test user who should
    be an admin)

    if ($localAdministrators.Count -eq $numberLocalAdministrators) {
    foreach($localAdministrator in $localAdministrators) {
    switch ($localAdministrator) {
    #Adjust to your local administrators
    “Administrator” { $memberCount = $memberCount + 1; break; } – The default admin account is called
    Administrator (Disabled)
    “$currentUser” { $memberCount = $memberCount + 1; break; } – The test user
    “S-1-12-1-xxxx” { $memberCount = $memberCount + 1; break; } – xxx – to protect identity
    “S-1-12-1-xxx” { $memberCount = $memberCount + 1; break; } – xxx – to protect identity
    default {
    Write-Host “The found local administrators are no match”
    exit 1
    }

    The remediation script is almost untouched, apart from the S-1-12-xxxx accounts which were changed to my S-1-12 accounts and they are added successfully.

    #Define variables
    $currentUser = (Get-CimInstance Win32_ComputerSystem).Username -replace ‘.*\\’
    $localAdministrators = @(“S-1-12-xxx”,”S-1-12-xxx”) #Adjust to your local administrators – Not sure here if anything else
    needs to be added like the
    disabled Administrator
    account, etc.

    I ran the scripts locally first within PowerShell to test the results.
    The detection script output:
    The number of local administrators doesn’t match – This is correct.

    If I run the remediation script, I get this:
    Successfully removed S-1-12-xxx from Administrators group
    Successfully removed S-1-12-xxx from Administrators group
    Successfully added S-1-12-xxx to Administrators group
    Successfully added S-1-12-xxx to Administrators group
    Successfully remediated the local administrators.

    but it does not add the current user to the local administrator group.

    From scripts and remediations in endpoint central I get similar results. It detects the issue, incorrect number of admins, but the remediation script does not fix it or add the current user.

    Any advice would be greatly appreciated.

    tia
    Marlin

    Reply
      • Hi Peter,

        Thanks for the reply, really been struggling with this.
        I have it configured like this at the moment.
        $localAdministrators = @(“S-1-12-1-xxx”,”S-1-12-1-xxx”) #Adjust to your local administrators

        Should I add the Administrator and $currentUser to make up the total of 4 administrators?
        $localAdministrators = @(“S-1-12-1-xxx”,”S-1-12-1-xxx”,”Administrator”,”$currentUser”) #Adjust to your local administrators

        Regards,
        Marlin

        Reply
          • Hi Peter,

            I tried the remediation script now with $currentUser and get the following error.
            $localAdministrators = @(“S-1-12-1-xxx”,”S-1-12-1-xxx”,”Administrator”,”$currentUser”)

            Exception calling “Add” with “1” argument(s): “A member could not be added to or removed from the local group because the member does not exist. ” + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,remediate.ps1

            If I run it locally with elevated rights it works just fine, but via Intune Detections and remediation it gives the above error.

            Regards,
            Marlin

Leave a Reply to Peter van der Woude Cancel reply

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