Least Privilege not showing full list of Windows Services

You already found the section that is about the special privileges that are required to work with NT services.
If everything else is working apart from these, it is pretty likely you did a mistake while setting these ACLs.

However...
You can check if your user has sufficient privileges by starting a Powershell with that particular user on the target machine and see if you get output for following command:

Get-WmiObject -Class Win32_Service

Yes... we're also working on this on a fresh deployment and running into some barriers.  I've reached out to LM to see if we can be a guiness pig for this effort.

If you install other things after you've run the least priv script, you'll have to re-run the script to set the right permissions on the new services.

LM appear to have released an update for it recently (you'll find it in the LM install folder on your collectors).  The change is to the Security Descriptors that are used to set the permissions on SC Manager and Windows Services.  Before that change, we weren't getting full info on service (like PathName - crucial for identifying SQL instances).

We typically have the script pushed out via Group Policy so it re-runs regularly.  The script doesn't check that the correct permissions are already in place for SCManager and the Windows Services, so it applies duplicate permissions each time it runs.  We've had to write some code to this before the script makes any changes, so we don't end up with a lot of duplicates.  We've found it can get to the point where you can no longer make any further changes to SCManager/Service permissions as it hits a maximum security descriptor length.

In coding this check, I found that the SDDL that the script is using seems to be translated into something else by Windows when applied.  So, even when we put in a check to prevent it duplicating permissions, it still configured duplicates.  I found that we had to use different SSDLs for SCManager and for Windows Servers, so have had to modify the script a little to use different descriptors:

SSDL for SC Manager = CCLCRPRC
SSDL for Windows Services = CCLCRPLORC

What error are you getting when you try to use SDSet?  I've found it's usually due to trying to push a malformed security descriptor or, because of the duplicates created if re-running the script, because it can't accept any further updates.

what do you get if you run sc.exe sdshow SCMANAGER ?

If it's more than a couple of lines then you might have issues with duplicates as we did.

Agree with this not really being scalable for an MSP environment.  We've made quite a few modifications so that it can be reliably run (and re-run) via Group Policy without causing problems.  I think I'd probably get shot if I shared it, but happy to answer any questions if I can help.

Worth also mentioning that we use gMSA accounts, these do not work with the section of the script as the powershell is looking up "principle" data to get the SID. So, we manually added the SID into the command line. Everything else works as far as we can tell, its just windows service monitoring that is not.....which is the most critical for us right now. We have no visibility of service health other than using process monitoring.

Script for what its worth:

# Requires elevated privileges to run
Param (
    [Parameter(Mandatory)]
    [String]$SID  # Provide the SID to be appended
)

# Function to update service permissions
Function Set-ServicePermissions {
    Param(
        [String]$SID
    )

    # Get all services
    $services = Get-Service

    foreach ($service in $services) {
        Write-Host "[INFO]: Updating permissions for service: $($service.Name)" -ForegroundColor Cyan

        Try {
            # Get current security descriptor for the service
            $currentSDDL = & (Get-Command "$($env:SystemRoot)\System32\sc.exe") @("sdshow", $service.Name)

            # Append read access for the provided SID
            $newSDDL = $currentSDDL + "(A;;CCLCSWLOCRRC;;;" + $SID + ")"

            # Apply the updated security descriptor
            & (Get-Command "$($env:SystemRoot)\System32\sc.exe") @("sdset", $service.Name, $newSDDL)

            Write-Host "[INFO]: Successfully updated permissions for service: $($service.Name)" -ForegroundColor Green
        }
        Catch {
            Write-Host "[ERROR]: Failed to update permissions for service: $($service.Name). Error: $_" -ForegroundColor Red
        }
    }
}

# Call the function to apply permissions to all services
Set-ServicePermissions -SID $SID

C:\>sc sdset PRTGCoreService D:(A;;CCLCRPLORC;;;AU)
[SC] OpenSCManager FAILED 5:

Access is denied.

Key Differences in SDDL
PRTGCoreService does not have permissions for AU or AC, which might be why it cannot be queried via WMI.

ClipSVC has permissions for AU (LCRP), meaning Authenticated Users can query the service state.

Trying to fix the above gives is an error:

sc sdset PRTGCoreService D:(A;;CCLCRPLORC;;;AU) 

or

sc.exe sdset PRTGCoreService D:(A;;CCDCLCSWRPWPDTLOCRRC;;;SY)(A;;CCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;LCRP;;;AU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

[SC] OpenSCManager FAILED 5:

Access is denied.