Mistake #1: Scrimping on SharePoint's RAM or Hard Disk Space
Mistake #2: Using Virtualized Microsoft SQL Server
Mistake #3: Using the Farm Configuration Wizard
Mistake #4: Using an Incorrect URL when Creating a Content Web App
Mistake #5: Running Web Apps or Service Apps in Separate App Pools
Web applications are a tougher matter. There's no easy, out-of-the-box way to change the application pool that a web app is using. Fortunately, we have PowerShell at our disposal. The steps to this process won't fit in this article, but I outline them in detail in the article "How to change the App Pool ID of a SharePoint 2010 Web Application."
Mistake #6: Using One Account for Everything
Mistake # 7: Keeping Default SharePoint Database Settings
Mistake #8: Not Enabling BLOB Caching
Mistake #9: Not Installing a PDF iFilter
Again, you can harness PowerShell to make this task easier. Brian Lalancette, creator of AutoSPInstaller, wrote a great script that automatically downloads, installs, and configures a PDF iFilter, and this script has become my preferred method. The script is part of a larger package, so I've stripped out the relevant parts and posted them on this page. Save that file as pdfsearch.ps1. The file contains two functions: Configure-PDFSearch and Configure-PDFIcon. The former installs and configures the iFilter; the latter adds a PDF icon to the SharePoint interface. As I describe for the script in Mistake #8, install the functions by dot-sourcing the pdfsearch.ps1 file and then executing the function.
Mistake #10: Not Pointing Your SharePoint Servers at ThemselvesWhen SharePoint works, it is magnificent. When it doesn't work, it can be a nightmare to fix. For this reason, anything you can do to ease troubleshooting is time well spent. To that end, make sure that every server in the SharePoint farm points to itself for all web apps. If you get sporadic reports about SharePoint not responding, you can easily use RDP to log in to each server and try to pull up SharePoint. If this attempt works, then you know that the server is working. If SharePoint does not come up, then you know in exactly which Microsoft User Location Server (ULS) logs to look for the relevant errors. No worrying about which web front end the load balancer sent my request to. The quicker you get to the correct log files, the quicker the problem is resolved.
Pointing your Search indexer at itself has another advantage: It improves performance for your end users. If you don't point your Search server at itself, then when it starts to perform a crawl, it lets DNS do its work and then starts crawling whichever web front end DNS points it to. That server is most likely the same one that is sending pages to your end users. Making the server do double-duty means that everyone waits longer. Pointing the Search server at itself means that your web front end doesn't need to handle that traffic and can get back to doing its #1 job: keeping users happy.
There is a simple fix for this mistake: Open the hosts file (C:\windows\system32\drivers\etc\hosts) on each SharePoint box, and add all the URLs that SharePoint knows about. Point those URLs to 127.0.0.1, which translates to "this computer." Figure 3 shows how this file looks in a typical SharePoint environment. This approach provides all the benefits that I've mentioned but uncovers a nasty beast: loopback detection. This monster, as well as how to defeat it, is scary and too long for this article, but you can read all about it in my blog post "Can’t crawl web apps you KNOW you should be able to crawl."