Deployment Solution

I am getting into image automation by using jobs/tasks . If I try to deploy the Windows 7 x64 image and include deployanywhere drivers I consistently receive error 183 in the details of my failed image job. If I uncheck deployanywhere the image goes through successfully; of course without any drivers. So DA must be the cause of my 183 error and I have no idea what exactly is causing this 183 error and how to remediate it. As of August 2014 we are using 7.5 SP1.

Below is a copy of the message I am consistently receiving:

ErrorMessage: Exception has occured in File Tcube_ClientImageDeploy.cpp at Line No 1208. Type of exception is ClientImageDeployException. Error Description is Child Process returned an error. The exit code from process is 3. Value of Windows error code = 183 and message is Cannot create a file when that file already exists.

FYI, this has to be something to do with deployanywhere. I made up a XP image for fun. This one fails also exactly like the 7 image, same error also.

I see the same issue when imaging sometimes. I was actually adding drivers so I was looking closely at the process and I agree it's DA. I think my issue at least has to do with not being able to get the drivers from the site server. Here is an excerpt from DSTasks:

common\util\SMPPackage.cpp@707: Error in downloading file from HTTP.source :http://<servernamehidden>/Altiris/PS/Share/pkggroup_{2f8cb600-b9aa-442d-a1d3-5234bfc7a014}/{20827DDD-C698-49E8-B312-830DF1D935B2}/cache/Intel_Corporation.igfx.10.18.10.3412/igd10iumd64.dll and dest :C:\Program Files\Symantec\Deployment\DriversDB\Intel_Corporation.igfx.10.18.10.3412\igd10iumd64.dll. The COM error = A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
[2014/08/27 16:07:44.237 1416:1640 0] File:common\util\ExecuteCommand.cpp,Line:4335 ERROR: Exception has occured in File SMPPackage.cpp at Line No 708. Type of exception is GeneralError. Error is A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Error Description is  "util::CSMPPackage::GetMultiplesFileFromHTTP". Value of Windows error code = 183 and message is " Cannot create a file when that file already exists.

When I manually browse to the path "http://<servernamehidden>/Altiris/PS/Share/pkggroup_{2f8cb600-b9aa-442d-a1d3-5234bfc7a014}/{20827DDD-C698-49E8-B312-830DF1D935B2}/cache/Intel_Corporation.igfx.10.18.10.3412/" it works.
"

There may be more information ABOVE that in the DSTasks log.

To the author of the thread, you'll need to find out where the FIRST failure is in the DSTasks log.  The 183 is the "final" failure - which for lack of a better word means "failed".  183 is generic. It says nothing.  We have (I know, 'cause I wrote it) an entire KB on reading the 183 error and diagnosing it.  Look at the Recommended Reading list. Generally, you can find where it fails.  Remember, find the 183 in the log, then look UP, and up, and up, until you see the last "successful" command and the first failed one.  THAT is where the problem starts, and everything after that is just aftershocks. 

<sigh - I wish I could edit that KB now...  oh well>

I can get you the whole log file if you want.

I did just speak to support and they advised me to do HF2, which I'll be trying this weekend.

Sorry, it took long to respond Thomas. I'll check it out today. I  have made myself busy with this by unchecking "Fail Job if any Task fails" and moving on to adding application deliveries and joining the domain. But I would like to have failures as an option, I'll check out the DSTasks Log today.

How about this line:

File:common\util\ExecuteCommand.cpp, Line:4335 ERROR: (Contents are in my first post above, too long to re-type)

I did a FIND for 183, scrolled up till I saw a SUCCESSFUL which was about 5 lines up. Then went down to ERROR and this was the line.

I have seen something similar before, there was one particular file that couldn't be found by the DA driver download.

Browsing to the driver directory the file did exist, however attempting to access the particular file via a web browser, it wasn't available.

I believe that it may have been a .config file, which was being hidden by IIS, and a change to the settings for IIS was required so that DA was able to download it.

Phil

Are you sure about this file being hidden by IIS? If so what is the file and where is it? Maybe I an have my Admin make an adjustment.

