Video Screencast Help
Endpoint Management Community Blog

Some problems with the default access to the Deployment Share on package server

Created: 12 Jul 2012 • Updated: 12 Jul 2012 • 1 comment
Ludovic Ferre's picture
+1 1 Vote
Login to vote

It seems to be the Package Server problem season for me [1].

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 [1]). 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).

[1] Can you install .Net 4.0 on a Package Server?

Comments 1 CommentJump to latest comment

Ludovic Ferre's picture

From a few tests and installations I have conducted this week the problems is not related to the default share, but rather to the customer policy that prevents shares from being accessible to anyone other than the administrators groups and the system.

DS share worked a treat in my test server (PXE Is another story, but I'd rather not get into that now ;).

I am currently off-net, on a retreat of some kind. I'll be back real soon, and you sure will hear from me then ;-).

Ludovic FERRÉ
Principal Remote Product Specialist
Symantec

-2
Login to vote