We have a software that needs to get password to be initialized. Software is running on a build server (Windows 10) and used as part of the build process. Password resets after reboot or after RDP session. Therefore RDP access to the server is disabled and it's running VNC.
However, still we have a problem that once in a while server reboots and in this case someone needs to login to the server over VNC and to initialize the software by typing password in.
Is there any way that this process may be automated? Some QA tools that may be utilized for this puprpose?
If auto logon is set (find the instruction on SuperUser site), startup script can run on this server without alive VNC connection (in Windows Task Scheduler by logon trigger). As an GUI automation library you can use pywinauto (need any Python on the server + pip install pywinauto). If you keep the server always logged in, maybe another trigger would be useful (from Jenkins slave if it's connected to Jenkins). But it must run not as a service (services can't access GUI).
Related
I am running an EC2 instance on AWS running RockyOS. The system boots with gnome running, but I can not access the gnome session, so I can not run the settings apps to enable the remote desktop sharing.
Is there anyway to configure the remote screen sharing password and enable the remote desktop sharing service via the command line?
I know I can install xvnc, but I would rather just be able to access the main gnome session.
I found this gist that enables VNC + RDP. I personally had trouble with writing password in secret-tool due locked gnome-keyring but it's still good inspiration:
https://gist.github.com/greyltc/7085bff8f2e728b60077b81329019828
We have written a Windows Service that is planned to be deployed to many or all client windows machines in a company. For technical reasons this service has to be run under the logged in user (i.e. not under LocalSystem or any Service Account).
Furthermore it's a requirement that our software has to be deployed using an installer that requires no user interaction (e.g. silent mode is fully supported).
We now face the problem that we are unable to install our service without having the user to provide it's credentials.
My question now is:
Is it possible somehow either during the installation process or in a start up script of the end user to have a service registered or started up without having to enter the users credentials?
If that is not possible (which I assume): Is it possible to start a process as a regular process and
have it register itself as a service at startup, so it appears in the Services panel?
Any help or idea is appreciated.
At $employer we have a customer trying to run NiFi on Windows 2012 server. We have helped them configure it as a windows startup task using the Task Scheduler. I realise this may be more of a ServerFault question but there's nothing much about NiFi on there.
When this is run as user with local admin rights, it runs perfectly. When run with the user created specifically for this service (with the required "Run as a batch" permission), it starts up and then promptly shuts down with a permission denied error on a TCP connect.
Is there a specific Windows permission that is needed for NiFi to run as a batch and listen on TCP ports?
On *nix systems, if the TCP port is below 1024, you need to run as root. I am not sure if this applies to Windows systems as well (surprisingly little documentation to answer this common question directly), but that could be the cause -- when run as an Administrator this works; when run as another user it fails. Can you share the explicit error you get from the nifi-bootstrap.log and/or nifi-app.log files?
We have a remote support tool that allows us to connect to machines behind a NAT firewall. Once connected, we can choose to either connect to the console session or to any active RDP session from a list. We cannot connect to inactive/disconencted RDP sessions, and the tool has no way to create new loopback/redirected RDP sessions. What we would like to do is find a way to spawn these RDP sessions via a script or a small application so that the support tool can detect them and allow us to connect. The motivation to get this working is to be able to have multiple techs access the same server simultaneously (up to one active console session and two active RDP sessions, all at the same time, for a total of three techs).
If we log on to the console session of the target servers and then RDP to the loopback, we see the new RDP session in our support tool, which we can then select and connect to. The problem is that this RDP session creation depends on the console session. It also gives the console session access to the RDP session, and if the RDP window is minimized then the output/input for that session in our support tool is frozen. I was able to use the PS script Connect-Mstsc (mostly just a wrapper for mstsc.exe but with support for adding creds) to create RDP sessions from another random server on the remote internal network to the target server we want to create a new RDP session on. This works well from an automation standpoint but we have the same limitation described above - it only works if run interactively. If you run this from a SYSTEM shell remotely, the RDP session never appears in our support tool.
The remote support tool in question is ScreenConnect and our servers are all Windows, mostly 2012 R2, all AD environments. I think the core challenges to this solution are getting the RDP sessions created and active in a non-interactive fashion, and then preventing RDP from freezing the session input/output.
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