OK, so I'll admit it's blatant self-promotion - but we have a few slots left until we fill up 

MSP Revolution Sponsors     Level Platforms         Autotask       Reflexion     SecureMyCompany         MSP OnDemand       eFolder     StorageCraft        Xilocore     Labtech Software Labtech Labtech       MSP Partners   itControl Suite       MSP University         Great Little Book Publishing       Ambition Consulting PRE Day Conference Events Designing, Implementing, and Making Money with Virtual Environments by Dave Sobel and Karl W. Palachuk   How to add $100K (or more) in revenue in the next 6 months! by Matt Makowicz and Stuart Selbst from Secure My Company   For more information: www.smbpreday.com Our Website Services More About Us MSPSN Blogs   Dear Chad, Last Call for MSP Revolution!   Seats are filling quickly and MSP Revolution 2008 is the only event this year where we'll take you deep into the Managed Services Business Model and deliver a proven Road Map to profitability in Managed Services.   September 4-7 in Chicago   Register at www.msprevolution.com Chad, Thursday September 4, 6p-9p   Cocktail Party with MSP Mentor.  MSP Mentor's Joe Panettieri will lead us in an interactive discussion on the "State of the MSP Channel."   Friday September 5   Kick the morning off with a keynote by Len DiCostanzo of Autotask where you'll learn how to "Organize, Integrate, and Automate your IT Services Business."   Next, dive right into the MSP Revolution Excellence in Business Acumen business simulation experience delivered by Andromeda Training.   Discover how to strengthen all aspects of running and managing your business through this focused and intensive management education that allows you to work through and resolve major business decisions in a fun, fast paced environment.   Working in teams, participants gain an experience of what it is like to operate a business in a competitive market. They make all the decisions - production, marketing, sales, finance, and own all the results. Teams and long-term professional friendships are built in a challenging game environment.  The secret benefit is that some very thorough business finance learning occurs.   End the day with cocktails and dinner with MSP University's Erick Simpson who will share his professional insight in "Growing Your Practice During an Economic Downturn." Saturday September 6th & Sunday the 7th   Spend a day and a half with the greatest minds in the Managed Services Channel today.  Our speakers are the BEST minds in the Channel and you won't want to miss this opportunity to learn from them.   Each speaker has built multimillion dollar Managed Services companies and they are going to share their knowledge & experience with you! Defining Your Managed Services Offerings Learn how to design and deliver profitable Managed Offerings. Ron Cook, Xilocore   Pricing Your Managed Services Offerings Discover How to Price Your Managed Offerings Profitably Ramsey Dellinger, MSP On Demand Developing Your Contracts & Service Level Agreements Service Level Agreements, Why You Need them & How to Create Them Karl Palachuk, KP Enterprises Marketing Your Managed Services Learn how to fill your pipeline with proven effective marketing techniques. Erick Simpson, MSP University Building a Profitable Service & Help Desk Learn how to inject efficiency into your Service Desk and realize the profitability you've been seeking. Amy Luby & Chad Gross, MSPSN Selling Value in the Managed Services Model Proven Techniques in transitioning from selling features to selling Value. Matt Makowicz, Ambition Consulting Partnering for Success Industry, vendor and peer partnering can transform your business.  Learn how. Stuart Selbst, SecureMyCompany   To learn more about each speaker, go to www.msprevolution.com.   We are bringing some of the greatest minds on Managed Services together for a premium event like no other.  We can't wait, and we hope to see you there.  Don't miss out on this opportunity to learn from the best!

I have a confession . . .   I took my first step moving to the dark side three months ago.  You see, my beloved Treo 700w had finally died for the last time - it had lived a long, hard life of just over 2 years and had been dropped countless times.  I was looking for a Windows Mobile 6 device that had a touch-screen and a vertical orientation like the Treo (I for one dislike the slide-out keyboards because it requires two hands to type).  I was surprised at the lack of options available for those three criteria.  As a matter of fact - Verizon did not have a single device that met all three criteria - they still had the Treo 700w with a touch screen, but running WM5.  They had the new Moto Q with WM6 and the vertical orientation, but no touch-screen.  Or the Samsung isomething that had a touch screen and WM6, but had the horizontal slide-out keyboard.

