"Generate Sysprep configuration file using inventory data" Not Working

[Migration User]

After the update to 7.1 sp2 mp1, part of our imaging process has stopped working.  To image a new pc (Windows XP), we use a custom sysprep file and a script.  After the image has dropped and the drivers have been copied, we prompt for Computer Name and OU.  The script edits the sysprep file with the entered content and during mini setup, the PC is named and domained.

To image an existing (managed) PC, we use the Generate Sysprep configuration file using inventory data option.  This was working flawless.  It was great. We made it mandatory that someone would have to hit F12 to boot to WinPE just incase the job was sent to the wrong PC, but after that nothing had to be done.  It would eventually end up at the login prompt, named and domained and ready.

Now domaining is hit or miss and the name is the name in the local sysprep file instead of using the info for that PC in the inventory.  I have managed to get domaining to work more often, but the name is always wrong.

After the update, our custom sysprep file was gone, so I replaced it.  The sysprep file that is being used for the Generate Sysprep configuration file using inventory data option looks fine as far as I can tell.

I will add that this update really messed up our system.  We had to rebuild all our site servers to get PXE booting and imaging to work.

Any ideas, comments, information, would be greatly appreciated.  I'm not sure what to look for to make this work again.

 

Thanks

[Migration User]

There are a few things of interest here.

First, you said that other than F12 to PXE boot, you don't have to do anything, but you also said it prompted for name/domain.  Who is prompted for the name/domain, and when/how?

Second, you should look at the panther folder to see what happens vs what you THINK happened.  In there, you can see the unattend.xml file that was used, AND which sections were processed.

Third, do you select the option to use DeployAnywhere?  Try NOT selecting it to see what, if any, difference that makes.

 

That's where I'd start - especially with that unattend.XML under c:\windows\panther.  Each section will say "processed" or not, and if not, that may be what happened.  If not, you can dig through the logging, OR you can look at the file to see what may have gone wrong (e.g. not closing the XML correctly for instance, or missing a tag).

One thing we've seen happen a bit lately, is that the unattend built by people are made by a microsoft tool, and then we cut and paste into it.  The problem here is the architecture can get messed up.  IA64 is NOT the same as AMD64 or whatever, for instance.  If 3 sections are one architecture, and 2 are a different one, either 3, or 2 sections will fail to run.  Just something that helped a number of our customers.

 

Again, that's a start.  Let us know what more you find out, OH and the answers to the questions above.  :D

[Migration User]

When we hit F12 and let it PXE Boot and don't have to do anything else, that is for a Managed PC.  A new PC is not in Altiris yet, so we prompt ourselves to enter the computer name and OU.  It is the already managed PCs that are really giving us grief because it is supposed to get the computer name and OU from inventory like the "generate sysprep file" option states.  When we input the info for an unmanaged PC, it seems to be ok because our own script edits the custom sysprep file after the image has been dropped and still in WinPE.  But when this is left up to Altiris, the correct computer name is not used during mini setup.

We do not use the Deploy Anywhere option.  We have kind of engineered our own deploy anywhere.

Do you mean C:\Windows\Panther on the imaged PC or the NS or Site Server?  I found it on the NS, but there is no "unattended.xml" file, unless I am taking the name too literally.

But here is the thing.....you mention incompatibility between unattended files, but since Altiris is supposed to create its own from inventory, the file we created would be irrelevant, wouldn't it?

[Migration User]

This is getting a little more painful.  Duplicate GUIDs are being assigned now because when PCs are being imaged, they are not getting the proper computer name and they are all getting the generic computer name in the sysprep file. Same computer name = same GUID.

[Migration User]

It's like Altiris is not generating the sysprep file at all.

[Migration User]

ok, after some testing this is what I have found.

 

I took out image and stripped the sysprep.inf file from it.  Using the Deploy Image task with "Generate Sysprep configuration file using inventory data" checked I imaged a managed PC.  While still in WinPE, I then went to C:\Sysprep\ and opened the sysprep.inf file that Altiris generated.  It looked good except in the [Identification] section it said "JoinWorkgroup=workgroup" instead of the domain information it needs to domain the PC and have it end up in the proper OU.  I tried to copy this generated sysprep.inf file to a USB drive and it said the file was not there.  I rebooted and I had to enter everything manually during mini setup.  So, the file did not actually get copied to C:\Sysprep\.  Weird.

