11 Replies Latest reply on Nov 24, 2016 3:15 AM by phoffmann

    Capture Template Fails

    sy0385 Rookie

      Hello all,


      I'm running into an issue where I cannot capture an image. This is the error from the core server:


      VERBOSE             ProvisioningWebService                               10/3/2016 2:09:45 PM   : SetActionStatus (historyTaskIdn 135, historyEntryIdn 670, next -1): state FAILED

      VERBOSE             PHistoryEntry                    10/3/2016 2:09:45 PM   : Unable to write to database. Altering history task Idn 135 state is not allowed. Failed.

      ERROR  ProvisioningWebService                               10/3/2016 2:09:45 PM   : Unable to set the action status (historyTaskIdn 135, historyEntryIdn 670, next -1): History task is not in the running state.


      On the client I have the following error:


      OS partition is mounted as c:


      Action #2

      Capture Image


      Execute Result

      return: -1



      The action failed.


      I have done the following to troubleshoot:


      Ensured the UNC path is correct

      I can mount the preferred server share

      Attempted to capture with two PCs

      Used a template that use to work and recreated one.


      I appreciate the help!




        • 1. Re: Capture Template Fails
          jaysmith SupportEmployee

          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

          • 2. Re: Capture Template Fails
            technobabble Apprentice

            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.

            • 3. Re: Capture Template Fails
              jaysmith SupportEmployee

              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. 

              • 4. Re: Capture Template Fails
                sy0385 Rookie

                Thank you for the input! I found the issue, the preferred server name was configured with the domain name, this is located in the LANDesk management console>Content Replication>Preferred Servers>Server name. After taking out the domain name it worked like a charm!

                • 5. Re: Capture Template Fails
                  jaysmith SupportEmployee

                  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.

                  • 6. Re: Capture Template Fails
                    Motaz ITSMMVPGroup



                    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

                    • 7. Re: Capture Template Fails
                      jaysmith SupportEmployee

                      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.

                      • 8. Re: Capture Template Fails
                        Motaz ITSMMVPGroup

                        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?

                        • 9. Re: Capture Template Fails
                          jaysmith SupportEmployee

                          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?

                          • 10. Re: Capture Template Fails
                            Motaz ITSMMVPGroup

                            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.

                            • 11. Re: Capture Template Fails
                              phoffmann SupportEmployee

                              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 .

                              1 of 1 people found this helpful