As I understand, when we start windows it starts Session 0 which does not connect to any GUI, etc. and runs all windows services. So my task is, after windows was started, emulate windows input for selecting user and login to is session. I know that for sending input from service I should run desktop app and through it send input, show GUI, so on, but how can I do it before any user session was start? (for example I see that TeamViewer can do it)
WTSGetActiveConsoleSessionId() will tell you which session is attached to the physical console.
You can then duplicate your security token with DuplicateTokenEx(), change the new token's session with SetTokenInformation() and the TokenSessionId option, and launch a process with CreateProcessAsUser().
The new process should then be running in the right session, but it may also need to attach itself to the right desktop before it can interact with the logon interface. You can use EnumDesktops() to list the available desktops, and trial and error to determine which one the logon interface runs in. (Note that this may be different in different versions of Windows.)
Related
We manage several laptops that are used for emergency situations and thus are rarely used (knock on wood).
When we start up these laptops periodically to run windows updates, we also sign in with several user accounts for each laptop in order to keep the profile up to date.
Is there a way to automate the logging in of each account with a script?
For example, I could log in as administrator, run the script and the laptop would do the following:
Log out my administrator account,
sign in with useraccount 1, log out
sign in with useraccount 2, log out
sign in with useraccount 3, log out
I havent had much luck in googling this type of thing and was hoping someone here might have an idea.
I simply cant find a script that logs in with a user account.
The closest I can find is recommending auto signin but that only applies to one account and not what I need for this task.
Globally, you can't do that: it would break security if you were allowed to interact, programmatically, with the login screen.
IF it's possible, I would look to a way to do the login to remote machine through either Telnet (not recommended! but can be done with standard Windows tools) or SSH (will need a SSH server). If you can do the upgrade this way, then you're saved, in particular with SSH because you can avoid passwords' sharing through key exchange - probably won't work with domain accounts, however, but local accounts will be fine.
Otherwise, if you require to really open a Windows session, best you can do, IF your configuration allows it AND if it works (regarding the profile's update) is to connect through RDP (Remote Desktop) to each laptop, with each login.
You'll need to establish a RDP connection to each laptop from a "pilot" PC, save each connexion individually within a .rdp file, saving password inside the connection file.
Then, you can launch the connection with the command mstsc <machine+account>.rdp to establish a connection. A bit later, you can kill the connection (with either taskkill or through a pilot process / tool, I would use AutoIt for this preferably).
If password saving is an issue, then each employee should have its own set of RDP files. Through something like Autoit, in particular, you can input the password once, and fill automatically each password prompt.
The tricky part would be to know when it's time to close the remote desktop. I would try to automatically execute a command to distant computer that would reboot it once done, so your remote desktop would close automatically.
Anyway, it will be a real gas plant to implement all this in a smooth process...
I want to develop a c++ service to get notified whenever user does login or logoff the system. I went through some functions but those are asking for windows handle. Since it is a service, which windows API will be useful for this?
The title didn't scare you off. Great!
This is what I'm trying to do:
I have a service that at some point in time plays a very important sound. Because it is so important, I make sure that the mixer is ummuted and that the volume is at a proper level at startup.
This works fine when I start the service logged on locally to the computer where it's executing.
However, when I start the service from a remote desktop session it fails to get the volume control if I select "Play on this computer" when logging on.
The obvious solution is "Select 'Play on remote computer' when logging on" but for various usability reasons this is not feasible.
So; the M$ question is: "how can a service launched from remote desktop session set the local mixer main volume if 'Play on this computer' was selected at log on?"
The service runs on WinXP and I use the horrible Mixer* API from C++.
Thanks,
Rickard
The problem is that as an OS service, you can't control the volume for a TS user unless you have code running in the TS user's session. In order to remote audio from the server to the client, the TS service virtualizes all the audio APIs. Those virtualized controls aren't accessible from Windows services.
In order to solve your program, you'll need come code running in the user's session. I might suggest a scheduled task which is triggered on user logon. The task scheduler APIs allow you to create a task which causes a COM object to be created upon user logon. From that COM object, you can communicate with your service and then perform the mute operation on behalf of the user.
Here's what I want to do:
a program that listens in the network for a message, and when that message is received, if the user is not logged in (for example the computer just powered on and windows displays the classic login screen), it automatically logs in a certain user accordingly to the message. the username and password are known and stored safely inside the computer in a configuration for the program i'm talking about.
What I had in mind was a windows service that starts with the computer and also listens to those messages, and if one is received, then it does it's job
but I have no idea of where to start
(basically i'm trying to login a user without having to type the password, which I said is stored and known - need something mostly like the fingerprint software windows 7 comes with, and the ones that you had to install in vista/xp so that fingerprint login would work (fingerprint was only an example) )
There's two methods to pursue depending upon which operating system you're looking to run under.
For Windows XP, Windows 2000, and Windows Server 2003 you need to create a GINA.DLL. This is a replacement DLL which must follow specific rules which handles the authentication process. In your case your replacement DLL would be known by the service which was listening for your start signal, and it would make a call into the DLL with the username and password as appropriate.
MSDN Magazine article on customizing GINA.DLL
MSDN entry on GINA
For Windows Vista/7 and above you'll need to look into the Credential Provider API.
MSDN Magazine article on Credential Provider API in Vista.
MSDN entry on Credential Provider API
You can use windows auto logon feature to do this.
Create a service which waits for the required data on a network socket. Make sure this service is started after the network service (Tcpip). Modify winlogon service properties (manually) so that it depends on your service. By depends, I mean that winlogon service is started after your service.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon to 1
Once you receive the data on your network socket, set the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword
Once the registry settings are in place, then the winlogon service can read those values and proceed with the login process.
For more details on setting the registry values refer: http://support.microsoft.com/kb/315231
I want clarify a little the suggestion of Vikram.exe.
Of cause the usage of AutoAdminLogon seems native for the problem, but saving of the password in registry as a clear text under HKLM\...\Winlogon\DefaultPassword is not good. Since Windows 2000 it is supported the usage of the secrets DefaultPassword which makes the same effect as the DefaultPassword registry value (see Protecting the Automatic Logon Password for the code example).
Another way to force user login or to do any other actions on the login screen is switching to the Winlogon desktop (full name WinSta0\Winlogon). You can use SwitchDesktop and SetProcessWindowStation to do this (see Window Stations and Desktops). If the service run under System account you will have all rights to do this. Depend on the configuration of your service it could be also needed to use SetTokenInformation with TokenSessionId to change the current session id. After the service process will run on the WinSta0\Winlogon desktop you can use functions like FindWindow and other GUI API to place any information in controls of the window (user name, password and so on) of other process. So you can implement more complex scenarios.
Firstly let me just say im not 100% sure how to fully complete such a application but I have a few tips.
you will need to create a Windows Service that starts during the Pre-Login, you can create a service in C#, An example of creating a C# Service is linked below:
http://msdn.microsoft.com/en-us/library/zt39148a(VS.80).aspx
Within your application you would set the property Startup Type to Automatic, This will automatically start your service on boot.
You should know that windows services run under a secure context by account so you will have to get your service to run with privs do do this.
In your Service Properties you can Click Log On and you can
To specify that the service uses the Local Service account, click This account, and then type the following NT AUTHORITY\LocalService.
To specify that the service uses the Network Service account, click This account, and then type the following NT AUTHORITY\NetworkService.
As your trying to do this remotly you will have to look at WMI (Windows Management Instrumentation) and you will be able to start/stop and send commands to your service.
Your service then would send a command to the Login Management (Not Sure of the name).
you may also wish to check this WOL class which will switch the computer on remotely as long as it supports Wake On LAN, If this is for a corporate environment then I advise you to check your network cards to make sure they are supported
http://www.codeproject.com/KB/IP/wolclass.aspx
I know of some education software that I use for schools that's called CC4 ( http://www.rm.com/shops/rmshop/story.aspx?cref=PS1026195 ) and we can do exactly what you need within this system, I'm not fully sure of how it works fully but i believe it takes the same principles described above.
i'm using a Windows 2003 Server.
I have a session with my username on it and i have a windows application (not service) opened on it. I want this application to always be running.
The problem is, when Security updates force Windows to reboot, my session is closed and i need to reconnect to the session to get my application working again ..
How can i do to automaticaly force the opening of my user's session upon server's reboot ? (application launch is in the startup of my session)
Thanks
If you want to have the program running consistently, I would highly recommend making it into a Windows service (see also this page). Then you can set the username that the service logs on with (this is particularly important if the app needs to access networked resources), and even set the stability values to have the service restart itself if the EXE crashes for some reason.
Otherwise, if you really want the computer to login as your user and run the program, you could set the autologon parameters to your username and password, and put the shortcut to your program in the user's Start Menu Startup folder. (But this does not provide you any of the stability benefits that a service would.)
Add a startup script, http://technet.microsoft.com/en-us/library/cc779329(WS.10).aspx