Yeah just use Cygwin to run the Unix commands under Windows. I do it all the time with grep.

All right, here is my jack of all trades psexec script(s). You can modify this to your hearts desire but one of the best way to learn to script is to see others. So here goes. NOTE - All quoted text should be one line, some lines wrapped.

This script can be tailored to do just about anything, it is a script that calls another script BUT with the important distinction that that other script is then running on another computer. I've rolled out the Win2K/2K3 DST changes to over 1000 machines back in 2005 with this script. I've created a profile backup tool with it for use in migrating a 1200+ machine environment to XP from Win2K. It can do almost anything you can script.

The script is actually three things, two scripts (the one that will call psexec and the script that psexec will execute) and a text file with machine names, one per line like this:
PC1
PC2
PC3
and so on. This is versatile so that if you have over a couple of hundred machines and the script takes a while to run, break the machine list up into batches of 50 and run it on different machines at once (each machine will need psexec and the three files needed by the script). With that said, here we go.

The first script is the script that calls psexec. I usually put psexec in my C:\Windows\System32 directory since that is alrady part of the path but you can put it anywhere you want just make sure to use the whole path in the script.

@echo off

:: Begin Script - Name = Sample.cmd
:: This is the most versatile script you'll ever use. 
:: Created by Les Bowman
:: 08/01/2006 Ver 1.0

:: ** Following command changes the root folder to where batch file is running from.
cd /d %~dp0

:: Requirements - sample-list.txt, a list file of PC names one-per-line w/o "\\"
if not exist sample-list.txt goto :end

del /q sample-dead.txt
cls
Echo - 
Echo Running List Check...
Echo - 
FOR /F %%i in (sample-list.txt) do call :listcmd %%i
 pause
goto end

:listcmd
@echo off

if "%1"=="" goto :errmsg

::Display PC name being processed
echo.
echo.
echo Processing: %1

:If file on remote PC not seen - skip as 'dead'
if not exist \\%1\admin$\system32\ntoskrnl.exe goto dead

:******************************************************************
:******************************************************************
:SECTION_BEGIN - FOR COMMAND LINES RUN AGAINST THE REMOTE SYSTEM 
:************ Modify entries within this section only *************
:******************************************************************

:: set local environment path for utilities
set CMDTOOLS=\\remotesvr\path\

:: Copy All Files Needed to client
copy "%cmdtools%\exename.exe" \\%1\admin$\system32

psexec \\%1 -c -f _sample.cmd

:: Delete copied files from client
del \\%1\admin$\system32\exename.exe

:******************************************************************
:******************************************************************
:SECTION_END FOR COMMAND LINES RUN AGAINST THE REMOTE SYSTEM 
:******************************************************************
:******************************************************************

:errormsg
echo There was an error with the -list file, verify that there are no blank lines.
goto :end

:cont
::Log system as done after running command against it
echo %1 checked >>sample-checked.txt
goto :end

::Log system as 'dead' if remote file check failed
:dead
echo             Dead\Offline
echo %1 >>sample-dead.txt
goto :end

:end

I have the file pretty well remarked but I'll go over it anyway.
@echo off

echo off tells the script not to print the commands of the script to the screen, you'll see only output. The @ in front of echo off tells the shell not to print that command. It's for presentation only, during writing and troubleshooting of scripts I recommend you keep this line commented (two colons will do for that). Commented lines don't run at all.

The sample-list.txt file is the list of computer names that you want to run the script on.

This script will create a file called sample-dead.txt with a list of the machines that weren't on when you ran the script or that weren't able to be accessed. This will allow you run the script again but you can copy/paste or rename the names in this file to the -list file. The script cleans itself up, so it will delete the -dead list everytime.

cls - clear screen

It is now piping output to the screen as it checks the list and goes through the rest of the script.
The FOR .. DO loop is a powerful thing, what this one does is for each line in the -list file it goes to the :listcmd passing the %%i parameter (%%i is a temporary variable that the script is using to keep track of the machine name). The FOR command can have its own post, do a for /? and read up on it if you like.

As you've seen I have sections of the script labeled, :listcmd is such a label, this way I can tell the script to jump around the script (usually only downward so you've got to do some logic) depending on certain conditions. In the case of the FOR DO loop I have it verify that the line (ie the machine name) isn't blank "" and if it is not it will go on to the :listcmd otherwise it will jump down to the :errormsg and tell the operator something is up.

