Compatibility:
SharePoint 2013 Foundation (SPF) and Server (SPS) SharePoint 2010 Foundation (SPF) and Server (SPS) Windows SharePoint Services (WSS) 3.0 / Microsoft Office SharePoint Server (MOSS) 2007
SPF & SPS 2013 • 2010 • 2007
User Voices
(Loading...)
« Solution Installation & Deployment | Walkthrough: Web Uploader »
Saturday
Mar052011

Deployment Checklist

Review Server-side Upload Limits

To support bulk-uploads of large file sets, you may want to review the maximums currently supported by your SharePoint server farm.

  • Review the Maximum Upload Size setting on the Web Application General Settings page under Central AdministrationApplication ManagementSharePoint Web Application Management.
  • Internet Information Services (IIS) respects the ASP.NET maximum request length setting, pre-empting even the above SharePoint Web Application Maximum Upload Size setting. The maximum request length setting is stored and can be modified manually in the <wwwroot>\wss\VirtualDirectories\<webapp>\web.config file (on each web front-end server) by locating the <httpRuntime> node and editing the maxRequestLength attribute value.
    • The stored attribute value represents KB — divide by 1024 to get the value represented in MB (for example, the default value 51200 represents 50 MB). If you decide you want to change the setting to a different MB value, multiply that one with 1024 and store the result as the new attribute value.
  • To prevent a large file upload from timing out before completion, review and customize if required the Request execution timeout (seconds) setting on the Application tab in the ASP.NET Configuration Settings dialog box by opening the Properties dialog box for the SharePoint Web Application in Internet Information Services (IIS) Manager on each SharePoint web front-end server and clicking Edit Configuration on the ASP.NET tab.

Preparing a Web Application for the Chunking feature

When chunking is used, UploadZen temporarily stores the individual file chunks in the _layouts/roxority_UploadZen/fc virtual directory (before putting them back together later on to add the original file to the target Document Library folder when all chunks have been transferred). This typically corresponds to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\roxority_UploadZen\fc\ physical directory (12 instead of 14 for WSS 3.0 / MOSS 2007) — unless you specified a different target storage folder for chunks on the Configuration page.

When writing to and reading from this directory, UploadZen uses SharePoint code elevation so the user account that will access directory will be identical to the user account specified as the Identity for the IIS Application Pool (under [app pool] / Advanced Settings / Process Model — more often than not this is set to Network Service).

You need to ensure that read and write access to the file chunking temporary storage folder (either _layouts/roxority_UploadZen/fc or a custom-configured one) is fully granted to the above user account, ie. the IIS app pool identity. Note:

  • the permissions to check or set are on the Windows Explorer / server-side storage OS level rather than IIS / ASP.NET / web server or SharePoint-specific permissions.
  • in a multi-server farm environment, you would need to perform the above for all _layouts/roxority_UploadZen/fc folders on all web front-end servers; however:
  • in such an environment you SHOULD instead re-configure the file chunk temporary storage directory to a central file-system location such as a network drive, shared folder or other network-mapped location since different chunks might otherwise end up in different _layouts/roxority_UploadZen/fc folders on different servers and UploadZen could not put these back together to complete the chunked upload as intended.

Document Libraries and Other Libraries

No special preparation considerations apply to Document Libraries or other libraries. All Library Views with a their Toolbar Type setting set to either Full Toolbar or Show Toolbar provide your Upload Actions' menu items and may hide the SharePoint Upload Multiple Documents menu item if so configured.

XSL, Data Form, Data View Web Parts

If you have in use XSL / Data Form / Data View Web Parts that were created by converting from an out-of-the-box Library View (for example using SharePoint Designer), keep in mind that their menu structures are "frozen" at conversion time:

  • the UploadZen menu items will never be visible if UploadZen was not activated at conversion time, and
  • the UploadZen menu items will always remain visible if UploadZen provided active menu items at conversion time.

If you intend to create such Web Parts by converting from Views, uninstall or disable UploadZen temporarily prior to the conversion. You can still generate your own Upload Multiple Files links manually and add them to your pages for such Web Parts or Document Libraries if desired.

Secure Sockets Layer (SSL)

UploadZen will work fine over SSL, except when the browser raises a prompt about the SSL certificate. The prompt can be raised when there is something wrong with the certificate, such as when the site names do not match or the certificate has expired. To make UploadZen work over an SSL connection, make sure that the certificate is up-to-date, and that the certificate data matches the site data.

