Modified PSService script to have some additional functionality

[omrsafetyo]

Change 1: Added $User and $Password parameters. Modified the installation routine to utilize the user Id and password provided when setting the RunAs account for the service.

Change 2: Sub folder called "functions" When using this framework in my own project, I found that I did not want to rely solely on this particular script for all of the logic of the application. So I created a sub-folder called "functions", and put my functions files in that folder. Modified the installation routine to scan this folder for any .ps1 files, and dot source them all.

Modified the uninstall routine to ensure that the directory is removed recursively, to include the functions directory.

[JFLarvoire]

Hi Nathan, Thanks for submitting this, but there are several issues that need to be addressed before I can merge it...

• I like the user and password parameters you've added during the setup stage. Several people have already asked for something like this. But I'm afraid that you've not finished the implementation: The $RunasAccount variable is commented out. And the things you mentioned in https://github.com/JFLarvoire/SysToolsLib/issues/7#issuecomment-347910930 are not there either. Yet I'm pretty sure that implementing something like that is necessary for the new paramenters to be usable, and the service to work fine, whether you configure a specific user or not. (Actually, for doing that, I prefer the variables proposed by @furt1v3ly in https://github.com/JFLarvoire/SysToolsLib/issues/7#issuecomment-294571471.) Anyway, I think there's still much work to do to make this ability to run as another user fully functional, and test it in all cases.
• On the other hand, I don't like the copying of other "function" files. This is very specific to your personal needs. Other people reusing the script may put it anywhere before running -Setup. And every file in subdirectories there would be copied along with the service. This is very dangerous. Please remove that for now.
• Finally, one minor annoyance: You're indenting blocks with tabs, instead of the 2 spaces used in the rest of the script. This breaks the code blocks alignment in my editor. I would have changed it myself, but I'd appreciate if you could do it beforehand if you submit an updated versions. Jean-François

[omrsafetyo]

Okay, apologize for being new to GitHub pull requests. I tried to sync my code up with the recent accepted merge requests, and realized it created more changes than I anticipated.

I reverted the changes and re-did them, making just the proposed changes.

I believe I have addressed your concerns - I've renamed the User and Password parameters to ServiceUser and ServicePassword.

I've completed the isSystem check. I didn't see where this was being used when I originally updated the code, so I wasn't sure it was neccessary - but now I see where it is being used.

Additionally, I have changed any tabs that I added to spaces.

[JFLarvoire]

I can't make it work with any user account except the LocalSystem account. Did you test it with other accounts? And if so, what should I do to make it work?

[JFLarvoire]

Answering part of my own question: The user must have the "Log on as a service" right. I'll add that information to the help screen.

[JFLarvoire]

I've played a lot with your code over the week end.

The first issue I had was the failure to start the service using my own account. First there was that problem about giving it the correct rights, as mentioned in my previous comment. This was purely a documentation problem, and I've added explanations in the help screen.

But there still was a problem with the way we had been detecting if the Start and Stop commands came from the user or from the Service Control Manager. The initial method I had used (relying on the user account detection) had become unusable, once it was possible to run the service on the same account as the user. None of the alternatives suggested by you, or earlier by others, could address that issue It took me a surprisingly long time to find the obvious solution: Use different options in the PSService.exe stub, when passing on the Start and Stop commands. I called them -SCMStart and -SCMStop. That change is simple, and gives a reliable code that works in all account combinations cases.

A second change I did was to rename your -ServiceUser and -ServicePassword arguments to the more standard names -UserName and -Password. I hope you'll forgive me for that. This required renaming the existing variable $userName to $currentUserName. Maybe it is because of that variable that you couldn't call the argument -UserName to begin with. Then, as entering a password on the command line is very convenient but considered unsafe, I added code to securely prompt for the password if the -UserName is specified, but not the -Password. Finally, as an alternative to entering the -UserName, I added the ability to pass the whole credential directly with a standard -Credential argument. That last change caused a minor problem with the old PowerShell version 2 on Windows XP: If you use -Setup with no -UserName or -Credential, PS complains about not knowing which parameter set to use. This is obviously a bug in PSv2, as the command completion does work. So I've documented that in the help, along with the obvious workaround, which is to use -Setup -UserName LocalSystem.

Anyway, I've pushed the updated script to the GitHub repository. It's working fine with the default LocalSystem account, and with my own account. There still is a problem with the LocalService and NetworkService accounts. The SCM seems to be perfectly happy about them, and reports success in all cases. Yet, even though the PSService.exe stub starts, the PSService.ps1 -Service instance does not. I don't know why. I've written in the help screen that theses accounts do not have enough privileges to run PowerShell, but this is just a speculation. I'm still hoping that somebody will find a solution for these two accounts, which are precisely the recommended ones to use for running services!