We have offices throughout the world and have the resources to support the largest global organizations whether they be in the Americas, Europe, Middle East, Africa, or across the Asia Pacific and Japan region.
Let’s break down investments by workloads…SitesCommunitiesContentSearchInsightsComposites
No SQL maintenance plansAll gardens need weeding. SQL databases need tending too. Left on their own, content databases and config databases will generate runaway transaction logs. Combined with overzealous local backup retention plans and you’ll quickly fill up you storage. Take a little time to understand Full Recovery vs. Simple Recovery in SQL. Or, more importantly, use a maintenance plan to backup and truncate your logs – it’s not that hard.Default names for every databaseThe default database name for a SharePoint content database is “WSS_Content”, and if you take the defaults, all subsequent databases will take the default format WSS_Content_[really-long-GUID]. Don’t do this – down the road, during backup, restore or SQL maintenance operations you'll be constantly jumping into Central Admin to figure out which sites use “WSS_Content_abdc1234-1111-2222-878adf0e”. Much better to name the databases according to a person- friendly standard – “WSS-Content-HRPortal”, etc. Even if it’s obvious to you, it may not be obvious to your DBA or someone else who has to support it in the future. No patchingGiven my crazed obsession with SharePoint version numbers (see http://blogs.kma-llc.net/microknowledge/version-build-numbers/) this is not a stretch. Microsoft has made it as easy as possible to stay in sync with the latest patches, Service Packs and Cumulative Updates. Do you need to update your systems every two months? Probably not. Should you still be running the nearly four year old RTM version of SharePoint 2007? Definitely not.One environment for everythingDon’t build a development environment. Don’t build a test environment. Just make all changes live, in production. What could ever go wrong?One acct for everythingBig, big no-no here. If you don’t pay attention, you may be tempted to use one master account for the SQL service, for the installation, for the farm account, for search, for content access, and for the IIS pools. Then, when you administer the site, it’s always easy to work around security restrictions by handing out those account credentials to a wide group of people. Next thing you know, someone forgets the password and locks out the account. The great news is that you don’t need to build a monitoring system for this alert, because everyone and I mean everyone, will get the dreaded web page that reads:Cannot connect to configuration database.So don’t give out the admin accounts, and, especially, don’t reuse the farm account.Single server install with SQL ExpressIf you don’t pay close attention on the original installation sequence, you may pick a “standalone” single server installation. You’re starting with only one server for now, right? Unfortunately, you’ll wind up with a server that can’t be expanded, running SQL Express Edition. And limited to 4GB of content database size. Well, at least you’ll avoid the next problem:Runaway content database sizeMicrosoft recommends that SharePoint content databases stay below 100GB (200GB if it’s the only content DB in a SharePoint 2010 site collection). But SharePoint doesn’t stop you from adding more – it’s a recommendation for optimal user performance. However, I’ve seen too many installations that grew grew grew to 250GB, 500GB or more. Plan your content database sizes in advance of critical sizes. You can add databases and site collections to create more manageable units, or use Remote Blob Storage (RBS) to pull those file of attachments out of the databases and into external storage, reducing file sizes.
Use SP to managed SPBusiness owns home page
I would be happy to discuss what we are trying to put together for partners/TEC.