So now that the script has a machine name (the script is now displaying "Processing MachineName") it needs to confirm if that machine name is valid it does this by seeing if the ntsokrnl.exe file exists in the C:\Windir\System32 directory of the remote machine. How do I know this? Look at the path:
\\%1\admin$\system32\ntoskrnl.exe
\\%1 is the machine name
\admin$ is the admin share, this is a built in share on a windows box that points to the C:\Windir directory, note that this will find the directory if it's Winnt or Windows or ScoobyDoo unless something is seriously FUBAR'd on the machine or there are group policy settings in place to turn off admin shares. This also means you will need admin rights on the machines you wish to run this script on.

So if this file doesn't exist because the machine isn't on or we can't reach it, we put the machine name in the dead list by jumping down to :dead. If the machine is on we continue.

We are now in the working part of the script, the other stuff before this was for speed (trying to copy files to dead machines take a while to time out) and error checking.
First the script defines a set location for necessary files. This could be a special .exe you don't want left around on the worker PC when the script is done. You may not need this section, I use it to keep things like the resource kit tools on a central server but copy them over to the client for speedier running and then delete the .exe from the local client when done. Delprof is a good example but you could also get by by just calling the command from the psexec section too. This is a demo script only, I've not really fine tuned it since I wrote it in 2005.

So if you need to copy files over from the resource location you can do that.

PSEXEC time. I put psexec in my system32 so if you put it somewhere else you may need to include the path ie:
C:\temp\psexec.exe \\%1 -c -f _sample.cmd

The -c and -f switches tell psexec to copy the _sample.cmd over to the remote machine (c) even if it exists (f). This allows it to run remotely, this also means that in your scripts directory you should have:
_Sample.cmd
Sample.cmd
sample-list.txt

This is another reason I use that resource share, it allows me to only keep the scripts/sub-scripts (the _sample) and the list/dead files in my script directory.

What is _sample.cmd? Here it is for this demo:

@echo off

:: Begin Script - Name = _sample.cmd
:: The actual script that the remote PC will run via PSEXEC.
:: Created by ME
:: 03/16/2010 Ver 1.0

:: Ensure log directory and file exists

mkdir %windir%\logs

Set log=%windir%\logs\sample.log

scriptcmd.exe /arg1 /arg2 >>%log%

Not much I know but structure really is more important than payload. Basically, I like to have a log of each time a script runs. You can do more fancy things, I've added the date and time of the script being run as a header as the log file grows but this is a demo.

scriptcmd.exe /arg1 /arg2 can be any exe you want. It can be a .exe you copied over from the resource share it can be a bunch of batch commands like:

Here's the thing, if the script hangs, this is where it is going to hang. This is the script you need to troubleshoot on a few test machines locally to verify it works OK before trying it out on 1or3 using psexec.

When the script completes psexec closes and you're back at the sample.cmd where you left off.

Now the script will delete any files you copied over from the resource share and the FOR DO loop continues, so it starts the loop again if there is another machine name or it ends if there is not. I never have the master script delete this list like I do the dead list. This and logs can be helpful in determining when and who ran scripts.

We've already gone over the errmsg and dead portions of the script.

Damn that took longer than I meant it to.

There is a freeware app called flexible renamer that can do what you ask.

The forum has a code tag, no need to use quote and dots to indent.

Edit: Problem resolved, post cleared to reduce clutter.

Your post is using <code> which breaks for me as well, while I used [code] in mine.

Edit: too slow

I am going to try both methods tomorrow. While reading and experimenting with it today, do either of these scripts (PS or Cygwin) support archives? I noticed that the majority of files are in archives, which I didn't notice at the time?

Windows command shell that's been around since NT is powerful enough to take on most search-and-rename operations. No warmed-over Unix utilities are needed. Familiarize yourself with options offered by the for command by typing help for at command line. Besides for, all you need are copy and rename commands, which are also built-in.

That's the way to go!

The only thing I would recommend changing about *legion*'s scripts would be to use -iname instead of -name as an option to find. It won't really matter on windows, since the filesystem is case insensitive, but you could miss stuff on a *nix box.

I love the find command. find $path -$modfiers -exec {} \; = win on so many levels. I've done some really awful things with that command as a base (shell one liners rule!). I was even more pleased with it once I discovered it had the -ioptions.

Only if your shell was compiled statically. As soon as you start relying on shared objects, all bets are off!

Hell, the unix command line has started plenty of wars in and of itself (shell purists, emacs vs vi[m], startx vs xinit)!

oh, uh.. finding stuff. replacing! On track, truly!

VIMer REPRESENT!

Recently I wanted to write a script that was dead simple in Linux, but couldn't even begin to figure out how to do it in Windows. But I wanted to learn how. And I didn't feel like installing Cygwin. Then I found this:

An A-Z Index of the Windows XP command line
http://ss64.com/nt/

It's not quite the same set of commands, but it's a lot better than having nothing or knowing nothing.

Who says he isn't?