Join me Thursday morning at 11am CST as I present on Disaster Recovery Planning for SharePoint as part of ThirdTier.net’s Third Thursday webinar series:

Third Tier has invited you to attend an online meeting using Live Meeting.

Follow these steps:

1. Copy this address and paste it into your web browser:

https://www.livemeeting.com/cc/harborcomputerservices/join

2. Copy and paste the required information:

Meeting ID: JCHM5Z

Entry Code: g$P5j6,Kq

Location: https://www.livemeeting.com/cc/harborcomputerservices

OK – just a quick poll . . .    Raise your hand if you’ve seen this:

You install Windows SharePoint Services 3.0 (either on a Windows 2003 or 2008 server) and create a new web app & site collection.  While the site works great for all of your local clients, and even works externally – you can’t access the site from the server it is running on.  Specifically – when you try to browse to the site on the local server, you get prompted for credentials 3 times before getting a generic 401 unauthorized error.

I’ll admit I have been seeing this for quite some time, but have always been too busy to track down the cause, especially since the easy workaround is to just access the site from another machine.  Well, I finally did some digging and was able to identify the cause & the solution.  This is actually caused by a failing loopback check – which is the exact same scenario that causes the infamous 2436 Gatherer errors for our companyweb in SBS 2008.  And to keep things consistent – the exact same fix for the 2436 errors will fix our inability to access a WSS 3.0 site on the local server it’s running on.

You can find the specific steps on the SBS support blog:

http://blogs.technet.com/sbs/archive/2009/05/07/event-2436-for-sharepoint-services-3-search.aspx

Just add the URL of your site to the BackConnectionHostNames registry entry, run an iisreset and you’ll be good to go!

A while back, someone in the SBS 2008 newsgroup had a good question.  Short story is that they are making extensive use of their companyweb, including content approval in some document libraries.  They have configured email alerts on these libraries, so approvers are notified when new documents are added and waiting approval.  However, a few of these approvers travelled regularly, and were often out of the office.  When they received new email alerts from their companyweb, the embedded links all pointed to http://companyweb/…  The obvious problem was that if they were working from their laptop with Outlook RPC over HTTPS at say an airport, Starbucks, or wherever then the links in the alert email wouldn’t work (since http://companyweb is only resolvable on the LAN).  The poster in the newsgroup asked where SharePoint stored the URL so he could edit it.

The beauty with this question is just how simple the solution is.  SharePoint 3.0 supports a single web application being accessible via different URLs, with the different URLs being in different security zones.  This is evidenced by your companyweb in SBS 2008 being accessible via both http://companyweb (intranet zone) and https://remote.yourcompany.com:987 (default zone).  When a user is creating alerts on a SharePoint site, SharePoint is smart enough to take note of which URL the user is using to access the SharePoint web application when they create the alert.  As a result, links in alert emails will include the base URL that was used to access the SharePoint site when the alert was created.  SO – if you browse to http://companyweb and create an alert on a list library, all emails you receive for that alert will have links that point back to http://companyweb.  On the other hand, if you browse out to https://remote.yourcompany.com:987 and create an alert on a different list or library, all emails you receive for this alert will have links that point back to https://remote.yourcompany.com:987. 

SO – if you have users who are regularly out of the office, rely on alerts from your SharePoint site and want to be able to use the links in the alert emails, make sure those users browse to the public URL for your companyweb when they create their alerts.

I’ll admit this post is long overdue.  I’m sitting here staging a new server for a client and just finished running through these steps on their server, so I figured now was a good time to post since the process is fresh in my head.  Particularly, the task at hand is to configure companyweb on our SBS 2008 to properly index Office 2007 documents and PDF documents, so their contents will appear in SharePoint search results.

Yes, you read the correctly.  Small Business Server 2008’s companyweb does not index Office 2007 documents out of the box – I kid you not . . .

Luckily, getting Office 2007 documents to show up in companyweb search results is simple enough, all you have to do is download and install the Office 2007 iFilter from Microsoft on your SBS server.  When downloading, obviously be sure to download the 64-bit version of the filter pack.

After installing the Office 2007 iFilter, we need to install a PDF iFilter as well.  Luckily, Adobe has released a 64-bit version of their PDF iFilter, which you can download here.  Unlike the Microsoft Filter Pack, there is some manual configuration to complete after we install the Adobe PDF iFilter:

