Aimless Ramblings from a Blithering Lunatic . . . : WSS / Companyweb

External Links in Companyweb E-mail Alerts

cgross — Sun, 02 Aug 2009 17:39:51 GMT

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.

Optimizing Companyweb Search Results in SBS 2008

cgross — Sat, 13 Jun 2009 04:27:38 GMT

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:

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\
Right-click on the ExtensionList key and select New –> String Value
Enter 38 for the new string value and hit Enter
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.
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.
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:

Open a command prompt (as Administrator) and run an iisreset
After the iisreset completes, change your working directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin
Stop the SharePoint search indexing process by running this command: stsadm –o spsearch –action fullcrawlstop
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!

SBS 2008 + loopback check + remote.company.com = SharePoint 2436 errors

cgross — Thu, 07 May 2009 19:43:00 GMT

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:

Disabling the loopback check all together.
Tweaking the Alternate Access Mappings in SharePoint (unless you need to for other legitimate reasons – not the 2436 error)
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.

SharePoint Search & Event ID 2436 errors in SBS 2008

cgross — Mon, 30 Mar 2009 00:30:00 GMT

*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.

On your SBS, open Active Directory Users & Computers (Start –> Administrative Tools –> Active Directory Users & Computers.
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)
Right-click on the OU and select New –> User
On the first page of the new user window, enter the following info:
- First Name: SPSearch
- Last Name: <leave blank>
- Username: spsearch
Click Next.
Enter a strong password for the new account.
Uncheck the option “User must change password at next login”
Check the option “User cannot change password”
Check the option “Password never expires”
Click Next
Click Finish.
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).

When SharePoint 3.0 Central Administration opens, go to the Operations tab.
Click on the “Services on Server” link
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.
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.
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.
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.
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.
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.

Migrating a WSS 3.0 Site to SBS 2008

cgross — Sun, 22 Mar 2009 23:38:51 GMT

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.

Managing Sharepoint in SBS 2008

cgross — Tue, 17 Mar 2009 16:26:49 GMT

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.

Large Files in SBS 2008’s Companyweb

cgross — Thu, 26 Feb 2009 03:29:00 GMT

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):

Log in to your SBS and navigate to Start | Administrative Tools | SharePoint 3.0 Central Administration
At the User Access Control prompt, click Continue
In SharePoint 3.0 Central Administration, navigate to the Application Management tab and click on Web Application General Settings.
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.
In the Maximum Upload Size field, enter the maximum upload size you want to allow.
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:

Open My Computer and navigate to C:\Program Files\Windows Small Business Server\bin\webapp\InternalWebSite
Right-click on the web.config file and select Properties.
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).
If necessary, click the Edit button to give your administrative user Modify permissions.
Click OK to close the file properties.
Open the web.config file in notepad.
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>

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.
Save the changes to the web.config file.
Open IIS 7 Administration (Start | Administrative Tools | Internet Information Services (IIS) Manager ).
Expand <servername>, then expand Sites.
In the list of sites in the content pane, click to highlight the SBS SharePoint site.
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.

Using your SQL in SBS R2 Premium as a back-end for WSS 3.0

cgross — Mon, 28 May 2007 18:23:56 GMT

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.

SharePoint v3, Updates and 404 Errors

cgross — Tue, 15 May 2007 21:39:23 GMT

I think I figured out how I blew up my SharePoint on my test box a couple weeks ago. I mentioned in my previous post that I blew up SharePoint while testing an upgrade scenario. Of course, being a typical tech working on a test box, I was guilty of changing too many things at once - including changing the SharePoint config and applying patches. I know, I know - whip me, beat me, and send me to my room . . .

I'm doing a little server consolidation here getting ready to move our servers in to a data center. So I did a clean install of Windows Server 2003 R2 on what is destined to be my new web server. I proceeded to get SharePoint, SQL, and all of my other stuff installed, then updated the box via Microsoft Update. About 50 updates (including Win2k3 SP2 - yes, I am a glutton for punishment) and a few reboots later, the server was fully patched and humming right along. I opened SharePoint 3.0 Central Administration and after a few seconds was presented with a nice 404 Page Not Found error.

WTF?

I verified my services were running, then went to check out the Event Viewer. In the Application Event Logs, I saw a slew of SharePoint errors with Event ID 5586 with details about being unable to connect to the database. Looking up this error on EventID.net, there wasn't much there - and I wasn't particularly keen on running psconfig -cmd upgrade -force and then uninstalling / reinstalling SharePoint.

Googling on "SharePoint event id 5586" wasn't very helpful either. I encountered a number of threads that all referenced the hotfix from KB 932091 not installing correctly, and recommending extracting the update and manually running it again. I had tried this a couple weeks ago on my test box to no avail, and found several others in the threads that this didn't work for. Just to be safe, I tried it again on this box, but it still didn't work.

One difference with this server is that I am actually running full SQL 2005 (instead of SSEE on the test box), so I could access my database via the SQL Management Studio. When I opened the Management Studio and attempted to connect to my database instance, after a long pause the Management Studio threw an error that it wasn't able to connect to the database instance - I discovered I received the error whether I was trying to connect via Windows or SQL Authentication, which was an interesting tidbit of information I hadn't found when troubleshooting the issue on the test box with SSEE.

On a whim, I decided to check the SQL Client Configuration - since I remembered seeing something similar in the past with Microsoft Retail Management System when it couldn't connect to the database. I went to Start | Run and cliconfg

