I notice an extra S in the word "/compress" in your ImageX command line. Not sure if that's really on your core or if it's just a typo in the Community.
It would be nice to see the log files.
Can you please gather them and post them? The CaptureHandler log I would be interested in seeing.
In addition from the Logs directory on the core server you would want to get Prov_Schedule.exe.log.
The following document details the log files used during provisioning jobs:
In addition, what actions do you have in your template prior to the Imaging action?
If you are mapping drives earlier on, you likely shouldn't be. The capture action will map them for you.
If they are already mapped, it will fail to map again and the imaging will fail.
Review the deployimageactionhandler.log on the client in the windows\temp directory. This may point to a maptopreferrredserverhandler.log.
I did have mapping to the imaging tool location and to the Data location. I have removed that mapping and will try again.
You mention that you are mapping the drive, and I can see that you calling the F:\ drive. If you are using LDMS 9.5, or LDMS 9.5 SP1 that is not necessary. Simply enter the UNC (i.e. \\servername\sharename\folder\imagename.tbi) in the Capture Image action and as long as you have setup the server in the list of Preferred Servers in your LANDesk Console it will map the driver to server automatically.
I removed all mapping references and added my server into Preferred servers.
It shows in the logs that it copies the file for the imagew (downloadhandler.log)
I also show the imagew is working in CaptureImageHandler.log
HOwever I see the following in CaptureImageHandler.log
ExecuteCMD maptopreferredhandler.exe /path="\\prodldsk001.medpro.com\osd\imagedata" /driverletter=f /nopref
created process, file handle 4c with non-readonly parameter
Process Exit code: -1
Failed to Setup envionment for imaging type LANDeskWinV2
I also opened up maptopreferredhandler.log and saw the following:
*****Mapping to: \\prodldsk001.medpro.com\osd\imagedata
drive letter = f
lddwnld.dll version is too old or missing. Aborting download.
Could not map or unmap drive. error code: -1
End of Map Drive. Path used: - .
I have no other actions in my provisioning template, ONLY the capture action and that's it.
Also new command for capture is as follows:
LANDesk ImageW V2
/b /d:0 /rb:0 /f:\\prodldsk001.medpro.com\osd\imagedata\NewImage.tbi
Not sure if the coreserver name is needed there or if it's implied.
I'm looking over ther referred documentation as well to see if I'm missing a step in the preferred server setup or something. Thank you very much for your assistance.
What version are you on and what patches do you have installed?
I think in this case you need to re-deploy your PXE representatives.
Your boot.wim that the PXE representatives are using is outdated, thus it contains an outdated LDDWNLD.DLL.
The following document details how to deploy the PXE representatives.
I'm on 9.5 SP1.
I copied the boot.wim from the server to my PXE rep. Still no change, same error message. in maptopreferredhandler.log
Does it have to be a actual redeploy of the PXE rep? Or does the boot.wim need to be "updated" in some way on my coreserver?
It's always a good practice to do a full re-deploy.
I agree. I have to make a custom change to the boot.wim in order for it to boot on our Lenovo's so it's an extra few steps, but I have redeployed the PXE Rep, and am still getting the same error.
Does my PXE rep also need to be in the Preferred servers listing?
Do I need to use any Sources from the Content Replication configuration page?
Drop to a command prompt in WinPE, compare the LDDWNLD.DLL in the LDCLIENT dir with the LDDWNLD.DLL in the LDLOGON share on your core server. If they don't match, something is wrong.
Bam! Killed it. Copied lddwnld.dll over from the LDLogon share on my Coreserver to the boot.wim on my PXE Rep and now it's working. I'll take a look at the boot.wim on the server and see if something is just getting lost between the server boot.wim and the boot.wim on my reps.