We just finished an upgrad of a customer SharePoint environment from 2003 to MOSS 2007. The upgrade went rather smootly through the first little bit, then blew chunks, then (after three hours with MS) was completed and working (covered in another post - link to come).

 

Now the little quirky thinkgs start coming in from the customer. For instance, "our alerts aren't working anymore". Well, why the heck not? They look like they are all set in the list just the way they should be. I even deleted one (from the Site Settings pages) and recreated it. Still no go.

 

I create a new site and added an alert to the default announcement list, and it worked! Ok, so all the resets of the timer and admin service finally worked. "Customer, you should be good; I just received an Alert." And, of course, the response from the customer, "still not working for me on my site."

 

By now I have already read through MANY posts, one of which (link coming later) is a Microsoft KB article with a good script in it. Only problem is, I really don't like writing console apps and not being exactly sure of what the script really is doing. The explanation isn't quite full enough for me. Then I saw a couple of folks mention the good ole "ImmedSubscriptions" and "SchedSubstcription" tables. So, they want me to clear these out and recreate my alerts. Um, how about NO!!! I am not about to ask hundreds of users to rebuild hundreds of alerts because something weird is going on in my SharePoint site after my upgrade.

 

I opened up the tables and noticed there were two different values showing up in the SiteURL field. One was the correct URL with the other being a very slightly different URL. So, I ran a simple update on each table and HERE COME THE ALERTS!!! Yea!

 

Asked the customer, "did you guys rename this site prior to our doing the upgrade?"

 

Customer responds: "Oh yeah, we took the hyphen out of the URL right before you guys came in."

 

And there ya go, the alerts actually weren't working PRIOR to our upgrade process, but we didn't have all the information of what had happened prior to our service starting. So, could have saved myself a good bit of effort probably, but lesson learned (and shared).

What we found was that the customer had Office 2003 loaded up everywhere. We (myself and my co-worker) tested this on our own machine, and yes, it did open as read-only. Strange though, we could still save the file back to the item attachments and overwrite the current attachment item with our changes.

 

So, even though Office claims that the attachment is read-only, it lied! We could make all of our changes, click the save button and then just click the one extra OK/Save button.

 

Still, this didn't fix the problem for the customer. They were not able to do this. After looking a little further we found that our machines were loaded with Office 2003 SP2, but the customer systems had not yet been updated to this service pack. I tested it out on one of their boxes, and wouldn't you know, opens read-only, but saves right over top of the current attachments. Finally, they don't have the "copy of copy of copy of " myfilename attachments anymore.

A common need in SharePoint 2007 is to create your own Content Types (great new feature) with a bunch of custom columns for metadata tags. The process for this is documented all over the place and easily found, so I won't go into it here. But, what I do want to cover here is how to get those properties setup as "Managed Properties" so you can search only on a given set of your custom columns on the search pages.

 

To do this is basically straight forward and, again, is documented in a lot of places on the web. The basic process is to nav to the SharedServices Admin site and click Search Settings. Then select the link for "Managed Properties". Now click the button labeled "New Managed Property". On that next form, just fill out the appropriate information and click the Add Mapping button. Enter your custom column name and select it from the list, click OK a couple of times and done!

 

Well, what you might notice, if you are so lucky as me, is that you CANNOT add the mapping to your custom column. Why Not? It just won't show up in that danged list!!!! Hmm, try forcing a full crawl, still no luck. Delete all my indexes (don't recommend this on production too often) and force a new crawl, STILL no luck.

 

As this is all happening on a pre-production system, we didn't have too many docs out there using my new content type. Additionally, most (if not all) of our custom columns are optional, meaning that the docs might not have values for those fields yet. And there's the rub! Until SharePoint crawls at least one document with a value for a custom column, that column cannot be mapped to a Managed Property. So, I uploaded a junk file and set ALL of my custom columns to contain junk data. Forced another crawl, and I HAVE MY MAPPINGS. Now I can setup my custom searches to pull the way I want.

 

Happy Indexing and Searching!