Default installation configuration and what you need to know.
With my focus on Governance I thought about settings and configuration that really should be changed from default. I've often had people ask... What should I configure, what is the default? The expectation is that you do need to configure it. I've had some good conversations with Bill English and some of his staff around some of what a company needs to do in terms of planning. You may have seen the poster from Tech Ed. Here are some ideas and cautions around default...
For me this is a top of mind list... you may find others... feel free to comment on them or blog... It's something I haven't seen in any form, so I welcome feedback.
One quick story... A default basic/simple install will give you a single web app, an SSP, the central admin all on one box with SQL Express with a max SQL limit. All the sites will be in one site collection with no self service all in an Intranet portal template with site creation in the site directory all using NTLM (Windows Authentication) and no quotas. This isn't likely what you are looking for in a collab environment and maybe has the wrong template if you're looking for a WCM environment or even a ECM Records Repository or Document Repository.
Farm and Web Application -
Email - Outbound first, then you may want to configure inbound. I wouldn't recommend starting with inbound on. It's something I recomment you try to understand all the implications first.
Usage Reporting - Needs to be turned on for WSS (central admin) and MOSS (SSP). You may want to consider a third party tool for farm reporting or web app reporting.
Web App Policies - No policies other than adding the crawl account to the read policy. Consider any deny policies for people outside your company/organization especially on knowledge repositories.
Alternate access mappings & zones - you'll get a default one when you extend, but not much else
Service Accounts/SPN - first it will assume NTLM auth, if you want Kerberos which is recommended you'll need to create the SPN, you'll also need to create domain accounts, don't use local service or network service in multi server farm environments. For security it is recommend you use more than one account. My recommendation is the crawl account and your central admin connection account are different than your account you use for the content app pools. That crawl account is one you want with the least rights since it potentially will be accessing more systems than anything else (For MOSS/WSS 3.0 it really only needs read... hence the read web app policy.) Shane Young is working on putting secure install all in one lab in his new Admin Training course SPA401.
Quota Templates - even though you may see some, they are not applied on a web app by default. My recommendation is you create at least 3. 1 GB, 2-4 GB 5 GB, 15 GB are decent. Something low, something mid range and something at your max range.
Recycle bin - These are configured at the web app level. I actually really like these defaults and recommend you leave them alone. I recommend keeping it out of your mind even. Do you think about your Windows recycle bin or your Outlook recycle bin. Ok then. Consider a third party recovery solution for sites and site collections or look at the site delete capture tool that MS IT shared on codeplex.
Features and Solutions - The features you'll find will be paired back to what is in the box, and catered to the site template that is chosen. The enterprise and standard features are different. If you later put in the enterprise pid, then you will then be allowed to activate features at the farm, then web app, then site collection and site level. It's something that is recursive. Often you won't see the features if they aren't enabled up stream. There are some exceptions, but could cause unexpected issues if they aren't enabled first at the site collection level. If you go from WSS to MOSS, the exercise of learning how to enable these and walking from farm to web app, to site collection to site will help you learn the differences between templates and features. It's still not 100% smooth to turn a team site into a publishing site for example. It's easy to add features and enable cool new lists and functionality, but changing the look of the home page and it's behavior is another issue.
Backups - Now this is important! SharePoint does not back itself up without your help. It doesn't know what drive you want to backup to or what you want backed up. The expectation is, is that you will do a scheduled backup on your own. The web UI is cute and gives you a slick way to do a backup prior to a hotfix or service pack install, the expectation is you will create a scheduled task and use the stsadm full to backup your farm, with optional differentials. You'd either then use SQL to backup your databases and NTBackup to backup your drives, system state and frequent metabase backup. There are some great third parties and solutions out there to help you navigate this space, especially if you're looking for high availability and disaster recovery.
Self Service - it's off by default. Note when you do enable this for a web app it still requires that the user has rights to create site collections. The SSC as it's known is to enable the creation of site collections. By default it is off, and sites in WSS under the root site collection of a web app will be sites in that root they will all be in the same quota. The SSC enables separate site collections that can go into separate databases. Even my sites require the rights. The thing I wanted to get to here is the site directory, by default it creates sites not site collections, this can be configured in the site settings of the intranet portal. For WSS it's a matter of sending people to the SSC right location, in the team template it will add an announcement with the link. /_layouts/1033/scsignup.aspx (replace 1033 for your LCID)
All in one content database - (That's the default) everything all goes in one content db. If you create a portal and then start creating my sites and site collections via SSC they will all go into one db. The first thing I do is put the my sites in their own db, and the keep the other site collections separate. Sure you can try to move them later, but it's more painful later. I also recommend thinking about how many databases you want up front and how large you want them to get. I've got some reading on these topics on my blog. Look for site collection sizing, and content database sizing. Looking for some quick numbers... try 100GB as a max for planning, and 15 GB as a top max for site collections. I wouldn't go more than a few hundred site collections in a db. 200 max is a good range for the average team site for example.
Default - No SSP you need to create it. If you create another one you need to specify which one is default so new content web apps will know where it is getting its indexing configuration, and other SSP info.
Site Collection and Site -
Quotas and Quota Templates - Quotas are not applied by default. If you create and then assign the quota template for a web app, you'll get all sites created with a single quota. If you do nothing at all, all site collections will have no quota. How big should they be? If you can't think of anything good. Start with somewhere around 1GB. It will be manageable if you start with 100MB you'll get plenty of support calls.
Document/List settings - Versions are off by default on nearly all lists (exceptions are doc workspace, enterprise document repository, check it out), force check out is off on nearly all as well. Content types, there are some good defaults, but required columns, and turning on major and minor versions are all things you need to think through.... email enabled lists and all those settings all off by default. That cool document information panel is something you can turn on and enforce to get richer captured data. The content types are very simple, no template, no workflow, no auditing or information policies. The things you want you need to turn on.
Information Policies and Reporting - You need to turn this stuff on. You want auditing, you want to know who deleted a particular document or item, it's off by default. MSDN has a great sample by Ted Pattison on how to programatically enable auditing. Even expiration is something you'll have to think about turning on.
Master page - yep you'll get the beautiful blue out of the box ones and the style sheet has a bunch of fun stuff in it you may want to clean up or minimize. The themes are fun for classic FrontPage fans, but otherwise you're likely going to want to build your own master page. It's not tough with SharePoint Designer, but there is great training out there (check out Heather Solomon's training for example). Don't go overboard in your designs keep it simple. Master pages are very cool you can do a lot with a little. It's often here that people make mistakes thinking they have to do hard core development to change the look and feel. No longer. The nav is pretty flexible. Try to make the out of box nav work first. Look up the minimal master page on MSDN.
Cache (Blob and Output cache) settings - they'll be non existent on all the WSS templates and some minimal enabled on the Publishing template. The web app cache settings and page settings will need to be configured cause obviously this will be different based on what you're doing.
Navigation and placeholders - The Intranet Portal has some placeholder type content in it that you can clean up. You may not need all that stuff, you can delete the lists and put what you want in the Nav.
Workflows - off. All those fabulous workflows are off by default. You need to create some if you want them. Even WSS comes with a couple of workflows. SharePoint Designer workflows are more powerful than most give them credit for.
Templates, Features, and Solutions - The features you'll find will be paired back to what is in the box, and catered to the site template that is chosen. WSS will have specific site templates... MOSS has different templates, but of course since it sits on top you'll see all the WSS ones which can then be enhanced.
Excel Publishing - safe locations are off by default in the SSP. You need to either set the entire web app as safe or specify certain paths or site collections. It isn't difficult, just specify the path.
KPIs and Reports Center - it simply requires configuration
Search and Indexing and Search Center - Indexing of the content and central admin web app are indexed by default. You will need to create rules, best bets, keywords, if you want or need those things, but the default with search will automatically index sites that are created either in WSS or MOSS.
BDC - it's ready to configure in a MOSS install after you create the SSP in an enterprise farm.
Forms - again, ready to go, you need to web enable them from the Infopath client if that's what you're looking for.
Technorati: Microsoft, SharePoint
