Running a Script on Active Directory Domain Member PCs without Reboot or Logon

Question

I have an Active Directory domain running on Windows Server 2003 R2. Clients are a mixture of Windows XP SP2, Vista, and Windows 7. I want to run a script (batch file, but possibly a VB script) on each machine, once. I don't want this to happen on Logon, Logoff, Startup, or Shutdown. I just want it to happen as soon as possible, and once.

Is there a relatively painless way to do this that will work across all the client types?

Thanks.

UPDATE: I should have mentioned this originally: Many of the PCs are behind cheap 5-port routers plugged into an ethernet jack. Think five grad students sharing an office. So each PC in an office has an RFC1918 IP. I'm on the public side of the router, so I can't connect directly to the PC. Hence PsExec or WMI won't work. WinRM might, but most of the PCs don't have that installed. I think my only option is to use a GPO somehow, maybe to schedule a task to run a script from a network drive.

Solution

I would say use psTools psexec.exe to remotely run the script.

It's a painless process to get up and running, doesn't need you to log into every station, and doesn't leave a footprint after-wards.

---

In response to all the comments, since they can talk to the DC's to be on the domain, you should be able to jump onto a DC and run the psexec script from there.

Comments

[Mr Furious]

Are you wanting the script to run on the local client desktops (in the current session) or just perform some operation against the desktops? What sort of script are you running?

[BoxerBucks]

You will probably want to query the AD for all your workstations and use that as your source to loop through since you seemingly already have a properly functioning domain. If you have SQL server, you could easily write the results to a table or a log file and use SSIS to import the results then view via SQL reporting services or something cool like that. Of course, if you do all that work maybe SCCM is something you will want to look at.

[David]

A salient detail I failed to mention was that many of the PCs are behind routers (with non-routable IPs. This wasn't my decision, but it's understandable -- we get billed internally per IP). So I think psExec and WMI won't work. WinRM might, but it's not an option for the XP boxes.

[David]

I'm not internal to the network. I'm on a routable IP, but many offices have cheap routers plugged into a single ethernet jack, and then 3 or more PC's are plugged into the router. So I can't get past the router. The best I could do is port-forward to a single PC.

[David]

@Tony: No, I can't ping them. Can only get as far as the public-facing side of each in-office router.

[tony roth]

r these workstations domain members?

[David]

@Tony: Yes, they're all members of the domain.

[tony roth]

well since most people don't change their default cheap router pw's I'd hack that and fix things! just kidding this sounds painful. Does the script need to run as administrator. If not then just email the users and tell them run it. Another question how do they communication with your domain?

[David]

E-mailing users and asking them to run the script isn't really an option. Yes, it is painful. The University charges us a monthly fee per IP (currently $7, ramping up $1/yr to $14/month ultimately), so the decision was made to save money by NAT'ing. We don't control the network closets, so it's done on a per-room basis. Even behind the router, workstations can communicate with the domain. For example, clients poll for GPO updates.

[tony roth]

why not email them the script, as convoluted as things sound they probably are all admins on their workstations anyway.. The only reason that I can think of is if the script does something malicous.

[David]

Answering in multiple comments. Although I didn't install the routers, they are all configured identically. So yes, multiple workstations in the domain may have the same RFC1918 address (192.168.1.234, say). The workstations are configured to use the University DNS servers, and do not register their IP back to the server. This doesn't appear to have created a problem.

[David]

Clients are not connecting via VPN. As described in another comment, we have multiple offices (each with multiple workstations) in several buildings on a university network. The university charges a fee per IP per month, so NAT'ing routers were placed in the offices to save money. This was not my decision.

[David]

Don't worry, I'm not offended. In general, I want to be able to run scripts to query the configuration of individual workstations in potentially arbitrary ways. In this specific case, I have a relatively small subset of workstations with a particular piece of commercial software that uses a registry setting to store the location of a shared network license. I want to run REG query on each workstation to see which workstations have that key. I will use an adm template via GPO to push a new value of that key to those clients, and then I want to query the registry again to see if it worked.

[David]

The script isn't malicious (see my comment to Avery Payne). I'd rather visit the desktops involved than ask all my users to run a script. Some are admins, some aren't.