Quantcast
Channel: Symantec Connect - Endpoint Management - Discussions
Viewing all articles
Browse latest Browse all 6689

DS 6.9 SP5 MR3 - intermittent failure to copy unattend.xml

$
0
0
I need a solution

Got a strange one here.

2 organisations - have both migrated their DS to new (virtual) servers. Were both on Server 2003 R2, now on 2008 R2, running DS 6.9 SP5 MR3 - ie. the latest version prior to SP6.

The image deployment process is fairly generic, although I don't use the Altiris-provided GUI for image deployment.  It's a Windows 7 Enterprise WIM image - 1 of them is 32 bit, the other is 64 bit.

My image deployment works in the following way, and it has worked flawlessly ever since Windows 7 was released:

  • Boot to WinPE (32-bit)
  • Map the drives via PXE redirection
  • Create partitions/format the drives
  • Apply the image via imagex
  • Perform token replacement on unattend.xml - the only token is the computername.  One of the environments uses %SERIALNUM% for the computername, the other one uses %ASSETTAG%
  • Copy the unattend.xml down to \windows\panther\unattend.xml
  • Copy drivers down based on the model
  • Inject the drivers
  • Reboot - and Windows takes care of the rest - the dagent installs via setupcomplete.cmd

The intermittent issue I'm seeing is - the PC's are failing to get the unattend.xml copied down properly. The reason I know this is because the token-replaced file is sitting in the express share under \TEMP\%ID%.xml.  And the deployment process "thinks" that the file copies down to the client machine OK.  But when the machine boots up the first time, it doesn't get the right host name which proves that it's a problem copying down the token-replaced XML file.  How do I know this?  Because the unattend.xml file on the image used an "*" for the hostname, so the machines that fail to get the token replaced file copied down boot up with a ORGNAME-SERIAL type of hostname.  Proof that the token replaced xml file didn't copy down.

Of course, when I put a pause (press any key) in the job after the file copy, it's fine - which leads me to believe that it's a timing issue.

I'm currently trialing the use of a PING -n 10 127.0.0.1 >NUL after the file copies down, in the thought that it's a timing thing.  This never occurred when the server was 2003, so I can only think that it's an issue with the express share now being on a 2008 R2 server and Windows PE 2.1.

 

This is one of the most bizarre bugs/issues I've seen in DS in the years I've been working with it, and I'm wondering if anyone has any suggestions/fixes or if anyone has seen it before.

 

 


Viewing all articles
Browse latest Browse all 6689

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>