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
Related
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
How can I configure Visual Studio remote debugging when:
My developer machine is a member of an AD domain, and my username is "DevelopersName".
The "remote" machine is on the same Ethernet segment, but is not part of the domain.
The "remote" machine must run software under "RemoteUserName".
Most documentation I can find suggests that you need have both machines in the same domain and with identical usernames. That's not possible here.
I could possibly add my username to "remote", but the software still needs to run under "RemoteUserName.
If it helps, I could add 2nd network card to my developer machine and directly connect the "remote" machine.
Using VS2008, but will be moving soon to VS2010.
Thank you.
Sorry, but I've just spent the last 10 hours trying to debug your exact problem. My findings are not good.
You need to get your accounts synced, especially if you are using your remote app to connect to other systems in your SOA environment, ie: Sharepoint, AD.
You can to some extent get remote debugging to work, if you create an account on your local machine with the same name as that of your remote machine (lets do it like this rather rather than working with the domain account).
You then need to make sure the remote service is running under this account, and its a member of the administrators group. And by this I mean hold down control, and right click run as - with the remote debugger, and select the user (not required if remote server is logged in as the required user).
Run the wizard it will open the required ports, use Authentication, because non authentication won't debug managed code. Breakpoints are never met, and there is nothing you can do about this.
On your local dev machine, log off your domain account, and log onto the local account with matching name as the account on server thats running the remote service.
Now you stand a change of remote debugging. If you can't do any of the above, sorry there is no workaround, its entirely dependent on the user account and having the right permissions.
If you don't want to create a local account, try starting our debugger via command prompt using the following command:
runas /user:[user#machinename] /netonly [debugger.exe]
E.g.:
runas /user:john#mypc123 /netonly devenv.exe
I assume it's managed debugging you're talking about (for native debugging there's a remote debugging solution with no authentication). In this case, I would suggest that you use a local user to launch the debugger on your machine. If this local user's name and password match "RemoteUserName"'s name and password, it should work.
(Note that this does not preclude you from using the AD account to log in to your workstation, you just need to set up another account and use runas to launch Visual Studio.)
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.
I'm having problems with a scheduled task running in a windows 2003 server scheduled task
Task is running under the nt authority/system account sending files to another windows2003 server in same domain.
Machine where task is executed runs under a domain account with limited permissions in domain and machine
Folder where files are sent in remote server has been configurated granting total rights to system and user which
The problem happens when scheduled task is tying to write the file in remote server, task returns an exception like "Access denied to path ...."
Which is the user which remote server detects running externat scheduled task?
Which permissions should i grant in remote folder?
Thanks in advance
Fernando
A Scheduled Task running as the System user will not have access to another machine on the network. When it runs it is the same as if you were to logon to the local machine instead of the network. You will need to run the task as a special network user or store the file on the machine running the task for another process to pick up later.
A process run under Local System account doesn't have permissions to access other computers' resources. A typical solution is to create a separate domain user exactly for running the tasks and run the task under this user.
Besides the mentioned solution of creating a domain user to run under, if you just need anonymous network access or "domain member" network access, you can also run as Network Service which as a positive side has almost no rights on the local computer (unlike Local System which is even more powerful than Administrator).