The SCCM client polling interval is a configurable setting that applies to all clients in the site. Sounds like it's set to 30 minutes at your site but (depending on network limitations/server load) this can be safely changed down to 15 minutes by someone with the appropriate SCCM site access.
There are ways to force a machine to check outside of its normal polling schedule.
There's an open source tool called SCCM Client Center that you can use to connect to a client machine and check/set a lot of the SCCM details with (as long as you have the appropriate permissions).
What you can do is once you've placed a machine in a collection, rather than waiting for it to poll you can connect to it using the Client Centre, select Client Actions -> Download Machine Policy, then wait a minute or two and select Client Actions -> Apply Machine Policy. This forces it to connect to the SCCM server collect any pending policy changes (eg new adverts) and then once they're downloaded you tell it to run them.
Setting a timer on the job running is down to whoever set up the advert for the job in the first place, they had a number of options they can pick for scheduling the job once it's picked up by a machine and presumably in this case picked "As soon as possible". You can also set up Maintenance Windows on machines that set when jobs can/can't be run on them which would stop builds happening in working hours if that's what you want, but it sounds like these parts are outside of your control unfortunately?
I could be mistaking how you're set up but normally once a machine's set up in SCCM you don't need to know it's MAC, and if you ever do you can just find the machine in the console right click it and look at it's details. Adding machines to a collection can be done by machine name, MAC, IP or pretty much any criteria, you only need to know one unique thing about it.
New 'bare metal' builds are obviously slightly different but we don't currently use that part of SCCM (but are planning to move over to it) so I can't tell you much there.
How are you running the batch file? Is it an "Install Software" step using an SCCM package, or is it a "Run Command Line" step? This makes a big difference to how you use and control batch files.
If you're using an "Install Software" step then all you should need to do is make sure you've got the Source location specified properly in the Package properties, and that you've got the command line right in the Program (along with leaving the "Start In:" box blank) and as always make sure the "Allow this program to be installed from the Install Software task sequence..." box is ticked.
If you're using a "Run Command Line" job, then after checking the same as above for its package, make sure that you've ticked the "Package" box in the step's properties, have specified the correct package that contains the files, and haven't specified anything in the "Start In" box.
Presume that the package is correctly out on the distribution points, else the Task Sequence should fail at the initial "Checking dependencies" step, but just in case you can run the SCCM report "Packages referenced by a specific task sequence" (in the Task Sequence - References" category) to check the distribution status of all the packages used by your TS.
Finally the SMSTS.log on the client machine should show the exact command lines being run at each step, where the files have been downloaded to (if at all) and what the current working directory is at the time the command is run. It's a huge file, and a pain to go through but does give you all the info. If you're using a batch file, you can also ECHO any useful info and it should show up in that log too. On a machine that's successfully run the entire build process the log will end up in either "C:\Windows\System32\CCM\Logs" or "C:\Windows\SysWOW64\CCM\Logs" depending on how much info has been logged you may find that the early steps of the task sequence have been archived in a smsts-date- time.log file.
If you don't have it already, then trace32.exe from the SCCM 2007 Toolkit is highly recommended to take some of the pain out of reading SCCM's logs. It's a tiny little log viewer app that understands SCCM's log format and highlights lines with potential errors or warnings.
Best Answer
Through the built-in default SCCM reports you should be able to find a report called "MAC - Computers for a specific MAC address" (under the Network category). Just put your MAC address in there (colon separate the character pairs in the MAC) and search, it should back with any SCCM known machines with that MAC that you can then look for in the main console and delete.
Alternatively (and slightly more work), create a new collection, create a query membership rule with a criteria something like "Network Adapter" - "MAC Address" and put your MAC in as the value. It should now list any known machines with that MAC.