Running a powershell script as a service but in the context of the currently logged on user
I have a question that may be more of a design/windows question, but I figure if anyone has resolved this issue it would be a scripter ;)
I'm having an issue with a particular powershell script. The script runs perfectly when I run the script as me (with admin rights) and with my test account (user rights). I want to run the script as a service, but when the script runs as a service, it of course runs under the system account which in turn causes part of the script to fail. Actually it doesn't really fail, it just does not do what I want it to do... here's an explaination of the script.
The script is deigned to run a check, and based on the result of the check, toggle registry settings between two different values. The script then pauses for a bit and then re-runs so it is essentially monitoring and adjusting settings on the fly. I believe the problem has to do with the registry keys the script is modifying which are all located in the HKCU hive. When the script runs under the currently logged on user, the keys are changed as designed. When the script runs under the system account, the script changes the keys in HKU/S-1-5-18 which is the System account profile, instead of HKCU.
I read up on some ways to impersonate users inside powershell but none of these seem to work (maybe I am not implementing them properly). I also tried calling external files (other ps files, bat, vb, etc) but I still run into the same issue.
Does anyone know a way to run a script as the curretly logged on user OR edit the HKCU keys with the system account (or other service account)?
Also, I've read that running a powershell script as a service is not a good idea, but no one said WHY. Can anyone fill me in on this one?
Answers (3)
Hi,
You can run a vb script to read the logged in users hives and do the required operation in service i.e system account.
I have posted a sample script on this forum for the same ,just have a look and check if its fits in your requirments
I'll give that a shot but have a feeling it will not work either. My powershell script already explicetly targets the HKCU keys but I think there is a built in satey feature of windows that redirects the changes to the HKU\{system account} keys when the script is run by the system account.
Thanks Sumitsingh1984! I didn't directly use any of your script but it did give me ideas which led me to more digging and an eventual solution. I now have a fully functioning powershell script :)
Here's how I resolved the issue and I was right, it was more of a design issue than anything else...
The script determines the logged on user, resolves their SID, and then (if conditions are met) makes the registry edits to HKU/{user SID}. This completely bypasses the need for the system account to impersonate the logged in user.
Just like Windows, there are several ways to accomplish each of the above steps. The trickiest was user lookup. When running the script as a service, some user look ups resolve to the logged on user while other still resolved to the system account. I had most of the script worked out when I found the final piece in a post by Paul Digby (Thanks Paul!!!): http://blogs.microsoft.co.il/blogs/scriptfanatic/archive/2010/05/16/quicktip-additional-powershell-registry-drives.aspx I wish I had found this post sooner, because his script does almost exactly the same thing as mine.