Use Them.  Really.

With Sharepoint, there’s this thing called “MySite”.  It’s a personalized, customizable, directory-enabled site for users.  It’s really cool – most of the information comes from Active Directory, like phone number, email address, reporting structure, etc. and it can show you the files you’ve been working on (anywhere in the company) and give you document libraries to store personal and project-based documents.

1. Private and Public Views
   When a user looks at their own MySite, they can switch between these two views.  The above is an example of a “public” view – normally if I look at my own MySite, I don’t want to look at my own picture.  Well, I *do*, but I don’t want everyone to know that.  The Public view is what everyone else sees about me, and the Private view is customizable and presentable to me and me alone.  I might put my calendar on there, or pictures of my kids… it’s a drag and drop kind of workspace, like the Yahoo and Google’s of the world where you can put whatever you want wherever you want.
2. Active Directory info
   Most of the time, our corporate directory is up to date with reporting structure, phone numbers, email, etc.  SharePoint pulls this info straight out of Active Directory so I don’t have to keep and maintain yet another set of information on employees.  It also has neat dropdowns that let me schedule meetings, use VOIP to call an end user, do instant messaging, email them right from the page, and see their presence info (ie, at their desk, in a meeting, etc).  It even lets me know if they’re free in the next 8 hours or what office they’re from.          
3. Shared Lists
   Each employee can use the web to store documents, lists, or have private documents.   They can create new websites without knowing any HTML or coding, and collaborate with other employees easily.
4. Recent Documents
   This is really cool – since SharePoint indexes not only itself but also other fileshares throughout the company, it can know what YOU have modified or own, and shows the recent documents not just on the SharePoint server but any file server in the company.  When other people view your site, they can see the documents you’ve been working on that THEY have access to, again increasing collaboration.  This is cool for system admins who have access to EVERYTHING, and then we can watch people make their resumes.  Ok, I’m kiddding there a little.  Just a little.
5. Shared Workspaces
   If the employee happens to have other sites they made with other employees, they can show up here, giving kind of an automatic bookmark

Now, none of this is new.  This is from a product called SharePoint 2003, which you can probably guess is about 4 years old now.  Microsoft has released SharePoint 2007 (aka “MOSS”) and it improves a lot of this.

Why am I telling you about old stuff?  Well, for one, it’s still in use at a lot of places.  And secondly, if one of your SharePoint administrators inadvertently edits the MySite in FrontPage and breaks it, you just might want to know how to recover.

That’s what this article is about.  In the extended entry, so’s I don’t bore most of you all.  See how I put YOU first?

First off, you should probably read about the difference (and performance difference) of ghosted vs unghosted pages in SharePoint.  The simple essence of it is that once you edit a SharePoint page in FrontPage, you UNghost it.  That means a series of potential issues with the page, although it feels cool to edit the page and make little changes.

Well, many admins new to SharePoint don’t realize this.  They also don’t realize one very very important tidbit about MySite – when you edit it in FrontPage, it affects ALL MySites, not just your own.

That’s the biggie.

Oh, and throw in the fact that once you edit a page in FrontPage, there’s no GUI or built-in way of going back.  You can’t “revert” a site back to the state before you edited it unless you restore.

So in this article I show you what Matt taught me about some low-level surgery you can do on your SharePoint portal content database to re-ghost the page.

WARNING: you need to make a backup before attempting any of these steps.  Surely if you have enough admin control of your SQL Server and Sharepoint Portal Server, then you know enough to have backups before you go tinkering around with the guts and brains of the system.  You don’t tug on Superman’s cape, you don’t spit into the wind, you don’t make registry edits without at least three backups and you DON’T MESS WITH SQL QUERY ANALYZER WITHOUT A BACKUP!

Ok, with the disclaimer out of the way, this article shows you how to fix it.

Here’s an example of our MySite after an admin edited it with FrontPage and removed some fonts, removed the picture and other modifications:

Le EWWWW!

Let’s go over some basics now — as we said, when you edit a page in FrontPage, it UNGHOSTS it.  You can tell if a page is ghosted or unghosted by looking in the content database

This query is totally safe.  We’re just displaying rows in the database, if they exist, that match the criteria.  We’re looking in the content database (for mine, it’s called MegaPath1_SITE – yours WILL be different, but you’re looking for the one that ends in _SITE).  You can drop that down from the menu so you’re on the right database.  We’re looking for entries that have a DirName of MySite, a LeafName of default.aspx (this is the Private version of MySite; we’d use Public.aspx for the public version) and if content is not null. 

If MySite has been edited (ie, unghosted), you’ll see a result similar to the following:

You can scroll to the right to see the dates and stuff just to make sure, but this is telling us that it’s been edited.  When this data isn’t here, SharePoint will pull the site from the filesystem like it should, but when the data is there, it pulls it from the database (slower, less easy to migrate, “bad”, etc).

If MySite has NOT been edited (ie, ghosted), then you won’t get any results.  Quel frommage.

Now to undo the damage.  The following code is how you set content back to null

 STOP.  LOOK.

This is SQL that will CHANGE YOUR DATABASE.  If you don’t know what you’re doing, find someone who does.

In the above example, I went to one of my draft content databases (DraftMeg1_SITE), and we’re updating the docs table and setting “content” to null for default.aspx.

Once you execute this (again, be sure you know what you’re doing and that you have a backup), you can re-execute the select statement and make sure nothing is in the results.

Now, when we go check our MySite, we can see that it’s back to default.  The following example is for Public.aspx instead of default.aspx.

Who *is* that handsome devil?

So now it’s back to defaults! YAY!

