Top 10 SharePoint 2010 Administrators Mistakes and How to Fix Them

This blog explains the top 10 mistakes of SharePoint 2010 administrators and how to fix them? Here is the solution to fix all top 10 mistakes by SharePoint 2010 administrators.

Microsoft SharePoint 2010 is a complex yet powerful beast, with so many features that you can call attention to all. There is no doubt why we get some of them wrong over time. I’ve been using SharePoint 2010 from the last couple of months and I’ve seen many configuration mistakes people do. In this blog, I will cover of 10 Administrators Mistakes people do. I will clarify what, are the correct configurations, why are they correct and how to fix the setting.

Mistake 1. Balanced of RAM or Hard Disk Space on SharePoint 2010.

I have seen this multiple numbers of times. SharePoint servers have limited resources of time which led to the jagged working of SharePoint. The reason for this condition is hostile virtualization. Thinking outside the box is not bad, but it should be done reasonably and without disturbing SharePoint tasks.

If the SharePoint run out of RAM, it would automatically shut down some of the functionality so that it can work in the available space. Similarly, it caches less in the web and recycles those pools again and again. This less caching and constant recycling results in diminishing the user experience, as SharePoint should similarly amass the ASP.NET code repeatedly.

To overcome this situation, there are very simple things that you need to do and i.e. increase RAM. Microsoft has recently published a manual about hardware requirements for SharePoint 2010. According to these requirements, SharePoint 2010 should have RAM of 8GB and 80GB of storage in C drive. In some of the cases, there are chances that won’t be enough. If servers are already networked, then keep an eye on the usage of the 8GB of RAM for refined performance. Also, if your servers are not networked, you can use various load-testing simulations to mimic your load and analyze how your servers perform.

And for your C drive, Windows requires most of the space with respect to SharePoint. Consider adding a new secondary drive while adding space to the servers. This drive would be the best place when installing SharePoint. All the third-party installation can be stored in the extra drive and also you can add SharePoint logs and Search index files in this drive. This approach would easy out all the tension from the C drive and health C drive results in the fast and safe output.

 Also Read: Best Plan for SharePoint Disaster Recovery

Mistake 2. Utilization of Virtualized Microsoft SQL Server

Virtualization is not bad, but there are tones of chances that the administrator will make a mistake or two and making a mistake on a grander scale can be problematic. Take virtualizing SQL Server with respect to SharePoint. The main misstep users do be overcommitting the host, via RAM, CPU, or drive space. As we know all the everything saves in SharePoint are saved in the SQL server and if the SQL is slow then ultimately SharePoint will also slow down.

The first and the very obvious solution are to move the SQL server to the physical box, where it doesn’t need to share of the resources. Using aliases, it has become very easy to move SharePoint SQL server. We will discuss how to move SharePoint SQL server in a different blog.

If you are unable to obtain a physical box for SQL server, then there are things that you need to keep in mind.

1. Your virtual drives shouldn’t thin provisioned. I/O is where virtualized SQL servers skirmish the most, and having thin-provisioned drives infuriate the situation.
2. Try putting SQL server guests’ virtual drives on spindles on the host. By this, you can enhance I/O by restricting the SQL server from conflicting with other guests.
3. Never allow virtualization host to overcommit its RAM. If this happens then, the host will try to engulf more the RAM to meet paucity of memory. This will ultimately slow down the whole system.

Mistake 3. Farm Configuration Wizard

One of the most common mistake people did when SharePoint 2010 came out was using the Farm Configuration Wizard, but over time it has reduced as our understanding is increased with SharePoint 2010. There are so many wizards, so will only discuss few of the popular one.

 

1. Let’s start with the most detestable wizard that creates major issues and can easily be spotted by their unique identifiers (GUIDs) at the end of their name. This wizard builds a content web app at http://servername and to worsen the situation it creates your My Site host on the previous build app, at http://servername/my. Also, this wizard would push you to create a service that you will never you.

 

2. Another but not last wizard that gives you a hard time is the Farm Configuration wizard. What this wizard does is, it leaves its handprints throughout the SharePoint and it is very difficult to clean them up. Let’s start cleaning with the easiest place i.e. your web apps. First, create a web app for My Site and provide it an FQDN (Fully Qualified Domain Name), like mysites.company.com. After that generates My Site host at the web app’s root. With the help of Windows PowerShell cmdlet, shift- SPSite to any My Site to any of the content database, now attach the content database to your fresh build the web app. You should also adjust your user profile and guild it to your new My Site location.

 

3. In this, you need to clean all your service applications. Uninstall all the applications that you are not using. After that stop the associated service instances aka services on the server that provide power to them. Try to remove GUIDs from the service application database.  

Mistake 4. Entering Incorrect URL while Creating a Content Web App

SharePoint doesn’t inform Microsoft IIS about of any changes done after the creation of web app. The problem arises when SharePoint suddenly need to be accessible from the Internet. Budding SharePoint administrators unintentionally give the web there a short URLs like http://portal. Obviously that URLs do not provide internet access, so the web app needs a working URL added to its stable of AAMs. The new URL is not written to the IIS host headers along with it is also missing from all the signals, workflow, or anything that saves URLs. Not writing to one another i.e. Microsoft SharePoint and IIS results in the collapse of Web Application service.