So on a whim, I did an abrupt face and bought myself an iPhone.  This was back in March, and I admit that what finally pushed me over the edge was the announcement of the iPhone 2.0 software update that would include support for push email via Microsoft ExchangeSync.  Admittedly, there are days that I still miss my Treo  (I still prefer a physical keyboard over the iPhone's on-screen keyboard - but I eventually discovered the trick to fast composition on the iPhone is to just get close and trust its auto-correct to fix your typos - and 98% of the time it gets it right).  The biggest pain over the past 3 and half months has been the lack of over-the-air calendar and contact sync.  After having that for over two years with my Treo, having to dock my iPhone every few days or remember to look at my Outlook calendar before I ran out the door was getting old. 

But anyway, today was d-day - when the iPhone 2.0 upgrade was officially available to the masses.  I didn't get a chance to really try the upgrade until late this afternoon.  I started earlier this morning, but I could not get iTunes to backup my phone prior to the upgrade (unknown error -43).  Of course, it gave me the option to continue without a backup - I would just lose little things like my text messages, favorites, mail accounts, etc. - basically anything that wasn't sync'd with my PC.  So I stuck it out and eventually tracked the issue down to iTunes not playing nicely with folder redirection in a domain environment.  My music lives in a redirected folder and syncs ok, so I'm assuming the issue is with a redirected Application Data folder.  But anyway . . . )   So late this afternoon I finally got the phone backed up and initiated the upgrade.  The entire process took about 30 minutes to download, install, restore & activate.  Luckily, I did not run in to the mess this morning where Apple's activation servers were overwhelmed and couldn't be contacted, leaving a lot of people with a nicely upgraded phone that could not activate and thus had no service . . .   but again, there's a reason it's called the bleeding edge . . .

But the big news for me is the Exchange integration.  I removed my previous IMAP account, and set up my Exchange account.  Biggest surprise for me: the iPhone will sync with Exchange over the air if you're using a self-signed SSL certificate on your SBS / Exchange server.  It complains a bit that it can't authenticate the certificate when you're setting up the account, but you can acknowledge the warning and it will start synchronizing.  Naturally, if you select to synchronize your contacts and calendar, any contact & calendar data on the phone itself will be overwritten by data on your Exchange server.  For me this was no big deal as I was manually synchronizing this data anyway. 

I still have to play around a bit, especially with installing some of the new apps, but so far the Exchange integration is working just as I would have expected.  The contacts feature even handles multiple contact folders in your Exchange mailbox very nicely - even additional top-level contacts folders, and even allows you to search the GAL

Anyway, I'm off to go play on the dark side a little more . . .

Ok, I admit it.  I'm a creature of habit, and I don't always adjust nicely to change.  I'm getting ready to do my first of the month recurring invoicing, and reviewing an Excel spreadsheet one of my vendors sent me.  As I try to navigate the spreadsheet in Excel with my arrow keys, I find that my arrow keys are scrolling the worksheet instead of moving cells. 

So a quick google came up with a simple solution: disable scroll lock.  The problem was this was the first thing I tried, and it didn't work.  After the scroll lock suggestion, I found a few workarounds, including a post from my old friend Kevin

The problem is that I've never been a big fan of workarounds - I want to know the answer and solution to the problem.  As I was checking out a few of the hits where the scroll lock option wasn't working for the original poster (including Kevin's post), I quickly identified a common thread:  Logitech keyboards.  And I'm using a Logitech MX3200 cordless desktop on this machine.

Within a few minutes I had the solution to the problem.  In order for the Scroll Lock key combination (FN + Pause/Break) on the Logitech keyboard to work, the Logitech SetPoint software must be running.  Once I fired up the application, it worked like a charm.  Close the app, and they key combination doesn't work at all.

Here's hoping this saves a little bit of someone else's sanity . . .

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.

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 

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.

I did it.  No - hell didn't freeze over, and no - pigs aren't flying.  But yes, I just recently did some network reconfiguration here at the office, moving from a dual-nic SBS Premium setup with ISA 2004 to a single-nic setup with a hardware router/firewall instead.   Gasp!  The horror! . . .

I'll admit that for a long time I thought it would be a cold day in hell before you could pull ISA from my dead hands - but I would also be lying if I didn't tell you that I definitely had a love/hate relationship with ISA - and it usually depended on the hour as to whether I was loving it or hating it.

So what is my thinking?  You know, if someone figures that one out would you please clue me in?     

Like most technology decisions, this was motivated by business needs - both the business needs of our clients as well as our own business needs to profitably deliver quality services to our clients.  First - we're seeing an increased demand in managed security with the SMB client.  Second - we are continuously looking for ways to increase productivity and gain efficiency.  Third, we're revamping our product offerings to better line up with our core business as an MSP by adding products that allow for additional recurring revenue opportunities.

So, the big question is what did we decide on to replace ISA 2004 in our office?  CheckPoint's Safe@Office 500W Unified Threat-Management device.  Now why did this solution win out?

1)   Affordability / Flexibility.  The CheckPoint has several base models to choose from (wired or wireless with 5/25/Unlimited clients)  And nice add-on services including gateway anti-virus, anti-spam, web content filtering, etc.  The base models make it affordable to get this device into smaller clients who wouldn't normally consider ISA.  Additionally, the add-on services allow clients to purchase features cafeteria-style and provide us with additional recurring revenue.

