Capture Template Fails

You may want to check your preferred server and make sure the "write" credentials are specified and correct.  These are necessary when capturing images.

In WinPE, you'll find the provisioning logs at x:\ldprovision.  If you use net use to map a drive, you can copy *.log from x:\ldprovision to your mapped drive to retain the logs.  Start with the ldprovision.log and see which action failed.  Then look up the log for that specific action handler to get more details on the failure.  For example if the capture image action failed, you can look at the captureimagehandler.log file. 

This doc explains the process in more detail:

How to copy log files from WinPE and troubleshoot failing template actions

I had a problem where my template for capturing profiles worked prior to updating to LDMS 9.6 SP3. The problem was with the curlib.dll got corrupted during the upgrade process.

In support we have seen that happen on some occasions.  Generally you can compare the versions, file size and date with curllib.dll on your core server and use a script to copy over the correct version or the non-corrupted version  to all your devices.  If you use a managed script you can still deploy it with landesk even if curllib is corrupt on your clients. 

You may also want to run streams.exe -s -d on your LANDesk install directory.  If Alternate Data Streams are present it can cause corruption. 

In  your packages, provisioning templates etc. whenever you reference the core or a preferred server you should use the naming convention that is configured in the preferred server record for that particular server.  Each customer's environment and DNS could be unique.  However it resolves in your environment is what is going to work for you.  Some customers will find that FQDN works better than shortname, but for you shortname is working better.  We do recommend configuring two preferred server records for each server, one by FQDN and one by short name just to cover all your bases.

Hi,

I ran into the same issue yesterday and made sure that everything is correct. However, The only way I could capture the image was by doing the following:

1- When the image capture fails, I opened a new console and mapped the shared drive.

2- From the same console. I went to X:\ldprovision\ldprovision.exe and executed it.

3- It asked me for a domain username and password so I entered the same ones that I used in the preferred server "I used a domain admin account" and then clicked OK. then the capturing started.

Please note that the task in LDMS showed as failure. However, the image was captured successfully.

I am leaving my notes here as it may help someone in the future

It sounds like you are satisfied with your workaround, but if you take a look at the provisioning logs we could probably solve this for you.  My hunch is that the map to preferred action is failing.  If you can map a drive manually, but the same drive using the same credentials via landesk fails, it is almost always a cert issue. 

If you would like more assistance take a look at the community doc I linked above that describes how to retrieve and view provisioning logs, and then let us know what error or errors you are seeing in the logs.

Sorry for my late reply. Yes the issue is actually with mapping the drive and I used to check the logs that are under the path X:/ldprovision/maptohandlers (or something similar) and it was pointing that the creds. supplied couldn't be used to map to the preferred server.

However, I noticed that when I use a local account to map into the drive using the OS provisioning it works without any issues. Could you please let me know can this be solved when using a domain account for the preferred server and to map the drive?

The product does allow the use of domain accounts, in fact most customers have it setup that way. 

Just to clarify,  you are specifying the local account in the preferred server properties, and that works, but when you specify a domain account in the same place it does not work?  Can you use net use and map the drive manually using the domain account?  Obvious question but, does the domain account have sufficient rights on the preferred server?

Yes you are right. About the permissions, I am using a domain admin and made sure that he has full access on the share folder.

Little tip from my side - try using a server-local account.

This is mainly from *my* experiences, but I generally try and avoid domain-related authentication / anything related to domain if at all possible during imaging, because (for some weird reason) DC's chose to have THAT particular moment to misbehave authentication wise / jump off the network and any other ways of giving you a "haha - screw you" feeling .

Server-local accounts do NOT rely (as much) on network / DNS / DC's etc. working properly - so it MAY be worth trying it out. (Of course, you need to be quite careful in making sure that those local accounts ONLY have access to those shares you specifically want them to have access to -- and don't take shortcuts like giving them local admin access etc -- generally "service accounts" without permission to logon work well).

If you find that a local account DOES work and your domain one does not - you have (a) a workaround for the time being, meaning less pressure on you while you're trying to figure out why domain authentication isn't working as well as you'd need it to.

Again, down to my own experiences only -- if you have a rock solid network, it's fine to use domain accounts & so on (and most folks do). I - personally - prefer not to, as "anything that relies on the network functioning properly" tends to have this weird tendency to act ornery when I'm supposed to have a look more often than not .