For certain end users, the opening and saving of documents was taking forever, to the point where Word and Excel were displaying the “Not Responding” message. Sometimes the document wasn’t saving and the auto recovery wasn’t doing its job. However, when waiting for the document to save or load, other open documents appear to work fine and can save and load while the SharePoint hosted document is hung. This is a huge problem, especially in the help desk area where they are constantly bringing up guides or procedures with a client on the phone. Luckily the fix is rather simple. Open up Internet Explorer Go to Tools > Internet Options Click the Connections Tab > then click the LAN Settings button Un-check the option "Automatically Detect Settings" Click OK through all the dialog boxes to save your settings Close and re-open your Internet...

Some of the security features in the new SharePoint 2010 are interesting. One of them is that SharePoint 2010 now adds some fun security headers in files that may be dangerous if downloaded to a client computer. So instead of opening the documents it will only give you the option to download or cancel the operation. While I can understand this with some files such as .html and .sql, it doesn’t make sense with files like PDF. While this can be annoying, I completely understand. Most blogs that I’ve read suggest that you go into the Central Admin and for the general settings of the web application you’re interested in changing the file handling from strict to permissive. DO NOT DO THIS! It opens some wonderful security holes and completely circumvents the reason for strict file handling. Once again, PowerShell comes to the rescue by allowing us to specify specific extensions (well, MIME types) that we will allow to be openned in the browser. Here is the script: $webApp = Get-SPWebApplication http://sharepoint If ($webApp.AllowedInlineDownloadedMimeTypes -notcontains "application/pdf") { Write-Host "Adding PDF MIME Type..." $webApp.AllowedInlineDownloadedMimeTypes.Add("application/pdf") $webApp.Update() Write-Host "PDF MIME type now allowed for inline download." } Else { Write-Host "PDF MIME type already allowed for inline download."...

Our company has many sins of the past, one of them being a lack of information architecture (IA). Due to this we often have large numbers of sites dumped into a subweb. Working on the corporate intranet migration to the 2010 platform, I noticed that the TOC webpart was only displaying 20 sites, despite having multiple subwebs below it. In order to fix this issue, you need to make a change in the site settings for the navigation of the site, since this is what the TOC webpart relies on. Navigate to Site Settings –> Navigation Change the Current Navigation limit entry to something appropriate for this level of subweb: Maximum number of dynamic items to show within this level of navigation: In my case, I set it to 200, your needs may be different. After making this change to the current navigation setting all my subwebs now appear in the Table of Contents...