I'm working on an application to start up the various servers and workstations in a system from one central server. As part of this, I need to log in to several workstations (currently running Windows 7) so that their startup applications can load.
I have tried running the startup applications remotely (using both a WMI approach and a scheduled tasks approach), but that has not resulted in the application fully initializing.
Does anyone have any suggestions on other angles I could try? Note that I cannot use PSExec on these systems.
UPDATE: To isolate the specific problem, is there a way to non-interactively remotely log in to a server as a specified user so that its startup applications execute as if the user just logged in on the workstation manually?
Related
I have created a Service in C# in which I am performing two tasks.
Task-1: Extracting Windows Event Logs.
Task-2: Sending the desired log (if present) to a Database that reside on another system.
If I run this Service under LocalSystem Account, it successfully performs Task-1 because its System related, but not Task-2 because LocalSystem Account does not have access to Network.
If I run this Service under NetworkService Account to access the Database on other Machine, it does not perform Task-1 because NetworkService Account has Limited access over System resources. Due to this, it is unable to extract Windows Event Logs.
I know that my code is correct because I have tested the whole code in Console Application and it performs both Tasks correctly.
I need the solution through which I can perform both Tasks through a Service.
"If I run this Service under LocalSystem Account, it successfully performs Task-1 because its System related, but not Task-2 because LocalSystem Account does not have access to Network."
This is not true. The LocalSystem account has access to everything on the system, as far as I know, including the ability to interact with the network. I can speak to this from personal experience because I've had a Windows service in the project I work on for almost a decade now, and it interacts with the network all the time. Check out the accepted answer here for more info.
It's very likely that an exception is occurring when your code is running from the Windows service, but does not occur when running from the Console app. Have you tried debugging your service? Have you checked the Windows event log for errors?
I have written a C# console application that uses the Interop.domino.dll assembly to interact with domino / notes to create, update and delete documents. The application runs successfully when running it manually through a cmd prompt or through Visual Studio. However, when we try to set the application up as a scheduled task (running under a domain service account) it fails with the following error:
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following
error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).
The error occurs as soon as we try to use an object from the Interop.domino.dll, specifically when try to create an instance of the NotesSession object as per the following:
ISession notesSession = new NotesSession();
After some investigation I found that the interop assembly requires a desktop to interact with and that if we ran the scheduled task with the service account logged into the machine that the scheduled was running on the scheduled task would run successfully. While logged in as the service account you could see that the application would bring up a svchost.exe window while the application was running and that is the reason it requires the desktop.
However, having the service account logged into the machine all the time is not an acceptable solution as it means that the account has to be logged in again each time the server restarts. There are also some security concerns around having about allowing a service account to login to machines.
So, I was wondering if anyone had any suggestions on how to get around this issue? Is there a way to suppress any UI that the assembly tries to show? Alternatively, can anyone suggest an alternate to a scheduled task which would achieve a similar result. What we need to do is:
Have the application run at a set interval (IE - once a day / once an hour)
Ideally, have it run under a domain service account (as opposed to a local system account)
Run without requiring the service account to be logged into the machine / UI elements from the Interop.domino.dll suppressed
We have thought about writing a similar application making use of the notes web services rather than the Interop assmebly and will go down that path if we can't get the console app running as a scheduled task. However, we would like to make use of what I have already written if possible.
Update 01/05/12
I have tried etting the NOTESNTSERVICE OS environment variable as per #dna-man solution. However, this did not solve the issue.
For now we have set the application up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account, but the application does work so we will go with this approach for now.
There was an answer that suggested this approach, but it seems to have been removed so I can't mark it as correct. I might leave the question open a bit to see if anyone else has any suggestions.
If your code is running on a Domino server you must make sure the OS environment variable NOTESNTSERVICE=1 is set. You can find out more abou this environment variable in the Lotus C API documentation, but it applies to the COM API as well when running as a service. I had created way back in 2003 a VB.NET application that had to run as a service, and setting this environment variable was the key. If it wasn't set, the service would stop working as soon as I logged off the machine. To make sure somebody didn't forget to set this environment variable when installing the service in the future I simply had my service manager start code set this environment variable directly on startup using the VB.NET call to SetEnvironmentVariable. It had to be set before creation of the Domino session object.
It's hard to say exactly why, but I believe it's failing to read the registry information for the Lotus interop classes. Obviously the entries are there, otherwise it would not work while running manually. So let's consider other possibilities.
I don't even know if this is possible, but os your application running as 32 bit when run manually, but 64 bit when scheduled? IBM doesn't support the Domino COM classes on Win64, and I'm pretty sure that the first symptom of that is that the registry l
A more mundane possibility is that the service account just doesn't have access to read the registry entries for the Notes/Domino install on the machine, possibly because the software was installed under a specific user account.
I ended up modifying the application slightly to set it up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account. However, this approach does allow the application to run without requiring an account to always be logged in and does allow for the interop UI elements to be shown (thus avoiding the error).
To schedule the windows service to perform the task at a set interval (which I set at once a day) I used the Timer solution proposed here.
I read some topics here, but I haven't found the solution of my problem.
I wrote application(C#, WPF, EF, sql server compact) that should start at windows startup. I tried to achieve that in two ways:
Add entry to windows register. Unfortunately that wasn't work on Windows 7. I found here that adding a shortcut to Startup folder can solve my problem...
I've added shortcut to my application in Startup folder. Unfortunately again it is not working...
My application is starting with admin permissions because is using external dll's sql server compact. Maybe this is reason? In addition my application is not signed and probably will not be. Also writing a wcf service could be bad idea in my application.
Do you have any suggestions, or solutions for that problem?
It's against windows guidelines ( and enforced by the operating system ) to put a program that requires UAC elevation in the startup process. It's a horrible user experience to be prompted for elevation every time they logon to a computer.
I would factor the wcf / sql into a service and keep the client side UI elevation free.
Reference: Error message when you start a Windows Vista-based computer: "Windows has blocked some startup programs"
The solution for that problem was to make user to install sql server compact on his own computer instead of embeding it in application folder and change permissions for application to asInvoker from admin.
Are there situations that we should use a windows service ?
I am building a client-server project (c#) and the server supposed to work alone without any user so someone advised me to use a windows service to run the server, is this right ? or there are a better solutions ?
Windows services are normally used when an application needs to continuously run. For example if they need to:
Wait for incoming requests. (Like through remoting or wcf)
Monitor a queue, file system etc.
If a program just needs to run periodically, like once a day. It is normally easier to create a scheduled task.
In your situation I would use a service for the following reasons:
You don't need to have a session running. This is good for security, and also reduces overhead on the server.
You get some of the managment commands built in for free
Start
Stop
Pause
Continue
You can handle server events such as shutdown.
Windows service can start running as soon as the machine is powered up, which makes ideal for running as a server, http server for example. No one is required to login.
You should create a Windows Service to run code in the background, without user interaction.
For example, a Windows Service will run even if no-one is logged on.
Any server that accepts connections (such as a mail, web, or FTP server) should usually be a Windows Service.
Well, a Windows Service provides a full framework for your application to work and to remain active while you want it to, so I think its ok.
Windows services are the right thing to use for something that should run all of the time, whether or not a user is logged in.
If you need something to run without an active user logged in, you need to use a windows service.
When you need the application to start running even when no one has physically logged into the machine, which is common with server machines, a service is a good candidate in this case. Especially because the service can be configured to auto start, which means the service will start when the machine is rebooted withut human intervention.
If however you are wanting to host web services (WCF) while a service is an option, you might consider hosting in IIS, this relieves you of writing the actual hosting code etc.
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.