Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Annual Tidying of Scripts on DS6.9

Variables, Stored procedures and logevent
Created: 07 Jul 2014 • Updated: 07 Jul 2014 • 2 comments
ianatkin's picture
+1 1 Vote
Login to vote

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,

  1. 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.
  2. 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,


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... ;-)

Comments 2 CommentsJump to latest comment

ianatkin's picture

Amazing what a good night's sleep will do.

As I'm using a custom stored procedure (sp) to shoe-horn in a variable storage and retrieval process, I might as well create my own sp for for variable storage directly. That way, I can bypass the need to use logevent and the location table.

So now I have to save the variables the following few lines in the first task of a job,

REM %#*"{ call Custom_StoreVars (%ID%,'XML','Win7_Ent_%OSPROC%.xml' ) }"% REM %#*"{ call Custom_StoreVars (%ID%,'DAGENT_PATH','M:\Agents\AClient') }"%

and to retrieve the values I have,

SET DAGENT_PATH=%#*"select value from custom_vars where varname='DAGENT_PATH' and computer_id=%ID%"%
SET XML=%#*"select value from custom_vars where varname='XML' and computer_id=%ID%"%

Not for everyone granted... but a better for making environment variables more 'global' in my DS job execution chain.

And also rather handy as for long term storage of other data for each particular machine.

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which assist you most in resolving your problem, and give a thumbs up to useful articles and downloads

Login to vote
SK's picture

Very nice Ian.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Login to vote