2)   Efficiency in Management.  CheckPoint offers their Security Management Portal for centralized management of these devices.  Their SMP was designed and built from the ground up for target MSPs and how we work: 

      *   Everything you can configure locally via the device can also be configured centrally from the SMP.  Additionally, with the SMP we can create groups with common configurations and apply those group settings to multiple devices very quickly and easily. 

      *   The SMP also streamlines setting up site-to-site VPNs between devices.  Simply build your VPN community in the SMP and pick the devices you want to belong to that community, then the SMP will generate the necessary configuration and push out to each of the devices.  This also allows you to have IPSec VPNs between devices that can only get dynamic public IPs.  When one device's IP changes, it notifies the SMP which automatically updates the configuration on the other devices in the VPN community. 

      *   The SMP allows you to customize both administrative and customer-facing reports, so you can change the layout, the content, and even the look and feel to match your branding.  Customer-facing reports offer a lot of nice, colorful graphs which make sense to CXO level individuals at your clients. 

      *    The SMP is available either in a hosted solution, or in a purchase and run on your own server setup.

From a technical standpoint, there are pros and cons to both ISA and the CheckPoint (or other hardware firewalls).  There are a lot of things that ISA does better than many hardware devices - primarily web publishing, with its ability to inspect http traffic and route requests based on HTTP host headers, as well as providing egress filtering that integrates with Active Directory.  Where ISA falls short is when you have a service provider who needs to efficiently manage multiple installations at different customer sites with different needs.  Sure, I could probably build a repository of management scripts, and use Level Platforms' Managed Workplace to push those scripts out to our managed client base, but why recreate the wheel - and run the risk of having to recreate those scripts as subsequent generations of ISA are released? 

Also, I will admit that I am beginning to question the feasibility of ISA on SBS.  I still don't fully buy in to some people's arguments that ISA on SBS is inherently insecure.  I'm beginning to question the feasibility of ISA on SBS not because of the security implications, but of the added complexity in setup and administration.  If you look at the SMB space and the SBS customer - their needs are changing.  Two years ago we could sell an SBS Premium to a customer who relied on Exchange and file shares.  In that scenario, adding ISA to the mix wasn't that complicated or that big of a deal.  The customers we're encountering today are looking for much more diverse and mature solutions.  Our typical SBS-based deployment is now a multiple-server environment.  SBSers are doing more with Exchange - particularly in terms of mobility, depending on SharepPoint for workflow management, version controls and increased collaboration, instead of simply document storage.  Our SBS clients are also much more likely to be running at least one Line-Of-Business app - in our experience most likely Dynamics GP and/or Dynamics CRM.

When you start putting all of this on to one box, change management becomes a bit of a challenge to say the least.  And even us long-time ISA fans have to admit that ISA is usually the first thing to come up when we start thinking about moving services off our SBS.  But investing in another box, plus another Windows Server license, plus ISA is often hard to swallow - especially when you look at it from a customer perspective and include services to install and configure that box.  From a business standpoint, when you compare that option to a solution like the CheckPoint that offers a significantly lower entry point, provides the MSP with a mechanism to recurring revenue, and provides a pre-build solution to efficiently manage a large number of devices from one central location, and it becomes a bit of a no-brainer.

Now the question is just how well this is going to work.  We're now at 4 days since CheckPoint has replaced ISA in our office, and so far so good.  I'll be sure to report back on my post-ISA experiences 

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

Velma Kelly and Matron Mama Morton asked that question in Chicago and I'm asking it again now.

I believe in humanity.  I believe that for the most part people are inherently good and want to do the right thing.  But I also believe that the online experience has helped foster the decline of basic manners, respect, and class.  I could get in to a long-winded dissertation on why I think that is, but that is a subject for an entirely different audience and venue.