This issue does not sound like a big deal but has created so much problem for the people around me. Now how to resolve this issue. As SharePoint writes host header only when the web app is created, so you will not be able to fix these problematic web apps. You need to recreate them once again. Doing so have both good as well as a bad side. The good part is that won’t lose any of the content and the bad part is that you will lose all the settings that you have worked on.

The first thing that you need to do is to make notes of all your web app settings. Usually, there are not many and you’ll be familiar with the changes you have made. After that detaches the content database from the web app. Now, make a copy of the web.config file. Finally now go to the Central Administration and delete your previous web app. Command SharePoint to delete the unwanted stuff.

Now to recreate the web app. First, enter the correct and fully qualified URL in the Host Header box. For convenience put the web app on port 80. In the Security Configuration settings, you need to accept all the defaults. You can change any of the settings later and make sure your web app is working perfectly before applying any security settings. This would help you in troubleshooting if needed.

It is very important to give a distinct name to your content. By this, you could easily locate your content and would know under which web app that database goes exactly. And after the web app is created, you can change the setting according to your requirements. Most of the setting can be changed in Central Administration. If any changes were made to the web.config file of the original web app, now change the setting of the newly created web.config file as well.

Mistake 5. Run web apps or service apps in separate app pools

Both of the apps run under the same application pool and that is W3WP.exe. You should run all SharePoint web apps inside one application pool and do the same for service applications. Running both the web app in their own application pool makes less use of the server’s memory.

We all know SharePoint works slower in the morning as app pools recycle overnight and need to

Cache the data again. Doing so results in the same data is cached multiple times.

The service applications problem can easily fix. All you need is to keep few things in mind like, use good service application pool. I would suggest calling this pool Default SharePoint Service App Pool. Now use the dedicated sp_serviceapps account to create the pool’s identity. In the Central Administration, you can easily assign a new service application pool by modifying their properties. If there is no option available there, then look into PowerShell.

Mistake 6. Using only one Account for each and everything

What most of the people do is use one account to handle all the things. When you use a pre-existing account, you open up SharePoint to various security issues that can easily corrupt it. If anyone gets hands there on the password then its game over as they are doing whatever they want and you won’t be able to audit who made which changes. If the account’s security gets compromised then SharePoint becomes vulnerable to any kind of attack.

The best way to bypass this problem is to create unique accounts and add the sp_webapps and sp_serviceapps accounts as managed accounts. Use the similar method which we discussed in mistake 5 to fix your web app and service application accounts. Under the Central Administration >> Security >> Configure Service Accounts >> change the accounts those are processes are using as well. If you are utilizing the user profile service then make sure that your newly created sp_userprofile has the required permission in the Active Directory (AD), along with recreating your AD connection.

 Also Read: Reasons for Corruption in SharePoint Server & Solution

Mistake 7. Using default SharePoint settings

Leaving SharePoint on default settings is another mistake user do unknowingly. When SharePoint is left own it owns itself assume things like: The database files grow by 1MB and it ensures that they auto grows with every upload. Which lead to the slowing down of the SQL server. Another it Config and Content databases with the recovery model which is not bad but slow down SharePoint because of fragmented databases.

To eliminate this problem, set your database auto to grow setting so that it does not need to grow frequently. I would also recommend changing your 1MB auto grow to 500MB or 1GB.

Mistake 8. Not Enabling BLOB Caching

BLOB caching is one of the best, easiest and cheapest ways to improve SharePoint performance. It helps to quickly deliver files to the user and eases out the burden from the SQL servers.

It is the easiest solution you can opt to improve your SharePoint. All you need to do is enable Blob caching. It is actually a feature of IIS but SharePoint takes it to advantage. So to enable Blob cache just change its settings. The web.config files are in a directory under C:\inetpub\wwwroot\wss\virtualdirectories by default.

To enable BLOB caching all you need to do is replace “false” with “true” and save the web.config file. Also, move the file to the other drive directory.

Mistake 9. Not utilizing a Pdf Filter

As most of the documents are saved in the Pdf format nowadays to installing one is not a bad idea in the SharePoint farms. Adobe provides a free PDF iFilter that you can easily install. Only install to those SharePoint servers which run on the search Index role. You can also use PowerShell to make this task easier.

Mistake 10. Does not Pointing your SharePoint Servers at themselves

Pointing SharePoint servers indexer at itself has another advantage. It improves the performance of the end users. If you don’t point Search server at itself, it will automatically start to perform a crawl action and it lets the DNS perform crawling whichever web front DNS points out. By this server have to do things twice which ultimately lead to the slow down. So you should point the servers at itself and pointing the Search server at itself means that the web front end doesn’t need any handling to traffic and can perform its task easier.

Follow these steps to fix this mistake: Direction to open the hosts file on each SharePoint and also add all the URLs (C:\windows\system32\drivers\etc\hosts). Now point all the URLs to 127.0.0.1, basically which translates to “this computer.”

Bottom Lines

There are tons of screws up SharePoint. So be aware of the things that affect SharePoint and try to avoid them. In this whole article, we have discussed what are the mistakes what users do and how to fix them. So now that you are filled in with the information you will be able to avoid and fix the SharePoint errors.

Related Post