This is what your cliconfg should show:

This is what cliconfg showed on this server:

I enabled TCP/IP and Named Pipes, then selected "Enable shared memory protocol." After clicking OK and rebooting - Voila! SharePoint is back in business and SQL Management Studio can connect to my database instance via both Windows and SQL Authentication.

I'm not sure which update broke this, but considering in the course of 3 reboots I MU'd approximately 50 updates (including SQL2k5 SP1, 932091, and Win2k3 SP2) - it's hard to know exactly what disabled my SQL client protocols. But it was an easy fix, and it's working now - so I'm happy

Moving a WSS 3.0 site to a new farm

cgross — Thu, 10 May 2007 04:12:31 GMT

If you haven't heard already, I am going to be at Jeff Middleton's SMB Disaster Recovery Conference in New Orleans at the end of this month, and at some point during the weekend I will be discussing Windows SharePoint Services in the context of Disaster Recovery - not only how to recover from a SharePoint disaster, but how SharePoint can be a valuable technology in the face of a true catastrophic disaster.

Well, it just so happens that I have had my own little SharePoint disaster on my hands. A little over a week a go, I was testing a SharePoint upgrade scenario on my web server and proceded to blow up WSS 3.0 on that box. The good news was that I had a disaster to fine-tune my recovery skills. The bad news? Being a bit lazy I actually had a production SharePoint site on that server (oops ) Luckily, the production site was non-critical (just the site for my family - and while they're used to me blowing things up, I really didn't want to have to mess with recreating that site and it's 20GB of data). And I'll also admit that I was slightly behind on my SharePoint-based backups for that site as well - far enough behind that I really didn't want to have to go that far back if I didn't have to.

I'll admit that I'm not making much progress with repairing the WSS installation on the web server - I've tried just about everything, and it looks like I'm going to break down and call PSS to get it working again, assuming I don't just re-install. Naturally, the only thing holding me back was this one site that I really wanted to salvage. Well I'm happy to say that after some trial & error (and the help of Google), I have the site up and running on a separate SharePoint farm - and it was actually quite painless.

First - for the sake of clarity, I'm going to talk about this process in terms of moving a site to a different SharePoint farm, for the simple fact that we can have multiple front-end servers running SharePoint in a single farm, and moving a site to different servers in a single farm is a separate process. Most SBSers are going to be running a single server farm, and as such will often talk about moving a site between servers, when they're really talking about moving between farms.

So to accomplish this task, here's what I did:

1) On the database server for the current farm, I performed an offline backup of the content database for the site I wanted to move. (Easiest way to accomplish this is to stop your SharePoint database service and copy your .mdf & .ldf files).

2) I restored the .mdf & .ldf files for the content database to the SQL data directory on the database server for the new farm.

3) I attached the restored database to the SQL instance for the new farm.

4) On the new farm, I opened SharePoint Central Administration.

5) On the Application Management tab, I created a new SharePoint Application. In doing so, I created a new web site that used the same port and host header the site on the original farm used.

6) When the application creation process completed, I did not run the Site Collection Creation Wizard.

7) Within SharePoint Central Administration Application Management tab, I clicked on Content Databases.

8) I verified the Web Application, then clicked on the content database (which should be an empty content database created during the Web Application creation process)

9) On the Content Database Settings page, I changed the database status from Ready to Offline, clicked to select the option to Remove Content Database and clicked OK.

10) Back on the Manage Content Databases page, I verified the web application then clicked Add a content database.

11) On the Add Content Database page, I entered the name of my SQL server where I attached my restored database, as well as the database name. I verified Windows Authentication was selected, selected the appropriate Search Server, and clicked OK.

12) Once that process finished, I was returned to the Manage Content Databases tab and could see that the restored content database was now associated with the web application I had created minutes earlier.

13) I edited my local hosts file so the URL of my site would resolve to the local server

14) I opened a command prompt and ran an iisreset, then ran an ipconfig /flushdns, then pinged my site URL to verify it resolved to the local server.

15) I opened Internet Explorer and browsed to my site - and voila! there it was