Preparing a Web Application for the Windows Uploader mode

This section only applies to the legacy Windows Uploader mode and is for reference in legacy systems only. You will likely use the newer (and default) Web Uploader mode in production instead, and can safely skip this section.

UploadZen's legacy Windows Uploader only works for SharePoint site visitors using Windows and Internet Explorer, or Firefox (with the Microsoft .NET Framework Assistant installed).

CAUTION: the legacy Windows Uploader mode will NOT work out of the box for remote clients unless you take the additional administrative steps outlined in this section.

As a minimum requirement for the legacy Windows Uploader mode to work for remote clients (i.e. your users), you need to:

  1. enable both the Browse Directories and the Use Remote Interfaces Site Permissions on the User permissions for Web application page (in Central AdministrationApplication ManagementApplication Security — be sure you selected the correct target Web Application), as well as
  2. perform the following steps in Internet Information Services (IIS) Manager on each SharePoint web front-end server:
  • Locate the _layouts/roxority_UploadZen/help virtual directory in the IIS Web Site corresponding to the SharePoint Web Application you want to UploadZen-enable.
  • If you're using IIS 6.0 on Windows 2003 server, or IIS 6.0 compatibility mode on newer Windows versions :
    • Open the Properties dialog box for the _layouts/roxority_UploadZen/help virtual directory from its context menu and on the Directory Security tab, in the Authentication and access control section, click the Edit button.
    • In the Authentication Methods dialog box, tick the Enable anonymous access check box and click OK. Back in the Properties dialog box, click OK. (If you are now prompted about applying your changes to child directories or files, select all of them in the prompt dialog box and click OK.)

  • If you're using IIS 7.0 or higher, on Windows Vista, Windows 7, Windows 2008 Server or newer Windows operating systems:
    • In the Connections side bar on the left, select the _layouts/roxority_UploadZen/help virtual directory in the IIS Web Site corresponding to the SharePoint Web Application you want to UploadZen-enable.
    • In Features View, double-click the Authentication icon in the IIS group. In the Authentication list view, select Anonymous Authentication and then click Enable in the Actions side bar on the right.

Granting anonymous read access exclusively to this virtual directory is acceptable with regards to server security, since no sensitive information is ever stored underneath the help virtual directory, nor does it at all expose access to any server-side code anonymous users could ever invoke. Granting this anonymous read access is however also required for the legacy Windows Uploader mode to work, as the software is based on the Microsoft .NET Framework ClickOnce deployment technology, the integration of which with both SharePoint and remote Internet Explorer users with varying Windows versions, security and authentication settings more often than not simply does not work without making this simple, safe and proven-to-work adjustment.

For remote Internet Explorer users, invoking a legacy Windows Uploader mode Upload Action is likely to produce only HTTP 401 error messages unless and until you take the above steps for all IIS Web Sites associated with your content Web Applications on all SharePoint web front-end servers — even though the menu item is already available in all Document Library Upload menus throughout your server farm immediately after solution installation.

Granting Web Service Access

This section only applies to the legacy Windows Uploader mode and is for reference in legacy systems only. You will likely use the newer (and default) Web Uploader mode in production instead, and can safely skip this section.

While running, the legacy Windows Uploader window will attempt to access via HTTP / SOAP, under the user-specified credentials, the following XML Web Services:

  • http://site/_layouts/roxority_UploadZen/Files.asmx http://site/_layouts/roxority_UploadZen/uploadzen.aspx
  • http://site/_vti_bin/Lists.asmx
  • http://site/_vti_bin/SiteData.asmx
  • http://site/_vti_bin/Authentication.asmx

It is the responsibility of the administrator deploying a legacy Windows Uploader mode Upload Action to make sure that remote users are granted access to these interfaces. In most environments, completing the steps outlined above should be sufficient to grant this access.

Proxy Authentication

This section only applies to the legacy Windows Uploader mode and is for reference in legacy systems only. You will likely use the newer (and default) Web Uploader mode in production instead, and can safely skip this section.

For the legacy Windows Uploader mode to work with default proxy authentication in a corporate setting, the defaultProxy element in the .NET Framework machine.config file on all client computers (under %WINDIR%\Microsoft.NET\Framework\<version>\CONFIG\) must be set to allow System.Net to use default security credentials. Alternatively, you can configure defaultProxy on client computers to use a specific proxy server.