It seems to be the Package Server problem season for me .
Whilst trying to stabilise my customer environment so they can enjoy PXE 2.1 and OS deployment tasks I found that the two package servers have some issues accessing the deployment share... getting an access denied message (which leaves no doubt to the root cause of the error).
Package Server 2 is trying to download the drivers.manifest.txt file from Package Server 1 (fully synchronised - and freshly cleaned of .net 4.0 ). But all we where receiving there was an error 500 (application error).
Checking on PS1 the url provided to PS2 was effectively throwing an error, indicating that .Net could not read the web.config file in path "\\?\Deployment\...". This may look unfamiliar to most of us, but having spent a couple of hours it rang a bell immediately, as earlier attempts to synchronise PS2 threw similar errors, but locally (when the PS was attempting to copy a downloaded file to \\localhost\Deployment\...".
After a quick debate we decided to give everyone read access to the Deployment share (it may be debated again whether this should be the case in production, but we are still in pre-prod only - so getting the PS to work is the priority). With this setting in place IIS could access the drive and find no web.config in the location, and started serving the page properly.
The same changes went on PS2 so it will be able to download packages to the alternate location when needed.
Remains to see if these restrictions are by design and whether we should be using Package Access Credentials or open the Deployment Share for read (to authenticated users, specific groups or everyone).