By the way, if you need SharePoint help, consider engaging Catapult Systems – top notch help, let me tell you.  In particular, Matt McDermott has been a fantastic resource many times for our company.  I think his full name is Matthew, but he goes by Matt.  I keep forgetting to ask him where he keeps the excess “hew”. 

Use them.  Really.

So maybe we’ll change our relationship to this: HE does the work but *I* explain it to the masses.   That’s what this entry is – a technical explanation of something we solved in SharePoint – namely, how to do something really cool with search.

First, a quick introduction.  SharePoint is a Microsoft product that gives companies a great intranet tool, collaboration platform, document search, a portal, and a ton of other great things.  I depend on it daily, as do many groups at our company.

One of the recent projects we engaged Matt for was to help us with the technical side of rebranding our intranet.  There are many things you can do out-of-the-box, but some of the ones we wanted to do weren’t so easy.  And one of the things that kept eluding me was how to get a better “Search” web part on our main home page.  We didn’t want the generic search that it includes at the top of the typical SharePoint area:

And we didn’t want the overkill “Advanced search web part” that is on the main built-in search page:

(click to enlarge) 

But instead, we wanted something between the two and that could fit nicely on the right side in its own Web Part Zone, plus give employees two main functions: an easy and smart Employee Lookup and a quick search of documents both in SharePoint and on the file shares throughout the company: 

 
(click to enlarge)

So Matt helped us out.  I’ll put the rest of the technical details in the extended entry below for those of you who want to know the solution.  And get a few laughs.  And it might cure acne, but I haven’t told the FDA about that yet.

For those of you not familiar with the Content Editor Web Part, let me do a cursory introduction.  This little gem (aka CEWP) lets you put any HTML source in a web part and stick it anywhere on the page.  Mostly this is good for putting static text, colors, or generic HTML somewhere, but it can be far more powerful.  You can use CSS, javascript, and other tools to really accomplish a ton of things.

If you want to know more about CEWP, take a look at one of many blog postings by Todd Bleeker.  Great stuff there by a very talented guy.

The first piece to tackle for this more intelligent search part is to have a Better Employee Lookup Tool or BELT for short.  That way I can tell our end users to BELT our employees.  HAHA.  Anyway, when you use the built-in SharePoint search tool to look for people, the results mix up both people and documents unless you manually pick the “People” content source, which — let’s face it, most users aren’t going to go around and customize their search parameters.  They just want to find what they’re looking for, thankyouverymuch.

So your normal search for people using the built-in search might look something like this:

(click to enlarge)

What I’ve found is that it will put a nice little star (indicating it’s a best bet) if it’s an exact match of the name of someone (or alias), but this doesn’t help much if you only know the first name.  Or how to spell the last name.  I don’t want all that clutter.  I just want to find a specific person.  Quickly.  Heaven help the poor soul who tries to search with just a first name.

So we started with the “People Finder”.   

It’s a CEWP that just takes a single line as input, and people can type in a first name, last name, nickname/alias and it gives ONLY people objects in the result.  This is sooo much better.  Now when I search for just “Wayne” I only get two results, and they’re both people objects:

One of them is not me, so the other guy’s gotta go.  Can only have one “Wayne” at my company, you know. 

So, how’d we* do it?

Here’s a dirty little secret about SharePoint search – you can pass parameters to it via the URL.

Now, all the parameters are not documented (as far as I can tell) but you can use something like Fiddler or other development tools to reverse engineer what parameters are being sent, and then you can craft a nifty url that looks like a form post.

What does this mean?  It means you can structure a custom SQL query, pass it along to search.aspx in URL parameters instead of form values, and it all works awesomelike!  BWUAAHAHAHAHAHA!

The CEWP allows us to use javascript, remember?  With fiddler, we* found out that the “w” parameter functions like a where clause.  So we* can put all that stuff together so it looks like this:
function DoWildPeopleSearch()
{
  var url = "http://mega/Search.aspx?w=CONTAINS(%22urn:schemas-microsoft-com:sharepoint:portal:profile:AccountName%22,%20'%22__searchterm__*%22')%20OR%20CONTAINS(%22urn:schemas-microsoft-com:sharepoint:portal:profile:FirstName%22,%20'%22__searchterm__*%22')%20OR%20CONTAINS(%22urn:schemas-microsoft-com:sharepoint:portal:profile:LastName%22,%20'%22__searchterm__*%22')%20OR%20CONTAINS(%22urn:schemas-microsoft-com:sharepoint:portal:profile:PreferredName%22,%20'%22__searchterm__*%22')%20AND%20(%22DAV:contentclass%22='urn:content-class:SPSPeople')";
url = url.replace(/__searchterm__/g, document.all["txtWildPeopleFinder"].value);
window.location=url;
}

(you would replace “mega” with your portal name)

See what we’re* doing?  We’re* making a url that consists of referencing the Search.aspx and then giving it a “where” clause (aka the “w” parameter).  We* look to see if the AccountName, FirstName, LastName *or* PreferredName contains the phrase entered.  Oh, and we* also say *AND* the class has to be SPSPeople, which is the class of objects in the Profile Database.

The rest of the CEWP is visible in the exported .dwp file that I’ll make available to you all.

Wildcard People Finder Web Part

Basically you can download this and import it onto one of your SharePoint pages and try it out.   Note that you WILL need to edit it to put in your portal server’s name where “mega” is.  Just go to Modify Web Part –> View HTML Source and make your changes. 

Well, this concludes Part 1.  I’ll put the document search section in another post for Part 2.  It was a little trickier because instead of just making a where clause, we* needed to reverse engineer more of the search form so we* could put in source, document types and a date search along with keywords:

So in that entry I’ll likely detail how we* reverse engineered the form. 

* And by “we” I mean Matt did the work and I watched.  And ate some breakfast.  It was good (the breakfast).