Deployment Solution

Hi,

I'm currently implementing DS7.1 as our first automated OS build solution.

The problem I have is with new machines. Some of the software we deploy is dependant upon the machine being named correctly when it is installed, and using Initial Deployment causes the software to be installed under a temporary name like "minint-a123456".

So I'm looking at using Predefined Computers to provide DS with information about the machine before it lands.

A bit of research shows that DS6.9 was quite happy as long as it was provided with Serial Number OR MAC address, but DS7.1 MUST have UUID, MAC Address, and Serial Number.

The UUID is 32 characters long and tedious to write down and add to a spreadsheet, so I'm hoping someone can tell me of a way to get round the UUID.

Any thoughts?

Regards

We have a fix already - just not sure if it's public.  Checking on that, though I suspect it'll be in MR3.  I'll keep this thread posted.

is that this will be fixed in MR3.  For now, stick with the ugly.  MR3 is due out mid Dec, and appears to be on-target last I checked, but of course, could slip.  Keep an eye out for it in a couple of weeks or so.  Pre-christmas gift if all goes well.

The fix is that you'll only have to put in one or the other, or more if you want.  We're also I think trying to fix the little issue with it not working if you don't include an IP addy (and if you have more than one site server and are connecting to something other than the NS for task).  In other-words, some good fixes are coming for DS in MR3.

Excellent!

Any idea if the issue with certain HP laptops not Ghosting is fixed? Discussed it with Symantec Support a little while ago, not sure if it filtered through to the devs......

Regards

Do you have a KB or case number?

Case 413-058-844

Basically the newer HP BIOSes present the CD drive as the first device not the hard disk.

As Ghost is set to image the first device, it crashes when it tries to write a partition table to an empty CD drive.

I thought it was just that HP had wired them backwards, but then older machines started doing it after a BIOS updates.

Laptops aren't a huge problem as we just disable the CD drive in the BIOS before PXE booting, but desktops we have to crack the lid off and disconnect the CD!

It may well be something that HP need to get their head in gear about, but if Ghost can be given some option to look for the first HD, not just the first device it is given, it would make things a lot easier.

Of course, changing the Image task to hit the 2nd device won't work as not all machines have CD drives and not all machines have this issue - so the other machines that work fine would then break!

It'd be a real shot in the arm if that could be fixed!

Did this change make it to MR3?

We're still testing the solution and ran into some problems with it, so it wasn't able to make the cut.  I apologize.

The fix for predefined computers is somewhere near #1 on our hotlist, but it's not done yet folks.  Just thought I'd update you on this.  We've found some unexpected issues with our resolution and are working through those before we release it.  I think though that one "version" of the fix is now being field tested - not positive, and no word back on the results.

I expect to see this fixed in ITMS 7.1, but frankly wont be too surprised if we have to wait for MR1 a few months later.  We can't afford to introduce more bugs even for ease of functionality.

Thomas,

Thanks for the update. It's holding up implementation of Altiris right now for us - a piece of disk encryption software we use needs to have the correct machine name at installation, and adoption will be exactly zero if our guys have to collect a 32 digit GUID, Serial number and MAC Address for every build.

I'll forward this to the team.  Thanks!

Can anyone think of a way of having Automation ask the technician for the computer name as part of Initial deployment? I tried running a command script or vbscript from inside Automation to ask this but it seems that automation doesn't support scripts....

If it's a part of the job though, you have to be sure it's executed as "system" - not a specific user or it will fail.  There is no user account in WinPE, so you have to run as System.  Because of that, mapping drives REQUIRES you enter user credentials and password, since the System account does not have ANY network access.

We have people running scripts in automation all the time.  VBS is supported, but remember that it's usind CScript, not WScript - there are subtle differences.  The best way to test is to get a system up in WinPE, connect to the network, make changes, test it, change it, test it... etc.

Lots of people in the forums here are using scripts to do HII currently based on a WMI call to the system computer model.  They then do a lookup on the network for all drivers for that model and pull them down manually.  So believe me, scripts DO work in automation.

Does that help?

I tried running in Altiris service account, system and Current Logged in User. I think what I established was the the script was running but just wasn't giving any visual prompts to the person on the machine. I'll have another go and start another thread if I can't get anywhere.

Won't be able to do anything with it for a while yet though as all my DS jobs are currently cabbaged! Oh joy.

So I know that at least one customer has predefined computers working with just MAC, but I'm not sure yet if that is a public release or if we all need to wait.  I'm trying to find that out among a billion other things.  We're not yet flexible enough to accept any one of the 3 though, so those used to using Serial#'s - we're not there yet.  Again, this is all still being worked.

The scripts I've run in automation generally work, UNLESS I forget that we don't use WScript, we use CScript.  The differences are subtle, but for things like user prompts, can be critical!  WScript has a different set of prompts than CScript has, so be careful.  Do your research.  I ran into a prompt issue once and that was literally the only difference - had to use a different prompt command.

Try a short script as a test:

msgbox "hi"

if that works, you know your scripts are at least "capable" of displaying and accepting user interaction.  Remember to run as System.

GL all.  I'll try to post if that point-fix becomes available to the public, or even if you have to call support to get it.

But no-one could answer it. The problem is I don't know how to make the vbscript return a value back to the job to be used in the Apply System Configuration task - I can return a value from within a function but not return it to Altiris to be of any use.

Any suggestions?

I can get a value back to the console (wscript.quit(value)) but I'm not sure that the apply system configuration task will take wild-cards or tokens.  We do have limitations on what kinds of tasks will use tokens.  Script tasks will, but many of the other task types will not.  I've expiremented with modifying the other tasks using tokens and it hasn't worked.  That's a feature request that we should bring up, but it has to wait.

What specifically are you trying to get into the system config from your script?  Serial#?

but the script errored:

C:\Users\dharker\AppData\Local\Temp\AltirisScript05FF293009865FBF8.vbs(2, 1) Microsoft VBScript runtime error: Type mismatch: 'wscript.quit'

Here is my script:

a = InputBox ("Computer Name")
wscript.quit(a)

The idea is that as a work around for Predefined computers, this script will allow me obtain the correct host name for the machine before the disk encryption software I mentioned installs and causes problems because the host name is set wrong. You see, the software connects itself to the server and performs key backups based on the current name. It then doesn't update the backup with the new name when the computer name is set correctly, so the backups are all in the form minint-xxxxxxx, and the key backups are very important as they are the only way we have to get in to a machine where a user has forgotten their password.

If you can spot what I have done wrong with the above script I will try again.

Had I have put my brain in to gear I would have realised that it was a type mismatch because WScript.Quit only takes a numerical value. Rats.

Back to square one!

Here is the forum thread where I am discussing this

https://www-secure.symantec.com/connect/forums/really-simple-one-return-value-within-script-so-it-can-be-used-job