My tips and tricks, best practices, and lessons learned from the field. Feedback is always appreciated. Please leave comments.
Friday
22Jan2010

PSSPUG - SharePoint Database Provisioning Presentation

Last night I had the pleasure of presenting at the local Puget Sound SharePoint Users Group on a topic dear to my heart – SharePoint database naming and provisioning.

image

The user group is a great forum for interacting with other people passionate about SharePoint, so if you are in the Seattle area and have not attended, I  highly recommend it.

It was a great group as always, with some good questions that I will be answering as updates in this post shortly:

  • How do you rename the SharePoint farm configuration database?
  • What is the upgrade impact on databases from SharePoint 2007 to 2010?

Download: SPBITS - SharePoint Database Provisioning.pptx

Friday
08Jan2010

Rewriting short URLs with Alternate Access Mappings

In the early days of building SharePoint Intranets on SharePoint 2003, many organizations did not have remote access strategies for employees. The choice of a URL for a SharePoint site often reflected a preference for short, user-friendly names that took advantage of automatic domain suffix mapping to auto-complete the fully-qualified domain name. For example:

http://intranet
http://mysites

In this case, the fully-qualified domain name might be “intranet.company.com”, but DNS would resolve the name correctly by assuming a DNS suffix related to the current Active Directory domain. It was assumed that employees would be accessing the Intranet on the company network. For organizations that did support remote access using VPN strategies, this also worked fine.

When SharePoint 2007 was released, it became easier to support additional variations in the site address to accommodate more sophisticated scenarios by using Zones. It would be common to configure sites to use Zones to support short names for the “Default” zone for internal company users, and fully-qualified domain names for corporate WANs and/or secure Internet access.

image

Originally, there were some technical constraints influencing this design. SharePoint Search could not crawl sites that used Kerberos or were secured by SSL on the default zone.

Fast forward to the beginning of 2010, and the technical constraints are now mostly gone through the release of Service Packs and Hotfixes, and I have been discovering some issues with this strategy:

  • Desktop tools that integrate with SharePoint often require the fully-qualified domain name (ex. Colligo Desktop). Users often cut and paste these URLs from the browser, so displaying the fully qualified domain name for the site is becoming more of a necessity.
  • In response to a more mobile workflow, organizations are increasing exposing SharePoint sites to the Internet for direct access. Users now have to contend with bookmarked and embedded document hyperlinks that are a mish-mash of unqualified and qualified domain names.

My recommendation to clients now is to standardize on fully-qualified domain names, and restrict the use of alternate Zones to the specific purpose it was designed for – supporting alternate authentication providers.

Thankfully, we can still take advantage of some tricks with Zones to continue to support the user-friendly unqualified domain names by having SharePoint re-write the unqualified names to the fully qualified names when a user browses to the site.

  1. Create your SharePoint web application using the fully-qualified domain name for the Public URL. SharePoint will automatically add the appropriate IIS host header. If you have an existing site you want to convert to a fully-qualified URL, then edit the Public URL under Alternate Access Mappings.
  2. Open IIS Manager and edit the bindings on the web application you created. Ensure that both the unqualified and fully qualified domain names are included on the web application.
  3. Open Alternate Access Mappings and add a new Internet URL to the default zone for the unqualified domain name. The Public URL will remain the fully qualified domain name.

The final configuration in SharePoint will look like this:

image

Now when the user enters “http://intranet” into their browser, SharePoint will accept the unqualified domain name, but re-write the URL to the fully-qualified Public URL ensuring standardization and consistency.

Monday
04Jan2010

How Themes work in SharePoint 2010

Themes have been around in SharePoint since 2003 as an option to customize the visual appearance of SharePoint. SharePoint 2003 and 2007 both included a set of themes out-of-the-box that could be applied to a SharePoint site by a Site Owner through the SharePoint UI, and web designers and developers had the ability to create custom themes containing custom images and CSS files.

One of the problems with how themes worked in SharePoint 2007, was that to customize them required a web designer or developer to create custom CSS, image and supporting theme registration files, and deploy them to the file system on the SharePoint Web Frontend Servers. This restriction required technical knowledge and access to physical servers, and thereby restricted non-technical users from being able to customize the SharePoint visual design of their sites.

Themes are also supported in SharePoint 2010, but how they work has changed considerably. One of the goals stated by Microsoft is that they wanted to provide the ability for non-technical users to have ease of use and control over the visual design of their sites, and the ability to customize themes through the SharePoint UI.

Click to read more ...

Sunday
27Dec2009

Design and Apply a SharePoint Database Naming Convention

It must be the geek in me that craves order, but I have never liked the out-of-box database names for SharePoint 2007. SharePoint uses a somewhat large set of databases for a farm installation combining configuration, search, and content databases. If you were to setup a normal SharePoint Farm using the suggested database names, it would look like this:

  • SharePoint_ConfigN
  • SharePoint_AdminContent_<Guid>
  • SharedServicesN_DB
  • SharedServicesN_Search_DB
  • WSS_Content
  • WSS_Search_<ComputerName>

There are a few of problems with this approach that become even more obvious when you install SharePoint on a database server that hosts more than one SharePoint Farm, and mix SharePoint databases with other application databases.

Click to read more ...

Sunday
27Dec2009

Manually create SharePoint Farm Databases with PSCONFIG

A SharePoint Farm installation utilizes a number of SQL databases. A normal MOSS 2007 installation requires a minimum of six databases including configuration, search, and administration web application content databases. Over time, as organizations add sites for user content, this list can grow to many more.

The standard approach to installing a new SharePoint Farm involves running the SharePoint Products and Technologies Configuration Wizard at the completion of a WSS or MOSS 2007 setup program. Among other things, the configuration wizard creates the farm configuration database , and the content database for the Central Administration web application.

Unfortunately, the default names are not very user-friendly, and this can cause problems with managing our SharePoint databases. Where these problems become most relevant is when hosting multiple SharePoint farms within a single instance of SQL Server, and when mixing SharePoint databases with other applications within the same instance. It can be difficult to differentiate the SharePoint databases between the various farm instances.

The solution to this problem is to use a command-line utility included with SharePoint called PSCONFIG.EXE to provision the initial farm configuration and administrative content databases manually.

Click to read more ...