You DID WHAT with your SharePoint Implementation?

I was subcontracted out to another company to go and do a SharePoint audit of one of their clients. I get to the client and start looking at his implementation, while he is running through the items that are not working correctly, some being alerts not working, the search configuration not working, not being able to access additional features, etc.

As soon as he brings up Central Administration I can basically tell where most of the problems are coming from. The entire Intranet is built as a subsite under Central Administration. Well as any SharePoint Admin will tell you that is just bad news waiting to happen or in this case already happened. There are numerous reasons why this is a bad idea, to name a few security, scalability, features not working as designed, etc.

Alerts of course are not working because the timer job is not created in Central Administration. The Publishing feature is also unavailable and the Search Center will not work either. I have to give the guy some slack however because he runs a tight ship and had one of the cleanest server rooms I have ever walked into, for a one man band this guy has it together managing an entire 60 server farm and an insane amount of applications all while performing tech support, but you cant do everything yourself when it comes to IT, so I am glad he realized he needed some outside experience.

So I then continue my audit seeing that the databases are all included in one instance, I am not just talking SharePoint here, all of his database applications, so 30+ databases. I see the default SharePoint Databases so no problem there (besides Central Admin containing the Intranet of course). All items are also stored on the same network store. The infrastucture updates were not in place either, and some other misc timer jobs were failing, as well as some errors in the application log. All in all a big mess.

My recommendation:

• Install the Infrastucture updates
• Diversify the user accounts for the different web apps and the search service
• Move the SharePoint Databases to their own instance in SQL
• Carve out a seperate store for the SharePoint databases and logs
• Break the Intranet out into its own web app and create new site collections each with their own content database 1. For Scalabilty(I have seen different recommendations but the most common is to try to never go over 100GB for a content DB and try to stay under 50GB, 25GB even better) 2. For Disaster Recover, youll have less downtime if you have to restore a 50GB DB vs a 250GB database.
• Tie all items back to one search center

Im sure there was more but this is all I can remember off the top of my head, Ill explain how I did the move in my next blog.