How I identified the file in my case, was to run the deployment as per normal, which will fail as you have described, then open the directory on the machine being built where the drivers end up - d:\drivers\symantec from PE.

This will show you how far it's got with the downloading of the driver components.

Next open the unc share to that driver on the package server, that should show you what the next file to download should have been.

Then open your browser to "http://<servernamehidden>/Altiris/PS/Share/pkggroup_{2f8cb600-b9aa-442d-a1d3-5234bfc7a014}/{20827DDD-C698-49E8-B312-830DF1D935B2}/cache/Intel_Corporation.igfx.10.18.10.3412/"

If the next file is shown, click it and see if you are prompted to save it or if it's opening as a text file etc.

In my case the file that was failing was a .config file.

The next stage is to work with your admin to make sure that all the files will download via a browser - for the package shares, all files should have the MIME type set to application/octet-stream, in my case (if I remember correctly) the MIME type for .dll.config and .exe.config was set to text/xml - note that this is correct normally for IIS, however for any package shares all files types should be downloadable, so the only entry under MIME types should be .* application/octet-stream

Phil

Hmm, so I am more or less looking for a driver file from my DriversDB that did not copy?

Kind of yes. What I found was that it had copied correctly to the package server, but the IIS settings were incorrect, preventing that file from being downloaded to the machine that was being imaged.

Looking over the drivers that were copied to the target computer. I looked at:

C:\drivers\Symantec\NonCritical1\NCCDB1\PCI

There are two sub-folders with drivers, they both happen to be the same Intel video driver. They match up with the contents on the package server.

C:\drivers\Symantec\Retarget\PCI

One sub-folder taht has the broadcom nic driver, this one also matches up with the package server.

I also checked out C:\Program Files\SymantecDeployment\DriverDB

There are eight different drivers in there and they all match up with the contents of the package server.

Overall, I found nothing missing file for file. Am I missing something else that I should be looking for????

If you can attach the logs from the machine I can take a look.

Here is my dstasks.log

Attachment(s)

DSTasks_1.txt   29 KB 1 version

Ok, so the first deployanywhere task is working, it's the second that does the critical drivers that is failing. So if you can run the following a much more detailed log file specifically for the deployanywhere part :

"X:\Program Files\Symantec\Deployment\Ghost\DeployAnywhere.exe"  /target=C:\ /HandleNonCriticalDrivers=minisetup /ddb="C:\Program Files\Symantec\Deployment\DriversDB"  /loglevel=255

Phil

I re-ran the job, failed. Ran the command you have stated above, what information do I need to give you? I do have an error line that came up just above the 'End Of Retargeting'.

Error: Registry key %1 not found on system. target_software\\Microsoft\Windows NT\CurrentVersionRegistrationOwner

DA Return code is 3(GH_ERROR).

FYI, when I build an image, I clear the contents of the string: RegisteredOwner. Then our Company Name is put in there via sysprep.inf or unattend.xml. Is this a problem for DA?

I can't see why DA would complain about that reg key, but not knowing the inner workings of it who knows! If you can upload the logs I'll have a scan through and see if there is anything else there.

Phil

Here are logs taken from C:\Program Files\Altiris\Altiris Agent\Agents\Deployment. Have fun, found a link that is giving me a begginers course in how to read those logs and understand all the data in them.

http://www.symantec.com/business/support/index?page=content&id=howto95220&viewlocale=en_US&impressions=false

Attachment(s)

Logs_37.zip   42 KB 1 version

FYI, I have case open with Symnatec. Troy has given myself a call about 20 mins ago. But look into this also if you wish. I do appreciate any help I can get.

Ok, had a glance through the logs - DA_Logs_Thu_Sep_04_11_26_22_2014 contains the following info :

Processing All Drivers Databases

Starting to look in C:\WINDOWS\inf(Windows Drivers Database) for matching INF's.

