I have implemented a screen saver with and without screen locking capabilities on our domain to ALL endpoints, not including servers. This was a security issue that we were forced to do. Well now we need to do an audit to make sure PCs that needed to lock, are locking, or PCs that don't need to lock, are not locking, etc. I have written up a powershell script that looks at several registry keys, specifically located in "HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop". Powershell script works fine (tested numerous times manually on local PCs) exactly as needed. Based on what the script finds per Pc, it writes the PC name to a different but specific text file.
The issue I am having is I am getting a bunch of false positives when I execute the script via an AGENT PROCEDURE. I have built plenty of Powershell scripts in Kaseya and executed them using Kaseya, no problems. Scanning the registry with a .ps1 via Kaseya, I am somewhat new at. So I investigated several of these PCs that I know for sure are returning FALSE results, and looked through the registry on the local machine.....everything is set to what it's supposed to be. When I look at the PCs registry via Kaseya and Live Connect, I notice there isnt even a CONTROL PANEL subkey after the Windows registry key part, from the path I listed above. So the registry path does exist on the local machine, but through Kaseya it says it does not exist, therefore giving me a bunch of false positive results. Why doesn't Kaseya have the endpoints full registry info? And if Kaseya cannot do this, then what good is having the REGISTRY as a possible function in Kaseya?
From my experience of using Kaseya these past two years, yes it works okay on somethings, but most things are delayed, lag, and causes even more issues further down the road. Since our company is cheap, they went with Kaseya without even asking us (the IT department) what we want to use.
Looking at one specific endpoint that is giving me a FALSE POSITIVE RESULT form the Powershell script:
Manually accessing the registry on the PC, I see the following path available:
Looking at this same PC via Live Connect REGISTRY, I see path:
HKEY_CURRENT_USER\Software\Policies\Microsoft.......... NO WINDOWS SUBKEY AVAILABLE, therefore no superseding keys in registry to run the actual ps1 file against.
If Kaseya performs on the last scans on endpoints and the info in the current database, then what good is this? Why would you not be able to do a simple scan through an endpoints registry via Kaseya?
Perhaps this will help?
I'm betting the post that zippo references contains the cause. You have to remember that unless you have a logged in user (and run as that user in the agent procedure), or impersonate a user, or use credentials in an agent procedure, then your powershell is running as the system user, which is the same reason that you don't see what you expect in live connection. That is looking at HKEY_CURRENT_USER from the system user's perspective, not necessarily the logged in user.
Dealing with HKEY_Current_user hive is always problematic with Kaseya.
Your best bet would to be to have your agent procedure always check first to see if a user is logged in and if it is a 64 or 32 bit machine, then specifically use the executePowershellcommand64BitUser, or executePowershellCommand32BitUser commands in the agent procedures.
Otherwise you are running as system and will never get the data you are expecting.
Keep in mind also that this may not actually tell you want you really want to know either. Even when your powershell command works all it is really telling you is how the registry key is set specifically for the *exact* user that is currently logged on to the PC. So just because things are set exactly the way that you want when "Bob" is logged in, doesn't mean that it will be if "sally" logs into that exact same machine.
No I am running the script by IMPERSONATING USER, using my admin credentials, so that is not the issue. That's a rookie mistake and I believe I am beyond being a rookie lol.
Also to answer your last question, yes you are correct it is only looking at the CURRENT USER, ALTHOUGH we implement the GPO linked to PC accounts, so no matter what user is logged in, if I get positive results on user "Bob," I will have positive results on any other user that logs into this PC based on how our Group Policy has been implemented..
This is very interesting article. I think they make a point when they say:
"There are several ways to work around this the easiest is to make your script check if somebody is logged on and to run a Execute Shell Command or Execute File step with either the REG shell command or by importing a .reg file with the regedit.exe command."
So part of my script should be to pull the specific registry info out of the registry to a .txt file or something, and then later in the powershell script, run through that info in the .txt file instead of scanning the registry directly? Does that sound right?
I don't think anyone here cares if you are a rookie or not - we're just trying to give you the best help we can given the limited info you have shared with us.
Assuming that GPO is working perfectly may also be problematic. As Jonathon indicated, what bob see when he logs in may indeed be different than what sally sees. I have seen corrupted user profiles and many, many instances of GPOs not being applied to some users for a variety of reasons.
You probably already know this but here's what MS has to say about the HKCU hive:
That article seems to suggest that another possible avenue to explore might be obtaining the SID of the currently logged in user and then querying recursively HKEY_USERS\ SID of current user for the key/value pair you're after.
In any event, if you wish, post your procedure and ps1 file (edited of any vital info, of course) and give us a chance to do some testing and maybe we can be a bit more precise in assisting you to achieve your intended results.