Symptoms
Uploads done by ManageSoft for Windows Deployment 7.2 PostWork scripts using the HTTP protocol fail if the uploads are going directly to either:
- An administration server running ManageSoft Deployment Manager 7.8.1 or later or
- A distribution server with Deployment Manager 7.9.1 or later installed and configured to import uploaded files directly to the database.
PostWork logging (typically found in C:\MGSPostWork.log) shows the failure as follows:
Mon 21 Apr 2008 02:55:17 PM: Uploading file 'rad66A6B.tmp' to 'http://server/ManageSoftRL/RolloutStatus/computer.acme.com.xml' with username of ''.
Mon 21 Apr 2008 02:55:43 PM: File upload failed. Upload returned error code 0x80004005
Logging from IIS generated by the upload (typically found in files under C:\WINDOWS\system32\LogFiles\W3SVC1) shows PROPFIND and MKCOL operations failing with "405" HTTP errors at the time of the uploads:
2008-04-21 14:55:17 W3SVC1 192.168.1.75 PROPFIND /ManageSoftRL/RolloutStatus/ - 80 - 192.168.1.75 - 405 0 0
2008-04-21 14:55:17 W3SVC1 192.168.1.75 MKCOL /ManageSoftRL/ - 80 - 192.168.1.75 - 405 0 0
2008-04-21 14:55:17 W3SVC1 192.168.1.75 MKCOL /ManageSoftRL/RolloutStatus/ - 80 - 192.168.1.75 - 405 0 0
Cause
This problem is caused by an incompatibility between how the ManageSoft for Windows Deployment 7.2 PostWork scripts upload files using the HTTP protocol, and how uploads are handled by:
- Deployment Manager 7.8.1 or later administration servers and
- Deployment Manager 7.9.1 or later distribution servers configured to import files uploaded using HTTP directly to the database.
The ManageSoftRL virtual directory in IIS is normally set up on such servers to point to the C:\Program Files\ManageSoft\DotNet folder, from where an ASP.NET HTTP handler is configured to run to handle and import uploaded files. This ASP.NET HTTP handler is unable to handle the specific HTTP operations the PostWork scripts use during file upload.
This problem does not affect uploads by the Deployment Manager upload agent (ndupload.exe) running on a managed device or distribution server only uploads by PostWork are affected.
Workarounds
Any one of the approaches described in the following subsections can be used to work around this problem.
Upload using HTTP direct to filesystem
Manually configure a new virtual directory on the administration server pointing to the C:\ManageSoft\Incoming folder, enabling read and write access. Configure the PostWork scripts to upload to this virtual directory instead of ManageSoftRL.
The upload location is typically specified by the UPLOADLOGURL setting in the C:\PostWork\PostWork.ini file in the image that is being deployed. Note that the upload location cannot be configured through the site server configuration with this workaround, as the site server configuration will only be used to upload to a directory named ManageSoftRL.
It is also possible to delete the ManageSoftRL virtual directory and re-create it pointing to the C:\ManageSoft\Incoming folder rather than C:\Program Files\ManageSoft\DotNet. This has the benefit of resolving this problem with a server-side only change (and not requiring any change to the PostWork configuration), but has the drawback of potentially degraded performance while importing files that are uploaded.
The RebuildRL.bat script attached to this article contains commands which can be used to create an HTTP directory for uploads as described here. Review the comments and settings at the top of the script (and modify as appropriate) prior to running the script.
Upload using file protocol
Configure the PostWork scripts to upload using the file protocol instead of HTTP. Uploads using the file protocol bypass the problematic ASP.NET HTTP handler running on the destination server, and hence avoid triggering this problem.
The upload protocol is typically specified in site server configuration, or alternatively in the UPLOADLOGURL setting in the C:\PostWork\PostWork.ini file in the image that is being deploy
Comments
0 comments
Article is closed for comments.