i had the same problem and as a workaround until they give me a fix is map a drive and then use a execute file action to run the install from the exe
Yes, I am installing thru mapped drive now. But I wanted to know if there is fix, because if I update the agents config, I dont need to update all my templates
I had a similar issue myself recently. Try this.
Open Tools-Distribution-OS Provisioning
Click the icon that looks like three people to open Public variables.
Check the variable "corename" and make sure it has the name of the core correctly entered. Now for the part where mine was broken.
Open Tools-Distribution-Content replication
Click on Preferred servers (Targets)
Make sure you have an entry in here for the core and that the server name perfectly matches the entry for the "corename" public variable.
Test the Read-only credentials for the core entry and verify that it is successful. (NOTE: no sources need to be configured for the core, it is not really a preferred server but it uses this to get the read credentials)
My issue was that the preferred server entry for my core was FQDN and my public variable was not. The name has to match perfectly.
I had the exact same problem too. It is documented but worked without have the core be a preferred server in 9.5
I've just recently gone through some of this, having just set up a core, sql, and a storage (application) server all in the last month. I've tried to place as many deployment files on the storage server, but have had a problem for a few days getting deployments to work. This included test applications, OS Provisioning and self-extracting agent deployments.
That's a lot of lead up to get to the point, but the point was that I had to allow firewall traffic for ports 80, 139, and 445 through PUBLIC on the firewall for the servers in order to get access from WindowsPE.
Hope this might help now, or in the future for somebody.
Is your device joined to the domain already when you try to deploy the agent? It might just be a simple rights issue...
I'm running into the same issue with my template, except I get a 100003 error. In mine, the agent install occurs as the first thing in the System Configuration phase, and before joining the domain.
Frank Wils, you suggest putting it after joining the domain...how do you do this since a reboot is needed after joining the domain. When I try, the PC reboots and just sits at the login screen.
I gave up and started using install using exe file as workaround.
I suspect something funky about my preferred server config.
This is our ConfigHandler log:
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:Got core name: LDWFMGT1
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:Got config tool: wscfg32.exe
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:Got configuration file: WFH 9.6 Agent
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:Got user:
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:password is not variable, encrypted
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:Attempting traditional agent install.
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:LDLogon Path: \\LDWFMGT1\ldlogon
2015-05-13 15:50:38(3468-3472) ConfigHandler.exe:Mapping drive using preferred server credentials
2015-05-13 15:50:44(3468-3472) ConfigHandler.exe:Could not get credentials for \\LDWFMGT1\ldlogon
2015-05-13 15:50:44(3468-3472) ConfigHandler.exe:Check to make sure preferred server credentials are correct. May need FQDN and shortname entries.
2015-05-13 15:50:44(3468-3472) ConfigHandler.exe:Could not connect to \\LDWFMGT1\ldlogon,
2015-05-13 15:50:44(3468-3472) ConfigHandler.exe:Connecting to path returned: 100003
2015-05-13 15:50:44(3468-3472) ConfigHandler.exe:config tool \\LDWFMGT1\ldlogon\wscfg32.exe was not found.
The problem must be with the server name. I don't understand is why is it using the actual server name 'LDWFMGT1' when we've defined the core public variable and the preferred server name to be 'landesk'. That's a DNS alias for the core.
Actually, it carries the Core Server name all the way back from WinPE. Whatever is in WinPe x:\temp\corename is the Core Server name it will connect to for the agent install.
And no, you don't need to reboot immediately after a Join Domain...
Our CORENAME.TXT as well as the REG.ALL has the alias, not the server name. Where else may WinPE be grabbing the name from?
so I found my fix for this today, it appears when SP1 was installed it renamed curllib_nossl.dll to curllib.dll, you might want to check your ldlogon folder and see if you have the right file. the curllib.dll should have been 378k but it was 350k which is the size of the curllib_nosll.dll.. No one can tell me how this could have happened but I traced it back to around when we installed SP1. we hadn't updated our agent so it wasn't having a major impact but started to roll out SP1 agent a couple weeks ago and started having SWD tasks failing to download, found that dll was wrong so I decided to see if my agent deployment via provisioning was fixed as well and it was.
How does one use the execute file action to install the landesk agent in an action handler?