There’s a popular myth that keeps popping up that I wanted to post about.

Why is it so popular? Well, because it seems intuitive if you aren’t working with SharePoint on a regular basis. If you are then I’m sure you don’t think this… and if you did, well shortly you’ll know the truth.

So here’s the myth “We don’t need to split our content across separate content databases because if we need more than 200GB support for each database we will [1] move subsites around to different site collections in different databases or [2] use remote blob storage and put it all on file shares… then we’ll have a very small content database size.”

If you’re having an issue with MP4 videos not playing on mobile devices, and you’ve already added a mime type for MP4 in IIS, then it could be due to the “AllowedInlineDownloadedMimeTypes” setting of your web app.

To fix it, you can update the setting in PowerShell, with script such as:

$webApplication = Get-SPWebApplication “http://intranet.contoso.com” $webApplication.AllowedInlineDownloadedMimeTypes.Add(“video/mp4”) $webApplication.Update()

Recently I had to help someone that wasn’t able to delete a field off a list!

Seemed a bit strange I thought.. just go and delete it :)

Well in this case there was a catch - it was sealed. One of their developers had deployed a custom feature containing list fields and had set this particular one to sealed.

This was reasonably easy to figure out by opening up SharePoint Manager 2010 (SPM2010).

**Issue: **New-Object : Cannot find type [Microsoft.SharePoint.SPSite]: make sure the assembly containing this type is loaded. At D:\data\Permissions.ps1:253 char:23 + $rootSite = New-Object «« Microsoft.SharePoint.SPSite($siteUrl)

Resolution:[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)

As a best practice, SharePoint should be installed using a SQL alias.

Think of a SQL alias like a DNS record, but also being able to refer to a specific SQL instance name.

If you need to upgrade database servers in the future, you will usually be keeping the existing DB server in place, and creating a separate DB server environment (e.g. SQL 2005 vs SQL 2008). If you had your SharePoint installation configured with the server name details of the SQL 2005 environment, then now you have to undertake a long and arduous process to move to 2008.