A useful feature that allows you to use any data in your Deployment Server database in a script task is Custom Tokens. The syntax for a custom token is %#*"Your SQL Query Here"%. Here are some custom tokens that might come in handy.
%#*"SELECT GETDATE()"%
will return the current date and time.
%#*"SELECT @@servername"%
will return the name of the SQL Server.
%#*"SELECT g.name FROM computer c, computer_group g WHERE c.group_id = g.group_id AND c.computer_id = %ID%"%
will return the name of the group that this computer is a member of.
Hello, still no news for the %JOBNAME% in 7.1+ ? Thanks
Hello, any solution for Jason's question, we are also interested in the %JOBNAME% token?
Hi, any answer for Jason nice question ? we are interested also :)
In DS 6.9 there was a nice %JOBNAME% token. I use this token when imaging computers. How would I write something equivalent in DS 7.1? I am looking for the specific table that I would need to query as well as the format.
OH OH OH.
The DB and nominclature is COMPLETELY DIFFERENT than in DS 6.x. No, you can't use that methodology.
And I'm really confused on why we're posting on this thread.
But in DS 7.1, you have to first create the custom token in the NS Console (remember, this KB was written prior to the existence of Ds 7.1) and then you have to insert it into your script from there. Yes, you can use custom tokens, and yes, you can do fun things with them, but no, this sintax will not work.
Hi All,
I've tried to run Script task (command script or vbscript type ) with the custom token
%#*"SELECT GETDATE()"% on SMP 7.1 and got empty result. Does the SMP 7.1 support the custom token?
Is there a particular reason to have two scripts if they feed off one-another?
If there was, then My guess is that you'd be best to actually use SQL to write to the DB in a known location, maybe based on WS GUID or something, and then make your next script query the DB based on the same key. It'd be easier to combine the scripts, or possibly to use a return code, but there's a thought. Writing to the DB might be interesting though...