There is an option to configure a script to run as part of a plan for Bamboo. However, when I try to run a particular batch script, it fails. When I run it as the Administrator user from the remote desktop instance, it does not fail. I am assuming that the issue is that the script is not being run as an administrator, but as the Bamboo user. Is there a way to run a particular batch script as an administrator? I am using an elastic EC2 instance from AWS with Windows Server 2008 R2.
Here is my current setup:
By the way, this is part of an alternative attempt at this question: Boot EBS volume from Bamboo instance
I have not used bamboo, but to allow a Windows service to run commands as an administrator, first the service itself must have administrator privileges. Otherwise, it will be denied. Change the service user in the Windows services control panel. These are the generic instructions on how to change the service user:
Run services.msc
Find the target service
Open the properties for the service
Select the Log On tab
Select Use this account and enter an account on the server that has administrator privileges
Restart the service
Related
I have a VBscript file which connects to remote computers over our network and initiates a WBEM-Scripting method. I can open a CMD console using the credentials for a domain user account which has local admin rights on all of our desktop computers, and the script performs as desired.
I created a scheduled task on a Windows Server 2003 member server which runs the same script file using the same credentials, but it fails to connect to the WMI provider on remote computers.
The desktops are all Windows 7 SP1 and the domain is Windows Server 2008 level (forest and domain).
The domain user account was added to the local administrators group on the server, and was granted "Logon as a service" rights via Group Policy.
Question: Is there something else I'm missing that could be causing the scheduled task to fail while the interactive execution works fine?
I've had this same problem happening (scripts do not run as schedule tasks but, executable files do). You can get around this by doing the following:
There is a Start in (Optional) text box below the Program/Script text box on the property page for the Actions Tab. Fill it to include the path of your script So if your script is at c:\users\user\desktop\script.vbs, the text boxes will look like this:
Program/Script:
c:\users\user\desktop\script.vbs
Add Arguments (Optional)
Start in (Optional) c:\users\user\desktop
How do I get Topshelf to run as a specific domain user account? I have in the configuration
x.RunAs("domain\username", "password");
I have in the code a console statement that prints out the Windows Identity that the process is running under. It is not the one I specified.
The code snip-it you indicated is the correct method to apply a user. A couple of things apply to this...
This only works for windows services, if you run it as a console app it will still run as you
All shelved processes run as the host user, so shelves will ignore any user settings
You can double check the user the service is registered to run as by going into services in mmc, find your service, goto the properties panel, and there's a Log On tab which will display the user the service is to run under.
If you are just running as a console app, just servicename install start and it should be running as the user it's been setup for.
If this doesn't help, reach out on the mailing list http://groups.google.com/group/topshelf-discuss.
i created a ruby application and its working fine but when i run it as service it giving trouble. actully i have mysql as a databse in my application and i am using it to store only name of the file and placing the physical file on sambha server now when i run my applioaction as as service it's not able to find the path of sambha server... any hlep...
What user account is running the service? Windows defaults to using the local SYSTEM account, which cannot/should not access the network. If you change the service to run under the "Network Service" or a specific user account, it may succeed.
I have a script written in Visual Basic that starts a process (given to the script as an argument) on a remote system (again, given as an argument) using WMI. This script works fine when using an Administrator account on the remote system, but when using a non-administrator account, I get the following error:
ConnectServer Failed w/ (-2147024891) Access is denied.
I'd like to be able to run processes on remote systems as a non-administrator user with this script, and I'm pretty sure the problem is due to security settings on the remote system, but I've not been able to reset the right ones.
It sounds like you need to configure launch and activation permissions for this user, on the target machine, via DCOMCNFG. By default non-admin users do not have remote launch and activiation permissions.
Alternatively, depending on the operating system you are connecting to, there may be a "Distributed COM Users" group to which you can add your user. This group already has the appropriate permissions. The Distributed COM Users group was first included in Windows Server 2003 Service Pack 1 (DCOM Security Enhancements).
You can read more about WMI and DCOM permissions here. More detailed steps on how to configure WMI and DCOM are included in the serverfault thread Which permissions/rights does a user need to have WMI access on remote machines?.
What is the least set of privileges required that an account needs to be assigned in order to install a service using sc.exe? With account privileges I mean Local Security Settings in Windows Server 2003.
This service needs to be installed as part of a deployment script and is done remotely to said server by issuing something like the following command:
sc \\<server> create <servicename> binPath=<directory\service.exe> start=auto
Installing a service remotely requires no privileges on the target machine except the right to log on. But the account used must have the SC_MANAGER_CREATE_SERVICE access right on the Service Control Manager on the machine. This right is by default only given to members of the Administrators group. So by default the installing account must be an administrator on the target machine.
For systems prior to Windows Server 2003 SP1 (i.e W2K3, XP, W2K, etc.) the SCM security descriptor cannot be altered so this is the end of the story - you must be an administrator to install a service.
For W2K3 SP1 and later, if you do not want to run the script as an administrator then you could modify the security descriptor on the Service Control Manager for the target machine to include an ACE for the account the script runs under with the appropriate right(s). In general though, you would probably be better off re-thinking your deployment process to use an administrative account for service installation.