1. On your SBS, run regedit and navigate to the following registry key:
   HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications\<GUID>\Gather\Search\Extensions\ExtensionList\
2. Right-click on the ExtensionList key and select New –> String Value
3. Enter  38  for the new string value and hit Enter
4. Double-click on the 38 string value you just created to edit its value.  In the Value Data box that opens, type pdf then click OK.
5. Locate the HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf key and verify it contains the following registry entry:

   Name:  (Default)
   Type:  REG_SZ
   Data:  {E8978DA6-047F-4E3D-9C78-CDBE46041603}

   You will most likely need to edit this entry so its value matches the GUID listed above.

6. Locate the HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\Filters\.pdf  subkey and verify it contains the following entries:
   1. Name:  (Default)
      Type:  REG_SZ
      Data:  (value not set)
   2. Name:  Extension
      Type:  REG_SZ
      Data:  pdf
   3. Name:  FileTypeBucket
      Type:  REG_DWORD
      Data:  0x00000001 (1)
   4. Name:  MimeTypes
      Type:  REG_SZ
      Data:  application/pdf

That completes the installation / configuration of our iFilters.  If you haven’t already fixed the SharePoint Gatherer 2436 errors on your SBS yet, be sure to do so now.  (Check out the Official SBS blog’s post on the topic).

So, once you have your iFilters installed & configured, and you have your SharePoint Gatherer 2436 errors resolved, we just want to bounce IIS then force SharePoint to start a full reindex of your companyweb site to index any Office 2007 and PDF files you have previously uploaded:

1. Open a command prompt (as Administrator) and run an  iisreset
2. After the iisreset completes, change your working directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin
3. Stop the SharePoint search indexing process by running this command:  stsadm –o spsearch –action fullcrawlstop
4. Once that command completes successfully, start a reindex of your WSS 3.0 site(s) by running this command:  stsadm –o spsearch –action fullcrawlstart

Once the fullcrawlstart command completes successfully, SharePoint will start reindexing your site(s) and you should start seeing search results in companyweb within a few minutes, although it may take longer for the site to be fully indexed depending on how much content you have in your site.

Happy searching!

OK gang –

The SBS team has blogged explaining where our 2436 errors come from on SBS 2008.  The short story is that SBS is thinking it is protecting itself.  Recommended solution is to edit the registry to add the public URL for your companyweb (e.g.  remote.company.com) to the BackConnectionHostNames, allowing that URL to bypass your SBS server’s loopback check.

Google searches will result in a multitude of work-arounds different people have posted, most of them you do not want to implement including:

1. Disabling the loopback check all together.
2. Tweaking the Alternate Access Mappings in SharePoint (unless you need to for other legitimate reasons – not the 2436 error)
3. Changing your companyweb’s security zones in SharePoint (remote.company.com should be the Default zone, with companyweb in the Intranet zone).

If you’re like me and subscribe to the idea of least privilege access, you can still update the SharePoint search configuration as mentioned in my previous post.  Most built-in accounts (e.g. NETWORK SERVICE, LOCAL SYSTEM, etc.) have more permissions than required to perform SharePoint search functions.  Creating standard user accounts to do the SharePoint Search work follows the general best practices of least-privilege access.  While this follows SharePoint best practices in not using built-in accounts for the SharePoint search service or search content access accounts, it is important to note that editing the SharePoint search configuration on your SBS 2008 has not been tested by Microsoft and therefore is not officially supported.  This doesn’t mean it won’t work (my SBS 2008 boxes are running this configuration without issue so far) – it just means that if it doesn’t work, Microsoft isn’t going to support the configuration.  So if you want to keep in the fully supported realm, leave the SharePoint search configuration as-is. 

*UPDATE:  Still not why the steps below work on some boxes but not others.  However, the SBS team just blogged about the implications of the Loopback Check registry key as well as the ability to register your public URL on your SBS box so that it bypasses the loopback check without having to completely disable the loopback check.  I still recommend reconfiguring SharePoint Search as noted below in addition to registering your public URL to bypass the Loopback Check.

