For reasons why, see my new blog and my initial posting (Same title as this one :)).

 - Keith Richie

Oh, and I'll add IIS redirect virtual servers into the mix.

I've been working with a customer on detailing all the steps necessary to make this a reality, and I've seen quite a few posts out on some internet searches where a ton of folks are asking this exact same question.

"How and what is the procedure for upgrading a SharePoint Portal Server 2003 Shared Services Farm with Network Load Balancing and Forced SSL to MOSS 2007"

This is certainly a loaded question, and there are important aspects you really need to understand about your current deployment and take into consideration before you just install the bits and start running.  Also, this doesn't even consider the state of your sites, i.e. how many custom site definitions, site templates, or web parts, etc, etc, etc.

As well, I discovered one important piece about your current environment you need to be aware of that boils down to what URL and name you bound your portal/wss sites on to begin with. My team has been harping on me to document and explain this specific “What’s in a name” piece for a very, very, very long time, and I don’t see how I can get by with explaining this whole upgrade process without starting with it.

Unfortunately, you’re not going to get all your answers in “This” blog post, so consider this a teaser trailer for a series of blog postings on this subject coming to an aggregator near you!

More to come

-       Keith Richie

Note: First of all, poking around through the UI to look at all the details of indexes, content sources, etc is a real pain.  Thus (You guessed it :)) I wrote a tool to gather and export this information so that I could look at it holistically.  It was actually a modification to the SPSAddCS tool in the SharePoint utility suite, just modified to use XML and added a "Read" operation to it to dump the data in XML.

Once I've had a chance to test it out in more detail, I'll post the code for it as well.

Since this customer had 4+ portal indexes with approximately 10 content sources per index, it made it allot easier to look at everything and spot the problem quickly.

Once I saw that they had two content sources pointing to the exact same content yet on two different indexes, it was a simple matter of setting this up on a plain Jane standalone SharePoint Portal Server 2003 box to validate.

I validated this using the following setup on my local test server.

• Created a plain IIS web site and placed a default web page with the following contents:

<html>

<body>

<P>Hello!</P>

<P>Keith Richie was here</p>

</body>

</html>

• Issued a search in the portal for “Keith Richie”, then selected “Alert Me” to create a portal alert, with its’ settings set to immediate
• Added a content source to this plain web site did a full crawl and confirmed that the notification was sent
• Created a new index
• Created a duplicate content source to the same plain web site bound to this index
• Made an update to the default web page
• Did a full crawl on both indexes, and I received two notifications about the same change
• Created a third new index
• Created a third duplicate content source to the same plain web site bound to this index.
• Made an update to the default web page
• Did a full crawl on all three indexes, and I received three notifications about the same change

Depending on your structure, and Exclude/Include rules created, this can occur for SharePoint sites as well

You ARE however, blocked from creating a duplicate content source on the same index, but not on a completely different index.  When you attempt to create a duplicate source address on the same index, you'll get the following error message:

“The object you are trying to create already exists. Try again using a different name. “

But if you are creating this on a different index, you will not get a warning.

In MOSS 2007, you are not allowed to even have multiple indexes unless you create multiple SSPs.  I'm not 100% up to snuff on the WSS 3.0/MOSS 2007 alert architecture, but I am very curious and would suspect that you would encounter the same problem, and could confuse users.

 - Keith

Previous Posts on this series:

Understanding SharePoint Series

In this previous post, I discussed how I spent most of my evenings and vacation time updating my indieOpolis site to utilize WSS 3.0.

One of the things I wanted to accomplish during this "rebuild" was to utilize the Rich Text column type for the details section of each CD release I have, but I ran into a problem of

a) Being able to actually use the Built In Rich Text Editor control in the out of box edit page

b) And utilize that content via a Data View web part for displaying to the end user.

I found out that, apparently, you only get this feature if it's used in a list and NOT a document library.

Initially, I had created a custom content type with a base "Folder" content type.  The reason I did this, is that I wanted to create a Folder that I could use within a single document library to describe a specific release.   The folder would act as the container for all the relevant data (Documents, pages, etc, etc) related to that release.  I would then use the folder metadata to describe the release on the Product Details page.  The problem, is that I could not figure out why I couldn't use the out of box Rich Text control to edit the metadata for the "Details" column in the content type.

I then found that this same folder content type worked just fine when used in a list.  It didn't work when used in a document library.

So, it appears that rich text editing/displaying support of rich text columns is disabled when used within Document Libraries.