I did this all over again and copied the text from the generated sysprep.inf file and pasted it into another inf file I had on my USB drive so that I had a copy of it.  I then copied it to the C:\sysprep folder after the imaging was finished.  Now I know there is a sysprep.inf file there for sure.  It did everything unattended except domain the PC.

So....Altiris is not getting the proper domain information from inventory or the PC before imaging and it doesn't actually place the sysprep.inf file in the C:\Sysprep\ directory like it should in order for Mini Setup to run unattended.

This would explain why it isn't being named properly, because the local sysprep file is not being overwritten by Altiris' Generated file.  The PC gets domained because the domain info is in our own sysprep file and it gets the generic name we put in that file as well.

Any ideas on how to fix this?

[Migration User]

My bad on the panther folder - that's for Windows Vista and beyond.  This is XP - I missed that in the first post.  <sigh>  You went to the right place for the XP sysprep.inf file.  It's been a long time since I looked at that.

Duplicate guids will come from same name/domain combo, but... these should have unique names.  I'm not as worried about the domain as duplicate guids.  What was the machine name in the sysprep.inf file?  Frankly, I'd be opening a call to find out what's going on with that, because we can look at it a LOT faster than we can do it here in the forums (unless now that it's 4 days later that's all solved).

So when the image is completed, NO sysprep file exists in the c:\sysprep folder?  You said you looked at the one that we generated in the first paragraph, but then you said it wasn't there... so I'm not sure where you found the one we generated if it wasn't... there...  I'm confused.  Sorry.

Let us know where you stand.

[Migration User]

I'm confused too.  While in WinPE, after the image task is complete, I can open the Altiris generated sysprep.inf file at C:\Sysprep\ but when I reboot, Mini Setup uses the local Sysprep.inf file that should have been overwritten, or if I use the image that I took the Sysprep.inf file out of, I have to answer all the Mini Setup questions manually.  I have no idea why I would be able to view the generated sysprep.inf file and then it not actually be there. 

I can tell it's using the local sysprep.inf file because the computer name is BASEIMAGE.  So when they all get that same name and get domained we get the duplicate GUIDs.  We have the Duplicate GUID kit all setup, and/or a task to send when that happens.  I'm more concerned with why that generated sysprep.inf file is not actually being copied to the PC.

I have put in a support call to get the ball rolling.

One thing I haven't mentioned is that I noticed the image task says Failed with return code 1.  That's all the info it gives me.  The PC does get imaged properly though.

[Migration User]

Failed return code on imaging... Disable the use of DeployAnywhere in the imaging task and see if that givess a better result.  I'll contact the support rep too.

[Migration User]

We don't use the DeployAnywhere option in the task.

[Migration User]

OK - while we work on the rest of the problem (that is, what error you're getting when imaging or rather WHY you get an error) you can hack your way around this for now.

In the Sysprep.INF file that is either missing, or wrong, you can place your own in there as you've done in the past, but change the ComputerName line (5 from the top) to an * instead of your default.  IF you have unique computer names, the domain join might actually work as well.  Then you'd have to go back in and rename to the original name later, but at least the rest of it would/should work.

 

Let us know.

[Migration User]

Oh, the resultant line should read:

Computername=*

[Migration User]

I will test this, but I won't be changing the computer name in the sysprep.inf file for our image in production as we have scripts that look for our generic computer name in the sysprep.inf file.  We are deploying a large amount of new PCs at many locations and I'm not comfortable changing things while our regional support staff are relying on imaging so heavily.  I appreciate the workaround, but I will wait for a solution.  

[Migration User]

I'm a blind idiot.  This issue, turns out, is caused by our friend the missing FIRM file in the Task Handler folder (for anyone else watching this thread).  Thus, the image task failed.  However, being smart enough to know the image worked, we got sidetracked and looked at Sysprep instead of at the deployimage log.  One look at the log and it all became clear.

[Migration User]

Thank you very much.  By replacing the Firm.exe file the sysprep.inf file was generated and copied to the PC.  After a few more tests, our managed PCs are being named correctly and are joining the domain again.  AND....no duplicate GUIDs.  Thank you for the solution.  I now have the documentation for the MP1 update, as I am sure there will be more cleanup to do.