Professor
ProfessorGot it to run without alteration. Have to figure out how to do so without human intervention to make this a usable script in our environment (100+ domains = 100+ accounts).
Based on Mike_Moniz 's findings, I made sure to use the account explicitly as entered in the "Logon as" section of the service. I'd been assuming that the script would use the collector's host's domain for the account, so had just entered the username (as the flag implies)... but it wanted the domain stated explicitly. domain\username format. I was running in powershell under the account being changed to make sure the collector would be able to make the necessary changes from "within the house." I'll most likely be stealing the script out of the agent/bin folder and altering it to run using tokens for user and pass from a propertySource script. Have it run once a day, add a test for domain admin membership and run the LM LP change code against it if it is still a domain admin. Skip it all if it is not... then add a property at the end indicating whether or not the account has DA in each client domain.
NeophyteJust a note because you mentioned using tokens for user and pass. What I found is I do not think the Password of the account is needed unless you are running the script against the collector. Password would be required to configure the service to log on as.
I updated the script so when I run it against Windows Servers that I am monitoring. For that I see no reason a password is needed for the account. I added a parameter called "isCollector" with a validate set "Yes", "No" to the script. Then a simple if statement (after adding parmeter it's now line 886) to the section commented ## FUNCTION FOR PART 4 ## PARENT FUNCTION.
So that would be line 887-956...and it only runs that code (the part that requires a password) if it is a collector. So If ($isCollector -eq "Yes").
let me know if you have questions or this doesn't make sense