If you have done so, try this:
1. Make the template public.
2. Schedule the deployment by dragging the target machine to the template instead of creaeating a scheduled task.
The template is already a public templates, and the machines are bare metal machines which are PXE booting, therefore not in the DB.
Try using CSVimport to add the machine to the LANDesk database and then assign them to the provisioning job.
create a template and name it whatever.csv, include the following info:
Device ID = %1%
Network - NIC Address = %2%
Then create another csv file that has the name you want the new PC to have and the PC's mac address.
I use a batch file to execute the import by callingcsvimport.exe followed by the path to the template, then the path to the csv that has the pc info, and finally calling the ldscan share on the core. Make sure that ldscan is shared on the core prior to doing this.
The PC will now show up in the all devices section of LANDesk and you can assign provisioning scripts to the PC's. See if that eliminates that error.
I have tried the above and have exactly the same problem.
Any other ideas?
After the last task (the one that's failing), add a "wait" for 1-2 seconds. Uncheck the option to "stop processing the template if this action fails".
I have the exact same error, and this is working for me for the moment, until Landesk can resolve it.
Is there a wait in LD 87 SP3 I can't find one.
I highly recommend that you update your core server to SP5 if possible. Lots of fixes in it.
Sorry, didn't really think to ask the version of Landesk
The "wait" isn't important. the 80001500H seems to happen on the very last task in WinPE no matter what. All we want to do is add a filler type task to the end, and mark it as non critical so it wont cause the rest of the template to fail
You can add an "execute file" and just make it a ping, or something unimportant
In 8.8, we resolved this issue by removing a pxe rep from Landesk that was no longer being used. It appears to be related to unreachable pxe reps, especially if the machine physically no longer exists. Not sure why, but it worked for us. I know there is a patch in the works.
error:[80001500H]The call to the Web service failed
System: LANDesk 8.8 SP1 + Patch CR13950 database.dll
I have this problem too, but only temporarily. Sometimes the installations go further and then run the provisioning task properly through.
My guess is that these problems will occur if the core server gets a Time Out (increased network traffic by user), because the problems only during business hours occur (if users are present and surf the Internet).
The Corserver and the connection to Internet via the same route WAN goes.
Original in German:
Dieses Problem habe ich auch, aber nur zeitweise. Manchmal gehen die Installationen weiter und dann läuft der Provisioning task einwandfrei durch.
Meine Vermutung ist, dass diese Probleme dann auftreten, wenn der Core server einen Time out bekommt (erhöhter Netzwerktraffic durch User), da die Probleme erst während der Geschäftszeit auftreten (wenn User anwesend sind und im Internet surfen)und der Corserver sowie die Verbindung zum Internet über die selbe WAN-Strecke geht..
We resolved many of the issues we were having with the call to the web service in sp5. Your best bet is to upgrade to the latest service pack.
... or may as well wait for SP6 to come out and use that (which should be out soon now), since they've waited this long.
LANDesk EMEA Technical Lead
I have this same error occuring. 8.8sp2 on Win2003 R2 SP2. I built the template I was using via the BKM doc; after fighting this I found and downloaded the example from here - "Master XP Scripted Install flat". Variables are all there, from what I can tell. It consistently fails at "Scripting Install".
After searching here for common causes, I added a wait command after the failing instruction - no change. Made sure the variables were using Computer.Display Name (I add the machine by MAC as a bare-metal database entry.) I then replaced the variables in the template with actual data, which didn't work; I then changed the xp_unattend.txt file to take out the variables as well, which also didn't help.
Finally, I scheduled just the Scripted XP Install template and tried that. Fails - same 1500H error.
Anyone have any ideas what might be going wrong here?