SharePoint Large Upload Limits - The Definitive Article

There's a tremendous amount of confusing information on the internet surrounding configuring SharePoint to properly allow large uploads.  Much of the confusion is due to differences in SharePoint versions (2007 ("12"), 2010 ("14") and WSS / Foundation) along with changes Microsoft made to the underlying OS and IIS.

For our sanity - and everyone else's - here's what we've found is truly the only full proper way to make this work consistently across Document Libraries, Lists and everything in between. 

The following example would be to allow 500+MB uploads, and you would need to adjust the numbers to match your needs.  Keep in mind the numbers are (in true Microsoft fashion) in MB in some places, KB in others, and bytes in still others! 

We've also made these steps a fully GUI based affair, as many admins are still uncomfortable about hacking around in config files manually. 

Note: This process applies to SharePoint 2010 or greater on Windows 2008 R2 or newer.  On Windows 2008 (non-R2) manual edits to web.config would be required using the same settings, or download the Configuration Editor as part of the IIS Administration Pack.

1. In Central Administration, under Application Management/Manage Web Applications find the web application to update and select it.  Then from the ribbon choose General Settings.
2. Update the Maximum Upload Size to the desired size – i.e. 512 MB and click OK

Repeat the following steps on EACH Web Front-end Server and for each IIS site representing each SharePoint zone:

