One of the things about writing DS jobs in a rush is that the end result is often really difficult to repurpose and port to other servers. This is because my DS jobs contain many tasks; so rushing inevitably means that many aspects are hard-coded.
As a programmer having hardcoded elements distributed throughout a complex job goes against the grain; when programming I try to place all those nice user-editble variables at the start to make it clear that only one area needs attention when changing simple items like file locations.
However this is tricky to do with DS... sharing user variables between the client production, automation and the server is just plain awkward. In the past I've tried various routes to get around this,
- Creating on the fly and environment variable batch script (named %ID%_env.bat) on the deployment share. This hosts all the user-editable variables and can be called at the start of each script task to ensure they are available for use. It works but is cumbersome and has the drawback it's only useful for script tasks.
- Uploading variables into the SITE filed in the Locations table. As I've not seen a site yet that prompts the user to enter information for the Location table (contact, phone, email, department, site, mailstop) this has been useful. Was most useful in storing PXE server IP data without confusion as the SITE field here can kind of make sense for that. Using location fields also has the disadvantage that variables are obfuscated (i.e. you might be using the email field to store the location of an XML file).
Today though I wanted to bite the bullet on this one and revise all my OS build jobs to use one method. After revising the scripts I had built over the last few years, I plumped for the Location data as this permitted varianles to be utilised in both File Copy tasks as well as script tasks. The drawback however here was that my sharable variables would be limited to 6 in number and obfuscated.
So... what I now have is a job format which as one of the first tasks uploads my much needed job variables into the database using logevent as the handy upload mechanism,
WLOGEVENT -l:1 -ss:"VAR1(%OSPROC%)"
WLOGEVENT -l:1 -ss:"VAR2(%SYSPREP_XML%)"
WLOGEVENT -l:1 -ss:"VAR3(%GHOSTFILE%)"
WLOGEVENT -l:1 -ss:"VAR4(%MAINTENANCE_BACKDROP%)"
WLOGEVENT -l:1 -ss:"VAR5(%AGENT_INSTALL_SCHED_TASK%)"
Where the variables quoted above are onces which I need to made available throughout all the 7 tasks that make up this particular job. Once these events in the database I then copy them into location tokens which are native to the engine. This I do with a script which calls a stored procedure I made Custom_LogeventVarsToLocation,
REM Server: Store script Variables
REM %#*"{ call Custom_LogeventVarsToLocation( %ID% ) }"%
which just looks at the status events logged on that machines, parses it for VAR comments and copies these to the appropriate fields in the location table. So that's a couple of extra tasks in my job set to achieve the job portability which should make future maintenance a bit easier. Our techs here I'm sure will tell me otherwise over the coming months if that's not quite worked out... ;-)