So in the big picture, what is the big deal here? The significance is that with WSS 3.0, you can actually restore one or more SharePoint web applications to a new farm with nothing besides a file-level backup of your content database. And if you ever tried accomplishing the same feat with WSS 2.0, you can appreciate just how significant this functionality is. Don't get me wrong - this isn't going to be the preferred method (I still recommend you take a look at native backup/restore functionality either from within SharePoint Central Administration or via the command line using stsadm.

New York, New York!

cgross — Mon, 30 Apr 2007 22:47:59 GMT

Ok gang - just a quick heads up that due to a twist of fate, I am going to be presenting on SharePoint at SMB Nation East this weekend. There's still room if you haven't signed up yet. I'll be doing a deep dive on SharePoint 3.0 - and this will not be death by PowerPoint - but live demos.

Did you know that for all of our customers who have upgraded to Office 2007, SharePoint 3.0 has been the driving force and single greatest factor in selling those upgrades? I'll show you why - this Friday at 1:30pm

You do know about GroupBoard?

cgross — Wed, 07 Feb 2007 06:12:13 GMT

Just like they did with SharePoint Services 2.0, Microsoft has released application templates for SharePoint Services 3.0, which can be found here. And while you're there, take a minute to read through the list of Server Admin Templates that are coming soon . . . there's several things in there that I can't wait to get my hands on.

So far, the most exciting of the offerings is the GroupBoard template:

This single template has standard many of the most popular functionality requests that I've had from clients and end users over the last couple years, including:

*   In/Out Board

*   "While You Were Out" messaging

*   Resource Grouping / Organization Chart

*   Timesheets

Definitely worth taking a look at.

PDF Icon Update

cgross — Mon, 05 Feb 2007 07:01:29 GMT

Ever since I blogged about my batch file to simplify the task of getting a PDF icon to display in SharePoint 2.0 document libraries back in October of 2004, it has been the single-most popular post on my blog (with almost 60,000 hits to date). Well, ever since Windows SharePoint Services 3.0 was released, I knew that I needed to update my batch file, it just wasn't quite at the top of the to-do list. But now the wait is over - I have posted an updated package here.

Here's the details and caveats regarding these files:

* The package (pdficon.zip) contains four files: pdf.png (the pdf icon), docicon_v2.xml (the updated docicon.xml file for WSS 2.0), docicon_v3 (the updated docicon.xml file for WSS 3.0) and pdficon.vbs (the VBScript that makes our lives easier )

* pdf.png is an updated PDF icon that is a little more current (basically, it doesn't remind you of Acrobat 4.0 like the last one did)

* This is one of my first VBScripts, and as such I didn't get some of the functionality in there that I would have liked to. Mainly, the script makes the assumption that your SharePoint installations were in the default locations (in C:\Program Files\...). Secondly, it is not localized - it's specific to an English installation. If I actually get the time to learn some scripting, then maybe I can tackle those shortcomings.

* What the script DOES do is install the PDF icon for both SharePoint 2.0 and SharePoint 3.0. Basically, it looks to see if you have a docicon.xml file in the default WSS 2.0 directory. If so, it assumes that WSS 2.0 is installed, it renames your existing docicon.xml file to docicon.old, copies the docicon_v2.xml file as docicon.xml to the WSS 2.0 XML directory, and copies the pdf.png file to the WSS 2.0 images directory. It then does the same for WSS 3.0 - checks for the existence of docicon.xml in the default WSS 3.0 XML directory and if so, completes the required file operations. If it doesn't find the docicon.xml file in either location, it doesn't do anything. Finally, if it did find either WSS 2.0 or 3.0, it finishes up by doing an iisreset.

* The script will notify you with a message box when it completes, and it also writes a log file to C:\pdficon.log

Companyweb & Sharepoint v3 - Part 5

cgross — Mon, 05 Feb 2007 02:51:00 GMT

a.k.a. - Living on the Edge. Just remember, there's a reason it's called the bleeding edge . . . Here's your warning: In this post I am going to explain configuration changes I made to my own internal production environment to get http://companyweb to point to a new WSS v3 site. This configuration is not supported by Microsoft or myself. If you decide to try to replicate these settings in your environment, you are doing so at your own risk.

OK, let's recap. We've talked about the benefits of Sharepoint v3? Check. We've talked about planning what we're going to move, how we're going to move it, and what we're going to have to clean up after the move? Check. We've talked about prepping our environment so that WSS v3 search works? Check. We've talked about installing WSS v3 and accessing it via a common name? Check. Chad has warned everyone that just because he's crazy enough to implement a non-supported configuration doesn't me he's recommending it or supporting it? Check.

First, it's important to discuss why having http://companyweb point to your new WSS v3 web site is not supported. As we all know, there is a decent amount of integration between the SBS wizards and our WSS v2 companyweb site. Additionally, that integration is heavily dependent on DNS resolution to companyweb. However, the key issue is with the integrated SBS setup. If you find yourself in a position where you need to re-run SBS Integrated Setup and touch the Intranet piece, it's going to try to access your WSS v3 site, and with the differences between WSS v2 and v3 - well, let's just say it's not going to be pretty and will break more than it fixes.

It's important to note that I installed and configured my new WSS v3 site using the process I outlined in my previous post, and migrated all of my content over to my new WSS v3 site prior to making the changes mentioned below.

So when I was looking at deploying WSS v3 and deciding if I wanted to tackle having http://companyweb resolve to a new v3 site, I decided that if I were to do this, I needed to leave myself a backdoor so that I could point companyweb to the original companyweb site in the event that I found myself needing to re-run SBS Integrated Setup and touch various intranet components. Additionally, I wanted to be able to access the original companyweb site if need be after migrating everyone to a new v3 site.

Here's what I came up with. First - I needed to configure the original companyweb so that I could access it using another name. For my environment, I chose to use http://companywebold

1)   I started with adding the entry to our internal DNS so that companyebold resolved to the internal IP of our SBS.

2)   I flushed the DNS cache and verified that my SBS responded when I pinged companywebold

3)   I opened Sharepoint Central Administration (v2) and clicked the link to Configure Virtual Server Settings

4)   I clicked to select the companyweb virtual server, then clicked to Remove Windows SharePoint Services from virtual server.

5)   I verified that the Remove without deleting content databases option was selected and clicked OK.

6)   I opened IIS Manager, and opened the Properties page for the companyweb web site.

7)   I added two new host headers to the companyweb site - companywebold   and  companywebold.domain.local    Both host headers were bound to port 80 on the internal IP of the SBS (not all unassigned). DO NOT REMOVE the companyweb host headers at this point!

8)   I closed the Properties pages of the companyweb site and returned to Sharepoint Central Administration (v2).

9)   I clicked on the Extend or Upgrade virtual server link, then clicked to extend the companyweb virtual server.