ignoring inf flile. File is   C:\WINDOWS\inf\corelist.infError: Operating System API %0 failed. [InfBase::InfBase]  SetupOpenInfFile( C:\WINDOWS\inf\corelist.inf ) WinErr no : 1168 and Message: Element not found.
-------Ghost::DA::WinDeviceDriverRetargeterWin32::ParseInfDirectory():2351

ignoring inf flile. File is   C:\WINDOWS\inf\oem11.infError: Operating System API %0 failed. [InfBase::InfBase]  SetupOpenInfFile( C:\WINDOWS\inf\oem11.inf ) WinErr no : 3758096387 and Message: Can not convert Windows error code to text-------Ghost::DA::WinDeviceDriverRetargeterWin32::ParseInfDirectory():2351

C:\WINDOWS\inf\ramdisk.inf is failed in inf validation(IsINFValid()). So not considering for DA operation. Error: File %0 not found in any .CAB. ramdisk.sys-------Ghost::DA::WinDeviceDriverRetargeterWin32::MatchInfFileToDevices():2879

No of drivers into target Windows DB( C:\WINDOWS\inf ) is 717

Starting to look in C:\drivers for matching INF's.

No of drivers into ( C:\drivers ) is 0

Path not during found durning Parsing infs. Path is  C:\drivers-------Ghost::DA::WinDeviceDriverRetargeterWin32::ParseInfDirectory():2312

Processing Driver and user Database

DDB is empty-------Ghost::DA::WinDeviceDriverRetargeterWin32::ParseDDBDirectory():3103

Total no of inf files which are not valid is 1

Total no of drivers are which are not valid is 0

************************** Start of Missing Critical Devices/Drivers for Eval/Precheck **************************

No of Missing critical drivers is 1

Missing critical driver detected : Device Number = 1

 Device Class = Net
 Device Class Guid = {4d36e972-e325-11ce-bfc1-08002be10318}
 PCI ID = PCI\VEN_14E4&DEV_167A&SUBSYS_01DA1028&REV_02
 Desc = @netb57vx.inf,%bcm5750a1clnahkd%;Broadcom NetXtreme 57xx Gigabit Controller
 Inf Source =
 Best Driver =  and No of driver is 0
 Reason For Driver Selection = No Driver
 Device Type = Unique Physical Device
 Signer Name =
 Matched Drivers = No of driver is 0 ;
 Matched Drivers Signature =
 HW IDS = PCI\VEN_14E4&DEV_167A&SUBSYS_01DA1028&REV_02,PCI\VEN_14E4&DEV_167A&SUBSYS_01DA1028,PCI\VEN_14E4&DEV_167A&CC_020000,PCI\VEN_14E4&DEV_167A&CC_0200
 Compatible HW IDS = PCI\VEN_14E4&DEV_167A&REV_02,PCI\VEN_14E4&DEV_167A,PCI\VEN_14E4&CC_020000,PCI\VEN_14E4&CC_0200,PCI\VEN_14E4,PCI\CC_020000,PCI\CC_0200

************************** End of Missing Critical Devices/Drivers for Eval/Precheck **************************

Phil

Actually, looking again,  this is the pre-check where DA looks at the image to see what drivers aren't already there, before it checks in the DriversDb.

So that ran successfully at 11:26:22 - and created the log file, at 11:26:28 it tries to run the 2nd attempt where it looks in the DriversDB, it's this 2nd one that is failing.

The  command being run is :

X:\Program Files\Symantec\Deployment\Ghost\DeployAnywhere.exe

  /target=C:\ /HandleNonCriticalDrivers=minisetup /ddb="C:\Program Files\Symantec\Deployment\DriversDB"

Phil

Is it looking for a driver in C:\Program Files\Symantec\Deployment\DriversDB that is not there? FYI, I did not mention this before; but I have a chipset driver for the Dell Optiplex 745 that will not upload to the Driver Mgr Database. It is a ICH8, I have a forum posting that I started a couple days ago. https://www-secure.symantec.com/connect/forums/fail-uploading-chipset-driver-ich8id2

I also have tech support looking at that for me also. Could taht be teh root cause to this? I hope not.