1. In IIS Manager navigate to the Sites node and choose the appropriate site representing the chosen SharePoint Web Application
2. Click Advanced Settings in the Action Pane.  Under Connection Limits increase the Connection Time-out to at least 300 seconds and click OK
3. In the middle pane double click on Configuration Editor
4. Under Section, choose system.webserver/security/requestFiltering
5. Expand requestLimits and change the maxAllowedContentLength entry to a value of at least 536870912  (this is in bytes).  Click out of the entry box, then choose Apply in the action pane
6. Under Section  choose system.web/httpruntime
7. Modify the entry maxRequestLength to a value of at least 524288 (this time it's in KB!) and the executionTimeout value to 3600.  Click out of the entry box, then choose Apply in the action pane
8. Open Command Prompt As Administrator and execute
   iisreset
9. Go forth, and upload! 

All of these steps are required to fully and properly support large uploads across libraries and lists.

Does your SharePoint environment need help?  Contact us today.

Image courtesy Techbush

Exchange internal anonymous relay done the right way

UPDATED: May 2017

Allow internal SMTP email relay, bypass the junk filters, and make it all work right the first time.

Update: This guidance is still valid up to and including Exchange 2016, but the steps below refer to Exchange 2010. Newer versions use the same types of permissions, but most operations must be done through Exchange PowerShell.

A common scenario for server admins is allowing internal servers to safely relay anonymous emails for alerts, logs, or internal application notifications through Exchange, and ensure the messages are delivered correctly to users.

Beginning with Exchange 2007 Microsoft made changes which made this a better and more controlled process than previous versions, but also made two confusing and distinct ways to configure: the "Externally secured" method and the "anonymous" method. 

Both have their pluses and minuses, but our recommendation is always the latter, as it makes identifying emails that were submitted anonymously (and therefore potentially untrusted) more obvious. Why? Messages submitted in this fashion will advise Outlook not to resolve the sender address to a Display Name. Rather, it only shows the exact (and often completely random) sender from the host SMTP session's envelope. Equally importantly, using this method the end-to-end anti-junk mail configuration will work correctly across both Exchange and Outlook's various filters. 

Microsoft's provides this Technet article which covers how to configure both methods on the Exchange server, but unfortunately gives no context or explanation as to why an admin would choose one or the other. We've written this article based on our experience and testing, to provide the missing details.

Configuration Guidance for Anonymous Method:
We will follow the steps in the article section Grant the relay permission to anonymous connection

1. In EMC at the Organization/Hub Transport node under the Anti-Spam tab, ensure that the IP Allow List and Content Filter are enabled. These features together actually do the work to make the messages quasi-trusted and stamp the "SCL -1" rating.  Failing to enable both will result in messages not correctly bypassing filters.
   If you don't see these options you might have to run the script to enable Anti-spam features on your server.
    
2. You may use either the EMS or the EMC (Under Server Configuration/Hub Transport node) to create a new Receive Connector and define the appropriate remote networks or hosts that will be able to use this new connection.
   Note: Be sure you don't leave this new connector accepting connections from all IPs, as this is a security risk for mailicious staff or malware that may get lose on your network. All conenctions to Exchange should be secured or from known systems only.
    
3. Next, assign the appropriate AD Permission of Ms-Exch-SMTP-Accept-Any-Recipient via the Exchange Management Shell.  At this point, DO NOT follow the rest of the steps under Configure the Receive connector as externally secured, as this method will not be used.
    
4. Under Server Configuration/Hub Transport switch to the Anti-spam tab. and open the IP Allow List
    
5. Duplicate the list of hosts that you had enabled to send through your new Receive Connector here. This ensures that both server and client-side anti-spam are bypassed, and the X-SCL -1 header is stamped for Outlook's later use.

Email will now be accepted and relayed through your new connector and will always go directly to the Inbox of users in Outlook/OWA. 

Why Not Externally Secured? 
While this method is easier to configure - just click the checkbox in the EMC - it has two negatives. The first is the previously mentioned display name resolving in Outlook (via the AD Permission "ResolveP2")  With this permission Exchange will consider submitted emails to be authenticated (which they're not), and subsequently resolves the SMTP address to a display name if possible. This is a bad practice in our opinion, as it tricks the end-user into believing this is trusted sender.

The second, and more frustrating problem, is that Exchange will not stamp SCL headers into the message, so the Outlook client-side filtering will be applied (if enabled).  As more-often than not server alerts and backup log messages will look very spammy, they will promptly get turfed into the Junk Email folder. As Outlook thinks it is being helpful deciding on its own, rather than looking at what Exchange rated the message, when in fact it's just creating unhappy users and admins.

Further Reading
What happens when you make your new Receive Connector Externally Secured?

This will be granting several rights including the ability to send on behalf of users in the organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default "Externally Secured" permissions are as follows:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

This is telling Exchange to ignore internal security checks because these servers are trusted, which goes against the ethos of an anonymous relay point.

What happens when you add the Relay Permission instead?
This option grants the minimum amount of required privileges to the Receive Connector for accepting messages from and to anyone, and must be done consciously through the Exchange Shell, rather than clicking a checkbox.

Accepted Domains, Safe Senders List and You
http://blogs.technet.com/b/exchange/archive/2011/07/08/accepted-domains-safe-senders-list-and-you.aspx

Exchange anti-spam myths revealed
http://blogs.technet.com/b/exchange/archive/2009/11/13/exchange-anti-spam-myths-revealed.aspx

The saga of the "Junk Email" Folder - putting the puzzle together
http://www.exchangeinbox.com/article.aspx?i=155

Need your Exchange Server to work day and night, and not worry?
Planning an Office 365 Migration?
Contact us today.

Generate custom, self-signed, long-expiry certificates on Windows

We recently were introduced to a great utility that a Microsoft IIS Team employee maintains called SelfSSL7.   This is an upgraded version of the old SelfSSL tool that used to ship as part of the IIS Resource Kit.

Self-signed certificates have a myriad of useful purposes for internal uses in testing and staging environment, but are an awful pain to deal with using the (almost completely lacking) internal tools. 

SelfSSL7 to the rescue! 

Thomas has all the details at his blog below, but in a nutshell you simply download the tool, unzip and run from a command line.

For example, to create a self-signed certificate for a web server with a 5 year expiry and automatically export the whole thing to a PFX file for safe keeping, all while adding it to the local computer store and binding it to an IIS site automatically - simply execute the following at an elevated command prompt:

selfssl7 /k 2048 /v 1825 /x /f c:\SelfSSL7\my-5-year-cert.pfx /i

There is no step 2!

Such a time saver!