10) I clicked the option to Extend and Map to Another virtual server.

11) I verified that the companyweb site was being mapped, and that the option to Use an existing application pool was selected.

12) I verified that the DefaultAppPool was selected, then clicked OK.

At this point, I verified that both http://companyweb and http://companywebold resolve to the original WSS v2 companyweb. The key piece to understand with SharePoint, is that the SharePoint configuration database has to know about the host headers that you're using to access your Sharepoint sites. You can't just add another host header to a site in IIS and expect to get to your SharePoint site using the new host header. That is why I removed WSS from the companyweb site, then added the new host header values (companywebold), then re-extended WSS to the companyweb site. By doing so, the SharePoint configuration database picks up the host headers already defined for that site, and we are now able to get to the original companyweb site using either of our two host headers. It is important that WSS v2 configuration database knows about both host headers.

Now, I was ready to make the switch so that my http://companyweb pointed to the new WSS v3 site - both internally AND externally The key point to remember is that with WSS v3 we can have multiple web sites pointing to the same SharePoint application. The first thing we need to do is change the Properties of the existing companyweb site.

1)   I opened IIS Manager, expanded [servername], expanded [web sites], right-clicked on companyweb and selected Properties.

2)   On the General tab, I removed 444 from the SSL port, then clicked the Advanced button to edit the host headers.

3)   I removed two host headers:   companyweb   and   companyweb.domain.local   then clicked OK to close the Advanced window, then clicked OK to close the companyweb properties page.

4)   At this point I closed IIS Manager.

This leaves the original companyweb in-tact, however right now I can only access it via the alternate http://companywebold URL I created earlier. Now I was able configure http://companyweb to pull up the new WSS v3 web application:

1)   I opened SharePoint 3.0 Central Administration, and on the Application Management tab, I clicked on Create or extend Web application.

2)   I then clicked on Extend an existing web application

3)   Under Web application, I clicked Change web application then selected my WSS v3 web app (Sharepoint - 80)

4)   Under the IIS Web Site section, I selected the option to Create a new IIS web site, and entered companyweb new for the description

5)   I entered 80 for the port, and companyweb for the host header, then clicked OK.

At this point, I opened Internet Explorer and verified that http://companyweb opened the new WSS v3 site - yay! But I still wanted to enable SSL so that I could access the Sharepoint v3 application externally:

1)   I opened SharePoint 3.0 Central Administration and on the Application Management tab, I clicked on Create or extend Web application.

2)   I then clicked on Extend an existing web application

3)   Under Web application, I clicked Change web application then selected my WSS v3 web app

4)   Under the IIS Web Site section, I selected the option to Create a new IIS web site, and entered companyweb - SSL for the description

5)   I entered 444 for the port, and my public FQDN for the host header (mail.mobitech.biz)

6)   Under the Security Configuration section, I clicked the option to Use Secure Sockets Layer (SSL), then clicked OK.

Now that I had created a separate web site for remote access, I just needed to add my SSL cert to the site.

1)   I opened IIS Manager, expanded [servername] and [web sites].

2)   I right-clicked on companyweb - SSL and selected Properties.

3)   On the Directory Security tab, I clicked the Server Certificate button.

4)   I clicked Next to start the IIS Certificate Wizard.

5)   On the next page, I clicked the option to Assign an existing certificate and clicked Next.

6)   I selected my SSL certificate, then finished the wizard. (I had to check the SSL cert on my old companyweb to make sure I got the right cert)

At this point, I opened my web browser on a remote system and verified that I could access the new WSS v3 site via the public URL (https://mail.mobitech.biz:444) . . . and then just to test, I also logged in to RWW and verified that I could access the new WSS v3 site by clicking on the Use my company's internal web site link . . . YAY!

Now - I have my new WSS v3 site accessible remotely via the normal companyweb URLs both internally & externally. I can get to my original WSS v2 site via http://companywebold, and I can also get to the new WSS v3 site via http://intranet as well.

The key here is that http://companyweb is registered in both the WSS v2 and v3 configuration databases. So - if I find myself in a position where I need to recover my SBS server or some task that requires running a wizard that touches the Intranet portion, before I do so, all I have to do is stop two of my new WSS v3 sites (companyweb new and companyweb - SSL), then update the original companyweb site to include the original host headers (companyweb and companyweb.domain.local), and add 444 back in as the SSL port. As a result, the SBS wizards will touch the original companyweb site (that they can work with), instead of the new WSS v3 site that the wizards can't work with. And if necessary, users can still access the new site internally via http://intranet. When the wizards are done, I can reverse the process and be back to using the new WSS v3 site as my companyweb.

So far, the upgrade to WSS v3 has been well worth the effort - every day we're finding new functionality and my users are liking it more and more.

Having said that, I want to reiterate that the configuration outlined in this post IS NOT SUPPORTED. If you opt to duplicate this configuration in your environment, you are doing so at your own risk and realize that you will not get support from either Microsoft or myself

Regardless, if you opt to deploy WSS v3 in your SBS environment either in a supported configuration (the first 4 parts of this series), or in an unsupported configuration as outlined here, some of your SBS integration is not going to work with WSS v3. The big piece you'll notice eventually is the Add User Wizard - when you add new users to your SBS, they will not be automatically added to your WSS v3 site - you will have to manually add your new users to the new site.

Companyweb & Sharepoint v3 - Part 4

cgross — Sun, 04 Feb 2007 22:19:00 GMT

It's time to actually install WSS v3 . . . YAY! So, if you haven't done so already download the Microsoft document here and follow that step-by-step to install WSS v3 in parallel to v2 on your SBS. Just do me a favor and stop after Step 3 (that's right - forget about steps 4 & 5)

Here's the deal - when the Sharepoint configuration completes, you have a new Sharepoint site set up that is bound to port 80 with no host header. But this stops your default web site so the Sharepoint site can run. The Microsoft document has you create a new Sharepoint application that uses a funky URL like http://servername:9971/sites/sitename - which isn't exactly user-friendly. So go ahead and follow the document through Step 3 and we'll get this worked out so you have a user-friendly Sharepoint site co-existing with your default web site.

(insert cheesy on hold music . . . )

Ok, so now that you have WSS v3 installed according to Microsoft's instructions (through Step 3), we want to be able to re-start the default web site (so things like OWA and RWW work), and be able to get to the new Sharepoint site easily. For the purpose of this post, I'm going to use intranet to access the new Sharepoint site (although you can use anything you want (besides companyweb ). The first thing you want to do is make sure that you can get DNS resolution to work for intranet. So open your DNS MMC, expand <servername>, and expand Forward Lookup Zones. Right-click on your internal domain name, and select New Host (A). Create a new A record for 'intranet' that points to the internal IP of your SBS, then click Add Host:

Click Done then close the DNS MMC. Open a command prompt and flush your DNS cache by running ipconfig /flushdns then ping intranet and verify that you receive replies from the internal IP of your SBS.

Next, we want to create a new web site that responds to the http://intranet host header and points to the existing Sharepoint v3 application you have already created. Luckily, we can do this in one place - Sharepoint v3 Central Administration (Start | Administrative Tools | SharePoint 3.0 Central Administration).

1) Open SharePoint 3.0 Central Administration, and click on the Application Management tab.

2)  Under the SharePoint Web Application Management section, click on Create or extend Web application.

3) Click to Extend existing web application.