I'm still waiting on confirmation if this is by design, or perhaps a bug, and once I find out, I'll update you...but this was a real pain in the butt. :)  I thought I was doing something wrong, but then when I used that very same content type in a list, and it started working, I realized that it was because I was using it in a document library before.

Regardless, I moved forward with having a base product "list" that I use, then go back to the document library for all the other resources...it was just a pain to have to do that.  I was hoping I would be able to use one resource container for all.

The end result like the following:

https://www.indieopolis.net/Pages/ProductDetails.aspx?IPID=IPID0006

The section below the CD cover and track listing is a data view web part that is pulling the details column back out.  This was only available if the data was entered into an item in a list, not a document library.

If anyone has any additional information on if this should work or not, I'd be more than happy to hear.

- Keith

For WSS 3.0, click here.

For MOSS 2007, click here.

Now that these are official, I'll be updating the Capacity Planning checker portion of SPSiteManager to reflect these. 

Enjoy!

 - Keith

Edit, test ,test , test, edit, test ,test, test, test.

Check In.

Ready for more editing?

"Check Out First!!!!"

I have definitely learned my lesson. 

- Keith

This past weekend, I spent "WAY TOO MUCH TIME" re-generating everything from scratch for a few reasons:

1. I hated what I had before :)
2. As noted in my previous post, I broke everything :( because I chose to start from scratch, and just didn't want to migrate it.  I wanted to force myself into starting over with a better design.
3. 4 words, "Content Types Are Cool!"

So, with a bit of pain, and a few SharePoint Designer lockups later, I've got it back off to a good start.  Go Here and check it out!  And be sure to check out the Tangerine Dream Release Inspector I designed to just traverse through the semi-official Tangerine Dream release list.

 - Keith

I'm using custom content types throughout to base everything from.

Hopefully, when things slow down a bit, I'll start blogging about how I set this site up; utilized content types; changes via SharePoint Designer, etc for anyone who is interested

 - Keith

Check it out here!

I think when Tony has completed this series (If there is ever an end as he's still got V3 to start talking about (hint hint Tony :):):)), the will be a great series of postings on truly understanding the crawler.  Kudos Tony!

In my post "Understanding SharePoint - Part 1 - Understanding the SharePoint Portal Server Indexer"  I refer to what I call "PDR" for Processed Documents Rate for the SearchGatherProjects\Processed Documents Rate, which is an indicator on a specific index.  Tony provides details on the "Search Gatherer" object which is the gatherer as a whole.  DO check out what he states for estimating times to completion in his posting.  It's something we try to explain to our customers on a near daily basis, and he's got some great scenarios to describe on this to "estimate" times to completion.

Again, Kudos Tony!

- Keith

I certainly don't have a separate database server for each farm to support these configurations, and I don't want to have a separate virtual server for each SQL server either.  Therefore, I utilize one box primarily for SQL in which I store all my databases for my various farms.

The problem with this is when running the Post Setup Configuration Wizard for Windows SharePoint Services 3.0 and Microsoft Officer SharePoint Server 2007.  For each farm, a separate content database is created for each central admin site with a name that makes it difficult to just look at the database name and figure out which farm it belongs to :).  The name using the following form:

SharePoint_AdminContent_<insertguidhere>.

So, by looking at the database name, you can tell it's for the Central Admin site, but the guid doesn't just shout out which farm it belongs to :).  I can't count the times when I go cleaning up leftover databases from test farms, only to accidentally kill an admincontent database that was STILL IN USE!!

I could have multiple SQL Instances to help sort this out, but I don't, instead I use PSCONFIG rather than the GUI based configuration wizard and name my admincontent database explicitly.

So with that in mind, consider the following topology

krichie-fosqlp is the name of my SQL 2005 Principle Server.

krichie-fowfe1 is a web server running as a Web Front End.

adomain\SPService is my SharePoint farm account

adomain\SQLService is my SQL service account used by SharePoint

After installing, deselect the "Run the configuration wizard" check box and close, then jump to the BIN folder of the web server extensions path and run PSCONFIG such as follows:

psconfig -cmd configdb -create -server krichie-fosqlp -database krichie-fo-wss-configdb -user adomain\SPService -password "SPServicePassword" -admincontentdatabase krichie-fo-wss-admin-content -dbuser adomain\SQLService -dbpassword "SQLServicePassword"

This will run through the post setup configuration wizard and use the database names that I provide.  Now my database names reflect the farm their associated with.

Also, don't forget to provision the admin site itself.

psconfig -cmd adminvs -provision

I know, it's not much, but a nice tip to keep in your back pocket.

- Keith