Client Management Suite

 View Only

  • 1.  Really simple one - return a value from within a script so that it can be used in a job

    Posted Jan 13, 2011 07:03 AM

    Hi,

    Should be a simple one I hope. I'm trying to write a script which will prompt the user for their computer name when doing a new build - It's a work around until Predefined Computers is a bit more usable!

    I can't work out though how to return the value the user enters to Altiris to be substituted in to other jobs (specifically, an apply configuration job to set the computer name appropriately).

    I'm just testing this on my own PC just running the script on it's own from within Windows and checking the Task output.

    I've tried doing it from inside a Function called main() with main=value at the end - and the function is defined but never called. I call it but it still doesn't return the value back to Altiris - which is not surprising.

    Any thoughts?

    Regards

    Dan



  • 2.  RE: Really simple one - return a value from within a script so that it can be used in a job

    Posted Jan 13, 2011 08:34 AM

    I was looking for something to do the same. Unfortunately i'm not a scripter so if you do get this going It would be great if you would let me know how you managed it.

    Joe.



  • 3.  RE: Really simple one - return a value from within a script so that it can be used in a job

    Posted Jan 13, 2011 10:17 AM

    Is sysprep an option?  Specify COMPUTERNAME= and leave it blank; they'll be prompted after the image is sent.



  • 4.  RE: Really simple one - return a value from within a script so that it can be used in a job

    Posted Jan 17, 2011 09:46 AM

    and I'm not sure that would work. There is no Mini-Setup in use, Sysprep runs silently - DS takes care of that.

    But anyway, what I am aiming for is PXE boot, select job, enter computer name, go home. No need for anyone to be there, and it is ready first thing the next morning.



  • 5.  RE: Really simple one - return a value from within a script so that it can be used in a job

    Posted Jan 17, 2011 10:30 AM

    What if you used a token, like %JOBNAME% or %CALLINGJOBNAME%?

    You'd have a predefined reusable job called Reimage (Reboot to PXE, Deploy Image, Reboot to Production, Apply System Configuration).  The Apply System Configuration job sets the computer name to %JOBNAME%.  All you have to do each time is clone the Reimage job, rename the copy from 'Reimage' to 'HARK-PC' (or whatever), and apply it to the computer you want to be called HARK-PC.

    It's kind of a workaround, but it seems like it might meet your needs.  I agree it's odd that it's not simpler -- or maybe I'm missing something.



  • 6.  RE: Really simple one - return a value from within a script so that it can be used in a job

    Posted Jan 18, 2011 03:50 AM

    Thanks to Thomas Baird for an answer on this:

    https://www-secure.symantec.com/connect/forums/predefined-computers-ds71

    Call WScript.Quit(returnvalue) in your script.

    The problem is that WScript.Quit only takes a numerical value, so great for asking a user yes or no questions, but hopeless for computer names.



  • 7.  RE: Really simple one - return a value from within a script so that it can be used in a job

    Posted Jan 18, 2011 04:03 PM

    For what its worth I would probably make use of a hidden share that the PECTAgent (in WinPE) could access and have my script post the results up to a text file in that location.  There will be a DS token that you could use that will be unique for that particular job to name the file and make it unique (sorry can't remember the DS7.x tokens off-hand).

    You could then have a task script run on the NS that reads that file and updates the sysprep file accordingly.

    That also means you could make more than one decision at the client, record them in the file and then act upon them automatically in your job/tasks.



  • 8.  RE: Really simple one - return a value from within a script so that it can be used in a job

    Broadcom Employee
    Posted Jan 21, 2011 08:29 AM

    Hi SharkSmart,

    The way you exchange text data between process is via pipe or files.

    Both of these options are shell based, using the '|' sign for pipes, '<' for console input redirection from a file and '>' for console output redirection to a file.

    Additionally in _real_ shells (like bash) you have the option to execute commands with commands (using back ticks  '`').

    But let's not go there (as it doesn't exist in DOS, the default Windows CLI shell).

    Microsoft gives some examples on how to handle data from stdin:

    http://technet.microsoft.com/en-us/library/ee156599.aspx

    So you your first program outputs the computer name (from whereever you get it, web-service, popup window etc) you can take this output in your next script via VBS stdin functions Read, ReadLine or ReadAll.

    Readline will read a single line and return, which is good when you only need to pass a single string, but if you need more _power_ you can use read which allows you to define the count of bytes you'll get from stdin, then you can handle more complex data exchanges etc.

    Now how this would tie in Client Agent Tasks is simple: run the cmd shell with your process writen in batch.