4) On the page that opens, click on the Web Application field and select Change Web Application.

5)  On the page that opens, select your SharePoint Web Application.

6) In the IIS Web Site section, select the option to create a new web site.

7) Enter a description for the new site (e.g. Intranet)

8) In the Port field, enter 80

9) In the Host Header field, enter   intranet

10) Click OK.

Open your web browser and verify that http://intranet opens your new Sharepoint site. Now we need to remove the web site that Sharepoint setup created.

1)   Return to the SharePoint 3.0 Central Administration and click on the Application Management tab.

2)   Under the SharePoint Web Application Management section, click on Remve SharePoint from IIS WebSite

3)   In the Web Application section, verify that the web application is http://servername

4)   In the Deletion Options section, verify that the IIS Website is set to SharePoint - 80 (Default)

5)   Select the option to Delete IIS Web sites

6)   Click OK

So now, we have http://intranet resolving to the new Sharepoint site, and we've removed the site that SharePoint setup created. Now all we have to do is start the default web site. Open IIS Manager, expand servername and expand web sites. Select the default web site and click the Start button.

Voila! There you go . . . In part 5, we'll discuss the unsupported method of having http://companyweb resolve to this new site, and being able to access it through Remote Web Workplace as well . . .

Companyweb & Sharepoint v3 - Part 3

cgross — Sat, 03 Feb 2007 23:07:17 GMT

This post is all about installing WSS v3 in parallel to WSS v2 on your SBS. Now, the Microsoft provided documentation does a good job of walking you through this, but there a few things they don't provide solutions to that you need to think about in advance.

First, I'm going to go out on a limb and think that you are probably planning on using the search functionality within WSS v3. The nice thing about v3 is that you do not need full-blown SQL in order to get full-text search. The down side is that if you upgraded your companyweb database to a full SQL backend to get search functionality, this breaks the search in WSS v3. However, we can fix this - but it means that we aren't going to have search on our WSS v2 sites. If you're like me where you're moving everything to v3, this isn't a big deal. However, if you determine you need to keep full-text search on your v2 sites, or if you're running SBS Std you can go ahead and skip this post

(Edit: There's mixed reviews on just what does break search in WSS 3.0 as Susan mentions here. Short story is that we know search works if you're running SBS Std. We know search breaks if you upgraded your companyweb to full SQL 2000 Std. What we don't know is if search breaks if you upgraded your companyweb to full SQL 2005 Workgroup. I'm going to try to find a box to sacrifice and test this scenario. Until then - let me know what you've seen out there)

So here's the plan: In order to get full-text search working on WSS v3, we need to effectively downgrade our existing WSS v2 to use WMSDE instead of full SQL. The high-level overview of this process is that we're going to backup our WSS v2 site(s), remove the intranet component from SBS, uninstall the SHAREPOINT SQL instance, then re-install the intranet component and restore our WSS v2 sites. Simple, right?

Step 1: BACKUP!

I like to be extra safe with this, so I'm suggesting two backups of each site - one with STSADM and one with SMIGRATE. An stsadm backup is great because it keeps all of our security, etc. in tact. An smigrate backup is great because it gives us the flexibility of restoring to any machine running WSS v2, not just the machine the backup was taken from. So, to backup your companyweb create a new directory somewhere on your server, with two sub directories - stsadm and smigrate. (On my server the directory I created was D:\wsstemp)

Open a command prompt and change your working directory to C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\bin

Enter the following command:

stsadm -o backup -url http://companyweb -filename D:\wsstemp\stsadm\companyweb.dat -overwrite

Be sure to replace D:\wsstemp\stsadm with your local path. When that command is finished, you'll run an smigrate backup from the same working directory:

smigrate -w http://companyweb -f D:\wsstemp\smigrate\backup.fwp -y

Again, be sure to replace D:\wsstemp\smigrate with your local path.

Repeat this for each WSS v2 site you have. You can store multiple stsadm backups to the same directory, as each stsadm backup is contained within a single file, just be sure to use a different file name for each site . However, you will want to save your smigrate backups in a separate folder for each site, as the smigrate backup can be split among multiple files depending on the size of the site being backed up)

