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

Prompt for computer information during Deployment job?

Created: 21 Oct 2013 | 9 comments
I'm hoping I am making this way too difficult and that there is an easy solution:
 
Using Deployment 7.1, I am making an image job that will image a computer then perform our standard configuration tasks & software installations, and I would like to use it for initial deployment as well as reimages.  The difficulty I have is in gathering the unique client information, particularly when using initial deployment of a new system.
If reimaging via the console, I am using my own variables such as %!ComputerName!% and %!AssetTag!% on scripts and they are set to "Prompt me for task input each time the job is run."  The prompts are then displayed when the job is scheduled and all is good.
 
My real difficulty is during Initial Deployment.  I have tried having scripts launch on the client to prompt for this data, but when I view the script output, I am getting more information than I need, so I cannot use the output data later.
 
 
For example:
----------------------
Command Script:
SET /P computername= Please Enter Desired Computer Name:
ECHO %computername%
 
Output:
Script:  Please Enter Desired Computer Name: <COMPUTERNAME>
----------------------
VBScript:
ComputerName = UCASE(InputBox("Please Enter Desired Computer Name:"))
WScript.Echo ComputerName
 
Output:
Script:  Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.
 
<COMPUTERNAME>
 ----------------------
 
 
So my question is two-fold:  
1. Does anybody have a similar process that may be a lot more simple than I am thinking?  
2. Any ideas on how to prompt for input during initial deployment then use this output data as a variable in a later task?
 
 
 Thanks for your help,
 Erin 

Comments 9 CommentsJump to latest comment

Thomas Baird's picture

There are several custom scripts around that do what you're asking, but frankly, what you're providing there is pretty much it.

As for using the data for a later task, there are a couple of options.  1) it becomes part of inventory data if you do it right.  Might not be the answer you want though.  2) I've had a customer that actually used OSQL commands via command script to write data to a custom table.  Creative, obviously not supported.  But it can work, and tokens can access that data.  3) You can store data in wild-cards or system variables that can be called by follow-up scripts so long as you don't reboot, OR you can store data in registry keys (if you know how to write to production registries) OR you can store data in text files on the system drives.  

I've seen nearly every one of these used at one point or another.  I PERSONALLY liked the OSQL stuff best because it's accessible anywhere, but it's also the trickiest to put together IMO.

GL - maybe someone else here will simply give you a massive powerful tool.  Here's hoping!

Thomas Baird
Enthusiast for making things better!

 

degoen's picture

Thanks for the info, Thomas.

I had thought about storing the data in SQL, but was aiming for something a little more straight forward (especially since I'm trying to develop this process for a project ASAP).  And I'm not sure the system variable or reg key solution would work as I am imaging the computer between the prompting and the application of the data.

Perhaps I am simply using these tokens wrong.  Should I be able to prompt for data using vbscript or DOS and have it directly define a token?  As of now, I have it as written above: gathering the data then performing an echo.  Then I have another script basically saying echo %!computername!%, and that is set to "use output from a previous task (Script)."  Can I do something without that second script -- just have it define a token using the user input?

Thanks again

Thomas Baird's picture

What you do is take your second script and prompt for the data in it.  No output.  For instance, you could define your computername, and in the next line, you could read the Unattend.XML file, then search for a random wildcard you know (e.g. !!MyVariable!!) and replace it with the variable stored in computerName, and now you have only one script.

Thomas Baird
Enthusiast for making things better!

 

BugTastic's picture

I put an idea in the ideas section a looong time ago where you could enter hostname & OU container for machine to go in. Seems a logical thing to do (SCCM does it) apparently writing your own script is a better way to do it (allthough I've yet to see one that works ) ergo, if you dont want to use the silly prestaged import text file method then your left with The manual process of renaming and moving to correct OU. Theres too many 'Write your own scripts' solutions for altiris to be honest.

Thomas Baird's picture

Bugtastic, For moving a computer to an OU, we generally recommend a configure workstation task.

Which BTW may give another option for this request.  What if for Initial Deployments, you simply let the system get a generic name (random, generated by MS) and NOT join a domain.  Then, once the system is up and in production, you assign a Configure Workstation task for the name and domain.  Automated fully? No.  But then, if you need a script during initial deployment, you're assuming there is someone sitting at the system waiting for initial deployment to fire and then fill in the blanks.  Why not just let it do it's own thing, and then once done, have someone enter the information in from the console?  The user can't really log in until then, granted, but it's still another option.

And no custom scripts.

Just a thought.

Bugtastic is right - there are a lot of custom scripts out there.  But let's face it - there's almost always an alternative that would work without a script.  Sometimes, like with DA, the alternative is a lack of understanding (DA actually works, but many assume it does not).  Sometimes, it's because a company has documents and procedures that MUST be followed for... whatever reason.  But for most, as with this request, it's not because it CAN'T be done another way.

For you, degoen, you figure out what works best for you, and I hope this helps.

Thomas Baird
Enthusiast for making things better!

 

BugTastic's picture

To behonest - you are quicker to manually rename a worksation than getting someone to create a task to give it a name and add to domain in the right OU.

At the moment I have the intial deployment menu. Once a job is selected it will deploy windows 7 and give it its Min* name and I have a task to add it to the domain. The operator then renames the Computer and moves the machine account to the correct OU. This requires 2 actions on the techs part. 1 at the beginging and one at the end. If the hostname and OU could be entered at the Initial deployment menu then only the first task would be required.

p.s. DA actually works sometimes (I just logged a ticket and the result was I had to disable the DA tickbox and run a script to call deployanywhere - which I belive may have caused other issues which I am still investigating, but hey - thats another story)

Thomas Baird's picture

If you have to disable DA and run it stand-alone to get it to work, I'd be interested to know why.  That's... fascinating.  PM me your case#.  I'd like to look that up.

Thomas Baird
Enthusiast for making things better!

 

jpellet2's picture

A lot of interesting talk here. Here's what we do that works quite well.

We do use a VBscript that captures the name for the machine by our techs..however there is also a timeout so if no name is entered, the name in the console will be used. 

That name gets placed in a text file on the X: drive when PXE booted. After the machine is imaged we then grab our unattend file and replace the computer name line in the file with the name that was placed in the text file, now the rest of the job completed, machine is named, everyone is happy.

We bind to the domain by script as well, one of the first tasks after mini-setup. We use a script to do it as we've found it a lot more flexible meaning we can tell the OU to bind to and even force a bind if the machine already exists in AD (which can happen from time to time). Of courses there is no real reason we couldn't capture the OU by script initially and modify the unattend file for binding also, we just choose not to.

BugTastic's picture

I know its asking a lot but it would be good if someone could create an article on how to do this. It seems to be such a 'missed' feature that a lot of people would appreciate it.