Unfortunately, we all encounter individuals in our communities (both physical and virtual) who thrive on destruction.  Their only involvement within the community is to complain, criticize, and generally undermine the community.  At no time do they make any noticeable contribution to the community.  The reasons for criticizing instead of contributing vary by individual, but most often it is some derivative of personal insecurity - lack of self esteem, fear of failure, incompetence, inexperience, etc.

As virtually anyone who frequents msmvps.com knows, the last week to ten days have been a bit choppy in terms of reliability of the site as we try to work out what exactly is causing asp.net to peg the processor on the blog server.  What most people don't realize is what is involved with administering and maintaining the blogs:

1)  msmvps.com is a pure volunteer effort.
2)  msmvps.com is not affiliated with Microsoft in any way.
3)  msmvps.com continues to exist due to the gracious generousity and sheer strength of will from a few key individuals.
4)  msmvps.com generates a mind-boggling amount of traffic and has massive bandwidth requirements.

Since administering and maintaining msmvps.com is a volunteer effort, the blog server is at the mercy of our schedules (believe it or not, each of us actually have real jobs, families, pets, homes, etc. that require our attention).  Additionally, since msmvps.com does not have any corporate sponsorship and is a free resource for multiple communities, when it is time for an upgrade, new features, etc. for the blogs - that expense comes out of someone's pocket.  Likewise, having the blog server on what has been dubbed "p0rn quality bandwidth" costs someone somewhere as well. 

But apparently, a few members of the community have conveniently forgotten each of these points.  They have forgotten that people are willing to share their experience and knowledge to help complete strangers and receive nothing in return - but also that there are people who not only share their knowledge and experience with complete strangers, but they are willing to pay real money from their own pockets to do so, and to provide other people with a free platform to do the same. 

As mentioned above, there are those individuals who thrive on destruction - and one such individual recently had the audacity to suggest that the instability of msmvps.com doesn't say much for the the technical ability of MVPs.  This same individual stated flat out that it needs to be fixed, yet offered no assistance to resolve the issue.  They did not offer to take several hours out of their day to sit on the phone with Microsoft PSS or even pay for that support call.  They did not offer to volunteer their personal time to review server logs, find someone well versed in .Net to assist, or even to baby sit the server and restart services as necessary to ensure that msmvps.com was available to anyone who came looking for help.  Surprisingly enough, they did not even offer to make a cash donation towards purchasing support from Telligent to help resolve the problem.  No, all they had time for was to complain and criticize.  It's one thing to criticize the stability of the site - because that has been less than optimal - but to go so far as to criticize the people behind the scenes who give so much of their time, knowledge, passion and cash to provide community members with a free resource that is not cluttered with ads, not censored, and freely available to anyone who needs help is not only rude and unprofessional, but is very uncouth.

So what ever happened to class?  Well, I'm here to tell you that there is hope.  It can be found many places, including Fresno, California as well as certain posts in virtually any online community regarding SBS, security, or patching.  msmvps.com would not exist without the unbelievable passion and self-less generosity of Susan Bradley.  While she may call herself wacko, and emotional, and like all of the rest of us she can get a tad over-zealous on certain issues - she is a consummate professional and truly a class act, and in my mind her passion and contributinos to community sets the bar by which all other MVPs are judged.

Now if you will be so kind as to excuse me, I have to help a friend with a blog server . . . 

Ok, so that isn't exactly a witty title for this post - but it does get to the point    

I'm a big fan of Trend Micro - have been since the SBS 4.5 days.  As a force of habit, when we're rolling out a new network I always add a call to Trend's AutoPCC utility in our default login script, which will ensure that the Trend client gets installed when new machines are joined to the domain.  While there really isn't much benefit of leaving this entry in the login script after Trend has been deployed - I'll admit that I have a tendency to be a bit lazy and leave it there just to save a few clicks when we're adding new machies to a network.

Historically, there hasn't been an issue with leaving the call to AutoPCC in the login script - you'd get the occassional restart of the Trend services on the client during login, but that was about it.  Recently, we've started going through the process of upgrading our clients to Trend's Client/Server/Messaging Security 3.6 which includes support for Microsoft Vista.  A day or two after upgrading one particular client, we received a call from a user indicating they were getting a warning message on their PC.  The warning message was the Windows Security Center indicating that Anti-Virus wasn't running.  I quickly determined that the Trend services were stopped - and naturally starting them resolved the issue.