Step 2: Remove intranet component.

Now that you have your WSS v2 site(s) backed up, we can remove the intranet component from SBS. To do so, go to Add/Remove Programs and locate Windows Small Business Server 2003, and click Change / Remove.

When the Small Business Server Setup Wizard starts, click Next until you get to the Component Selection screen. On this screen, click the Action column next to Server Tools and select Maintenance. Then, click the Action column next to Intranet and select Remove.

Click Next and finish the SBS Setup wizard.

Step 3: Remove the Sharepoint SQL instance:

Once the SBS Setup wizard completes, you will return to the Add/Remove Programs window. Locate the Microsoft SQL Server 2000 (SHAREPOINT) entry and click Change/Remove. Follow the wizard to completely remove the Sharepoint SQL instance.

Once you have successfully removed the Sharepoint SQL instance, close Add/Remove Programs and reboot your server.

Step 4: Re-install SBS Intranet component.

After your server reboots, you are ready to reinstall the SBS intranet component. This process is virtually identical to the removal process we went through in step 2. The only difference is that when you get to the Component Selection screen, you will select to install the Intranet component, the finish the wizard.

Once the wizard has finished, verify that you can navigate to http://companyweb and that you get a new, stock companyweb site.

Step 5: Restore your existing companyweb site.

At this point, our easiest restore is going to be using our stsadm backup. Open a command prompt and navigate to C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\bin then enter the following command:

stsadm -o restore -url http://companyweb -filename D:\wsstemp\stsadm\companyweb.dat -overwrite

Be sure to replace D:\wsstemp\stsadm\companyweb.dat with your local path and filename of your backup. Once this completes, navigate to http://companyweb and verify that your original site is in-tact.

There you go - you have successfully downgraded your companyweb site from a full SQL backend to a WMSDE backend, which will allow search to function when you get WSS v3 installed.

Companyweb & Sharepoint v3 - Part 2

cgross — Sat, 03 Feb 2007 21:51:32 GMT

a.k.a. - the migration planning stage

You'll note that the key word above is migration. If you remember from the Microsoft document here, on SBS you're going to do a parallel installation of Sharepoint v3, so that you'll have both Sharepoint v2 and v3 installed. And since we're going to be migrating to a new site, we need to figure out what we're going to move, and how we're going to move it.

The first step to planning your migration is taking inventory of your current companyweb site. What type of data is housed there? If you're storing files in your document libraries, have you added new columns to track metadata on the documents? Are you keeping version histories on your documents? If so, will you need access to those version histories after the migration? What about custom lists? Also, do any of your document libraries or lists have lookup fields referring to other lists on your site? Besides the data itself, what about how the data is presented. Do you have any 3rd party web parts you're using? Have you created any custom web-part pages to display your data?

It's no surprise that if you're using any 3rd party web parts in your WSS v2 site, you'll want to check with the publisher to see if those web parts are compatible with WSS v3.

Next, you need to look at what tools you're going to use to migrate your data from the old site to the new. We can use Windows Explorer to move contents of our libraries (documents, photos, etc.). But what about your lists? Microsoft Access to the rescue! You'll need at least Access 2003 (but 2007 is preferred). Both Access 2003 and 2007 an open Sharepoint lists so that they appear as an Access table. If you have Access 2003, you'll have to create your lists in your new site manually, then build an append query in Access to copy your list contents from your original companyweb site to the new WSS v3 site. However, if you have Access 2007 you can take advantage of it's Export to Sharepoint functionality. Just open your original companyweb list in Access 2007, click on the Export to Sharepoint button (under the External Data ribbon), enter the URL of your new site and Access will create the list with the appropriate fields in your new WSS v3 site and copy the list contents over.

