I am performing some UI Automation on GCP using a Windows Server.
The process is as follows:
=> Machine Switches on at a defined time
=> RDP Connection to Machine
=> UI Interaction Script Runs on Startup
=> Process Ends
=> Machine Switches off at a defined time
All the components have been fulfilled except for automating the RDP connection in some way or other. I referred to this link but didn't find much insights or documentations.
Does anyone know a way to Automate an RDP connection right after instance turns on in GCP?
There is a windows application called IAP Desktop, using that you can manage multiple remote Desktop connection to Windows VM. While connecting to the VM you can save the credentials which will allow you to access the Windows VM using RDP just after boot on.
Also to automate the Windows password generation here is the documentation related to 1, inside of that document there are both options available automate or manually.
How are you deploying your startup script?
During the boot sequence, a script will either run before, after or during the boot process. By declaring Windows-specific metadata keys, you can run startup scripts after the instance turns on.
If that doesn't work, there is a paid Cloud Automation service that sounds like it will meet your requirements.
Tried using startup-scripts but no luck IAP Desktop didn't work due to scheduling as well. Finally Managed to solve it via using Windows 10 Auto login settings. This skips login screen and the best part was that out of all the users, it allows you to login via user of your choice. After I Login to the system, I added a startup a bat file by running shell:startup and it worked great.
I am running a Dotnet 3.5 executable in Windows 7 Ent, as a GPO computer startup script in a domain. The script resides on a network share. The exe is run as Local System. The exe runs correctly.
I would like to access a web Service in this exe, but it appears that the Local System does not have access to network resources per documentation. However if the same exe is copied to the C Drive and run from there under the same account and same conditions (i.e. GPO startup script) then the Web Service can be accessed.
How is it that the Local System has access to the web service when running from C: drive, but not from the Network Share? Is there anything that can be done to make it work from the network share, without first being copied to the local drive? is Local System same as SYSTEM and same as NTAuthority\system?
I have tried the following so far to make it work. None of these work:
Impersonate a domain user in code.
Give Full Trust to all zones in .Net Security Configuration
Add the network share to Trusted Sites in IE.
Use the netbios name instead of the fully qualified name of the fileserver, i.e. \server\share, rather than \server.domain.com\share
The following things I cannot do to fix this problem:
Change the logon account of the Group Policy Client service to a domain user
Run the exe as logon script. It has to be startup script.
To reproduce this problem I do the following:
Create an simple exe with some network function, i.e. WebClient.DownloadString("http://www.google.com")
Deploy exe to a network share
Run as normal user to show there is no error
Run whoami to show the current user
run psexec -s -i cmd.exe
Cmd will start as SYSTEM (Local System or NT Authority\System)
Run whoami to show the current user
Run exe from network share to show it will fail to download the page.
Copy the exe to C Drive.
Run exe to show the page is downloaded.
Am working on Creating windows service and launching an exe application through this,
from this link i have created a windows service Windows Service
But when i create a setup and deployment and then if i install, the exe which am calling from the service is launched as LOCAL SERVICE.
Still i can the xxx.exe in task manager as LOCAL SERVICE.
I cant figure even with this help : Launching GUI from windows service
How can i launch this exe as the local username which i have logged in ?
You have a number of options for creating a process that runs under a different user from the parent process:
CreateProcessAsUser or CreateProcessWithTokenW. These require you to obtain a primary token that represents a user, calling either LogonUser or DuplicateTokenEx.
CreateProcessWithLogonW which allows you to specify the user name and password as parameters.
However, if you want the process that you create to appear on the interactive desktop, you need to do quite a bit of work. This article covers the details: Launching an interactive process from Windows Service in Windows Vista and later.
I need a certain process to be constantly running in every user’s computer. If that .exe is killed, I must be able to restart it and send an alert.
I immediately thought of building a Windows Service as the ideal solution, but I am facing a problem:
The process started by that service needs to be able to interact with the user, e.g. be able to show him a GUI.
my application also sets a keyboard hook in order to monitor the user's typing rhythms, and when I start the .exe from a service, that information is not accessible.
From the service I am able to launch the process "as the user" (using the LogonUser and CreateProcessAsUser functions), but still can’t see the GUI.
Is this possible? If not, what can I use to achieve the desired functionality?
tia
By default the GUI .exe will be run in the service session, which is separate from the interactive session of the user. You need to look into techniques for building an interactive service.
I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?
Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...
The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.
WTSEnumerateSessions and CreateProcessAsUser.
Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.
That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7
On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.
I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...
If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.
Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx