Deployment Solution

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!

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

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.

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.

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.

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)

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.

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.

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.