*UPDATE:  We have confirmed that the steps below work on some SBS 2008 boxes, but not all installs.  If these steps do not work, see Dan’s entry in the Comment section about disabling the LoopBackCheck in the registry.  Despite what you may see in other forums, SharePoint search will work just fine with https://remote.company.com being the Default security zone for your companyweb – you do not need to edit your alternate access mappings.  Additionally, the SPContent account only needs to be a member of the domain users security group, and the SPSearch account only needs to be a member of the domain users and WSS_WPG security groups.  SharePoint Central Administration will add the SPSearch user account to the WSS_WPG security group when search is configured per the steps below.

*Updated on 2009-03-29 at 9:45am CDT (GMT -5).  Original post missed the steps of stopping the Search service before reconfiguring.

With Small Business Server 2008, SBS customers finally get Windows SharePoint Services 3.0 built-in to replace the SharePoint 2.0 companyweb included with SBS 2003.  However, when you get your SBS 2008 box all set up and running, you may notice a few quirks when it comes to SharePoint search.  Specifically,you are seeing 2436 errors in your Application event log:

Log Name:      Application
Source:        Windows SharePoint Services 3 Search
Date:          3/29/2009 4:20:05 PM
Event ID:      2436
Task Category: Gatherer
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      server.company.local
Description:
The start address <sts3s://remote.company.com:987/contentdbid={d4078aab-
ce82-4581-8d4f-973e1e6eac23}> cannot be crawled.

Context: Application ‘Search index file on the search server’, Catalog
‘Search’

Details:
    Access is denied. Check that the Default Content Access Account
has access to this content, or add a crawl rule to crawl this content.  
(0x80041205)
Event Xml:
<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>
  <System>
    <Provider Name=”Windows SharePoint Services 3 Search” />
    <EventID Qualifiers=”32768″>2436</EventID>
    <Level>3</Level>
    <Task>3</Task>
    <Keywords>0x80000000000000</Keywords>
    <Channel>Application</Channel>
    <Computer>server.company.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data>

Context: Application ‘Search index file on the search server’, Catalog
‘Search’

Details:
    Access is denied. Check that the Default Content Access Account
has access to this content, or add a crawl rule to crawl this content.  
(0x80041205)</Data>
    <Data>sts3s://remote.company.com:987/contentdbid={d4078aab-ce82-4581-
8d4f-973e1e6eac23}</Data>
  </EventData>
</Event>

The issue here is that Windows SharePoint Services Search uses two separate accounts – one user account runs the search service, and the other user account is used to actually access the SharePoint content in order to index it.  When configuring SharePoint Search, SharePoint Central Administration explicitly states that these accounts cannot be built-in accounts (such as LOCAL SYSTEM or NETWORK SERVICE).  By default, SBS 2008 is using built-in windows accounts, which is resulting in this error being generated.

Luckily, this is easy to fix.  The first thing we need to do is to create two new user accounts for SharePoint search to use.  Personally, I do not create these accounts using the SBS add user wizard, because they will effectively be service accounts, so they do not need mailboxes, and we don’t need to see these accounts included in the User account list on the SBS console. 

