I have created a windows service exe from the python code, it starts when I start it manually in AWS Ec2 instances. Also Starts automatically some time when the ec2 boots up. But sometimes the service will not be stared in the instance, why is it happening some times. For your info I also increased the timeout to service start till 700000 in regedit key. still the service will not start automatically. Why is that happening? can I get some solution for this?
If the service is set to start automatically at boot but it isn't, there should be a record describing the failure in the "System" area in the Event Viewer. Check those logs.
Also, try setting the service's "Startup type" to "Automatic (Delayed Start)". Doing so will delay service startup by a couple of minutes, which may be enough to fix the problem if it is a "race condition" as the system starts.
Related
I would like to delay the automatic start of a specific service, my tomcat client application here, that needs to wait few minutes before being launched so that another machine have enough time to start its own service before (database server here).
Is there any parameter for this in Windows server 2016?
Yes, this can be done for a specific service.
You need to :
First set your tomcat application Startup Type to "Automatic(Delayed Start)" in Services first.
2.Go to your registry and add a registry key named “AutoStartDelay” with type “DWORD (32-bit)” in below location:
HKLM\SYSTEM\CurrentControlSet\services<service name>\AutoStartDelay
3.Modify the value data of AutoStartDelay with decimal. The value indicated is in seconds. For example, the following is for 2 minutes of delay :
4.Save the change in Registry.
This doesn't work on Server 2022. AutoStartDelay is ignored at a service level.
I want to know if it is possible to configure a service to call a batch/powershell script when I stop it from services.msc.
While in Linux init.d services are fully programmable and even systemd services can have additional procedures I've yet to find a way to accomplish this on Windows.
Thanks in advance
You can configure services to run a program on failure, but if you are stopping the service via services.msc then that likely wouldn't count as a failure.
The only other option I can think of would be to set up a PowerShell script running as a scheduled task that either periodically checks the services running status, or (for a more foolproof option) looks at the event log for events indicating that the service has been stopped (since the last time the script checked) and then performs whatever actions you require.
Per the comment from montonero, you wouldn't need to run the scheduled task periodically as it could be configured to run when the event itself occurs. This is described here: https://blogs.technet.microsoft.com/wincat/2011/08/25/trigger-a-powershell-script-from-a-windows-event/
Use the Event Viewer “Attach Task to This Event…” feature to
create the task.
Launch "Event Viewer" and find the event. Once found, right-click on the event and select "Attach Task to
This Event...".
I can't seem to find the configuration setting but when I terminate a free tier instance a new one is created a few minutes later. I want to terminate it permanently and not have it restart. I created the instance using the eclipse tools originally if this makes any difference. I have tried stop and terminate and both will create a new instance and leave my other instances in the "terminated" or "stopped" state. Is there a setting that I can configure to leave it turned off?
I figured it out it is the application is configured in elasticbeanstalk. I had to delete the application in ebs and it terminated the application.
I have 2 separate servers (windows server 2008 r2) from where I am running vbs scripts through a microsoft scheduler ( my-computer>manager>Schedule). when I run vbs scripts locally they are working fine, but when it is being run through scheduler one of servers is getting stacked. while the other is working fine. And also I have noticed from task manager that the working server runs the WMIPRVSE.exe though Network Service user and the other one shows SERVICES as user.
How to make sure that WMIPRVSE.exe will always run under Network Services. Thanks
Edit:
I have tried to change the log on user from services, but it failed to start the service than.
There are a few things I have tried, but I don't know which one helped me.
What I did is I granted all permissions to wscript file which is located in system32 somewhere, and after some time it became Network Servies. Again not really sure whether it was because of that change or other thing.
I am windows user and wanted to use a spot instance using my own EBS windows AMI. For this I have followed these steps:
I had my own on-demand instance with specific settings
Using AWS console I used option "Create Image EBS" to create EBS based windows AMI. IT worked and AMI created successfully
Then using this new AMI I launched a spot medium instance that was created well and now running with status checks passed.
After waiting an hour or more I am trying to connect it using windows 7 RDC client but is not reachable with client tool's standard error that either computer is not reachable or not powered on.
I have tried to achieve this goal and created/ deleted many volums, instances, snapshots everything but still unsuccessful. Doesn't anybody else have any solution to this problem?
Thanks
Basically what's happening is that the existing administrator password (and other user authentication information) for Windows is only valid in the original instance, and can't be used on the new "hardware" that you're launching the AMI on (even though it's all virtualized).
This is why RDP connections will fail to newly launched instances, as will any attempts to retrieve the administrator password. Unfortunately you have no choice but to shut down the new instances you've been trying to connect to because you won't be able to do anything with them.
For various reasons the Windows administrator password cannot be preserved when running a snapshot of the operating system on different hardware (even virtualized hardware) - this is a big part of the reason why technologies like Active Directory exist, so that user authentication information is portable between machines and networks.
It sounds like you did all the steps necessary to get this working except for one - you never took any steps to cause a new password to be assigned to your newly-launched instances based on the original AMI you created.
To fix this, BEFORE turning your instance into a custom AMI that can be used to launch new instances, you need to (in the original instance) run the Ec2ConfigService Settings tool (found in the start menu when remoted into the original instance using RDP), and enable the option to generate a new password on next reboot. Save this setting change.
Then when you do create an AMI from the original instance, and use that AMI to launch new instances, they will each boot up to your custom Windows image but will choose their own random administrator password.
At this point you can go to your ec2 dashboard and retrieve the newly-generated password for the new instance based on the old AMI, and you'll also be able to download the RDP file used to connect to it.
One additional note is that Amazon warns that it can take upwards of 30 minutes for the retrieval of an administrator password after launching a new instance, however in my previous experience I've never had to wait more than a few minutes to be able to get it.
Your problem is most likely that the security group you used to launch the AMI does not have RDP (TCP port #3389) enabled.
When you launch the windows AMI for the first time, AWS will populate the quicklaunch with this port enabled. However, when you launch the subsequent AMI, you will have to ensure that this port is open for your security group.