Have you tried using "Map/Unmap drive" instead of "Map/Unmap drive to preferred server" action and point directly to preferred server that way?
I have not tried that, but that would not be a solution, per se. We have 8 sites with preferred servers just in North America (we're still implementing OSP after having moved from being an MDT shop, and this is one of our test sites). Hard pathing the PS in the templates would get rid of the dynamic solution for PS discovery.
However, I will definitely try that as a troubleshooting step.
How is your Preferred Server configuration set up? Did you configure it with NetBIOS name or FQDN?
If your Core is also the Preferred Server, it doesn't matter how it's called in WinPE (all.reg/txt file), it will stil grab the name from the PreferredServer config.
Also checkout the maptopreferredhandler.log in x:\ldprovison in WinPE. It should give you more information on what's going on in the background and hopefully provide an error code that makes sense.
Frank, that was it. I didn't actually have permissions to see the Content and Replication portion in LANDesk (I'm probably the least privileged LD admin in the world), so I asked our main guy, he gave me view, and they were all NetBIOS set. I asked him to set them to FQDN, and it started working immediately in all places we were having issues with.
I believe the actual underlying cause of the problem is DNS related; I came to this conclusion because when I edited the host file in X:\Windows\System32\drivers\etc to manually point the NetBIOS hostname to the static IP of the preferred server before selecting a template, the template processed without error. My original plan of action yesterday was to come in first thing this morning and manually edit the host file in our boot wims on the core, and then replicate to our PXE reps (until I read your reply), which was a band aid approach because there's too much room for human error.
Setting the preferred servers to FQDN in LANDesk is also a band aid approach in my opinion, even if it should have been set to that regardless. The real solution is to get the NetOps guys to fix the DNS like we've been harping on them to do for the past 3 years, but what can you do.