(Edit - Nick ever so graciously gave me a virtual smack up-side the head and mentioned SharePoint Designer 2007 (formerly FrontPage) for use in migrating your data. DOH! talk about missing the obvious . . . I'm going to blame it on sleep deprivation. Anyway - if you have access to SharePoint Designer 2007 it has some very cool features to help with moving your lists & libraries)

Finally, you need to be aware of what steps you're going to have to complete manually on the new site - which is basically everything outside of moving your content. You'll need to recreate your permissions (adding users to the site, editing list / library permissions if you had done so on your original companyweb, etc.). You'll need to recreate any custom views you had created for your lists & libraries, and if you had any custom web part pages, you'll need to verify those work as intended (especially if you had data view web parts linked together for filtering data).

Companyweb & Sharepoint v3 - Part 1

cgross — Thu, 25 Jan 2007 06:18:00 GMT

This is the first in a short series of running Windows Sharepoint Services v3 on your SBS 2003 / R2 server.

First the caveat: Upgrading and/or running your companyweb site with Windows Sharepoint Services v3 is not supported - neither by Microsoft nor myself. Just because I'm blogging about it doesn't mean I'm supporting it. Microsoft does support installing WSS v3 in parallel with v2 on your SBS - but only supports the companyweb site running as a WSS v2 site. Microsoft's official document on installing Windows Sharepoint Services v3 on SBS can be found here.

What's the fuss?

The first thing to talk about is why you want to move up to WSS v3. Being a long-time Sharepoint junkie, there are some impressive features in v3 that address many of the complaints and wishes we all had with previous versions. The key items:

Recycle Bin    All most WSS admins can say is FINALLY! No more juggling with multiple stsadm or smigrate backups to allow for individual item restores. And when you need to restore, no more needing to restore those backups to parallel sites. Granted it worked - but was cumbersome and painful.   WSS v3 gives us a dual-layer Recycle Bin. Each user gets their own Recycle Bin which allows them to easily recover anything they may have deleted (a document, a photo, or even a list item). In addition to the individual user recycle bins, there is a site-level recycle bin as well. So even if your users delete something from the site, and then empty their recycle bin only to come to you the next day to ask if there is any way of getting that item back - well now there is. The administrator can access the site collection recycle bin and restore items that users have deleted even if they have deleted their recycle bin. This is configurable so you can specify how long you want to keep deleted items in the recycle bin, so you don't have to manually empty the site collection recycle bin.

Offline Access to Document Libraries     Yes, you read that right. So you're finally getting your users to store their documents on your Sharepoint site - but you've still got those roaming users who are keeping files on their laptops so they can have access to them anywhwere, even if they don't have an internet connection. Well now you can have the best of both worlds. With Outlook 2007 and WSS v3, you can now keep a copy of your document libraries within Outlook - so your users can have offline access to their Sharepoint files.

Mobile Access.     Do you have users who are out of the office a lot? Do they have internet-enabled phones? WSS v3 includes a mobile page format optimized for web-enabled PDA's & smart phones - which presents an experience somewhat similar to OMA. Regardless, you can now access your Sharepoint site, including documents and lists right from your phone.  I only migrated our companyweb a few days ago, and I'm already finding myself taking serious advantage of this mobile access on a regular basis.

Tighter integration with Office.     WSS v3 and Office 2007 are a match made in heaven. With WSS v2 & Outlook 2003, we could link Sharepoint calendars and contact lists with Outlook. However, anyone who used this functionality realized this was a one-way connection: you could only view the calendars and contacts in Outlook. Any additions or changes had to be made via the Sharepoint web interface. Not any more - with WSS v3 and Outlook 2007, you have full two-way integration, allowing you to add/edit appointments or contacts from either the Sharepoint web interface OR from within Outlook. And an added bonus - if you delete a Sharepoint contact or appointment from within Outlook, it actually gets sent to your Recycle Bin within Sharepoint.

Improved Versioning.     WSS v2 allowed us to keep versions of items stored in document libraries. WSS v3 allows us to keep track of both major & minor versions within document libraries, and even allows us to keep track of versions of list items. So you can now see version histories within your lists, and just like with document libraries, restore any previous version at any time.

Improved Security.     WSS v3 gives us true item-level security on documents and even list items. So for you somewhat Draconian admins out there, you can control what your users can see, change & delete at a granular level.

There's a lot going on with WSS v3 - both on the surface and under the hood. So far our migration has met with positive results from our users - it's cleaner, quicker, and just flat out prettier. But now that you know why you want to migrate, in the next segment we'll address how to plan such a migration and what gotchas and pitfalls to avoid.

A companyweb by any other name . . .

cgross — Sat, 16 Sep 2006 22:00:00 GMT

So, one question that I get asked regularly is if you can use a different name to access your companyweb. For whatever reason, it appears SBSers have their own ideas of what URL / name they want for their individual intranets The good news is that this is very simple to do . . .

1) Pick a name you want to use - for the purposes of this post, let's say we want to use http://intranet (yeah, real original, I know . . . )

2)   Add and entry to your DNS. First and foremost, we have to make sure that intranet resolves correctly to your server's IP.
     a) So open your DNS snap-in, expand <servername> | Forward Lookup Zones | <domain name>.
     b) Right-click on <domain name> in the left hand pane, and select 'New Alias (CNAME)'.
     c) Enter 'intranet' for the Alias name.
     d) Enter the FQDN of your SBS in the target host field (e.g. sbs.company.local)
     e) Click OK and close the DNS snap-in

3) Edit the host-headers for your companyweb site. Now we have to make sure that IIS knows how to route traffic properly. You see, when IIS receives a normal http web request, it looks at the header of the request to get the URL that the user entered (in this case, http://intranet). IIS then looks at the websites to see if there is one that wants this traffic (has a host header present that matches the request URL). If it can't find a site with a matching host header, then it sends the request to the default web site. Since we want these requests to go to the companyweb site instead of the default web site, we need to add host headers to the companyweb site.
     a) Open IIS Administrator snap-in
     b) Expand <servername> | Web Sites
     c) Right-click on companyweb and select Properties
     d)  On the web site tab, click the Advanced button
     e) Click the 'Add' button on the top half of the page.
     f) Change the IP address from (All Unassigned) to the internal IP of your SBS.
     g) Set the TCP Port to 80
     h) Set the host header value to intranet (or whatever name you want to use)
     i) Click OK
     j) Repeat steps e thru i, only this time use the FQDN value in step h (e.g. intranet.company.local)
     k) Click OK |   Click OK | Close IIS Admin snap-in