Generally the chipset drivers not being there isn't too much of an issue, the builtin drivers will work - in your case the log shows this :

Matching critical driver detected : Device Number = 4

 Device Class = Storage
 Device Class Guid = {4D36E96A-E325-11CE-BFC1-08002BE10318}
 PCI ID = PCI\VEN_8086&DEV_2820&SUBSYS_01DA1028&REV_02
 Desc = @mshdc.inf,%pci\ven_8086&dev_2820.devicedesc%;Intel(R) ICH8 4 port Serial ATA Storage Controller - 2820
 Inf Source = Windows Driver Database ;
 Best Driver = C:\WINDOWS\inf\mshdc.inf and Identifier Score is 13824 and device {PCI\CC_0101}  from compatible device HW list found into Compatible inf HW list and Rank is 4278203904(ids= 13824) ;  and No of driver is 1
 Reason For Driver Selection = Only Matching Driver
 Device Type = Unique Physical Device
 Signer Name = No Sign and signing score is SIGNERSCORE_UNKNOWN ;
 Matched Drivers = No of driver is 1 ; C:\WINDOWS\inf\mshdc.inf and Rank is 4278203904(ids= 13824) ;
 Matched Drivers Signature = No Sign and signing score is SIGNERSCORE_UNKNOWN ;
 HW IDS = PCI\VEN_8086&DEV_2820&SUBSYS_01DA1028&REV_02,PCI\VEN_8086&DEV_2820&SUBSYS_01DA1028,PCI\VEN_8086&DEV_2820&CC_01018F,PCI\VEN_8086&DEV_2820&CC_0101
 Compatible HW IDS = PCI\VEN_8086&DEV_2820&REV_02,PCI\VEN_8086&DEV_2820,PCI\VEN_8086&CC_01018F,PCI\VEN_8086&CC_0101,PCI\VEN_8086,PCI\CC_01018F,PCI\CC_0101

The Intel inf file just points back to the Microsoft inf file referenced above..

Phil

So is this one it, the Windows\inf\mshdc.inf (Microsoft Hard Disk Controller)? Is it really looking for an Intel and taking the Microsoft and then failing? Sorry but I am not seeing what is causing the DA failure.

I can't see what's causing the failure either - It's found a driver, so the fact you can't upload the Intel one I don't think it the cause.

The command runs 2 passes, the first works fine, the 2nd fails. Hopefully the error shown will enable Symantec to check what is happening at that exact line and will help to resolve the issue.

Hopefully Troy will come back with further info.

Phil

I'm curious - did they ever get back to you on this?  If so, what did you find?

In the past, there were issues with the wrong drivers being copied down from the first pass of DA.  The first run of DA creates a generic list of drivers for the system to copy down.  The second run is where DA actually evaluates each driver against the system.  The second run is NOT run against the full DB. If the driver is not copied down, then the 2nd run will fail.  MOST of that issue was fixed around HF6 in pre SP1 though, so this is a little weird.

Thus, I'm interested in what they said OR what you did.

Thanks!

Sorry I did not reply. I have not been on the forums for a little while. I put in a ticket with Symantec in September and I have bee working with a Tech over the phone. As of today no resolution, back-End is working on it. In the meantime I made up a software release of the missing Optiplex 745 drivers (audio, chipset) then making a script using dpinst.exe to install those drivers. So I myself have made progress with an automated image with this Plan B for the drivers (thank goodness the nic driver is installed by DP).

I also have a separate ticket in for the exact same problem with Windows 7 x64 using a Optiplex 9020. So far I am using the same Plan B for the missing drivers.

Wonder why DeployAnywhere still has so many problems? It has been i us since at least 7.1 in 2011 when we first came aboard with Altiris.

I hope to heard back from someone with a resolution (probably another hotfix).

interesting, 745 is one of the only models that DA isn't broken for us on.

DA was working pretty solid for me until I went to 7.5 - been struggling with it now for 10 months. See my thread here: https://www-secure.symantec.com/connect/forums/75-deployanywhere-issues-ds-upgrade-mess-me