I'm developing a program in windows (something like client & server) and I want to run server as LSA(local system account).but I don't know how?
Note: I'm writing my program in VB6 but I'm familiar with C#,C++ and C. So if your code is in any of these languages, I would be appreciate putting your code here.
There are a few options that come to mind. This article covers some of them.
Other things you could do is to add your app to the system startup process (via the MSCONFIG.exe app - "Start -> Run -> msconfig -> Startup" tab, or something like that).
Another way may be to setup your app so it can be installed as a service. You can configure any service to run under any arbitrary account on the machine, or via an account on your domain, if you're on a domain.
Another resource that looks like it might work for you is this article, which describes in more specifics, how to create a service from a VB6 app.
Related
I have a Linux system with:
a daemon that communicate with another device via RS232 port.
a php + javascript web site that talks to the daemon through a
socket.
Now the boss wants to find out how much of an effort is required to port all these onto Windowze.
Having never really programmed on Windows before, I'd like to ask how easy/hard this is going to be and what the options are.
Thanks,
PHP will probably run as is. Javascript runs in the web browser, and will run as is. Your daemon is a service on windows. Apparently it listens on a socket for commands from the web page via javascript.
You did not state what language you are targeting for the service. Some languages such as C# dot Net, have built-in libraries for making clean services that can pause, stop, start, and interact with the Windows Service Control system. C# would be a good choice to make a service that can install and remove itself easily, and it supports nice high level socket control to listen to the PHP and javascript code. I have used perl, C#, C++, and even Visual Basic running as a service, so the choice is yours.
If your choice of Windows language is that compiles to some .EXE, then a low-level way to add a service is as follows. You will need INSTSRV.exe and SRVANY.EXE, which come on the Windows Resource Kit, or can be downloaded easily with a quick web search.
The short version :
After you get the server runnign when you are logged in and debugged, install the APP server as normal to the C:\Program Files\APP directory. This would be the app that connects to the serial port and does what you want via sockets.
Copy instsrv.exe to your C:\WINDOWS\system32 directory/
Copy SRVANY.EXE to C:\Program Files\YOURAPP
From command prompt, run this command – INSTSRV YOURAPP "C:\Program Files\YOURAPP\srvany.exe"
Run the Registry Editor (REGEDT.EXE)
Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YOURAPP: create a ‘Parameters‘ key (folder)
Under the this key, create a REG_SZ string value called Application and add in this data C:\Program Files\YOURAPP\YOURAPP.exe
Close Regedit, then open the services console in administrative tools, or start, run, services.msc, confirm it is set to start automatically and the logon account is LocalSystem. Then unclick the Allow Service to Interact with Desktop. If you click this, it will interrupt you on Windows 7 boxes whenever it writes to the screen.
Start the service, check in Task Manager, you will see YOURAPP.exe inthere, and if you stop the service then YOURAPP.exe will disappear.
The long version
Details on this are at http://support.microsoft.com/kb/137890
I need a background application to support my client application, which should always run on the client machine regardless of the main client application is running or not.
Windows Service was my first choice but problems I faced with Windows Service were: ease of control over windows service through main client application, release and installation of patches to the windows service and troubleshooting if windows service fails to run.
So, I started thinking for alternatives to the Windows Service and found that a Windows Forms application with NO visible forms can do it for me. This invisible app should start with system startup and keep running all the time, doing all the work that a Windows Service would do. But before I go deeper into the development, I want to explore the pros and cons of this approach.
Any suggestions/comments on this approach?
Your requirements are more suited for windows service. Main advantage with windows service is that it will start as soon as system comes up, irrespective of anybody is logged into system or not.
To sort out deployment issues, you build your business logic into separate assembly and call the necessary function withing windows service. This way you can deploy just the modified assembly.
Winform application with invisible form will not serve the purpose. HTH
That's not possible. User-mode applications must be started by a user, and will not continue to run when that user logs off. That's the purpose of the SessionEnding event: to allow you to shut down your app gracefully when the user logs off or the computer is shutting down. You can't just start something at system startup and keep it running all the time.
You need a Windows Service for that. But you should be aware that under Windows Vista and later, a service cannot interact directly with the user. They run in a separate process and are restricted from displaying their own UI. It's not clear from the question exactly what your needs are, but this is an important limitation of a Windows Service that is worth considering. A proper design really shouldn't require this, but there are apparently a lot of people to whom this new, more secure behavior is a real surprise. I explain this in more detail in related answers to this question and this other question.
As part of my app, my users install a Window Service (msi file written in C#) that uploads data to me. These Windows servers are usually behind all kinds of firewalls etc. and run by IT staff so it's difficult to get in touch with anyone to debug.
What can I put inside my application that would make it easier to figure out things? I'm not looking to do anything that would be considered "shady" but here are some ideas I've thought:
Open log files that are relevant to me in a separate thread and stream it back up to the server
Setup some kind of reverse tunnel (not sure if there is a sane shell environment on Windows that I can connect to)
Any ideas or thoughts would be appreciated.
The author of the logging framework we use (the object guy's) has a service that might be useful for you.
You can debug .NET and native code through remote debugger with Visual Studio, see the post of John Robbins about it : http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/06/15/vs-remote-debugging-across-workgroups-or-domains.aspx
I have an Erlang application that is deployed on a server with Windows Server 2008.
The way I do this:
Copy application folder in Erlang lib directory.
Open command line (cmd). Execute erl.
Execute application:start(app_name) in Erlang shell.
Are there any better approaches to launch the application? How to make the application to launch on Windows startup?
I have no experience with Windows but...
`1. First of all, you might want to have a look to the concept of release in Erlang. Essentially,
When we have written one or more applications, we might want to create a complete system consisting of these applications and a subset of the Erlang/OTP applications. This is called a release.
`2. Then, you might want to create a script that contains something like:
erl -boot ch_rel-1
Where essentially you're starting Erlang/OTP using a boot script that you created above (just follow the instructions in the releases page)
`3. This article explains how to create startup scripts in Windows Server 2008 (not tested, just googled):
http://technet.microsoft.com/en-us/magazine/dd630947.aspx
Hope this helps. Nice question.
Perhaps rebar might help. It makes building an app skeleton and release quite easy. A nice tutorial is here.
After getting familiar with releases, take a look at manual pages (erl -man ) for start_erl and erlsrv. I used them to start embedded system ( http://www.erlang.org/doc/embedded/embedded_nt.html ) in windows 2003, hope it still works for you in windows 2008.
After creating service with erlsrv it is possible to manage it via standard windows command line and GUI tools, e.g. setting start mode and restart policy.
May be you could start just your application by supplying "-s app_name" as erl/start_erl additional flag, but I didn't try that, as I had to go long route with embedded system release. In that case make sure you have "start() -> application:start(?MODULE)." in your "app_name.erl".
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.