9 Replies Latest reply on Jun 13, 2018 9:26 AM by GaryOco

    Deployment template - stopping around the Agent install/update

    GaryOco Apprentice



      We're very new to EPM and are an onprem client. I've been developing our deployment template which has been going well until now. For some reason the last day or so the deployment template crashes out around the Agent Install/update settings part and then fails all of the next steps. I appreciate if I untick the "Stop processing if this step fails box" the task continues but all of the steps except join domain fail.


      Nothing has changed to the template, the only settings I'm aware of that we've changed are the Patch folder location - which we moved off of the C drive due to Windows Updates every expanding content and set a policy in the Agent Reboot configuration to act as though a reboot is never needed (this latter amendment is temporary)


      I know the log locations for the WinPE deployment part, but I'm unsure where to start looking for logs once the image takes over (following the Configure Target OS step) to show why we are getting this issue with the Agent install/policy update steps. Can anyone help?


      This is my deployment sequence:



      These are my configure agent and update landesk agent settings:






        • 1. Re: Deployment template - stopping around the Agent install/update
          carlos Expert

          I would start by changing back what you change and test again? does it work?

          Then what you changed is the problem and go from there.



          • 2. Re: Deployment template - stopping around the Agent install/update
            GaryOco Apprentice

            HI Carlos,


            Thanks I was considering the agent change to be relatively simple to make, however the space on the C drive for the Windows Updates is what really concerns me. We were down to around 500MB left when I completed the move which was causing some issues with building PC's anyway.


            I'll set the setting back though and see how I get on.

            • 3. Re: Deployment template - stopping around the Agent install/update
              carlos Expert

              You CAN change the path, but first we need to see if that is the problem, not that is bad to change the Patch but more likely that the new path is not configured correctly.

              • 4. Re: Deployment template - stopping around the Agent install/update
                jeff.earhart Rookie

                I would check the new locations for Replication credentials to make sure the share is accessable for the clients. 


                How to configure the Source for Ivanti EPM Content Replication


                How to configure the Source for Ivanti EPM Content Replication

                • 5. Re: Deployment template - stopping around the Agent install/update
                  GaryOco Apprentice



                  So I moved everything back and downloaded all the updates (didn't want to copy them just in case) and reset the agent settings to no avail.


                  I've read through the document Jeff but I can't see anything with regards to agent replication. As I understand it the deployment template pulls the agent from the core, unless you specify a self contained agent install which I'm not. If I'm wrong in that understanding please let me know.


                  I've managed to find some errors now in the provisioning log on the Core, although it doesn't particularly help me understand what's wrong. I found a post that was resolved with a comment stating "had the 2017 beta and that's resolved the issue" or similar.


                  VERBOSE ProvisioningWebService 30/05/2018 16:46:03 : SetActionStatus (historyTaskIdn 209, historyEntryIdn 5560, next 5561): state FAILED

                  VERBOSE PHistoryTask 30/05/2018 16:46:03 : StopProvisioningJob (LDTaskId 357, computerId 407, historyTaskIdn 209), state Failed

                  VERBOSE PHistoryTask 30/05/2018 16:46:03 : update the history task state

                  VERBOSE ProvisioningWebService 30/05/2018 16:46:04 : SetActionStatus (historyTaskIdn 209, historyEntryIdn 5560, next 5561): state FAILED

                  VERBOSE PHistoryEntry 30/05/2018 16:46:04 : Unable to write to database. Altering history task Idn 209 state is not allowed. Failed.

                  ERROR ProvisioningWebService 30/05/2018 16:46:04 : Unable to set the action status (historyTaskIdn 209, historyEntryIdn 5560, next 5561): History task is not in the running state.


                  Any other potential suggestions?




                  • 6. Re: Deployment template - stopping around the Agent install/update
                    Robert.Bertino Rookie

                    So the only other suggestion I can think of is dig through some of the log files.


                    If I recall correctly, Provisioning installs the agent by going directly to the core and running "\\servername\ldlogon\wscfg32.exe" with a /C= switch that tells it which Agent INI file to use. To see if the agent configuration itself is failing, you can look for the WSCFG32.LOG - it's usually either in one of the Temp directories (c:\users\userprofile\appdata\local\temp or c:\windows\temp) or in LanDesk's own Log directory (c:\ProgramData\LanDesk\log). Some of those are hidden directories of course, so you may have to have Windows show hidden directories.


                    Since you also have it do a Policy Sync, you can look at the PolicySync.log and PolicySync.exe.log also in the C:\ProgramData\LanDesk\Log\ directory and see if those say anything useful.


                    As for Provisioning logs - Configure Target OS copies all of it's files to a C:\LDProvisioning directory before it reboots, and then kicks itself off by running the C:\LDProvisioning\LDProvisioning.cmd file usually from Sysprep Setupcomplete.cmd I think (been a while since I messed with this). There should be a main LDPROVISION.LOG in there that is kind of the general log for Provisioning, but each separate Provisioning EXE tends to create it's own more specific log. For example, if it's running a Map to Preferred Server action, it runs MaptoPreferredHandler.exe which then usually generates it's own MaptoPreferredHandler.log file.


                    I think by default that C:\LDProvisioning directory may get deleted upon completion of the template, unless you uncheck / disable the "Remove Client Provisioning Folder" in the template itself:

                    That will make the directory stick around after everything is done so you can then look at all of the log files and try to figure out why it's not working.


                    The only other random thought I just had - when you changed the Patch directory location was anything done to the permissions on the \\servername\ldlogon directory? It's possible whatever user Provisioning is running under no longer has read and execute access to that directory?

                    • 7. Re: Deployment template - stopping around the Agent install/update
                      jeff.earhart Rookie

                      In your first post you said you moved the folder off of the c: drive.


                      When you moved the files, did you share the folder and give the correct permissions to the users. 


                      When you copy a folder from one drive to another, the sharing and permissions don't transfer.


                      If the login you are using in the pxe boot/provision template doesn't have acces to the files it will fail.



                      • 8. Re: Deployment template - stopping around the Agent install/update
                        GaryOco Apprentice

                        Hi, Sorry for the delay.


                        Carlos - Thanks I got the logs to stick around this time

                        jeff.earhart I only moved the patch folder, which (as far as I know) has no impact on the agent install locations in the LDLogon directory.


                        All the permissions mirror exactly what was on the original locations for patch information I've tried using our service account (that was originally configured anyway) and my domain admin account to no avail.


                        Managed to finally get a machine built to the point I could logon and found the confighandler errors below:


                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:Got core name: SERVERNAME

                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:Got config tool: wscfg32.exe

                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:Got configuration file: Windows Client Default

                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:Got user:

                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:password is not variable, encrypted

                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:Attempting traditional agent install.

                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:LDLogon Path: \\CORESERVER\ldlogon

                        2018-06-06 14:28:45(2008-4416) ConfigHandler.exe:Mapping drive using preferred server credentials

                        2018-06-06 14:28:52(2008-4416) ConfigHandler.exe:Could not get credentials for \\CORESERVER\ldlogon

                        2018-06-06 14:28:52(2008-4416) ConfigHandler.exe:Check to make sure preferred server credentials are correct. May need FQDN and shortname entries.

                        2018-06-06 14:28:52(2008-4416) ConfigHandler.exe:Could not connect to \\CORESERVER\ldlogon,

                        2018-06-06 14:28:52(2008-4416) ConfigHandler.exe:Connecting to path returned: 100003

                        2018-06-06 14:28:52(2008-4416) ConfigHandler.exe:config tool \\CORESERVER\ldlogon\wscfg32.exe was not found.


                        So I went through the preferred server configuration and confirmed that the service account was configured and the password was correct and all the authentication tests against all 3 of our preferred servers worked for both read and the read/write tests. I found an old post: LANDesk Agent Install step fails while OS Provisioning  that describes the issue we're having but this was back in 2015 so not sure if it would still be valid.




                        • 9. Re: Deployment template - stopping around the Agent install/update
                          GaryOco Apprentice



                          I've been working with support and wanted to post the rather....frustrating yet simple resolution. I had a work around by deploying the WIM file and the answer file creating a local account, I could then manually install the agent and then run the application installs as a new provision template.


                          So my preferred servers were setup as per the install, i.e. 3 preferred servers with IP ranges, and then a "dummy" entry for the core, which I've seen mentioned in a lot of threads. These were not entered as the FQDN, following reading some posts I amended the entries to be the FQDN. This didn't resolve the issue. But the WIM file at least started to install which was failing before.


                          I re-amended the preferred server names to be the server name - not FQDN, and this didn't resolve the issue although the the machine would then join the domain. I re-entered the FQDN and nothing else changed.


                          Whilst speaking to support we took the FQDN out again, and were discussing that some posts indicate it's advisable to have entries with and without the FQDN (so two entries per preferred server) when a machine I happened to be building separately as it's a new machine and it installed the agent.


                          I've since tested it on a different machine and put our provision template back to it's original settings (I butchered it testing different ways of deploying the agent)


                          Not quite sure what fixed it as I just repeated the same step a third time, unless there was some latent network issue getting in the way, although these changes were made days apart. Anyways thought I'd post the resolution in case this affects anyone else (doubtful but you never know)