4) Re-extend Windows Sharepoint Services to the web site. Just like IIS needs host headers to know where to route requests, Sharepoint central config keeps track of the sharepoint sites in its database. Therefore, we need to re-extend WSS to the site in order to update the config database so it knows that we're using an alternate name to access the site.
     a) Open Sharepoint Central Administration
     b) Click 'Configure Virtual Server Settings'
     c) Click 'companyweb'
     d) Click 'Remove Windows Sharepoint Services from Virtual Server'
     e) Verify 'Remove without deleting content databases' is selected, and click OK
          (when this finishes, you will return to the Sharepoint Central Administration main page)
     f) Click 'Extend or upgrade virtual server'
     g) Click 'companyweb'
     h) Click 'Extend and map to another virtual server'
     i) In the Server Mapping field, select 'companyweb'
     j) Select to 'Use and existing application pool'
     k) Select 'DefaultAppPool (NTAUTHORITY \ NETWORK SERVICE)' for the app pool to use.
     l) Click OK
     m) Close Sharepoint Central Administration.

Now, open IE and browse to http://intranet (or whatever name you used) and verify that it opens up your companyweb. Note that after following these steps, you will still be able to access the site by browsing to http://companyweb. This is because the native SBS functionality relies on the Sharepoint site answering to http://companyweb. As a result, you can have your users use the new name you specified, but all of the SBS functionality (including the wizards in the SBS Admin Console and the companyweb links in RWW, etc.) will work just as before . . .

Swinging Your Companyweb

cgross — Wed, 07 Jun 2006 02:44:00 GMT

So, with my last post I talked about using smigrate to backup and restore your SharePoint sites. With this post I'm going to go one step further and attack a specific scenario that I seem to be getting more and more questions on - migrating your companyweb SharePoint site from on existing SBS 2003 installation to a new one. This may be because you're swinging your SBS to new hardware, or just starting over for whatever reason.

The idea is quite simple - you have a working companyweb on your current SBS, complete with tons of documents in various document libraries, a few custom lists, maybe a forms library, etc. - you're moving to a new server and you want to move that site completely in tact . . . it's not an unreasonable request by any means - and luckily enough it is rather simple to accomplis - provided of course you know how to do it. That's where this post comes in :^)

Obviously, the first step to making this happen is to backup your existing companyweb site using smigrate as I've outlined in my previous post. The restore part is where everyone seems to be stumbling, so here's what you need to know:

First, it is important to understand part of what the smigrate restore does. When it connects to your SharePoint site to perform the restore, it is going to set the site template for the site based on the template that your backed up site was using. Now, with SharePoint - setting the template for a site is a one-time thing - once you've set a template for the site you can't reset it. The only time a Sharepoint site is clean (e.g. does not have a template assigned to it) is right after Windows SharePoint Services has been extended to a website. The first time you access your new WSS site, you have to choose your template before you can begin using the site.

Most people who try to migrate their companyweb site using smigrate (or FrontPage) run in to this problem - their restore fails because the site is already in use. Specifically, the smigrate restore process cannot set the site template for the new companyweb site because it already has a template set. Sure, it's the same template as the one you want to use - but the restore process still needs to set it to be sure. As a result, the restore fails before it ever gets started.

So - how do we get the restore to work? Simple - we take the new companyweb site back to a clean state (where no template has been set). To do so, we simply need to remove WSS from the companyweb virtual server, then re-extend it. Now, before we remove WSS from the companyweb virtual server (on the new SBS server) - you need to be aware that this process is going to destroy this site (and all content). Most of the time this should be an empty companyweb - but just in case you have some content in there, either extract it or back it up first :^). So - your step-by-step process to get your new companyweb in a state that will allow an smigrate restore: (all steps are on the new SBS - assuming you have already completed the smigrate backup on the old server and moved those files to the new server).

1)   Open SharePoint Central Administration ( under Start | Administrative Tools )
2)   Click on 'Configure Virtual Server Settings'
3)   Click on 'companyweb'
4)   Click on 'Remove Windows SharePoint Services from virtual server'
5)   Click to select 'Remove & delete content databases'
6)   Click OK to acknowledge warning that you are deleting all content for the site
7)   Click OK
8)   When you return to the SharePoint Central Administration page, click 'Extend or upgrade a virtual server'
9)   Click on 'companyweb'
10) Click on 'Extend and create a content database'
11)  Select to 'Use an existing application pool'
12)  Verify that the app pool selected is 'DefaultAppPool (NT AUTHORITY / NETWORK SERVICE)
13)  Under the Site Owner section, enter the administrator email address for your domain
14)  Click OK to extend WSS to the companyweb virtual server.
15)  Once you see the page indicating the the virtual server was successfully extended, click OK to return the SharePoint Central Administration
16)  Navigate to http://companyweb, and verify that you get the Template Selection page. Be sure and close this window - DO NOT click the OK button as this will apply a template to the site and you will have to repeat these steps before you will be able to restore your existing companyweb site.

At this point, your new companyweb site is in a clean state, and you can use smigrate to restore your existing companyweb backup to the companyweb on your new server. Now, if you were using any 3rd party web parts on your old server, you want to be sure and install those on the new server before starting your restore. And if this is a swing migration, your original AD will be in-tact, and the smigrate restore will also restore all permissions for the site as well. Once the smigrate restore process has completed, there is nothing left to do - your companyweb will be back exactly how you left it - all permissions, settings, templates, etc. will all be there and you'll be good to go :^)