Im working on application for Windows Server 2008 R2 (.NET 3.5.1) that would work even after cold reboot, without requring someone to log on any account on the server.
Few words about application itself, it is written in c# application for registering employees work time at the company. Users (employees), have thier cards which are beeing scanned by barcode scanner, each scan means either "work started" or "work stopped", everything is serlialized into xml file which is later on modified and put into .csv but that doesn't matter.
Barcode scanner is working as a keyboard, so all codes are beeing "typed" like from a keyborad, to the PC. I made application read the keys despite the fact that console application is not in focus, or not visible at all.
What i need to do is to make that application work even after cold reboot, it has to be fully automatic.
So far i figured out 2 approaches to do it, one is to create a service which would keep another process alive (if its not working, just turn it on), i didin't have much luck with this one, i have already created service that launches another process for me, but the process is working differently, if i would run it myself, there is no communication with the process so i cannot even tell if its the right one.
Another one is to just put my app into registery /microsoft/windows/current version/run, and enable autologon for user with limited prividges. This actually could work but it is not perfect solution, because after all we do not want to have user logged in on server in company 24/7 right?
I know that most of you are way more experienced in programming than i am, so i would appriciate any solutions how to solve my problem
Lichoniespi
Your options depend on physical security of the system (whether passers-by can do much to it apart from scanning a barcode), but let us assume that it is an easily accessible desktop. In that case, you probably do not want a logged in user.
Use the service approach. You do NOT need a separate process for accessing the keyboard. Create a global hook of type WH_KEYBOARD_LL.
Declare your callback function like this and put it into place with SetWindowsHookEx.
I would use the first approach, create a service, and to comunicate with the running application i would be using a network socket or pipe. For the service be sure that you're using an existing user account (not System) and allow it to interact with the Desktop.
Related
I have a Windows Forms Application which runs on a server. I need this Application to always start automatically. Even if the Server just gets restartet and nobody logs into it the Application should run.
So the solutions with Registry don´t work here. I than read into Windows Services but it seems like I can´t start a WinForm Application with it.
Does anyone have an idea how I can achieve this automatic Start on Server startup?
The way we do things like that is that we create a Windows Service which runs without the need to have anyone logged in, and then if there is a need we have a separate GUI application (WinForms in your case) which interacts with the service, when needed.
The communication between the GUI application and the Windows Service is usually done by means of named pipes, but if you can get away with something simpler, like the GUI application saving a configuration file for the service to pick up, you might make it easier for you.
I have a kind of odd request- I have lots of users who run my application, and I need to be able to have the app know who is running it. This isn't a problem at all, and I am capturing this info just fine.
The trick is the application needs to access a network share that is restricted- none of the users running the app have permission to do anything there. And there's a lot of stuff going on there- reading files, writing, and since this is a WPF app, data binding to file URI's in that restricted area. To set ImageSource of an Image for example. In all different parts of the application, I need unrestricted access to that data.
I have been looking into the WindowsIdentity.Impersonation stuff, but it seems to be more targeted towards impersonating a user in a small context scope and then ending impersonation.. which is okay, but not convenient.
Is there a way to have my app start and then Impersonate a user within the app scope? So then I could do all the work with the correct permissions sets.
One approach that might work is to set up a Windows service on the users machine that can connect to the server with appropriate Active Directory account privileges. Your application would communicate with that Windows service rather than to the server directly. While this might literally do what you want, the implementation may be more involved than you care to mess with.
Here's what we'd like to achieve via a c# application. Is there a way this can be done, or is it impossible?
Block access to a website (say www.stackoverflow.com) between 11am and 2pm.
Also block access to MSN Messenger between the same hours.
Stop the blocking if the machine is rebooted.
What's confusing us is the exact point where the blocking belongs. The only possible solution we have at the moment is programatically altering the hosts file to block and unblock certain sites. This solution would fall down on a few points.
The user can manually change the hosts file back, which would be undesirable.
If the user had a browser open at 11am they would have to restart it to pick up the amended hosts file.
I'm a web developer so not entirely sure how this works, but I believe the c# app would have to be running as an administrator in order to edit the hosts file, which again would not be desirable.
To clarify, we're trying to produce something like macfreedom.com - so users's aren't going through a proxy or network that we control (unless the solution is to make the user's machine point to a proxy server but I doubt that's achievable or desirable). macfreedom.com appears to work by switching off the network adapter until reboot. We were hoping for a more subtle effect.
this should work like the most client firewalls ... a network filter driver dropping packets ... i fear you will have to use a kernel mode driver -> so .net seems to be out of the game ...
I have a Windows service which I want to periodically execute an external program. I'm currently doing this the usual way
Process program = Process.Start(#"C:\mpewatch\db_parameters\DBParameters.exe");
This doesn't seem to be working. I'm executing this from a separate thread which is started in my service's OnStart handler. Is there any conceptual problem with this? Is it not possible to execute external programs from a service like this?
You can execute external programs from a service, but there are security issues. For example, your service may be running under an account which does not have read access to the folder where the external program resides, even if your interactive account does have that access.
For test purposes, try to configure the service to run under your interactive account. If the program is invoked as expected, then the problem with the original account is that it does not have sufficient privileges to run the program.
Your question didn't indicate the operating system.
On Windows XP, you can configure your Windows service to interact with the desktop by opening the service control panel, double-clicking your service, selecting the Log On tab, configuring the service to run as local system, and checking the checkbox. It's pretty straightforward. You might try testing with something like Notepad.exe just to see if you can get it working.
On Vista (and presumably Windows 7), however, you may be out of luck. I have read that the ability for Windows services to interact with the desktop has been removed in Vista. I forget what the terminology is, but basically services will run in "shell 0," whereas users will occupy "shell 1". User applications will be able to communicate with services and vice versa using technology like WCF, but services will not be able to communicate directly with the desktop. For example, any error boxes that pop up will have to be dealt with by swapping to "shell 0." Again, this is based on something I read a few months ago, and I haven't gone looking at it again. For me, I've structured my Windows service to be configured using WCF via a front-end app.
I'm sorry I don't have a link for you, but if your service will eventually have to migrate to a newer OS (or you are already there), this is something to check on.
Another critical consideration with Windows Services is that there is no GUI. Technically, there is an option to allow the service to interact with a local GUI, but you will not see it. This is due to services running as the Local System user.
Within a service, any modal dialog box (OK, Cancel, etc) is considered an error.
I have been reading a lot about executing a GUI application from a Windows Service. The "Allow service to interact with desktop" check box worked for me when the Service runs as the SYSTEM user (I am using Windows XP).
Now I need the Service to run as a User defined in a domain (from the network). Everything works fine (even if no user is logged into the machine) but the GUIs are not shown (even if the same network user is logged in!).
I know that the GUIs are running, it's just that they are hidden. Why is that? Is there a way to show them if a user is logged on (like when created by the SYSTEM user and allowed interaction with desktop!) ?
if so, would it work if the user logged in is not the same as the one the service is running on?
Edit:
#casperOne: I see your solution, and it is the same that people (even you) have been posting around. In my case though, I am sure I am running on a secure environment and ONLY one user will be logged into a machine at a time. Isn't there anything one can do to simply unhide the GUIs? Why would this work with the user SYSTEM allowing interaction with desktop and not with another user?
Your approach is completely wrong, and will not work when deployed on Vista.
Services should NEVER assume a login session with a desktop to interact with.
Rather, you should have a second application which is run when the user logs in (or some other point in time) which communicates with the service and then displays UI elements when it receives notifications/responses from the service.
See this other question (and answers) for further information:
How to detect if a Window can be Shown?
Short answer: No, you can't do this
Long answer: Noooooo.
Basically, Microsoft are making changes to further prevent this. As casperOne stated, you'll need to separate your UI components away from the service.
And even on XP it didn't work on non domain joined machines (if you have multiple users using Fast User Switching the popups showed up on either the wrong desktop or no desktop at all).
As to why Microsoft changed this, do a quick search for "Shatter Attack" - by isolating service code from the desktop they completely cut off this entire family of security vulnerabilities.