The real surprise was when I logged in to the Trend console to verify this workstation was back online, I discovered that approximately 75% of their PCs were showing offline.  I soon discovered that the Trend services were stopped on each workstation that was showing offline, and starting the services brought them back.   Working on one of the PCs, I witnessed that the during logon, the login script was calling the AutoPCC utility - which was stopping the Trend services - but more often than not when AutoPCC completed, the services were not restarted. 

I've seen this behavior consistently across all of our customer sites that we have upgraded to CSM 3.6 - it seems to affect all PCs eventually, and I've been seeing anywhere from 25 - 75% of the PCs offline in the Trend console with local services stopped at any given time.  We never saw this with CSM 3.5 or prior.  In the mean time, we've resolved the issue by just removing the call to AutoPCC from the login script since we really don't need it there any more.

Some of you know that I'm a big fan of Trixbox - which is an VoIP solution built on the ever-popular linux-based open source Asterisk PBX.  We've been running it in our office for about 18 months (when it was originally Asterisk@Home).  I'll admit that it started out more as an experiment than anything else, but we ended up liking it and using it in production, and have started selling it as well.  Admittedly, the hardware we're running it on leaves a little to be desired, so we're looking to replace our current hardware.  Well while doing some research, I discovered that Trixbox is now offering a Trixbox appliance:

Now you've got to admit, that there is just cool . . .  and would look so good in our server cabinet 

Thanks to Nick who ran into this one before I did

Windows SharePoint Services v3 uses Microsoft SQL Embedded Edition (MSEE) for its data store.  When MSEE is installed, the data files are installed to your C: drive by default.  Well, like any good admin - we don't want data (that can grow exponentially) living on our system partition.  However, you can't successfully move the data files for an MSEE instance using your normal SQL tools (most notably SQL 2005 Management Studio).  Yep, you've got to resort to the command line . . .

First, you will need to have the Microsoft SQL Server Native Client and Microsoft SQL Server 2005 Command Line Query Utility installed.

1) Identify the Sharepoint DB you want to move (look under SystemRoot%\SYSMSI\SSEE\MSSQL.2005\MSSQL\Data)

2) Stop SharePoint services.

3) Open a command prompt

4) Go to the Microsoft SQL Server 2005 Command Line Query Utility folder (under C:\Program Files\Microsoft SQL Server\90\Tools\binn)

5) Enter the following command & hit enter:
           sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query -E

6) Enter the following commands & hit Enter after each:
           EXEC sp_detach_db <db_name_to_be_moved>
           GO

7) Repeat step 6 for each database you want to move.

8) Move the individual .mdf & ldf files for the detached databases to the new location.

9) Attach moved databases.  Return to your command prompt and enter the following command then press Enter:
           EXEC sp_attach_db @dbname = N'<db_name_to_attach>',
           @filename1 = N'<new_location_path>\<db_data_file_to_attach>.mdf',
           @filename2 = N'<new_location_path>\<db_log_file_to_attach>.ldf'

The line breaks above are for ease of reading.  When entering the command, don't use line breaks, just the the lines wrap.  E.g.:

EXEC sp_attach_db @dbname = N'WSS_Content', @filename1 = N'D:\SharePointDB\WSS_Content.mdf', @filename2 = N'D:\SharePointDB\WSS_Content_Log.ldf'

10)  Type   GO   and press Enter.

11)  Repeat steps 9 & 10 for each database you moved.

12)  Type Exit to exit from SQLCMD

13)  Type Exit to close Command Prompt

14)  Start SharePoint services you stopped previously.

15)  Verify access to SharePoint sites.

Ok SharePoint junkies . . .    the new Server Admin Templates for WSS 3.0 are now available for download on the Microsoft site here.  The new Server Admin Templates include:

*  Absence Request and Vacation Schedule Management

*  Budgeting and Tracking Multiple Projects

*  Bug Database

*  Call Center

*  Change Request Management

*  Compliance Process Support Site

*  Contacts Management

*  Document Library and Review

*  Event Planning

*  Expense Reimbursement & Approval

*  Help Desk

*  Inventory Tracking

*  IT Team Workspace

*  Job Requisition and Interview Management

*  Knowledge Base

*  Lending Library

*  Physical Asset Tracking and Management

*  Project Tracking Workspace

*  Room and Equipment Reservations

*  Sales Lead Pipeline

And if you don't want to go through the process of downloading each one of these - have no fear, my demo site (which has been offline for a while) is about to reappear with all of the WSS v3 templates loaded for you to explore 

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.

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

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.

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

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.

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

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 rec