What happens if you try to browse to the http://Server.internal.company.com/dsl/packages/windows/package/package.exe share?
403 is typically credentials. Try turning off Friendly HTTP Error messages in your browser Advanced options and see if it gives you a more detailed error.
There is often a subcode along with a 403. Such as a 403.1.
You can check the properties of the Virtual directory in IIS. Are their any settings such as IP addresses blocked?
You can also check the log files located on the web server in this directory: c:\windows\system32\logfiles\w3svc1
Look for any lines that show that path, at the end of the line it should show the 403.
Here is an example of how we typically set up a web share for use with Patch Manager, I would recommend following these guidelines closely.
Creating the Web Share
Right click on the folder you want to share and select Properties.
Click on the Web Sharing tab.
Click "Share this folder."
Check "Read" and "Directory browsing."
Click OK once.
Click on the Security tab.
Add the IUSR_computername account and give it "Read & Execute" permissions.
Open IIS Manager, navigate to the default web site and expand its contents.
Right click on the newly created virtual directory and select properties
Click on the Directory Security tab, then "Edit..." under Authentication and access control.
Check "Enable anonymous access" and apply the changes.
If you click "Test settings" when you are setting the patch location in the Security and Patch Manager Tool and you get the error "Failed to read test file from HTTP URL http://+servername+/+sharename+/TestWritePatchData.txt" it means you have not enabled Anonymous access correctly (Steps 7 - 12). If you have moved the patch directory to a new server and receive an "HTTP Error 404 File or Directory not found" when attempting to download any files, Open the IIS manager, right click the Web directory, choose properties, click the HTTP Headers tab, click MIME types..., and add .* All File Types to the MIME types. Now at the run line type iisreset and after IIS restarts the files should be available for download.
Below are the meanings of the 403 range of IIS error codes. For a complete list see this article: http://community.landesk.com/support/docs/DOC-1086
Error: 403 - Forbidden. IIS defines a number of different 403 errors that indicate a more specific cause of the error:
Error: 403.1 - Execute access forbidden.
Error: 403.2 - Read access forbidden.
Error: 403.3 - Write access forbidden.
Error: 403.4 - SSL required.
Error: 403.5 - SSL 128 required.
Error: 403.6 - IP address rejected.
Error: 403.7 - Client certificate required.
Error: 403.8 - Site access denied.
Error: 403.9 - Too many users.
Error: 403.10 - Invalid configuration.
Error: 403.11 - Password change.
Error: 403.12 - Mapper denied access.
Error: 403.13 - Client certificate revoked.
Error: 403.14 - Directory listing denied.
Error: 403.15 - Client Access Licenses exceeded.
Error: 403.16 - Client certificate is untrusted or invalid.
Error: 403.17 - Client certificate has expired or is not yet valid.
Error: 403.18 - Cannot execute requested URL in the current application pool. This error code is specific to IIS 6.0.
Error: 403.19 - Cannot execute CGIs for the client in this application pool. This error code is specific to IIS 6.0.
Error: 403.20 - Passport logon failed. This error code is specific to IIS 6.0.
This can be a NTFS file permission issue. Though you have set the permission to the folder, sometimes the files copied to that folder do not inherit the NTFS permission. If that's the case giving the files needed permission would be fine.
So, let me pose the first question again:
"I am throwing around the idea of creating a software distribution package that contains multiple installs (we have a set of applications that we install on all domain computers). Is this possible using Software Distribution? Can multiple installs be designated in a single distribution package?"
1 of 1 people found this helpful
The simple answer to your question is "yes" - but there's far more to this.
I would prefer answering with a "no", because a "single package containing a whole slew of others" usually ends up as a convoluted mess, and if something goes wrong (and the more you install, the greater the likelihood that something WILL go wrong) it makes it a bigger pain to try and look at.
From a BKM point of view, I'd suggest splitting things and keeping things split into little chunks.
This is not to say it can't be done - a few people do do it this way (batch files are a popular way for getting this done pretty easily) - but you MUST be VERY careful and have to be sure in what you're doing. It's one of those Pandora's boxes that's pretty difficult to control :).
Hope this helps.
LANDesk EMEA Technical Lead.
LanDave: Thank you. "Directory Browsing" was not enabled. All the NTFS perms were correct (we have always been able to browse the directories through UNC). After enabling it on the web site/share, we were able to browse the directory from the Landesk Console when creating Distribution Packages.
PHoffman: Thank you also. I will experiment with making a package that contains multiple installs.
Ok, I had the same problem with version 9 and the directory browsing was not enabled. So two weeks ago I enabled it but today it was disabled again. Any thoughts?