1. On your SBS, open Active Directory Users & Computers (Start –> Administrative Tools –> Active Directory Users & Computers.
2. Within ADU&C, navigate to the Organizational Unit where you want to create the new user accounts.  (Personally, I create a new “Service Accounts” OU under <domain> –> My Business –> Users)
3. Right-click on the OU and select New –> User
4. On the first page of the new user window, enter the following info:
   • First Name:   SPSearch
   • Last Name:  <leave blank>
   • Username:   spsearch
5. Click Next.
6. Enter a strong password for the new account. 
7. Uncheck the option “User must change password at next login”
8. Check the option “User cannot change password”
9. Check the option “Password never expires”
10. Click Next
11. Click Finish.
12. Repeat steps 3-11, using “SPContent” instead of “SPSearch” in step 4

We do not have to worry about granting any access or permissions to the two new accounts we created.  After the accounts have been created, close Active Directory Users & Computers, then open SharePoint Central Administration  (Start –> Administrative Tools –> SharePoint 3.0 Central Administration). 

1. When SharePoint 3.0 Central Administration opens, go to the Operations tab.
2. Click on the “Services on Server” link
3. In the Action column, click the link to Stop the “Windows SharePoint Services Search” service.
   • You will receive a warning that stopping the search service will remove existing indices.  Click OK to acknowledge the warning.
4. When you return to the SharePoint Central Administration Operations tab, the Windows SharePoint Search Service will show as stopped.  Click the link to Start the Windows SharePoint Services Search service.  This will open the Search service configuration page.
5. In the Service Account section, select the “Configurable” option
   1. For a username, enter <DOMAIN>\SPSearch  (where <DOMAIN> is your AD domain).
   2. For a password, enter the strong password you assigned to the SPSearch account.
6. In the Content Access Account section, select the “Configurable” option
   1. For a username, enter <DOMAIN>\SPContent  (where <DOMAIN> is your AD domain)
   2. For a password, enter the strong password you assigned to the SPContent account.
7. In the Search Database section, change the database name by appending and underscore 1 (“_1”) to the database name. 
   • By default, the database name should be WSS_Search_[SERVERNAME], so we’re changing it to  WSS_Search_[SERVERNAME]_1.
   • Changing the name is necessary because the default database name already exists with search data.  If we attempted to use the default database name, SharePoint would throw an error that the database contains user-defined schema and cannot be used.  By changing the search database name on this configuration page, SharePoint Central Administration will create a new database using this name and configure search to use this new database.  Since the new database is empty, we won’t encounter any errors.
8. Accept the remaining defaults and click the OK button.

After clicking OK, the settings should be applied and you should return to the “Services on Server” page in SharePoint Central Administration, and the Windows SharePoint Services Search” service should be listed as started.

Close SharePoint Central Administration and open the Services MMC (Start –> Administrative Tools –> Services).  Restart the Windows SharePoint Services Search service.  Verify that the Windows SharePoint Services Search service is configured to login with the SPSearch account you created.

Voila!  Moving forward, you should not experience the 2436 error event in your Application Log.

Ok, so I’ll give Nicky kudos for beating me to the punch on this topic.  But, I’m also going to provide a better way to accomplish this task 

So let’s consider this scenario.  You have an SBS 2003 box, and at some point in time you completed a side-by-side installation of Windows SharePoint Services 3.0, and you have been using your WSS 3 site instead of the default WSS 2 companyweb site on SBS 2003.  Now you have this shiny new SBS 2008 box that is running WSS 3.0 already.

Nick’s article gives you an option to move your WSS 3.0 site from your SBS 2003 box to the companyweb site on your SBS 2008 box.  But there’s one downfall – by using the backup & restore functionality in SharePoint’s stsadm utility, you’re effectively deleting the stock SBS 2008 companyweb site, and putting your existing WSS 3.0 site in its place.  Not that may not be a huge deal, but what if you want to use the SBS fax service and have faxes routed to your companyweb?  Well the fax library doesn’t exist (unless you’ve manually created it exactly like the SBS team had it).  Not to mention, your WSS 3.0 site that you restored most likely isn’t set up with the same security that the stock SBS 2008 companyweb used – meaning new users won’t automatically have access to the site unless you tweak the permissions.

Instead of yanking out the stock SBS 2008 companyweb and replacing it with your existing WSS 3.0 site, the better solution is to integrate your existing site into the SBS 2008 companyweb.  And believe it or not – it is entirely possible (and even pretty simple) to do so 

First and foremost – in order for this to succeed, you need to be running the same version of WSS 3.0 on both your SBS 2003 and SBS 2008.  On both servers, open SharePoint 3.0 Central Administration, navigate to the Operations tab, then click on the Servers in Farm link.  This will show your server along with its WSS version (e.g.  12.0.0.6303).  Install any missing Service Packs / Updates so both servers are at the same version.  Penny has a great post here on identifying what updates correspond to what SharePoint version.

On your SBS 2003 box, open a command prompt and navigate to  C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin   and enter the following command:

stsadm –o export –url http://[sitename] –filename [output path] –overwrite –includeusersecurity –versions 4

Where  [sitename] = the name of your existing WSS 3 site and [output path] is the path to the directory where you want to store the export (e.g.  D:\WSSExport\sitename.dat ).  If the path includes long file/folder names, enclose the entire path in double quotes (e.g.  “D:\WSS Export\sitename.dat” 

This command exports the contents of the specified site.  The –overwrite flag tells stsadm to replace the output file if it already exists.  The –includeusersecurity flag does just that – tells stsadm to include user security settings for all entities in the site.  Finally, the –versions 4 flag tells stsadm to export all versions of list items and documents. 

By default, stsadm will create a new file when the output file reaches 25MB in size.  So if your resulting export is 90 MB, you will have four files – the first three being 25 MB each, and the last being 15 MB.

Once the export completes, copy your export file(s) to your SBS 2008 box.  Then, on your SBS 2008 server, open a command prompt with administrator privileges.  Navigate to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin and enter the following command:

stsadm –o import –url http://companyweb –filename [input path] –includeusersecurity

Obviously, [input path] is the path to the location of the export files you copied to your SBS 2008 box.  Again, if there is a long file / folder name, enclose the entire path in double quotes.  If the output produced more than one file, you should specify the first file in this command  e.g.  “D:\WSS Import\sitename.dat”

When the command completes, you can navigate to http://companyweb.   Your first impression will be that you are looking at your original WSS 3.0 site – because the companyweb will be using the theme, Quick Launch & Top Link bars from the imported site.  However, the two sites have actually been merged in to one. 

• Every list, library, and sub-site from your previous site that did not already exist in the SBS 2008 companyweb was created with the previous security settings and all content (including versions) restored.
• Every list, library, and sub-site that exists in both sites have been merged, so that content from the export has been added to the corresponding entity in the SBS 2008 companyweb.  (For example – if your original WSS 3.0 site included an Announcements list, you will see that both your previous announcements and the SBS 2008 companyweb announcements exist in the same announcements list).
• SBS 2008 companyweb entities are still present – including the Fax Center document library and the Archived E-Mails sub-site.
• Security for the two sites have been merged.  The default groups used by SBS 2008 are still present and granted access.  Additionally, user permissions from your original site have been merged in to the site as well.

At this point, you just have some basic tweaking to do – including adding the Fax Center library and/or Archived E-Mails sub-site to the Quick Launch, etc. 

For simplified administration moving forward, I recommend reviewing permissions throughout the site and replacing permissions on the old site with the groups used by SBS 2008.  The fewer groups that are used, and the fewer explicit permissions granted to specific users, the easier your SharePoint security administration will be moving forward.  Note that you can add Active Directory Security Groups as members to SharePoint groups.  This way you can use SharePoint groups to control access to libraries, lists, & sub-sites in SharePoint.  Additionally, you can then create new User Roles in your SBS 2008 Console that include membership to necessary AD Security Groups.  This way, when you create a new user via the SBS 2008 console, you can select the correct User Role, and the resulting new user will automatically have access to the right areas in your companyweb.

Join me and Amy Babinchak this Thursday (3/19) @ noon Eastern time as we discuss managing Windows SharePoint Services 3.0 in Small Business Server 2008.  We will be talking about the what has changed with SharePoint from SBS 2003 to SBS 2008, most notably the move to WSS 3.0 and the new features & functionality available.  We will also be talking about emailing SharePoint lists & libraries directly, as well as backup and disaster recovery considerations 

When: Thursday, Mar 19, 2009 12:00 PM (EST)
Scheduled to Occur: Once
Duration: 1:30

Third Tier has invited you to attend an online meeting using
Microsoft Office Live Meeting.

https://www.livemeeting.com/cc/mvp/join?id=9THDZK&role=attend&pw=RpJ%285j%3A%2F6

Meeting time: Mar 19, 2009 12:00 PM (EST) 

Add to my Outlook Calendar:
https://www.livemeeting.com/cc/mvp/meetingICS?id=9THDZK&role=attend&pw=RpJ%285j%3A%2F6&i=i.ics

AUDIO INFORMATION
-Computer Audio(Recommended)
To use computer audio, you need speakers and microphone, or a
headset.

FIRST-TIME USERS
To save time before the meeting, check your system to make sure it is
ready to use Microsoft Office Live Meeting.
http://go.microsoft.com/fwlink/?LinkId=90703

TROUBLESHOOTING
Unable to join the meeting? Follow these steps:
  1. Copy this address and paste it into your web browser:
https://www.livemeeting.com/cc/mvp/join
  2. Copy and paste the required information:
        Meeting ID: 9THDZK
        Entry Code: RpJ(5j:/6
        Location: https://www.livemeeting.com/cc/mvp
If you still cannot enter the meeting, contact support:
http://r.office.microsoft.com/r/rlidLiveMeeting?p1=12&p2=en_US&p3=LMInfo&p4=support

NOTICE
Microsoft Office Live Meeting can be used to record meetings.
By participating in this meeting, you agree that your communications
may be monitored or recorded at any time during the meeting.

If you are making use of document libraries in your companyweb on SBS 2008, you may have noticed that you aren’t able to upload large files (> ~28MB) to a document library.  When you attempt, you receive a 404 error in your browser.  Additionally, you have tried setting the upload size in SharePoint Central Administration, but you are still encountering the problem.

This behavior is due to certain changes within IIS7.  To increase the upload file size limit for your SBS 2008 companyweb, you must edit the web.config file for the companyweb application in addition to increasing the limit in SharePoint Central Administration.

First – set the new limit in SharePoint Central Administration (if you haven’t already):

1. Log in to your SBS and navigate to Start | Administrative Tools | SharePoint 3.0 Central Administration
2. At the User Access Control prompt, click Continue
3. In SharePoint 3.0 Central Administration, navigate to the Application Management tab and click on Web Application General Settings.
4. On the Web Application General Settings page, verify that the selected web application is https://remote.domain.com:987. 
   1. If this application is not selected, click on the web application and select Change web application.
   2. In the Select Web Application window that opens, click to select the SBS SharePoint application.
5. In the Maximum Upload Size field, enter the maximum upload size you want to allow.
6. Scroll to the bottom of the page and click OK to save the changes.

After setting the increased limit in SharePoint 3.0 Central Administration, you must set the increased value in the companyweb web.config file:

1. Open My Computer and navigate to C:\Program Files\Windows Small Business Server\bin\webapp\InternalWebSite
2. Right-click on the web.config file and select Properties.
3. Go to the Security tab and verify the administrative user you are logged in as has modify permissions on this file.  (By default, the administrator account you create during setup will only have read access). 
4. If necessary, click the Edit button to give your administrative user Modify permissions.
5. Click OK to close the file properties.
6. Open the web.config file in notepad.
7. Scroll to the bottom of the file.  Directly above the </Configuration> line, enter the following:

</System.Workflow.ComponentModel.WorkflowCompiler>
 <system.webServer><security><requestFiltering><requestLimits maxAllowedContentLength="52428800" /></requestFiltering></security></system.webServer>

8. The maxAllowedContentLength= value listed is in bytes.  The value dispayed (52428800) corresponds to 50 MB.  I recommend making this value slightly larger than the max upload size you specified in SharePoint 3.0 Central Administration.  If this value is equal to or less than the value in SharePoint 3.0 Central Administration, users may not receive the friendly error page indicating they exceeded the file size limit.
9. Save the changes to the web.config file.
10. Open IIS 7 Administration (Start | Administrative Tools | Internet Information Services (IIS) Manager ).
11. Expand <servername>, then expand Sites.
12. In the list of sites in the content pane, click to highlight the SBS SharePoint site.
13. In the Manage Web Site section of the right-hand pane, click Restart to restart the web site.

Your users should now be able to upload large files to your companyweb document libraries.  However, depending on how large of files users are actually uploading, their uploads may still fail – not due to a size restriction, but rather an IIS timeout issue.  To adjust the timeout values for your site, take a look at this post over on Don’s blog.

I have been getting this question a lot recently, so I decided I should probably blog it.

When you install Windows SharePoint Services 3.0 using the published document from Microsoft, Windows SharePoint Services is set up as a stand-alone server.  This configuration results in Microsoft SQL Server Embedded Edition (SSEE) being installed as the SharePoint v3 data source.

For SBS Premium customers who want to use their version of SQL Server as the data store for SharePoint v3, you need to deviate from Microsoft’s published installation document.  Specifically, on page 7 under step 4b select “Front-End Server” instead of “Stand-Alone Server”  This will result in the setup process not installing SSEE on the server. 

When you run the SharePoint Products and Technologies Configuration Wizard after the install finishes, you will be given the option of either joining an existing SharePoint farm, or creating a new farm.  Select to Create a new SharePoint Farm, and you will be able to specify the SQL server instance you want to use as your data store.  The wizard will then complete the SharePoint configuration and you will then be running SharePoint 3.0 with a full SQL data store instead of SSEE.