Skinning Cats the Nerd Way

Today I got a walk-up request: "We need to put a unique INI file on 500 machines and then invoke a client-side utility to import the INI into a client-side database which is part of a client-side application that uses that configuration data to establish secure connections to a remote server.  The clients are running inside Microsoft MED-V.  We have a spreadsheet with the unique ID-pairs for each of the 500 computers, but there's no names.  We need to fetch the names from AD and populate the spreadsheet to match them up and then use that to generate the INI files."

Piece of cake.  Um… ok…

1. Add a column to the spreadsheet for the computer names
2. Run a query to collect the computer names from a specific OU in our AD environment and push the names into the column in the spreadsheet.  Save the spreadsheet (it doesn't change ever again after this point, except to add future names… maybe).
3. Obtain a template of the INI format.  Replace the unique values with sentinel strings (e.g. "PID1" and "PID2", etc.)
4. Read the INI template into memory
5. Read the spreadsheet rows, and for each row, create a copy of the INI template cache by substituting the sentinel values with actual values.  Save the copy to a unique INI file in a designated folder.
6. Run a PSEXEC (Sysinternals) remote process to invoke the client-side .exe utility to import the INI data from a specific INI file from the shared folder across the network.

Questions: 

1. How many scripts will it (did it) take to accomplish this?
2. How long will it (did it) take to write it / them?

Answers:

1. Whatever works for you.  For me it was three scripts:  One to query AD and populate the spreadsheet column.  Another to read the spreadsheet and generate the INI files.  And another to iterate through each of the INI file names and execute PsExec with the appropriate command syntax for the utility and the unique INI file and path.
2. Who cares.  I can (and will) say that if it takes anyone more than 2 hours they're taking too long.

Tid-bits:  MED-V runs a virtual client which is joined to the domain as its own unique name, so you can access it like any other computer provided you have sufficient permissions and the access gateways are opened up (firewalls, services, etc.)  So the PsExec script is aimed at the MED-V clients, not the physical clients.