The SharingPoint

Pinned: New URL for The SharingPoint Blog

2007-06-09T15:56:00.000-07:00

It seems as if many people are still not aware that this blog has moved. So, for all of you that still use this address and wonder why I haven't posted in, like, forever, head on over to http://www.binarywave.com/blogs/eshupps for the latest SharingPoint goodness. For those that use the FeedBurner subscription, no worries - it has already been updated.

Securing Application Pages in SharePoint 2007

2007-05-04T09:14:00.000-07:00

Anonymous security in SharePoint 2007 is more of an art than an exact science, it seems. Although drastically improved from 2003, there are still some gaps in the security model which need to be plugged (and some that need to be opened) for public-facing SharePoint sites. One of the most glaring examples is the List View application page (12\TEMPLATE\LAYOUTS\viewlsts.aspx) which is accessible by every user with read permissions. While not technically a security risk - there isn't much a user can do from this page without sufficient access rights - it may expose more information to anonymous users than is acceptable.

To work around this issue, add code to the individual application page(s) to check if the user is authenticated and, if not, redirect the user to the Access Denied page. Insert the following script at the top of the page (before or after the page declarations and registrations):

< runat="server">
protected void Page_PreInit(object sender, EventArgs e)
{
try
{ string sUserName = SPContext.Current.Web.CurrentUser.LoginName; }
catch
{ this.Response.Redirect("/_layouts/accessdenied.aspx"); }
}
< / script >

The above code attempts to assign the user login name to a string variable. If the operation fails, which it will if the user is not authenticated, the catch statement redirects the user to the default access denied page. Once the code is placed on a page in the /_layouts directory, it will effectively be hidden from anonymous users.

Anonymous Search Results in WSS v3

2007-05-04T09:13:00.000-07:00

When configuring WSS v3 (2007) for a public facing web site there are a number of steps to take to insure anonymous users don't have access to areas they shouldn't - removing default lists, modifying application pages to hide pulic views, locking down mysites, etc. - but there is one page that is absolutely necessary for everyone to access: osssearchresults.aspx. This page presents the list of search results and is the de facto target location for WSS search controls.

By default, viewing this page requires a user to be authenticated to the server. This can create a problem when your site definition includes the basic search control as it will attempt to render all search results on this page. To remedy this situation, locate the following text at the top of the file (inside the < % @ Page ... /> declaration) and remove it:

Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase"

This setting determines the inheritance of the page from the generic application page base class; however, it is not required for the page to function. Anonymous uers will be able to view the page without having to login and search results will continue to be security trimmed so users without proper permissions will be unable to view restricted items.

SharePoint 2007 RSS Aggregator Web Part

2007-05-03T08:43:00.000-07:00

One of the most common requirements we have these days is to display RSS feeds on WSS/MOSS sites inside of a web part. Most users want the ability to see just a list of article links, sorted by date, from multiple feed sources - a collection of technology blogs or all the official SharePoint blogs, for example.

There are several free utilities for performing RSS aggregation in SharePoint - inlcuding those that come out of the box with 2007 - but none of them work the way that I needed them to (in fact, I couldn't get the included web parts to work at all in WSS). So I put together a basic RSS Aggregation web part that fits the bill.

The functionality is really quite simple - supply the web part with a semi-colon delimited list of feed URL's, set a few parameters (like number of listings per feed, total number of listings, alternate stylesheet, etc.) and drop it onto a page. The web part will display a list of links from each feed source sorted by publish date in descending order. The formatting is controlled by a set of base and alternate styles that can be included in custom stylesheet or integrated with your base site definition styles.

You can download the RssAggregator web part here: http://www.binarywave.com/products/downloads/Free%20Utilities/BinaryWave.RssAggregator.zip. The zip file contains the Visual Studio 2005 solution with full source code (written in C#) and a readme file with setup and configuration instructions. Post any issues or questions as comments to http://www.binarywave.com/blogs/eshupps/Lists/Posts/Post.aspx?ID=3.

Note: I discovered while putting this together that there are quite a few differing feed formats depending on which source you are trying to access. Most RSS 2.0 and ATOM feeds should work but you may need to tweak the XML parsing methods in the source code if you are referencing a feed that uses non-standard or custom formatting in the source XML. If you do make modifications, please post them so everyone can benefit from your changes.

The SharingPoint Has A New Home!

2007-05-03T08:40:00.000-07:00

Now that we've completed the changeover from The eGroup to BinaryWave, this blog will be moving onto our new SharePoint 2007 servers. The new url will be http://www.binarywave.com/blogs/eshupps. For the near future, I will continue to cross-post as I move old content over and get the archives up to snuff (is there anyone out there who has written a utility to move Blogger content to SharePoint? I REALLY don't want to write that myself...).

For those of you that use the FeedBurner RSS link that will be redirected to the new blog address. Any troubles, post a comment and we'll figure it out.

Colligo Contributor v2.0 Review

2007-04-11T05:36:00.000-07:00

Part of our practice methodology at The eGroup/BinaryWave is to use SharePoint Team Sites to manage all of our projects - time tracking, project milestones, tasks, issues, bug tracking, project documents, deliverables, etc. - are all contained in SharePoint lists. This has several advantages, primarily complete project visibility for our customers, and secondarily, the capability for our staff to work remotely from any location. Beyond that, it also does an excellent job of demonstrating the capabilities of the platform to new customers and provides their project team with some informal on-the-job training.

This arrangement does, however, provide some challenges for frequent travelers such as myself. As I am often in transit from one location to another (usually across the Atlantic) it is commonplace to be without Internet connectivity for long periods of time. This makes it quite difficult to update project-related information, as I am unable to gain access to our SharePoint servers, a major roadblock in my role as project manager. To compensate, I had been relying upon a cobbled-together mish-mash of local files, Outlook folders, and a bit of slapdash code to keep things in synch which, to be honest, wasn't working very well at all.

Enter Contributor from Colligo. A month or so ago the folks from Colligo invited me to test drive version 2.0 of their Contributor product. Billed as an offline client for SharePoint, I had assumed that it's primary purpose would be to keep files in sync between my local folders and SharePoint document libraries. A fine utility, to be sure, but my experience with similar products was that they did a decent job of moving files back and forth but completely lacked any support for SharePoint lists, which is where I do the majority of my work.

I admit that I was pleasantly surprised by the product's capabilities in this regard. To set up Colligo to work with SharePoint, you first supply the URL of the site and your login credentials. The product then downloads the site contents and I was encouraged to see that list information was being collected along with document libraries. Once the content has been collected, the application presents the site information using the same basic layout as a WSS v3 Team Site - lists and libraries organized on the left, list contents on the right, with the same WSS list icon, headings, and breadcrumb at the top.

Choosing to duplicate the SharePoint interface was an excellent decision - the experience of interacting with the list contents is nearly identical to that of SharePoint's web GUI. Say what you will of Microsoft's design, at least the consistency between the two products means there is no learning curve to overcome - anyone who has worked with a SharePoint list will be immediately productive within Contributor. Switching views, uploading documents, sorting columns, and creating new list items is natural and intuitive. Entering a new item in a list brings up a dialog that contains all the list columns (including choice, lookup, and calculated columns) and which looks almost identical to the built-in SharePoint forms.

After modifying or updating the list contents, you can manually synchronize one or more sites to commit your changes. Alternatively, you can leave Contributor running the background and it will synchronize automatically (you can enable/disable this functionality by right-clicking on the synchronization message in the status bar but I was unable to find any way to modify the automatic synchronization interval).

Naturally, being an offline client, there are a few limitations. You cannot create new views from within Contributor; likewise, it is not possible to alter the list structure (add or remove columns, change column types, etc.) while offline. I also noticed that the list views, which do a good job of display grouping, filtering and summary selections, do not display column totals; that is, if you have applied a total parameter to a list (i.e. SUM the Hours column) the values for this calculation are not displayed.

The pricing for Contributor affordable for both individual and corporate users. At $125 per seat, it's hard to argue with the price/performance equation for this product. The time saved in lost productivity on one cross-country flight pays for the license several times over.

Overall, I think the Colligo team has done an excellent job with version 2.0 of Contributor. I use it exclusively to update list content while on the road, letting it synchronize all of my changes the next time I'm connected to the Internet. This has allowed me to be more productive - especially when flying - and I often use when I am connected as I prefer the WinForms experience over the browser-based approach. If you travel often, or have limited connectivity (i.e. dial-up or second-generation WWAN) and need to interact with SharePoint lists, Contributor may be the answer you've been looking for.

Visit Colligo's web site for more information. A free trial of Contributor 2.0 can be downloaded here.

CORRECTION: The automatic synchronization setting can be adjustd by modifying the followig registry value: HKEY_LOCAL_MACHINE\Software\ColligoOfflineClient\Synchronization\ PeriodicSyncInterval. This key determines the number of minutes between sync attempts - the minimum value is 15 and the default is 30.

The Trials and Tribulations of Being Your Own Boss

2007-04-06T08:10:00.000-07:00

Sometimes you've just got to stop and post something because it makes you smile. Fellow SharePointer Extraordinaire Heather Solomon recently decided to take the plunge and strike out on her own as an independent consultant. Earlier this week she put up a post about how little time she's had since taking The Big Step. It brought a smile to my face as people are always asking me why I don't post more and work less, why it takes so long to return emails, why don't I do more speaking engagements, etc. Welcome to the gotta-get-the-project-done-no-time-to-chat-why-doesn't-my-phone-stop-ringing-my-God-is-it-midnight-already-where-are-my-slides-for-tomorrow-did-I-get-that-invoice-out-when-do-I-get-paid? club, Heather!

Now, if I can just find a way to sabotage her email for a day so I can get her to work on some projects for MY clients... :-)

UK SharePoint User Group Meeting in Manchester April 11th

2007-04-02T06:42:00.000-07:00

The first UK user group meeting in Manchester will be held on April 11th at TSG. Nick Swan, whose travels for community meetings might actually come close my own air miles, will open the session with an intro on WSS v3, followed by some in-depth info on branding and customization. As this is the first meeting in Manchester, show Nick some SharePoint love by showing up en masse (you should be recovered from the big Manchester United match by then, right?).

Click here for info and directions.

Source Code for Hosting User Controls in Web Parts

2007-04-02T06:24:00.000-07:00

Every .NET developer who has come anywhere near SharePoint development has, at one time or another, seen, heard of, or used Jan Tielens' SmartPart. It's a great control and very effective for rapid application development within SharePoint - no need to learn web part coding, just whip up a quick user control and off you go.

We do a great deal of SharePoint user control development in our shop, for several reasons: 1) when you work on billable time, clients want the fastest, most effective solution to a problem not some esoteric argument on what is 'pure' SharePoint development and what is not, 2) It's easier to hire and get new SharePoint developers up to speed using .NET controls they are already familiar with, 3) it's far easier to turn over user controls to our clients for future code maintenance than try to give them a crash course in web part development, and 4) I don't know about you but I have absolutely no interest in hand-coding UI elements that I could otherwise drag-and-drop in the IDE (but then, I'm known to be a lazy programmer, so take that for what it's worth).

Because of this, we have developed our own web part wrapper for hosting user controls. Similar to the SmartPart, it's designed to be a low overhead control that can be deployed for rapid development scenarios but we needed a bit more flexibility than the SmartPart offers. We've been using it for quite a while and have had great success with it. We're releasing the source code to the community so everyone can do the same and also to see what kind of improvements and enhancements all you smart coders out there can come up with.

If you're looking for a way to host user controls in SharePoint and you would rather write and own the code yourself than use a third-party control, give it a try. Sean Skinner has posted the code over on his blog for you to download. Take it, make it your own, and let us know what kind of cool stuff you do with it.

Direct any questions to either Sean or myself via comments on these posts so everyone can participate in the discussion.

Enjoy!

UK User Group Meeting in Glasgow, Scotland March 28th

2007-03-24T14:52:00.000-07:00

Steve Smith of Combined Knowledge is organizing an informal UK User Group meeting in Glasgow, Scotland on March 28th. If you are in the area, make plans to attend and support the growing UK SharePoint community. After all, there's beer and food involved - can't miss out on that! Go here for more information.

BTW, the User Group meeting in London on the 22nd was an excellent affair. Tip o' the hat to Riaz Ahmed for doing a bang-up job presenting a Search deep-dive and accessibility overview (Riaz, if you're out there, post a comment with your blog URL so I can link you up). More than 75 people showed up (although how many were actually there for the free beer and pizza is impossible to determine). C'mon Dallas, we've some catching up to do - the UK gang is making us look bad!

SharePoint User Group Meeting in London March 22nd

2007-03-21T00:45:00.000-07:00

Just a quick reminder to all UK SharePointers that the user group meeting is this Thursday, March 22nd, at LBi in London. Go here for more information.

In case you've never attended, the UK meetings are some of the best user group gatherings I've ever been to (and I've been to many in my time). Nick Swan does a great job organizing the event, the participation is high (200+ attendees at the last meeting in February), and the content is excellent. If you live or work in the UK and SharePoint is our thing (why else would you be reading this blog???), I highly recommend attending. And be sure to say "Hullo!" when you arrive - I'm easy to spot, just look above the crowd for the 6'5" Texan wandering about ;-)

WSS v3 Drop-Down Menus in Team Sites

2007-02-26T20:01:00.001-08:00

While working with some custom site definitions based on the built-in STS (Team Site) definition I came across an annoying navigation issue that derailed me for a couple of hours. It turns out the the drop-down functionality in the top navigation bar, which works perfectly well in the Publishing and Collaboration Portal definitions, is disabled in the Team Site definition. After digging around in the object model for a while and trying a few different combinations, I found the solution in the menu settings contained within the default master page.

To enable drop-down menu functionality, locate the following block of code in the Default.Master page (/_catalog/masterpage/default.master in the site collection or \12\Template\Global\default.master on the file system):

< asp:SiteMapDataSource
ShowStartingNode="False"
SiteMapProvider="SPNavigationProvider"
id="topSiteMap"
runat="server"
StartingNodeUrl="sid:1002" / >

This sets the data source for the menu control and its associated parameters. Each Site Map Provider is defined in the < Providers > section of web.config. The SPNavigationProvider entry looks like this:

< add name="SPNavigationProvider" type="Microsoft.SharePoint.Navigation.SPNavigationProvider, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" / >

If you locate this entry in web.config you will notice another entry for "SPSiteMapProvider" immediately below it. After much trial and error I discovered that this is the data source that is required for the drop-down menus. To enable it, change the SiteMapDataSource settings in default.master (or your custom master page) to the following:

<asp:SiteMapDataSource
ShowStartingNode="True"
SiteMapProvider="SPSiteMapProvider"
id="topSiteMap"
runat="server" />

The navigation menu will now use the SPSiteMapProvider data source which contains all the nodes in the current site collection. Depending upon your requirements, you may also wish to modify the settings for the default number of static and dynamic levels (flyouts) the navigation control displays. To do that, adjust the following settings within the < SharePoint.AspMenu / > control:

StaticDisplayLevels="2"
MaximumDynamicDisplayLevels="1"

Adjusting these values up or down will increase or decrease the number of levels. Be advised that setting the levels to a higher value may impact performance, as the control will need to fetch the relevant information from the database and build the complete menu structure before the page can finish loading.

Multilingual Scenarios

2007-02-17T14:22:00.001-08:00

During the European SharePoint Conference this week I spent some time in a workgroup focused on multilingual scenarios in SharePoint and talked a great deal about these issues with other attendees. As you may already be aware, Microsoft's solution for portals supporting multiple languages is Site Variations, a process that allows for content duplication between source and target sites and automatic redirection based on browser localization settings.

Essentially, Variations act as an advanced form of replication. A publishing site is created and assigned as the source (the base language is irrelevant). Whenever a subsite is created, the administrator selects the site language pack and localization (such as US or UK English) and the site is then provisioned as a target. Whenever content in publishing controls on the source site is modified, the content is replicated to the target sites and, once approved, published for viewing.

While this is a good first step, there are a number of shortcomings to the Variations model. For one, it only applies to content in publishing controls - no lists, web parts, or other content is replicated. In addition, there is no translation performed during the replication process - it is incumbent upon a human being to at some point perform content translation into the target language. Finally, it does not provide a single portal - by which I mean a single, unified URL - to be presented in multiple languages; visitors are simply redirected to a target site (for example, from www.example.com to www.example.com/en) if one exists that matches their localization settings; if not, no redirection takes place.

In the multilingual working group we identified these as the top three items of concern out of a list of maybe ten or eleven issues (including search optimization, metadata translation, post-provisioning language reassignment, and more). From this, the group formulated some ideas on how to introduce features in the next version, or provide add-on solutions in the interim, to address these problems. As this is an important area of concern for our customers, we are giving serious consideration to developing our own suite of tools and utilities for multilingual portals. Before we go down this path, though, we need more information from the SharePoint community. We'd like to know how you are dealing with multilingual issues, what your top pain points are, and what form you'd like to see potential solutions take (web parts, custom site definitions, a packaged set of features, etc.). So talk to me - post some feedback (in the language of your choice, of course) and let me know what we can do to make your (multilingual) life easier.

European SharePoint Conference Final Thoughts

2007-02-15T03:17:00.001-08:00

The European SharePoint Conference in Berlin concluded with another full day of presentations. Previous commitments had me traveling back to the UK on Wednesday so I can't give a recap of day three (see here and here for a rundown on days one and two), which is really a shame as Ben Robb was scheduled to give a couple of good presentations on Internet-facing web sites and profiling/personalization that I would have liked to have attended. So instead here are my final thoughts on the conference as a whole.

Organization

The overall event organization was quite good. Check-in was a breeze, there were big signs in each area detailing the day's events, and if you got a bit lost all you had to do was grab hold of one of the ubiquitous orange-shirted emissaries to point you in the right direction. The sessions were a bit spread out due to the configuration of the facilities but you had plenty of time between sessions to wander to and fro and numerous opportunities to grab some refreshments on the way. There were some glitches with invoicing and payment that had a few people (including myself) scrambling a bit but I understand that was due to some EMEA regulations regarding credit-card bookings that were out of the organizer's control.

Content

I was quite pleased by the content presented in the break-out sessions. There was a distinct division between developer, IT and partner sessions, and quite a bit to choose from in each track. Naturally, the developers wanted to see more code and the IT people wanted more numbers, but that's always how it is. Aside from a few last-minute speaker substitutions most of it went off without a hitch.

Venue

The Hotel Estrel is a nice facility with lots of space but it wasn't laid out that well, especially for the vendor booths, forcing participants to walk back and forth across the hotel quite a bit. Guest rooms booked up quickly so a lot of people stayed at hotels scattered around Berlin (I chose the Upstalsboom Friedrichshain which was quite nice but, like everywhere else, had no WiFi to speak of). The staff were very good, exhibiting the renowned German efficiency - you could barely set an empty plate down before someone came and whisked it away. The food was mostly standard conference fair but I must say that the sweets were top notch - I had way more of them than I should have.

Speakers

There was quite a good mix of speakers for this event, even though some, like Patrick Tisseghem and Ben Robb, presented multiple sessions (which is fine by me because I like listening to them both). Speakers seemed to be matched well to their topics and generally provided good domain knowledge. The slide decks were fairly uniform (excepting Patrick, who seems to be as addicted to PowerPoint SmartArt as he is to Belgian beer) but there were lots of demos and code samples to keep things interesting. In fact, it will be a bit of a letdown when we get the final slide decks as most of the good content was in the demos.

Vendors

There was in impressive number of vendors at the event from all over Europe as well as the UK and America. Some were promoting general offerings - like HP and AMD - but there were a large number of SharePoint-specific solution providers in attendance. I didn't hang around the booths much so I don't know how good their conversion ratios were but there were a lot of people carrying literature and chatting up the vendors. The best venue for them was probably the vendor breakout sessions, of which there were quite a few, and which seemed to have pretty good attendance.

Participation

Quite frankly, I was amazed at the turnout for this event. Official figures were somewhere north of 2,300 participants. Considering all the other products that Microsoft has launched in the last year and the fact that SharePoint is marketed as part of the overall Office product line, this is really and astounding level of interest. If there were any doubts that SharePoint should be taken seriously this should dispel them entirely.

Conclusion

Like any event of this type, it wasn't perfect, but I think overall I'd give it a B+. The location was a bit difficult to reach for a lot of attendees (Paris, London or Rome would have been easier) but it wasn't too bad. The organization and content were good and the participation was excellent. I hope that next year will see an even greater number of attendees and more focused breakout sessions (and, of course, more in-depth developer content).

European SharePoint Conference, Day 2

2007-02-14T14:55:00.001-08:00

After the previous night's entertainment we were all a bit bleary eyed come Tuesday morning (I probably looked the worst as I stayed up late blogging and then fought with the worst pillows ever created in the history of mankind in a losing battle for even a few hours of sleep). But with a healthy dose of coffee and a can-do attitude (or, more accurately, an I'm-awake-so-I-may-as-well-make-the-best-of-it attitude) I dived back into the conference.

Designing, Deploying and Managing Workflow in SharePoint Sites (Christian Stark)

The toughest part of a conference like this is choosing which sessions to attend. There were a large number of presentations from partners and ISV's that I would have liked to have taken in but I concentrated on the Development track as best I could since that is our core business. Unfortunately, this presentation was just a click-n-show overview with no code and I think I dozed off somewhere in the middle. From the parts I do remember, I recall Christian pointing out that while you can author workflows for WSS sites you have to buy MOSS to get any built-in workflows or workflow templates (I wasn't aware of that). He also said that there will be a workflow SDK coming out soon that will have a bunch of workflow templates included with it. Hallelujah!

I realized later, after talking with Dr. Ulrich Knechtel of AMD, that I should have gone to his presentation about their search optimization project with Microsoft. The two companies are teaming up to create hardware/software configurations optimized for large-scale search optimization. If you've ever worked with search in a big deployment you know how resource-intensive this process can be so this new initiative looks very promising (post a comment if you want more information - they're looking for customer projects that might serve as good POC's).

Developing Visual Studio Workflows and Activities for SharePoint Sites (Steve Heaney)

Now this is what I came for. Steve got down and dirty and showed us how to code up workflows from scratch in Visual Studio. It was one of the most amazing demos I've ever seen - Steve hand-coded a five step WF, including two custom InfoPath forms, in a half-hour, without making a single mistake. In fact, he never even used Intellisense - just whipped out some classes, slapped in some methods, banged the code in and pressed F5. Build succeeded the first time! Unbelievable. Obviously, Steve had done this presentation many times before but it was still bloody impressive.

If you haven't played with it yet, the workflow designer in VS 2005 is really quite good. There are a bunch of built-in workflow objects that you can drop in from the toolbox and creating your own is almost as simple as whipping up a Visio diagram. What Steve didn't cover (due only to time restrictions, I think) was coding custom actions and activities, which is the real meat of VS and WF. In most cases, designers will create the workflows in SharePoint Designer with custom activities supplied by developers, as the VS method is much too complex for your average front-end person. That said, you can do a lot with it and it's very flexible and extensible.

Capacity and Performance Planning (Steve Smith)

The Combined Knowledge booth was the unofficial UK gathering point at the conference. We joked about hanging a Union Jack from one of the columns and I think we would have done it had anyone thought to bring one. Steve Smith, MVP with Combined Knowledge, gave several presentations but this was the first I one I could fit into my agenda. Steve derived a great deal of his content from Joel Oleson's blog and put up some useful figures from this post. Although I dispute some of his assumptions (he uses a 10% utilization baseline for concurrency which I believe is way too low - but it really depends on how each portal is used) and conclusions (40% of latency issues are at the client? I really don't think so - better check those capture stats one more time, mate), Steve did quite a good job painting a realistic picture of scalability issues and areas to look for performance issues.

At one point, Steve illustrated the issues regarding list rendering as it relates to item count by showing a line graph (shaped like a hockey-stick) of the per-transaction completion time of a document add operation in a library. The more documents you add (I think the tipping point was around 2,000) the worse the performance gets - way worse, in fact. I couldn't have asked for a better visual describing the limitations of using the object model for repetitive operations (he didn't say but I'll bet my hat they used the OM to do it). I can't wait to get my hands on that slide so I can demonstrate the stark difference in performance when executing the exact same operation using web services or FrontPage RPC's.

Speaking of slides, Steve hit us with so many statistics that I can't possibly hope to reproduce them all here (and I was scribbling like a madman so I probably got most of them wrong anyway). As soon as Steve uploads the presentation I'll post them all here - they really are important data points to consider when planning your farm deployment and/or expansion. For example, one thing that never occurred to me when troubleshooting performance is the relationship between your MOSS server farm and Active Directory. If you have several thousand users on a portal the new security-trimming features require a lot of authentication procedures; enough to overload that poor old AD box sitting all by itself in a forgotten corner of the data center. One more place to look when your users suddenly start complaining about how long it takes to login to SharePoint in the morning...

Building and Branding SharePoint Sites Using New Web Content (Arpan Shah)

Ok, so this one really didn't include much development content (unless you consider SharePoint Designer to be a development tool) but it was good nonetheless. Unfortunately for Arpan, he had just returned from vacation and it seemed like parts of his demo were still on holiday - Designer didn't want to cooperate and his MOSS site was a bit flaky but Arpan's an excellent presenter and what he couldn't show he explained rather well. He did a fair job introducing site variations to the audience but it wa really only a warmup for the next Dev session.

Multilingual Portal and Public-Facing Web Applications (Aku Heikkerö)

It was fitting (and somewhat amusing) that the presenter for Multilingual solutions had a Finnish accent so heavy I could barely understand him. Where's that universal translator from the Tardis when I need one? In any event, you should know by now that this is an important area of interest for me, and Aku did a good job of digging into the ins and outs of site variations. He was also very explicit on what variations can and can't do (and even though they can do some good things they are just a small step towards solving this problem). One thing I didn't know (just because I haven't had time to play with the new MySites much) is that users can now pick the language they want to see their MySite in. That's very cool. After the presentation I mapped out some ideas on how to improve site variations to make them more usable in real-world scenarios (more on this in a future post) with my new friend Razvan-Petru Radu from Luxembourg. And no, in case you're still wondering from yesterday, no word yet on that Redneck language pack for MOSS.

Shared Emotions

I don't think I was the only one who thought this was an odd name for the after-conference party. Even more odd was being shipped by bus halfway across Berlin to a big warehouse on some island for a dinner party when we had a huge hall at our disposal right there at the Estrel (we all fit in there the night before, didn't we?). Thankfully, there were no celebrity impersonators, just a really lukewarm jazz band. Personally, I would have liked to see the guy who did the Louis Armstrong bit on Monday night do another set just to liven things up (I poke fun at the lookalike entertainers but they really were very talented). Rob Gray from Microsoft UK managed to secure the upstairs lounge for our lot so we enjoyed feeling superior to everyone else from on high. The food was spectacular, especially if you are a fan of creme brulee, and the beer and wine were free. Can't beat that!

Internet Access

Let's tell the truth here - trying to get to the Internet in Berlin was like trying to find a place to stand in the conference common areas where someone wasn't smoking. First of all, there was no free WiFi at the convention center. Only hotel guests could access the WiFi and they had to pay for it - not even the conference speakers had access to the Internet. Think about that for a second - a Microsoft conference about a purely browser-based product and no WiFi? Uh, pardon me for pointing out the elephant in the middle of the room, that's just plain ridiculous. My hotel and the airport were no better, with either weak signals that were all but useless or pay-as-you-go services that wanted upwards of 10 euros for 30 minutes of blissful connectivity. I know the Germans pride themselves on their efficiency but they've got a lot to learn from us Yanks on this score.

Notes on Berlin

It's a shame really that I didn't get to see much of Berlin at all on this trip. Being a history buff I could probably spend days wandering around the museums and such. I did learn that the airport that I flew into (Flughafen Tempelhof) was central to the Berlin Airlift operation and used to be a US Air Force base (it was the Americans, in fact, who built the current concrete runways). There's a statue out front dedicated to the US and British pilots who died during that operation - very cool. East Berlin is still a bit grim but there is a fair amount of new construction intermixed with some really old structures. There's a strange statue on the river of three figures fighting or wrestling - I'm not sure which - that I never did figure out and none of the cab driver spoke enough English to explain it to me. The real travesty of this visit was that I had precious little time to sample any German beer. That's almost a crime, I think, to visit Berlin and never set foot in a Biergarten.

European SharePoint Conference, Day 1

2007-02-12T16:52:00.001-08:00

Today was the first day of the European (EMEA) SharePoint Conference in Berlin, Germany. As we have recently expanded into the UK, we are now officially a 'global' company (there's a scary thought for you) so we took this opportunity to join our mates from jolly ol' England on a jaunt across the Old Country. I have to say that I am quite impressed by the overall experience - if there were any doubts that SharePoint is a serious application around the world, let them be dispelled here and now. With more than 2,300 attendees (that's nearly twice as many as we managed to cobble together in the States last year) from 40 countries and 90 partners and vendors, it was quite a show. Read on for a summary of the day's events.

BTW, Southwest could learn a few things from SN Brussels Airlines. Like, how about some free chocolates on each trip instead of crappy peanuts, eh Mr. Kelleher?

Opening/Keynote

The Microsoft team kicked off the conference with a five-minute introduction in German (to the delight of the local audience, I might add) which left most of us scratching our heads and saying 'Was is das?'. The 'Wow is Now' video has long since jumped the shark, but the first speakers were energetic enough to make up for it. The catchphrase of the day was 'Ich bin ein SharePointer'. Say that a few times after a couple of Hefeweizen!

Derek Burney

There were quite a few Redmondites around - especially on stage and in the ubiquitous orange speaker shirts - and Derek Burney was first up (with an able assist from Mike Fitzmaurice). He laid some good numbers on us, like license count now exceeding 80 million worldwide and the official size of the internal Microsoft SharePoint deployment: 325,000 portals, sites and subsites comprising more than 12TB of data (who gets to back that up, I wonder?). It was interesting to note that on his slide promoting 'major' companies who had adopted SharePoint, three of the ten are based in Dallas :-)

Mike revealed publicly what had heretofore been confidential, so I can now tell you that sometime next month MS will unveil the official SharePoint Community Portal. Lawrence Liu gave us a rundown of this last week at the UK SharePoint User Group meeting (what, you weren't there?) and it's plenty slick. Just a beta right now but it will be live soon.

They closed with the most ridiculous commercial I've ever seen - a takeoff on those Total cereal ads where they claim that everything and the kitchen sink is in 'just one bowl'. It came complete with a corny jingle and sleazy used-car-salesman actor. Ok, I get the message, but was this really a good use of marketing dollars? Really?

Patrick Tisseghem, Part Eins

I always enjoying listening to Patrick as 1) he knows his stuff, and 2) he's a good presenter. And you just gotta like a guy whose every demo has something to do with beer. Patrick gave the standard rundown on using the object model, talked about garbage collection and good coding practices, and highlighted a bit about working with web services. He covered impersonation pretty well, which I think was lost on most everyone present, and even talked a bit about CAML and SPSiteDataQuery. Although he gave an explicit warning about using the DataQuery object to collect list data instead of looping through the SPListCollection, he did not voice similar concerns about using the object model to loop through SPWeb objects. In fact, he showed us how to do it (albeit briefly) and moved quickly past it.

I suppose I'm destined to be the lone voice in the wilderness on this issue, so let me state it once again in case anyone missed it the first thousand times - DON'T DO THIS! EVER! Unless you know for a fact that you'll never have more than a hundred or so sites in a site collection, this is bad, bad, bad. The overhead of GetSubwebsForCurrentUser and its equivalent(s) is tremendous and should be avoided like the plague. I know that's how it's shown in the SDK but you don't believe everything you read, do you?

Multilingual Working Group

Aside from the bizarre evening entertainment (see below) this was the highlight of the day. We don't think much about it in the States but this is a real pain point for many customers, especially throughout Europe where they often have to support three, four, five or a half-dozen languages at once. Hats off to Microsoft for realizing the severity of the issue and soliciting feedback and advice from partners and users. A couple of partners and myself gave 'em an earful for an hour (I also harped on Lawrence about this last week, so if you're reading this Al, that one's for you!). We came out with some good ideas and even a few suggestions for the workgroup sponsors to take back to Microsoft. We also agreed that since C# seems to be a universal language we are all now adding it to our resumes (CV's) immediately. And no, in case you're wondering, there is no Redneck Language Pack forthcoming in this or any future release, so y'all will have to just go on scratchin' yer heads at my vocabillary.

Content Types and Metadata

Good topic, wrong audience. This was supposed to be on the developer track and although Dustin Friesenhahn gave a good presentation it was all foam and no beer. There were only a couple of slides that even showed a smattering of code - the rest was all point and click. Nice for the IT guys but not what we hardcore OM types were looking for. General disappointment was expressed by all.

Patrick Tisseghem, Part Zwei

After that letdown, we needed some real code to perk us up, and Patrick didn't let us down. Some genius assigned him the topic of Templates, Definitions and Solution Deployment and only gave him an hour - now that's just plain wrong. I could talk for an entire day on any one of those subjects and I don't have all of Patrick's demos and SmartArt. He did an admirable job walking the group through custom site definitions and deployment - not an easy topic even for intermediate coders. Lots of great code samples and the ever-present Beer Team site.

Dinner and Entertainment

The Hotel Estrel Convention Center is reminiscent of Vegas-style auditoriums - lots of multimedia and light shows. After Patrick's final presentation a swarm of worker bees descended upon the room and cleared more chairs in five minutes than were on the entire deck of the Titanic. There's something to be said for German efficiency. While we all wandered off for a beer or two (konnte ich Schofferhofer bitte?) they turned out the 'rounds and we piled back in for some free victuals. I can't say much for the food - it was typical bland conference style fare meant not to offend anyone - but when the lights went down after the meal things go interesting.

Turns out the Estrel is the home of a popular Vegas-style musical review called Stars on Stage. Before we knew what was happening, a pre-Bobby Brown Whitney Houston was belting 'em out on stage, complete with scenes form her music videos and the requisite clips from Bodyguard during 'I Will Always Love You' on the big screens. Without a chance to catch our breath (or keep from falling over with laughter) were were hit in succession with Madonna, Boy George, Louis Armstrong, Tina Turner (who looked awfully like Whitney in a different wig) and finally, as you would expect, Elvis himself. I'll give 'em this - they were pretty damn good, especially considering they didn't have the best acoustics to work with and a stage with no Vegas flair (but some might fine-looking backup dancers). Louis Armstrong was simply amazing - right down to his facial expressions and the gap in his front teeth, this guy has it down, you dig? And all of this with a gigantic Office SharePoint Server 2007 sign in the background. Now don't that beat all?

So that's a wrap for day one. I'll post pictures as soon as I can get a reliable WiFi connection (don't even get me started on Internet access over here). And before I collapse for the night, a hearty "Salut!" to my new friends from Romania, Reka and Marius, and "Moien" to David and Razvan from Luxembourg.

Gute Nacht!

Creating a Basic Site Definition in SharePoint 2007

2007-02-02T16:13:00.001-08:00

Creating a site definition from scratch in SharePoint 2007 is no easy task; easier, certainly, than it was in 2003, but in some ways even more complex. Perhaps the most confusing new element to creating site definitions is the use of FEATURES. There are some great articles on what FEATURES are and how to use them (see here, here, and here) so do a little homework before you get started.

Unfortunately, the built-in WSS templates don't use the time-saving and oh-so-handy Publishing features of the portal definitions, so you'll have to create your own definition if you want to apply any customizations beyond basic style overrides. To get you going in the right direction, here's a handy little guide on creating a very basic site definition from scratch. Let's first assume that you want a custom Team Site - nothing fancy, just something you can style and modify without impacting the default definitions.

Begin by performing the same steps you would have done in 2003. Navigate to the \12\Template\SiteTemplates directory (the 60 hive is dead; long live the 12 hive). Copy the 'Sts' folder and rename it - say 'CUSTOMSITE' for this example. Next, find the WEBTEMP.XML folder in \12\Template\1033\Xml. Open it in Notepad and add a new Template node to the end, like so:

< Template Name="CUSTOMSITE" ID="1001" >
< Configuration ID="0" Title="Custom Web Site" Hidden="FALSE" ImageUrl="/_layouts/images/stsprev.png" Description="Customized site definition for My Team Site" DisplayCategory="Collaboration" > < /Configuration >
< /Template >

* Note: The same numbering conventions apply in 2007 as in 2003 - set your Template ID to something greater than 1000 and the first Configuration node should always start with '0'.

Save the file and do an IISRESET at the command prompt. This is all you really need for a basic site definition but, as you will discover if you create a new Site Collection using this new definition and open it in SharePoint Designer, there are some things missing. Some very important things, actually, like the DefaultLayout.aspx page (look in /_catalogs/masterpage and you'll notice that only the default.master page is present). Without DefaultLayout.aspx you'll be able to modify the master page but not the central content area of your site. Oops. What happened?

As I said at the beginning, it's all about the Features. In this case, not only does the ONET.XML file determine what Features are provisioned as part of the site, there are also Features which determine what goes into a site that have nothing to do with the site itself - they are system Features that SharePoint uses when provisioning all sites.

To make sure that your new Site Definition has all the right pieces and parts, navigate to the \12\Template\Features\BaseSiteStapling folder and open BaseSiteStapling.xml in Notepad. It should look something like this:

< Elements xmlns="http://schemas.microsoft.com/sharepoint/">

< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="STS#0" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="STS#2" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="MPS#0" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="MPS#1" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="MPS#2" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="MPS#3" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="MPS#4" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="WIKI#0" / >
< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="BLOG#0" / >
...

Take note of the first child node - it defines a Feature (in this case, the BaseSiteFeatureTitle) to be included with the site identified by the TemplateName setting. Does this setting look familiar? It should, as it's the same as the STS (WSS Team Site) < Template > node in WEBTEMP.XML. The #0 after it refers to a specific < Configuration > child node. Since your new Site Definition needs to behave exactly as the STS definition does, you must create a < FeatureSiteTemplateAssociation > for each Feature that STS is associated with, like so:

< FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="CUSTOMSITE#0" / >

Simply go through BaseSiteStapling.xml and each time you see an ID associated with STS#0 add an entry for CUSTOMSITE. But wait, you're not done. You now have to do the same thing in the PremiumSiteStapling.xml file located in \12\Template\Features\PremiumSiteStapling folder and, if you want the included workflows, do the same in FeatureStapling.xml in \12\Template\Features\StapledWorkflows folder.

Perform another IISRESET and create a new Site Collection based on your custom Site Definition. Now, when you edit the site in SharePoint Designer, you will see all the right files in /_catalogs/masterpage, such as DefaultLayout.aspx, AdvancedSearchLayout.aspx, SearchMain.aspx, etc.

As an aside, you can mimic some of the Publishing functionality of the Portal Site Definitions by create your own Style and Images libraries, uploading your files, and referring to them from your customized master and layout pages by relative URL (such as ../../images/myhomepageimage.gif or ../../styles/custom.css). See this post for information on how to override CORE.CSS using this method.

Overriding Default Stylesheets in SharePoint 2007

2007-02-01T13:27:00.000-08:00

Heather Solomon posted a detailed explanation on her site regarding the inheritance of styles in MOSS; specifically, the various methods for overriding CORE.CSS in master pages and site definitions. After defining the various options, Heather recommends the following for applying custom styles:

My recommendation is to store styles in the master page itself in a set of STYLE tags. If your master page design has variations for assorted subsites, store the CSS differences in a file and reference it via the Master Page settings, or if you need CSS changes for a single page, store it in an HTML file and reference it in a hidden Content Editor Web Part.

I wasn't at all comfortable with this approach, not so much because there is anything wrong with it (there isn't and Heather should get an award for incurring the brain damage required to sort through it all), but mostly because I don't like the idea of SharePoint forcing a default style onto my customized pages, thereby making me jump through hoops to correct a deficiency that never should have been there in the first place. I thought we'd been through this enough with 2003 and the design team would have learned their lesson but apparently not.

So after playing around with a few alternatives, I went old school and found the solution. Instead of using one of the new < SharePoint:CssRegistration / > tags to register your override style in the header, simply place it in a classic ASP < link > tag in the same location, like so:

< link rel="stylesheet" type="text/css" href="../../Style Library/en-us/Core Styles/core_override.css" / >

This procedure will circumvent whatever the parser is doing in the background to throw CORE.CSS into the mix at all the wrong places. The beauty of it is that CORE.CSS is called before your override stylesheet so you can inherit all the default styles and only override the styles you need. Be sure that the relative path is correct for the site definition you are working with. An alternative would be to place your override into the same folder as CORE.CSS and use a fixed path, which would make working with different site definitions much easier, as each master page can point to its own override file (this can also be done programmatically).

UPDATE: As Shane points out in his comments on this post, using the alternate style setting in the site collection settings IS a reliable method for overriding CORE.CSS; however, there are some things you should consider if you are using this approach:

1) The alternate CSS setting is GLOBAl for the site collection. This means that all pages, including _layout pages, will inherit this style. That may work for one implementation and not another; you might want different styles for the Admin pages (my term for all the pages found in _layouts), content pages, or subsites.

2) The Alternate CSS setting applies to all subsites in the collection, making it more difficult to assign those styles programatically. If you want to mix and match styles in your subsites you will have to find a method to override both CORE.CSS AND the alternate style.

3) The alternate setting must be done AFTER the site is provisioned. This obviously won't work for custom site definitions. A better approach would be to put the style in the master page settings, the PlaceHolderAdditionalPageHead, or, as I have suggested, use a <> tag.

SharePoint 2007 and the .NET 2.0 Object Data Source

2007-01-20T18:43:00.000-08:00

One of the smartest SharePoint gurus I know is Sean Skinner. Lucky for me, he was guillable enough to be fooled into coming to work for my company, so now I get to take advantage of all his know-how on a daily basis. Like, for example, when one of our SmartForms apps blew up all over the place, and we couldnt' figure out what in the world was going on, Sean kept at it until he had the answer. From his blog:

You cannot have an Object Data Source running on MOSS and it have a parameter (insert, update or otherwise) with a type of 'object'. This appears to be the type assigned for GUIDs (database fields of type 'unique identifier'). When you do, as soon as I would bind the formview I would get a generic MOSS error page. You know the one, 'A web part is causing a problem....'By changing the type on the parameter to 'string' everything started working...

(BTW, when he refers to ASP:Table elements junking up otherwise working code inside of SharePoint, what he really means to say is "Eric screwed up my perfectly functional code by filling it up with server-side elements that we didn't need". Now you know the rest of the story...)

There'll be a whole lot more where that came from when we get all of our blogs moved over to the new MOSS site so stay tuned - and if you don't read Sean's blog already, you're missing out. Add it to the 'ol blogroll, pronto!

Tag, I'm It!

2007-01-16T12:12:00.000-08:00

I was harboring secretive dreams that the recent spate of tagging would leave me unscathed but my hopes have been shattered. Friend and fellow powerblogger Heather Solomon got me at last. So what are five things that people don't know about me that aren't either a) embarrassing or b) still subject to a statute of limitations? How about these:

My primary intellectual hobby is ancient Egyptian history. I've read dozens of books on the subject, seen every documentary ever created, visited nearly every major museum with an Egyptian exhibit, and can even read and write some hieroglyphs. As an offshoot, I've also studied a tremendous amount of early Judaic and Christian history as well. If you value your sanity, don't ever get caught near the British Museum with me around or you'll end up losing an entire day of your life to my endless chattering about the proper pronunciation of Tutuanhkamun and why I think Zahi Hawass is an idiot. Unfortunately, I've never had an opportunity to visit Egypt in person but it's on my list of first things to do when I eventually take a vacation (yeah, right).
My favorite activity is training and hunting with my Labrador Retriever. If you're not an animal person, you just won't get this, but there is nothing more rewarding than the bond between human and dog when engaged in a singular activity. Cheyenne, my 100-pound black Lab, is an amazing creature - watching her do what she was bred to do is a wonder to my eyes. I spent two years learning about training hunting retrievers before I got her and I trained her myself from the time she was five weeks old. I took a chance and didn't buy her from a breeder (no reason to invest that kind of money if you're not sure of your own skills) but boy did I get lucky - she can hold her own against any of those pedigreed wondermutts you see on TV. One thing I've learned from her that has served me well is that a good dog doesn't need to be trained to work with a person - the person needs to be trained to work with the dog. The dog was born knowing what to do, it's us humans that get things all screwed up. Take that for what it's worth.
I'm part Scottish and part Native American (Mescalero Apache). My mother's family is Scottish down to their kilts. My uncle used to be one of the premier bagpipe instructors in the country and my cousin has played the pipes live for Rod Stewart on several occasions. Our line goes back to one of the oldest highland clans, the Atholl Murray's, and one of our ancestors came over on the Mayflower. My paternal grandmother is full-blooded Apache Indian. Unfortunately, all her birth records were lost in a fire years ago so we can't trace back our heritage on that side. And yes, I can drink me some whisky, in case you were wondering :-)
I play the harmonica. Or, rather, I did, then I gave it up, then I picked it up again, and now I can barely play the thing anymore. I keep threatening to take it up again but the rolled eyes around my house indicate that I may need some serious refresher courses before I'm allowed to blow any riffs around the 'ol campfire.
I used to sell floorcovering. At one point when I was living in California I got burned out on the technology business and went to work selling carpets, wood floors and tile. I did pretty well and actually had a good niche doing custom wood floors and high-end commercial projects. I even learned how to tear it up, install it, do finish work, everything. About as far from high-tech as you can get but at the time that was the whole point. It was fun but I don't think I was cut out for it - I kept finding excuses to play with company's computers and not rearrange my samples on the sales floor. Ah well, once a geek, always a geek!

So there you have it - more than you ever wanted to know about this humble SharePointer. Everyone on my list has already been tagged, so I guess I'm a 'dead end', so to speak. Hey, the chain had to end somewhere, didn't it???

UPDATE: Turns out there are a couple of people who have been flying under the tag radar and need a good one slapped on 'em:

Sean Skinner
Nick Swan

You're it!!!

Happy New Year!

2007-01-02T06:21:00.000-08:00

To all my readers around the world, I want to wish you a safe and prosperous New Year.

First, I'd like to thank everyone who reads and contributes to this blog. I started blogging in 2005 to share my thoughts with other SharePointers and I never dreamed that I'd be collaborating with people all over the world would. Last year more than 23,000 visitors read this blog and more than 60,000 pageviews were generated for readers in more than 20 countries. Sure, Bil and Jan and AC get more traffic but it's not bad for a country boy from Texas.

Second, my apologies to those very same readers for not posting more often in 2006. Business exploded this last year, leaving me with little time to sleep or eat, much less post regularly. I plan to correct that this year by setting (and sticking to) a regular blogging schedule.

Finally, the new year brings new changes. The eGroup started as a one-man SharePoint consultancy but has now grown by leaps and bounds, with some great new team members coming on board, new offices opening in the UK, and lots of other positive developments. To reflect these changes, we'll be changing our name and launching a new site soon (built on MOSS, of course). With more exposure comes more responsibility, so we'll be releasing more products, tools and utilities throughout the year and participating in events and conferencese throughout the US and Europe (I'll finally get a chance to meet many of you face to face for the first time - hoorah!).

As part of these changes, this blog will be moving to our MOSS web farm and off of Blogger. Not that Blogger hasn't done its job but with the new blog templates in MOSS there's just no reason not to switch. The good news is that all of our consultants and developers will be blogging on the new site so there will be lots of fresh new ideas and solutions. Links to all the new blogs and sites will be posted soon.

I look forward to a very exciting 2007.

Happy SharePointing!!!

Looking For A Few Good SharePointers

2006-11-27T18:30:00.000-08:00

It's that time of year again - no, I'm not talking about jolly 'ol Saint Nick, annoying crowds at the mall or an XBox in your stocking (hint, hint), this is even better - The eGroup is hiring! If you've got SharePoint development experience and you're itching to work with a dynamic team of fellow SharePoint-crazy codeslingers, mosey on over to our job postings and see if you fit the bill. No, you won't a free Tesla Roadster and you'll have to bring your own Aeron, but you will get to work on exciting client projects using the latest and greatest Microsoft technologies. Give yourself a Christmas present and tell the boss man you're movin' on up!

UPDATE: UK readers take note - we'll be hiring on your side of the pond in the first quarter of '07. We'll be looking for both experienced and junior SharePoint developers so send in your CV if you'll be in the market for a new gig after the first of the year. In fact, if you're in and about London, drop by the SharePoint UK User Group Meet Up on December 14th (you are a memeber, aren't you?) and introduce yourself (I'll be the only 6'5" Texan in the pub - pretty easy bloke to pick out of a crowd).

SPSiteDataQuery vs. GetListItems

2006-10-23T15:53:00.000-07:00

Mart Muller over at TamTam posted his thoughts about using the new SPSiteDataQuery object in MOSS 2007 to retrieve items in a document library without tripping over the annoying folder limitations of the much-maligned SPQuery class. This is handy method for getting list data via the object model but it also has some limitations and 'gotchas' to be aware of.

First, when retrieving list data, anecdotal tests have shown (and our experience has proven this to be absolutely true) that the object model is best suited for working with smaller data sets within web parts or controls in small to medium traffic environments (~10,000 users). Why is this? Nobody seems to know for sure but I suspect that it has to do with the overhead related to repeatedly calling the core DLL's that are also performing a number of other concurrent tasks (but I could very well be wrong; the cause may be up for debate but the results speak for themselves).

Second, as Maurice Prather and Bil Simser have pointed out here, here and here, all those SPSite and SPWeb objects you're throwing around in your code don't dispose of themselves - you have to handle that yourself (you are disposing of your garbage, aren't you?). Those little guys riding round on the back of the Garbage Collector truck never see those objects so they don't throw 'em on the rubbish pile - leave a few thousand of those things open and your application pool will come to a screeching halt.

Third, you have to keep a careful eye on that ViewFields element (and don't forget to write your query correctly). A blank value will return all the fields that the records have in common but not any fields that have blank or null values - these are omitted from the results. This is important when you're looking for a particular field only to discover it's not there at all - crash goes your code. Pass in a null value and you get the default view (such as AllItems.aspx) which may not contain any of the fields you're looking for. You have to specify ALL of the fields that you want to appear in the results. And, just to keep you on your toes, make sure to use the DisplayName value of the column in each < FieldRef > node and not the Name value (they are often quite different, especially in custom lists).

Finally, remember that object model methods of this type are always subject to the annoying but ever-present impersonation issue. Call SPSiteDataQuery in the wrong user context and you won't get very far. RevertToSelf, anyone?

Personally, I prefer to use the web services GetListItems() method to get items from a list because a) it's faster (I know, you don't believe me, but it's true - someone somewhere did a performance comparison once but I can't seem to find it again. UPDATE: Found it here but there aren't any hard metrics in the post. UPDATE II: Scroll to the bottom of this post for some very basic metrics), b) I have more granular control over user credentials (I can use an admin account to get the items then check the user perms to verify the access level - no impersonation required), c) the data is returned as an XMLNode object, and d) there's no garbage to worry about - once the TCP connection is closed the memory is released. Most importantly, the web services scale well, especially in shared services environments where you may have one portal context accessing list data from another portal context. That being said, I will probably use the SPSiteDataQuery object in one-off web parts where scalability and performance are not an issue because the code is short and sweet - which is an advantage unto itself, now isn't it?

New Article on Custom Master Pages

2006-10-19T07:44:00.000-07:00

I get a lot of questions from readers and clients regarding deployment of custom master pages in MOSS 2007. There are several ways to tackle this problem and here's a very good place to start - Heather Solomon's new article on How to Create and Store Master Pages on the Server for Use with Site Collections. Heather is one of my all-time favorite MVP's (I swear someday I'm not going to be neck-deep in projects during a SharePoint conference and we'll actually meet in person) and if you're not reading her blog on a regular basis then you're missing out. Go check it out and get those custom master pages going.

To < Query > Or Not To < Query >, That Is The CAML Question

2006-10-11T09:39:00.000-07:00

If you do any development using SharePoint's web services you've undoubtedly run across the evil CAML beast rearing it's ugly head to devour your nicely structured markup. For instance, if you invoke GetListItems() to retrieve the column values of each item in a list, you have the option of passing in a CAML query to return specific records or a blank value to get the whole enchilada. The SDK is quite helpful, as it documents how this specific query should look. If, for example, you want a particular record with the title "Yellow", provide the following CAML:

<Query><Where><Eq><FieldRef name="Title"><Value Type="Text">Yellow</Value></Eq></Where></Query>

Simple, no? Well, not quite so simple. Try as you might, this query will never return just those items whose Title column is equal to "Yellow". Instead, the web service will happily ignore your fancy little CAML fragment and give you all the records in the list. Alas, no amount of cursing, head beating, keyboard throwing or foot stomping will make it otherwise. I assure you, I have tried all of those methods, and many more, to no avail. What DOES work is simply removing the <Query> and </Query> tags, like so:

<Where><Eq><FieldRef name="Title"><Value Type="Text">Yellow</Value></Eq></Where>

What's that you say? That's not how the SDK says it should be done? You spent hours searching the newsgroups and nobody once mentioned this little bit of CAML trickery? I feel your pain, my friend, believe me, I do. Were it not for my innate stubbornness and determination to beat SharePoint at it's own game, I would have given up on this vexing problem many moons ago. What can I tell you - CAML is a mysterious creature and we know not it's wild and wily ways. Now go ye forth and slay that noxious Query fiend - or at least stab at it until the next time it bites you on the rear!

MOSS2007 Beta2TR Trials and Tribulations

2006-09-28T15:59:00.001-07:00

Today was my lucky day to install a new MOSS2007 Beta2TR virtual machine from scratch. Oh, joy. Has anyone anywhere at any time so far managed to do this without uttering a single curse of frustration? I seriously doubt it. So here are the lessons I learned on today's adventure to MOSS-land:

If you plan on using a unique admin account (other than 'Administrator') for database access and application pools (such as 'SPSAdministrator') be sure that you are logged in as that account throughout the entire installation, upgrade and configuration process. Otherwise, you'll get all kinds of strange errors during installation and configuration. Oh, and don't forget to add that account to SQL before starting the process with full admin rights (or at least 'dbcreator' and 'securityadmin').
The slipstream process ain't all it's cracked up to be. I tried three times to slipstream the install, which worked through the installation process (assuming you sorted out the somewhat misleading upgrade instructions), but it failed to create the central admin application upon configuration all three times. What is not quite so obvious is that you need both MOSS and WSS TR's to do the update - just MOSS won't work. This is confusing as you don't need have to install WSS before MOSS the first time around. Just remember to a) copy all the files from the Beta 2 cd image into a local directory, then b) extract the update files for MOSS B2TR and WSS B2TR into that directory's \Update folder.
Central Administration will not work from a clean slipstream install (at least not for me it wouldn't and I was working from a fresh Win2k3 install). The configuration wizard runs and the central admin app is created but you can't access it - just an annoying 404 error every time. You must first install Beta 2, then run the configuration wizard (which creates the central admin app correctly) THEN run the WSS B2TR followed by the MOSS B2TR.

Finally, after much gnashing of teeth and flailing of limbs, I have a clean MOSS2007 image to work from. Now it's on to custom site definitions which, based on the install experience, promise to be a all-out man vs. machine war. Stay tuned for reports from the battlefield.

Business Portals vs. Line of Business Applications

2006-09-13T05:52:00.000-07:00

A primary focus of our business is building custom SharePoint-based applications for our clients. Naturally, being SharePoint gearheads, we believe that everything under the sun can somehow be made to work in SharePoint (and we're not often wrong) but we run into a great deal of confusion when presenting clients with various customization options. One of the most difficult ideas to grasp is the separation between a business portal (BP) and a line of business application (LOB). Which is which and where/how do you use each one?

To begin with, a business portal is defined as any application or set of applications (and the default SharePoint experience is really a set of integrated applications) that share a common brand or visual presentation and is usually delivered as a packaged installation (as opposed to a fixed location extranet or intranet) to customers, partners, or other constituents. An LOB, on the other hand, is a distinct application that is deployed within an existing inter/intra/extranet implementation.

On a more technical level, a customized set of WSS site definitions, web parts, and templates that together combine to form a branded collaboration application for, say, the real estate market, would be a business portal. On the other hand, a set of web parts, lists, roll-ups, controls, or other programmatic elements, delivered individually or packaged together, and installed within an existing company intranet for tracking sales and orders, would be an line of business application.

Just to muddy up the waters a bit, it should be pointed out that the two are not mutually exclusive - an LOB can be deployed within a business portal and a business portal can be created to serve internal as opposed to external customers (an IT help desk solution for a company with multiple, independent locations comes to mind). Many organizations start creating LOB's soon after they deploy a new portal solution without realizing that's what they are doing, as they roll out custom web parts that roll-up, consolidate, or provide access to various sources of company data.

Business portals can be a very powerful tool for organizations that need to deliver rich web-enabled applications on a limited budget. WSS provides a comprehensive, flexible, and customizable (and let's not forget FREE!) platform for creating dynamic web applications. The best thing about BP's is that the framework is already in place - navigation, data storage (via lists), security, browser-based site management - so developers can focus on customizing and extending the framework without reinventing the wheel at every turn. With the introduction of SharePoint 2007 and the improved customization options, along with built-in workflow and item-level security, forms-based authentication, and the business data catalog, expect a dramatic upsurge in the number of business portals being created, many of which will be offered as stand-alone applications (hint: expect to see several from us before the end of the year).

eGroup List Viewer Web Part

2006-08-31T08:09:00.000-07:00

Whenever I begin a new portal design engagement, one of the most difficult concepts to communicate to the client's design/architecture group is 'Content-Driven Design'. The theory is simple - create an architecture and taxonomy around the information that is most important within your organization. What makes it difficult is the almost Pavlovian instinct to organize content based on company structure - breaking away from the org chart sometimes requires superhuman effort.

Fortunately, once the initial shock wears off, the light goes on and heads start nodding around the conference table. It doesn't take long for people who couldn't pronounce 'taxonomy' the week before to suddenly become content design experts. This only makes sense, as they already have a picture in their minds of how their company's information should be organized, they just need a push in the right direction to translate those thoughts into a good architectural design.

One of the most critical elements to a good content-driven architecture is the concept of "Author Once, Publish Everywhere". In this model, information is created and managed in the most granular context applicable to it's function but published in the context where it is most often consumed. For example, an HR policy would most likely be created and stored in an HR team site, somewhere within the overall departmental hierarchy. This allows team members to collaborate effectively on documents that pertain to their job function while permitting the greatest degree of security and oversight. Users, on the other hand, shouldn't be poking around in the HR team site, they should be browsing a portal area that is generally classified to contain that type of information (such as 'Employee Resources' or 'New Hire Information').

Unfortunately, this design methodology reveals an inherent weakness in SharePoint - the inability to distribute list content throughout the portal. In the SharePoint structure, lists can only be viewed in the context in which they were created (in our example, the HR documents could only be viewed within the HR team site). SharePoint does not ship with out-of-the-box capabilities to create list items in one area/site and view them in another.

To meet this requirement, we created a web part which allows list content in any area or site to be viewed in another area or site by users with sufficient permissions to view items in the source list (they must at least be a 'Reader'). We've used it in numerous client engagements and it is a critical component in our Content-Driven Design methodology. Just add the web part to a page, give it the portal/site url, list name, and view, set the display options (toolbars and column titles), and voila - list content for everyone, everywhere!

The web part can be downloaded here. The zip file contains a ReadMe document with instructions on installing the CAB file (in case you haven't done it before) along with information on deploying it to a portal/site page and configuring the various options.

As always, post any questions, comments, or suggestions to this post.

Enjoy!

eGroup SharePoint Utilities

2006-08-18T14:55:00.000-07:00

I am a big proponent of leveraging SharePoint to deliver enterprise line-of-business applications (LOB's). Much of the custom development we do at The eGroup involves the use of SharePoint lists as data repositories for dashboards, workflows, roll-ups and, of course, LOB's. Working extensively with SharePoint lists brings introduces its own set of challenges - coding against the web services, creating and maintaining a large number of custom views, managing security and migration of list structure/content from development to staging and production.

In the course of developing these applications we have created a set of tools to aid us in our efforts. To save our fellow SharePoint developers some of the headaches we've encountered, and to encourage other developers to contribute their time-saving apps, we'll be releasing various applications and utilities from our toolkit in the coming weeks and months. The first utility, the SharePoint List XML Viewer, received an enthusiastic response and generated a fair number of downloads. I hope it is serving everyone well and we will continue to improve it as we receive feedback from the SharePoint community.

The second tool to be released, the SharePoint List Creator, is a companion utility to the List XML Viewer. Using the XML output gathered from the XML Viewer, it provides developers with the ability to define custom lists in XML and easily deploy them to multiple sites/areas. This can be quite a time saver when you have a large number of heavily customized lists that must be moved to different environments, especially when each portal or site collection exists in disparate server farms and/or separate domains.

To use the SharePoint List Creator you'll need good working knowledge of XML and some CAML experience. Creating a new list requires a source XML file that contains the properties, fields, and views that will comprise the list. A sample file, DocumentLibrary.xml, has been provided in the \XML directory to give you a basic template to work from (remember to store all your custom list templates in this same directory). If you haven't done much CAML or manual list creation, a good first step would be to create a custom list in the SharePoint GUI then view the list structure with the List XML Viewer. Compare the output to the sample xml template and it won't take long to figure out how to create just about any list type from scratch. We'll release more samples in the future to aid new developers and in response to comments/requests.

To use the SharePoint List Creator, first download the eGroup SharePoint Utilities Windows Installer package from our web site. This package contains both the SharePoint List Creator and the SharePoint List XML Viewer. Next, install the MSI on your development machine and launch it from the program menu shortcut. Provide the site/area URL, list name, type, source XML document, and authentication credentials, and submit the changes. The tabs in the utility will display the source XML, new list XML being submitted, the results from the list updates, and the results from the view modifications. You'll also find any errors encountered under the appropriate tab (i.e. if view creation fails, check the "View Results" tab).

We'll update the Utilities suite with new apps as we convert or create them (many are ASP.NET applications that require migration to Windows Forms prior to deployment). As always, please post your questions, suggestions, feature requests, gripes and complaints as comments to the post. Feedback is the only method we have to gauge the community reaction to our efforts. I hope you find the tools useful. Enjoy!

New Version of SharePoint XML List Viewer

2006-08-06T08:34:00.000-07:00

I received some good feedback on the XML List Viewer utility and have posted a new version with the following modifications:

* Clear text entries hidden in password field
* XML displayed in structured view (similar to IE functionality)
* XML can be saved to local file (Right-click within XML field, choose 'Save')
* XML can be printed (Right-click within XML field, choose 'Print')
* XML can be searched for a specified string (right-click, 'Search')

Download the new version (1.1) here.

Please post any additional feature suggestions as comments to this post.

Enjoy!

UPDATE: Downloads from the earlier post had problems with the .NET 1.0 version of the tree view DLL. I have posted an updated version (use the same link above) that includes a recompiled .NET 1.1 version XmlTreeView source code within the executable (thanks to Thomas Siepe for making the source available on The Code Project).

SharePoint List XML Viewer Utility

2006-08-03T20:38:00.000-07:00

Many of us are rejoicing over the new web publishing features in MOSS2007 and the ability to create corporate web sites using SharePoint. Unfortunately, many enterprises are not planning to upgrade to 2007 for quite some time, and those that use SharePoint extensively are looking for ways to derive additional value from their portal investment. One of the best ways to do this is to use SharePoint 2003 as a basic content management system for a public web site (at least until a full 2007 migration can be completed).

I just finished a project where an existing - and very expensive - CMS application (I won't name names but it's not MCMS) is being phased out in favor of using SharePoint lists as the primary method for managing content on a standard ASP/ASP.NET public web site. When you think about, this makes perfect sense - SharePoint provides a form-based web interface for handling content submissions, security is built into the platform, content approvals and basic workflow are easy to implement, and every list in a portal/site is accessible via web services (for more information on using SharePoint as part of a basic CMS application, email me directly).

While working on this project I discovered that working with the SharePoint web services is no picnic; not only do you have to know all their little quirks (like the viewName argument requiring a GUID instead of the display name of the view) but you also have to make allowances in your code for all the funky things SharePoint does behind the scenes with the list XML. For example, when you name a field 'Field1', the list details show the field as just that - Field1 - but when you try to retrieve the list data using the Lists web service, you must refer to the field as 'ows_Field1'. And then there's the ever-popular trick of replacing all spaces in field names with '_x0020_'. Naturally, there are no tools in SharePoint that allow you to retrieve this information, invaluable though it might be. It's enough to drive you mad.

To maintain my sanity and bring some order to web service programming, I created a small utility to retrieve the XML for any list via the SharePoint web services. The SharePoint List XML Viewer is a small Windows app that programmers can use to retrieve the XML output for any list or list items (including any default or custom views) to aid them in building web service applications. You can download it here. Just unzip the file and run the executable. Give it the site/area url, list name, and view name, supply the necessary login credentials, pick which type of XML you want (list data or list items) and - voila - instant XML that can be cut-and-pasted into your favorite text editor.

The SharePoint List XML Viewer Utility isn't anything fancy - it's just a basic utility for developers - but it saved me countless hours programming against SharePoint's web services and I hope it helps you, too. Enjoy!

(Post comments to this post if you have any issues installing and using the tool)

BTW, I recommend using the application along with the CAML Query Builder and Execution Tool from the good folks at U2U. Sooner or later you'll need to execute a query in a web service call and the CAML Builder is the best thing going.

Extreme SharePoint Design 2007: Introduction to Customizing Default Pages

2006-06-23T09:54:00.000-07:00

This is the first post in a new series covering advanced design in Microsoft Office SharePoint Server 2007 (MOSS2007). As with previous Extreme SharePoint Design posts, much of the material will be undocumented, some posts will walk the line on supportability, and some will downright obliterate the line just to show what can be done; therefore, all techniques should be tried first in a test environment and a good backup is always a necessity. Now on to the good stuff!

MOSS2007 takes a radically different approach to rendering pages, due mostly to the integration of Content Management Server features into the product and an ongoing effort on Microsoft’s part to migrate towards a more structured, data-bound architecture (i.e. CAML and XML). Much of what we learned customizing SPS2003 will still be applicable but a great deal of the behind the scenes machinery has changed. A good place to begin learning how to modify MOSS2007 to meet your needs is with default page customizations; changing the structure, appearance, and layout of the default site welcome pages.

Since MOSS2007 is built on ASP.NET 2.0, a solid understanding of master pages is required in order to grasp how site pages are constructed and rendered. A master page (any ASPX page with a .master extension) is nothing more than a template with placeholders for content, much like a regular ASP.NET page that invokes user controls to render content. In .NET 2.0 syntax, these placeholders are implemented using the <ASP:ContentPlaceHolder> tag. Placeholders can be nested, so that a top-level placeholder may have multiple levels of child placeholders, much like a parent DIV can have many nested child DIV’s.

The master page by itself usually contains very little actual content other than headers and navigation – it’s just a framework for one or more layout pages that comprise the body of the page. In MOSS2007, the master page DEFAULT.MASTER, located in WEB SERVER EXTENSIONS\12\TEMPLATE\GLOBAL, defines the standard top header and left navigation layout found throughout the basic site definitions. Unlike SPS2003, where the default page in each site definition contained all the code necessary to render the page, the new site definitions, located in 12\TEMPLATE\SITETEMPLATES, have a DEFAULT.ASPX page that references the master page but contains no actual content. Instead, the default page is built at runtime when the site is created by combining MASTER.DEFAULT with the layout page referenced in the PublishingPageLayout property of the Default.aspx File node of the Modules configuration in ONET.XML (~SiteCollection/_catalogs/masterpage/defaultlayout.aspx for the SPS site definition, which corresponds to 12\TEMPLATE\FEATURES\PORTALLAYOUTS\DEFAULTLAYOUT.ASPX in the server file structure). The combined file is then stored in the Pages list on the top-level site.

DEFAULT.ASPX = MASTER.DEFAULT + DEFAULTLAYOUT.ASPX

When you edit the default page using SharePoint Designer you are actually editing the combined code from two pages – the master page and the layout page. Fortunately, because the default page is stored in a list, the whole ghosting/unghosting issue no longer applies (hooray for that!); however, there is one major drawback – since the page doesn’t actually exist until the site is created, editing it only applies to the current site instance – new sites or subsites based on the same definition will have to edited manually each time they are created. To automate this process, the site definition must be modified in a similar manner to the methods used in SPS2003 but using the new master page methodology. Doing so requires making changes not just to a single default page but both the master and layout pages (we’ll cover creating new site definitions from scratch in a subsequent post).

The layout page works with the default page by specifying what content is to be placed in the placeholder zones using the <ASP:Content> tag and referencing the placeholder id. The page handler process then assigns the content in the layout page, which consists of the HTML markup we are used to seeing in SharePoint pages (server controls, web part zones, etc.), to the proper zone in the default page. The following illustration is a wireframe model of a combined DEFAULT.ASPX page with all the major placeholders, server controls, custom tags, content areas and publishing/web part zones placed in their proper context (click on the image to view it full size):

Blue areas in the model indicate placeholders, red is for server/user controls, purple represents new ASP-specific controls (in this case the breadcrumb navigation menu), green indicates the new PublishingWebControls objects, and grey is the standard web part zones. The yellow headers indicate the relationship between the default and layout pages. The final rendered page looks like this:

As you can see from the wireframe model, the page layout is not all that different from SPS2003, except that content is now separated from navigation by using two different file types. The beauty of this model is that changes to DEFAULT.MASTER are global; no more cutting and pasting code modifications into multiple site definitions. Likewise, the DEFAULTLAYOUT.ASPX page is also universal, making changes much easier to implement. If, for example, we wished to change the basic layout of the web part zones in the body of the page, we can modify the markup in DEFAULTLAYOUT.ASPX without touching the headers and navigation contained in the master page. We can also add content to the master page by using <ASP:Content> tags and specifying the placeholder with the ContentPlaceHolderId setting without actually modifying the master page itself.

In SPS2003 the customization process was cumbersome and inefficient; with the new master page model, Microsoft has given us far greater flexibility in customizing SharePoint sites to meet each organization’s unique requirements. In subsequent posts we will explore in greater depth the new MOSS2007 architecture, including the new list file structure, the long-overdue changes to the administration pages, and how to create new site definitions from scratch.

Happy SharePointing!

Extreme SharePoint Design: Using the AlternateHeader Property in WSS

2006-06-07T19:45:00.000-07:00

I’ve done a number of customizations to administration pages (.aspx files located in the \LAYOUTS\1033 directory) by directly modifying the pages themselves. This is a cumbersome process, involving a lot of HTML search-and-replace operations. I felt it was time to use a more flexible approach so I attempted to create a more robust solution that works in both SPS and WSS. The first challenge to overcome was the fact that pages in a WSS context don’t inherit the AlternateHeader property from the Site Definition ONET.XML file. In the portal definitions, the following setting points the administration pages to a file called ‘PortalHeader.aspx’ and, if the file is not empty, renders the header contained therein:

< title="Team Web Site" listdir="Lists" ows="Microsoft SharePoint" alternateheader="PortalHeader.aspx" disablewebdesignfeatures="wdfbackup; wdfrestore; wdfpackageimport; wdfpackageexport; wdfthemeweb; wdfthemepage; wdfnavigationbars; wdfnavigationview; wdfpublishview; wdfpublishselectedfile; wdfNewSubSite">

This setting does not exist in the STS definition so it must be added (note that this will have no effect on existing WSS sites, only new ones created after the ONET.XML file has been modified). Unfortunately, the default PortalHeader.aspx file contains a number of < SPSWC: > control references which are portal-specific and will not render in a WSS context; simply adding this setting will not solve the problem. So the first step is to edit the ONET.XML file in TEMPLATE\1033\STS\XML to include the AlternateHeader setting and point it to a new header file, as follows:

Original code:

< title="Team Web Site" listdir="Lists" ows="Microsoft SharePoint">

Replacement code:

< title="Team Web Site" listdir="Lists" ows="Microsoft SharePoint" alternateheader="STSHeader.aspx">

Next, the new header file must be created (STSHeader.aspx in this example). This file must contain the proper WSS-context registrations to enable code execution (if necessary) and the content must be devoid of any portal-specific control references. Here is a sample STSHeader.aspx file:

< % @ Page language="C#" % >
< % @ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >
< % @ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >
< % @ Import Namespace="Microsoft.SharePoint" % >
< % @ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >

< link rel="'stylesheet'" type="'text/css'" href="'/_layouts/1033/styles/custom.css'">
< table width="100%" cellpadding="0" cellspacing="0" border="0">
< tr >
< td width="100%">
< div class="spsHeader" >
< !-- Insert Header HTML Here -- >
< % Execute Some ASP.NET Code Here % >
< /div >
< /td >
< /tr >
< /table >

After modifying the ONET.XML file and creating the new header file, copy ONET.XML to its original location and place the new header file in the \LAYOUTS\1033 directory. Perform and IISRESET on the server and create a new WSS site. Next select ‘Documents and Lists’ or ‘Create’ from the menu to see your new header code in action. If you plan to utilize custom server controls within the header file be sure to add the necessary registrations to the top of the page prior to deployment.

Ajax/Atlas in SharePoint?

2006-06-06T14:58:00.000-07:00

A colleague of mine is trying to get Ajax/Atlas assemblies working in SharePoint. All is good if he hard-codes the functionality but the SharePoint safe mode parser is kicking the code out anytime he tries to use the precompiled assemblies. Anyone have experience with this? Post a comment and throw a fellow code monkey a banana or two!

Enabling the 'Edit in Microsoft Word' Functionality for Office 2000/XP Users

2006-05-25T07:24:00.000-07:00

Ever since SharePoint v2 was released organizations have struggled with the Office 2003-dependent features of the product. The primary source of frustration are those functions that should work for all users but don’t – like the ‘Edit in [Application]’ link in document libraries. Users with Office 2000/XP get the dreaded “” error when trying to access files using this option, while Office 2003 users can continue working without interruption. While there are several workarounds for this missing functionality, all of them require Office 2000/XP users to perform different steps to access a document than those users who have Office 2003 installed on their system.

Fortunately, there is a way to overcome this problem. The ‘Edit in …’ option is exposed in the core JavaScript file OWS.JS located in the 60\TEMPLATE\LAYOUTS\1033 folder on each front-end web server. On or about line 1440 is the following function:

function editDocumentWithProgID2(strDocument, varProgID, varEditor)
{
var objEditor;
if (strDocument.charAt(0) == "/" strDocument.substr(0,3).toLowerCase() == "%2f")
strDocument = document.location.protocol + "//" + document.location.host + strDocument;
try
{
objEditor = new ActiveXObject(varEditor + ".2");
if (!objEditor.EditDocument2(window, strDocument, varProgID))
alert(L_EditDocumentRuntimeError_Text);
window.onfocus = RefreshOnNextFocus;
return;
}
catch (e)
{
}
try
{
objEditor = new ActiveXObject(varEditor + ".1");
window.onfocus = null;
if (SzExtension(strDocument) == "ppt" && varProgID == "")
varProgID = "PowerPoint.Slide";
if (!objEditor.EditDocument(strDocument, varProgID))
alert(L_EditDocumentRuntimeError_Text);
SetWindowRefreshOnFocus();
return;
}
catch (e)
{
alert(L_EditDocumentProgIDError_Text);
}
}

This function takes three parameters that define the document’s location, program ID, and the application which created it. The critical code in this function is found within the two Try…Catch blocks starting on line 1445. The first block applies to Office 2003 users (the “.2” designation appended to the variable varEditor indicates O2K3 clients), while the second is applicable to Office 2000/XP clients. This is the portion of the function that must be altered to enable the ‘Edit in …’ option for these users.

The original code identifies the application type and determines the correct application to launch based on settings in the DOCICON.XML file. For Office 2000/XP clients, the script must instead contain an explicit mapping between file extension and application (UPDATE: There is a way to parse the DOCICON.XML file dynamically to achieve these results but the code is lengthy and cumbersome – the performance trade-offs are probably not worth the effort). To achieve this, simply add a series of if…else if statements to the beginning of the second block for each file type:

if (SzExtension(strDocument) == "doc")
{
objEditor = new ActiveXObject("Word.Application");
objEditor.Visible = true;
objEditor.Documents.Open(strDocument);
}
else if (SzExtension(strDocument) == "xls")
{
objEditor = new ActiveXObject("Excel.Application");
objEditor.Visible = true;
objEditor.Workbooks.Open(strDocument);
}
else if (SzExtension(strDocument) == "ppt")
{
objEditor = new ActiveXObject("PowerPoint.Application");
objEditor.Visible = true;
objEditor.Presentations.Open(strDocument);
}
else if (SzExtension(strDocument) == "vsd")
{
objEditor = new ActiveXObject("Visio.Application");
objEditor.Visible = true;
objEditor.Presentations.Open(strDocument);
}
else
{
objEditor = new ActiveXObject(varEditor + ".1");
window.onfocus = null;
if (SzExtension(strDocument) == "ppt" && varProgID == "")
varProgID = "PowerPoint.Slide";
if (!objEditor.EditDocument(strDocument, varProgID))
alert(L_EditDocumentRuntimeError_Text);
}
SetWindowRefreshOnFocus();
return;

The script will now check the file extension when the ‘Edit in …’ option is clicked and, if it matches one of the ‘if’ or ‘else if’ statements, open the associated application and load the file. For compatibility, the original code is retained in the final ‘else’ statement. Also, the SetWindowRefreshOnFocus() and return lines have been moved to the end of the function so they remain applicable to the entire function (if not relocated, the window will remain in a wait state after the ActiveX object has been invoked).

There are a couple of caveats to this solution:

1. Each file type must be explicitly declared in the ‘if…else if’ statements. This can be overcome by instead parsing the DOCICON.XML file; however, as noted above this method is a bit cumbersome and the XML settings are not comprehensive (many of the mappings call SharePoint.OpenDocuments instead of the original application, so a clunky series of substitutions must still be made to be effective; overall, this solution is less efficient than simply making the declarations in the code itself).

2. If the SPS Area/WSS site is not in the user’s Intranet zone in IE and the ‘Initialize and script ActiveX controls not marked as safe’ option is not set to ‘Enable’, the user will get a warning dialog each time they select the ‘Edit in …’ option. For organizations that make use of policy files and/or login scripts, these settings can be enabled globally via a policy file on login.

While this is not a substitute for upgrading all Office 2000/XP clients to Office 2003 (users on the older platforms still won’t have the Explorer View functionality or be able to upload multiple files), it will serve as an effective interim measure until the upgrade process can be completed. Afterwards, the script can be reverted back to its original state and the workaround code removed.

Extreme SharePoint Design: Hiding List Types in Existing Sites/Areas

2006-05-23T09:11:00.000-07:00

It can sometimes be necessary to disable a certain list type within a WSS site or SPS portal area. If, for example, the customer doesn’t wish to provide portal users with the capability to create discussions, that list type should be removed from the list creation page. If you have not already deployed the portal or team site, removing the list is as simple as editing the ONET.XML file for the site definition. But what if you have already deployed a number of sites or areas? Modifying ONET will have no impact on sites or areas that have already been created – only new ones created after the change takes place. To remove a list type from an existing site/area you’ll need to directly modify the list display and creation pages to remove the list type from view.

In this example we’ll hide the Dicussion Board list type. Begin by removing the display of the list type from the Documents and Lists page (spsviewlsts.aspx in SPS and viewlsts.aspx in WSS – BE SURE TO BACK UP ALL FILES BEFORE MODIFYING THEM IN ANY WAY). Both files can be found in the /60/TEMPLATE/LAYOUTS/1033 folder on the front-end web server(s). On or about Lines 166 - 172 (viewlsts.aspx) or Line 175 - 181 (spsviewlsts.aspx) you will find the following block of code:

ArrayList rgDiscussions = new ArrayList();
rgRgs.Add(SPBaseType.DiscussionBoard);
rgRgs.Add(SPListTemplateType.InvalidType);
rgRgs.Add(L_szDisc_Text);
if (!bBaseTypeInited) { rgRgs.Add(L_szNoDisc_Text); } else { rgRgs.Add(L_szNoDisc1_Text); };
rgRgs.Add("?BaseType="+Convert.ToInt32(SPBaseType.DiscussionBoard));
rgRgs.Add(rgDiscussions);

Remove all but the first line of this code by closing the code block then commenting out the remainder of the text:

ArrayList rgDiscussions = new ArrayList();
%>

<%

This will prevent any existing Discussions from being displayed on the Documents and Lists page. It is important to leave the first line intact so the dependent code that relies upon the rgDiscussions array does not throw an error.

Next, perform the same edits on the WSS (create.aspx, lines 194 - 200) and SPS (spscreate.aspx, lines 199 - 205) list creation pages. Save all four pages to their original location (no reset required) and view them in your browser (/_layouts/1033/{filename}.aspx for each site/area). The Discussion Board group is now hidden from view.

There is one caveat: users with sufficient knowledge of SharePoint can still create and view the list type you have hidden by using the URL protocol. For example, the URL to create a new Discussion Board is http://{portal name}/_layouts/1033/new.aspx?ListTemplate= 108&ListBaseType=3 and the list can still be viewed at /Lists/{ListName}/AllItems.aspx; however, for the vast majority of users this method will be sufficient to prevent them from utilizing the hidden list type. It would also be a good idea to delete any existing lists of that type (if possible); or, at least remove any web parts or links that refer to them.

SharePoint Forums Released

2006-05-16T06:32:00.000-07:00

Sometimes, you just gotta put down your coffee, get up from your computer and dance a little jig. Today is one of those days. Bil Simser has officially released his new SharePoint Forums web parts. And there was much rejoicing and dancing in the streets (there was at my desk, anyway).

Seriously, everyone who has worked with SharePoint for even a day knows what a pain the built-in discussion boards can be. We all owe Bil a debt of gratitude for solving this problem AND making it freely available to the community.

So what are you waiting for? Go get ‘em!

SharePoint Resources

2006-05-10T06:32:00.001-07:00

Joris Poelmans (JOPX) has an updated list of SharePoint resources, including some great stuff for MOSS 2007. Check it out!

MOSS 2007 Upgrade Article

2006-05-02T05:48:00.000-07:00

I get a lot of questions regarding upgrading from SPS 2003 to MOSS 2007. So far, there has been very little information on this topic, but Joel Oleson just posted a good article on some of the upgrade options. I am intrigued by the scan option to identify customized sites/pages in a portal but I have a feeling that heavily customized sites (which most of my clients demand) are still going to be a painful process to upgrade.

On that note, if you are doing heavy customizations to site definitions and templates, it's always a good idea to warn the client up front that they will have to re-invest heavily in the upgrade when 2007 ships so they can budget accordingly. As a personal rule of of thumb I try to always present the 'doomsday' scenario as part of the upgrade discussion, meaning for every dollar the client invests today in customizations they should plan on at least a 100% matching investment to upgrade. That might be a bit over the top but personally I'd rather give them the bad news up front so they can make better decisions down the stretch.

SharePoint Developer Guidelines

2006-05-02T05:32:00.000-07:00

One of the most common mistakes I see new SharePoint developers make is that they jump right into Visual Studio and start writing code without any real knowledge of the environment their applications will be deployed in. They throw together some code, deploy it within a limited context (usually in WSS) on a local machine, do all their testing with an admin account, and then declare themselves to be SharePoint developers. While this sort of slap-dash approach may be fine if you’re just trying to figure the object model out, it creates bad coding habits that will cause all sorts of headaches the first time your web parts are deployed in an enterprise portal environment.

Here are a few guidelines for producing better code, in less time, with more positive long-term results:

1. Learn the Product

To begin with, developers should understand SharePoint before trying to create the next great web part that changes the world as we know it. Investing the time to learn how portal areas are different from team sites, how the data model works, what the differences are between SPSite and SPWeb objects, how, when and why to do impersonation, how data is stored in and retrieved from lists, and getting a handle on the ins and outs of code access security will be time well spent. Furthermore, one needs to work with SharePoint for a while to have an idea of how users are going to interact with the custom web parts being created. How can a person effectively design a portal application if they’ve never struggled with the default navigation controls, created site collections and subsites, managed portal area security, configured search, created custom views, added calculated fields, configured cross-site groups, or put together a basic data view web part? I’m not saying that developers should be admins – that’s not their job – but they sure need to know what they’re working with before jumping in with both feet.

2. Plan for success

It’s a funny thing, but SharePoint development tends to promote a kind of “code before planning” mentality that rarely exists elsewhere in the enterprise. Developers who wouldn’t normally write a line of ASP.NET code without a dozen use cases jump right into web parts without any kind of plan whatsoever. SharePoint’s inherent advantages – unified navigation, managed presentation layer, built-in security model, user-managed hierarchy – aren’t a substitute for a well-designed application framework; in fact, they often work against the developer to emphasize weak design elements and exacerbate poor application design.

Before writing a single line of code, stop and T-H-I-N-K. What’s the right type of project - web part, server control, event handler, or web service? How will the users deploy the application? Will it be used in both WSS and SPS? Does the code require external files, such as XML and XSL, and, if so, where will they be stored and how will they be accessed? What kind of permissions are necessary to execute the various functions in the code? How will configuration parameters be stored and modified? Does the output require a user control or will the HtmlTextWriter class of RenderWebPart be sufficient? Are success/fail messages required in the GUI or Event Viewer? How will you debug and test the application?

Finally, plan your code just like you would any other enterprise application. Identify your input elements, output parameters, presentation objects, class definitions, and so forth. Map out the structure and navigation hierarchy. Determine data storage requirements. Create a specification for all the supporting elements – lists, libraries, areas, sites, etc. In other words, treat it like a normal development project and avoid the common mistakes that cause web parts to fail under any conditions other than those used in the proof of concept.

3. Know the Object Model

Nothing is more frustrating than seeing an application that works flawlessly in development get kicked back from QA because the code is dependent upon some quirky object model function. Those handy little methods that look like lifesavers in development – IsRootWeb, DoesUserHavePermissions, GetSubwebsForCurrentUser, ParentWeb – can wreak havoc in a production environment (try using IsRootWeb on a top-level portal area and watch your code get blown to smithereens). Even worse, permission-dependent functions, like GetPermissionCollectionFromWeb, don’t work at all for non-admin users, requiring tricky account impersonation techniques.

The best way to avoid these common pitfalls is to test, test, test in the best simulation of a real-world environment possible. Make sure that the development SharePoint server has accounts for at lest each level of built-in security (and any custom security groups required by the application). Deploy code in the Home area, top-level portal areas, subareas, site collections (parent sites) and subsites. Above all, consider how the user *might* implement the code not how you originally intended it to be used.

4. Log Application Events

Debugging code is no easy task in SharePoint; it’s not always possible to run code on the local development server or virtual machine, the standard error messages are cryptic at best and nearly useless in many instances, and asynchronous code execution (event handlers, for instance) will give even the most seasoned .NET developer nightmares. One simple yet effective method for debugging in SharePoint is to write success and fail messages to the event log during development and testing. Using the WriteEntry method of the System.Diagnostics.EventLog class, developers can bypass the SharePoint safemode parser and STSFLTR ISAPI filter and write messages directly to the event log. This is a handy method for isolating code errors during development; just be sure to remove the event log code before moving into production (although it might be a good idea to leave some level of error logging in the application, especially if it is an event handler or other async process).

5. Code Only as a Last Resort

It sounds strange but writing custom code should be the last resort in any SharePoint deployment, large or small. Think about it – code is expensive to write, deploy, and maintain. In most instances, the original developer isn’t going to be around when the code breaks or fails to run after the latest batch of service packs and updates. No matter how good they are, nobody can fully comment a batch of code so that those who come behind them can just pick it up where they left off. But worst of all, custom code cannot be learned, deployed, managed or improved upon by the average portal user.

Out of the box, SharePoint provides a rich application framework that enables users to create dynamic collaboration spaces without any programming. It never ceases to amaze me how many creative solutions users come up with just using the stock web parts and lists. As developers, our first instinct when presented with a problem is to write code to solve it but users don’t think that way; give them a chance to create a solution on their own and you may be surprised what they come up with, especially once they learn how to use Data View Web Parts. Concentrate on writing code only where it’s really needed so developers can spend their valuable time solving really hard problems without getting bogged down writing throw-away web parts and duplicating built-in functions.

6. Lists Rule

The secret to SharePoint’s power and flexibility is the list object. The reason the product has been so successful where others have floundered (think Lotus Notes and PeachTree) is that it empowers users to create their own data-driven applications without even knowing how to spell ‘database’. But lists are more than Databases for Dummies – they can be a developer’s best friend. Need a datatable to store input parameters? Use a list. Need a sortable, filterable grid to display query results? Lists do it automatically. Need to store/retrieve file objects like XML configuration files? Document libraries have it covered. Need an automated method for launching processes in response to user-driven events? Attach an event handler to a document library.

In SharePoint it’s all about using what you have and not recreating the wheel. If the design includes any sort of data input/output requirements, stop and think how a list can serve this purpose before writing to any XML files in the /bin directory or attaching to an external database. Lists can be a tremendous time saver and, even better, can involve the user in the data management process, requiring less code and generating more interactivity.

7. Don’t Fear the Database

I know this is going to be controversial but I’ve never agreed with the misguided mantra promulgated by SharePoint product managers and evangelists of “Don’t touch the database”. What rubbish. Are we in the business of providing value to the customer or giving sermons on “supportability”? Show me one instance of how reading from the database will blow up a portal and I’ll be glad to reconsider – but I have yet to see one (please note that I am talking ONLY about reading from the database – writing to it directly is a really bad idea and should be strenuously avoided). And before you flame me with a zillion emails on the subject, stop and ask yourself why it’s wrong to read from the SharePoint database but OK to read from the MCMS data store? Is there some evil genie guarding _SITE that’s going to awaken and eat all our lists for breakfast if we query the Webs table? And here’s the real kicker – BizTalk can flood the SQL server with SELECT statements while executing a workflow process but my little navigation control is going to bring SharePoint to a screeching halt??? I think not.

The truth of the matter is that the object model only goes so far. Sometimes the right way to get information to the user is to fetch it from the database; sometimes it’s the ONLY way (think full-blown, drop-down, security-trimmed portal navigation, for instance, or rolling up list data across multiple portals/site collections). Of course, a good developer will follow good data access practices, minimizing redundant calls across the network, closing connections in a timely manner, doing advanced sorting and filtering in dataviews, and so forth. The database is to be respected but never feared; in fact, learning how the data model works in SharePoint can help one to develop richer, more efficient and flexible web parts.

Naturally, these techniques are not a comprehensive guide to developing in SharePoint but they are a good starting point for beginners (and a timely refresher for those with a few web parts under their belts). Learn to be a better SharePoint developer and everyone wins – fellow programmers, project managers, administrators, and, most importantly, the users who have to live with our applications on a daily basis.

TechEd 2006 SharePoint Sessions

2006-03-31T07:41:00.000-08:00

If you are planning to attend TechEd 2006 in Boston then you should drop by the web site and vote for the SharePoint Birds of a Feather sessions. Heather Solomon and Andrew Connell each have one and and Bil Simser has several (and if you don’t already read their blogs then get over there now and add them to your newsreader pronto). Don’t let the SQLers get all the exposure – show ‘em we want us some SharePoint!!!

Who Am I? Demystifying SharePoint Impersonation.

2006-03-28T13:02:00.000-08:00

The SharePoint security model makes it easy to programmatically execute code within the current user context. Just write and deploy your web part and it runs in the security context of the logged in user. There are even built-in functions that take advantage of the user’s security context – such as GetSubwebsForCurrentUser() – without requiring any extra coding on our part. Simple yet effective.

But what about those times when you need to execute code with permissions greater than that of the current user (like instantiating a site collection or enumerating list permissions)? Well, that’s not quite so easy, but it’s not that hard, either – Lois and Clark have an excellent post on various methods for altering security context. There’s also Todd Bleeker’s method and Maurice Prather’s approach. And just to cook your noodle a bit more, what about those times when you not only need to run in an administrative context but you also need to check permissions for the current user? So much for simple.

Thankfully, there is a relatively straightforward way to achieve both objectives. By combining a bit of RevertToSelf() with AppDomains and SPRoleCollections, we can run securely in an administrative context without hard-coding account details, force SharePoint to use the credentials we give it, and verify that users have access to the content being displayed. In fact, this is the only way I’ve found to enforce impersonation in all instances.

I must admit to not being the world’s greatest programmer, so I spent quite a bit of time flipping between each code snippet trying to piece together a solution (code wizards like Simser and Tielens can do this stuff in their sleep but I seem to be lacking an equivalent concentration of grey matter). To save you from the same headaches, here’s the code in full with a complete description afterwards.

using System;
using System.Data;
using System.Text;
using System.Drawing;
using System.Collections;
using System.Configuration;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Security;
using System.Security.Policy;
using System.Security.Principal;
using System.Security.Permissions;
using System.Runtime.InteropServices;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.WebPartPages;
using Microsoft.SharePoint.WebControls;

namespace MyNameSpace
{
public class MyClass : System.Web.UI.Page
{
[DllImport("advapi32.dll")]
static extern bool RevertToSelf();

private void Page_Load(object sender, System.EventArgs e)
{
WindowsIdentity objOriginalUser = WindowsIdentity.GetCurrent();
RevertToSelf();
WindowsIdentity.GetCurrent().Impersonate();

try
{
AppDomainSetup objAppDomainSetup = AppDomain.CurrentDomain.SetupInformation;
Evidence objEvidence = AppDomain.CurrentDomain.Evidence;
AppDomain objMyAppDomain = AppDomain.CreateDomain("MyAppDomain", objEvidence, objAppDomainSetup);

SPSite site = new SPSite(<portal URL>);
site.CatchAccessDeniedException = false;
SPWeb web = site.AllWebs[<site URL>];
SPPermissionCollection perms = web.Permissions;
SPUserCollection users = web.Users;

foreach (SPUser user in users)
{
if (objOriginalUser.Name.ToLower() == user.LoginName.ToLower())
{
SPRoleCollection roles = user.Roles;
SPListCollection lists = web.Lists;

foreach (SPRole role in roles)
{
foreach (SPPermission perm in perms)
{
if (role.ID == perm.Member.ID)
{
if
(role.PermissionMask.ToString().IndexOf("ViewPages") != -1 role.PermissionMask.ToString().IndexOf("FullMask") != -1)
{
// TODO: Insert your code here.
}
}
}
}
}
}
}
catch(System.UnauthorizedAccessException ex)
{
Response.Write(ex.Message.ToString());
}
}
AppDomain.Unload(objMyAppDomain);
}
}

Before we go any further, allow me to point out that the code sample is probably causing real .NET developers to pull their hair out – for one, I don’t know all their code optimization techniques, and for another, I’m trying to keep it simple so this post doesn’t run off the end of the page, spill over the keyboard, and end up in the reader’s lap. So have some mercy and don’t flame me too badly but do post any tips that will help make the code better. Also, note that throughout this post I’ve tried to use the same variable names and syntax as the original articles to avoid confusion.

Now on to business. In the above example, we are instantiating a new SPWeb object in the Administrator context and checking the permissions for the actual logged-in user for the target site. The first step is to make sure we have the proper references so be sure to add the proper DLL’s to your project and add all the required ‘using’ statements (you may need more or less depending upon what your application does).

using System;
using System.Data;
using System.Text;
using System.Drawing;
using System.Collections;
using System.Configuration;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Security;
using System.Security.Policy;
using System.Security.Principal;
using System.Security.Permissions;
using System.Runtime.InteropServices;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.WebPartPages;
using Microsoft.SharePoint.WebControls;

Next, we need to import the ‘advapi32.dll’ in order to facilitate impersonation of user accounts.

[DllImport("advapi32.dll")]
static extern bool RevertToSelf();

Once we have the proper resources, we can impersonate the administrative user account. The RevertToSelf() function returns the user credentials of the account under which the SharePoint application pool runs in IIS (MSSharePointPortalAppPool in a default installation). If you are running your portal under a different context, now would be a good time to change it to a local admin account that is also a SharePoint administrator. The biggest advantage of this method is that it does not required any sensitive information (such as passwords) to be stored in clear text; the credentials are specified in the IIS settings for the virtual server.

WindowsIdentity objOriginalUser = WindowsIdentity.GetCurrent();
RevertToSelf();
WindowsIdentity.GetCurrent().Impersonate();

The first line gets the current user account for later use. The second calls the Application Pool credentials and the third sets the impersonation context to that account (omitting it will generate an Access Denied error).

Once we have the proper credentials in place, it’s necessary to create a unique application domain to run our code in. SharePoint has a nasty quirk wherein it insists on using the currently logged in user credentials no matter how many times you tell it otherwise. The fix for this is to create an application domain wrapper for the subsequent code, in effect fooling the SharePoint object model into thinking your web application is actually a console application (see Maurice’s post for a full explanation).

AppDomainSetup objAppDomainSetup = AppDomain.CurrentDomain.SetupInformation;
Evidence objEvidence = AppDomain.CurrentDomain.Evidence;
AppDomain objMyAppDomain = AppDomain.CreateDomain("MyAppDomain", objEvidence, objAppDomainSetup);

Now that we have the proper credentials and domain in place we can move on to the actual SharePoint code. For this very basic example, we first instantiate a new site based on the root portal, then create an SPWeb object for a site so we can get its user and permission collections. Note the ‘CatchAccessDeniedException() method – this prevents authentication dialog boxes from appearing if the login somehow fails.

SPSite site = new SPSite(<portal URL>);
site.CatchAccessDeniedException = false;
SPWeb web = site.AllWebs[<site URL>];
SPPermissionCollection perms = web.Permissions;
SPUserCollection users = web.Users;

Earlier we captured the original user credentials before impersonating the admin account. We can now use that information to compare against the list of site users to see if the currently logged-in user has permissions to access the site. First, we’ll check to see that the user names match:

if (objOriginalUser.Name.ToLower() == user.LoginName.ToLower())

Then we’ll get the security role collection for the site:

SPRoleCollection roles = user.Roles;

Then we loop through the security roles and permission collections to see if the role ID for the current user matches the Member ID in the permissions table for the site. If it does, then we check to see if the user has either the ViewPages right or, if the user is an administrator, the FullMask right (rights are cumulative for Web Designers, Contributors, Readers and all other roles except Administrators, who simply have the ‘FullMask’ permission).

foreach (SPRole role in roles)
{
foreach (SPPermission perm in perms)
{
if (role.ID == perm.Member.ID)
{
if
(role.PermissionMask.ToString().IndexOf("ViewPages") != -1 role.PermissionMask.ToString().IndexOf("FullMask") != -1)

Assuming the user credentials are accepted, you may now execute whatever code you desire with confidence that the user has sufficient permissions to view the specified content. Once the code has finished executing it’s a good idea to destroy the application domain you created and, if you wish, revert back to the original user context.

AppDomain.Unload(objMyAppDomain);
objOriginalUser.Impersonate();

Of all the methods that are available for running code under an administrative context in SharePoint, this combination of impersonation and application domains is the only one that I’ve found works in every situation I’ve tried.

SharingPoint Update

2006-03-18T14:30:00.000-08:00

You may have noticed that I haven’t been blogging much lately. I’ve been swamped with projects, starting with a complete, top-to-bottom site customization at the beginning of the year that I completed in just two weeks, followed by a month in Indianapolis in February, a few days in Baltimore, then right on to a project in Dallas. In between I redesigned a company web site for a friend, did my corporate taxes, and emptied a storage bin full of old stuff. Whew!

During this time I’ve been doing A LOT of custom development in .NET – web parts, object model code, server controls, custom lists, the whole nine yards. As most people know I’m not the greatest programmer in the world and only know enough C# to be really dangerous so it’s been quite the learning experience. Here’s a sample of what I’ve been up to:

Dynamic drop-down portal area navigation server control

Custom list query/XML rendering administration pages

Visio design template for SPS/WSS deployments

Custom site navigation control/web part with security trimming

Advanced customization best practices document

Document library event handlers (not started yet)

List search pages

As is my custom, I’ll be posting detailed coding techniques, tips, tricks and sample code over the next few weeks. Stay tuned for some good stuff!

Extreme SharePoint Design: Modifying 'Grouped By' Headers, Part 2

2006-03-01T08:58:00.000-08:00

Creating a grouped list in SharePoint is easy – just Modify Settings and Columns, Create View, and select the column(s) to group on; however, getting the grouping to sort and display the way you want isn’t quite so simple. By default, SharePoint sorts alphabetically and there aren’t any options to hide group headers, style them individually, or change the layout.

One of the most common requirements for grouped listings is to create a manual sort mechanism to circumvent the built-in alphabetical sort. This is easily done by adding a new field with a numerical value and assigning each list entry to the appropriate identifier. When a new view is created, the list is first grouped by the sort field and next by whatever content field is appropriate. The problem is that the user sees the sort field in the first group header and there’s no way to turn it off in the list settings.

There are two ways to solve this problem. You can modify the SCHEMA.XML file for the list type and change the CAML to render the groupings the way you want them (read this post to learn how). The issue with this method is that it is a global change; all lists of the same type in the site definition will be changed. Alternatively, you can override the default styles using a web part which hides or alters the appearance of the stock group header on a page by page basis.

Each header level is contained within a table row that inherits the ‘ms-gb’ (first group header) or ‘ms-gb2’ (second group header) style from OWS.CSS. To override these styles, add a Content Editor Web Part (CEWP) to the page, open the Source Editor in the tool pane, and add your own stylesheet entry. For example, to hide the first group header row entirely (dark gray bar in default theme), enter the following:

Disable the CEWP’s ‘Display on page’ setting (under ‘Layout’ in the tool pane) to hide the web part, save it and the group header disappears. Because the CEWP is rendered after the default stylesheet references in the site definition page, it overrides the settings in OWS.CSS following the cascading rules of CSS (last reference takes precedence). Technically, the header still exists, users just can’t see it. Use the same method to apply font colors, background images, margins, and any other CSS style properties.

Unfortunately, this method doesn’t work as well for altering the actual text of the header entry (i.e. removing the ‘[Group Name] :’ prefix). You can use JavaScript to achieve this effect by altering the innerHTML property of each header and using the getElementById method, but you’ll have to apply it individually to each header ID and they’re not always the same from page to page. Plus, JavaScript in CEWP’s often causes unpredictable results (such as preventing web parts from being saved or disabling tool bar functions). If you do plan to use JavaScript on a web part page, it’s always best to store the script in a document library as a .js file or as part of an HTML page then call that page using a Page Viewer Web Part.

Extreme SharePoint Design: Dynamic Style Sheets

2006-02-13T05:25:00.000-08:00

Both WSS and SPS provide mechanisms for altering the presentation of pages using custom style sheets. While WSS provides a relatively simple template structure for improving the stock look and feel on a site-by-site basis, SPS customizations must be applied on a portal-wide basis (using the custom style sheet field in Site Settings) or for each individual site definition. If you employ user controls in your site definitions to create custom headers, navigation elements, etc. this means that each site definition must reference it's own separate control. This makes code maintenance difficult and time consuming.

But perhaps the most glaring deficiency in employing custom styles is the lack of style continuity in administration pages. No matter how eye-catching your design is, as soon as the user attempts to manage portal content, change settings, create a list, or do one of a hundred other administrative tasks, the styles revert back to the boring out-of-the-box template (this holds true for both WSS sites and SPS portal areas).

In order to overcome this limitation, a method of dynamically switching styles for sites, areas, and administration pages is needed Fortunately, the SharePoint object model provides several functions that can be leveraged to create a style switcher based on site definition, site template, user id, group, or any number of other parameters depending upon your requirements.

To begin with, if you are not already employing user controls in your custom site definitions, you should consider doing so as soon as possible. They are flexible, reusable, and easy to maintain. Perhaps most importantly, they also provide access to server-side scripting which is disabled on standard ASPX pages within SharePoint. Creating a user control is simple - modify a base portal page (such as the default page for a cloned site definition) until you have the desired look and feel, then extract that code into a blank HTML page with all <HTML>, <HEAD> and <BODY> tags removed. Add the proper registrations to the top of the page (see example below) and save it into a centrally-accessible directory (such as /bin or /_layouts/1033) with an .ASCX extension. In the default page, add a page registration for the file and a code reference in the body of the page and you're done. You can now reference the user control from any portal page - changes made within the control will be viewable on all pages which reference it. Now you only one page to maintain instead of dozens.

Here's an example of a user control (header.ascx) that creates a custom portal header:

<%@ Control Language="c#" AutoEventWireup="false" TargetSchema="http://schemas.microsoft.com/intellisense/ie5" %>
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SPSWC" Namespace="Microsoft.SharePoint.Portal.WebControls" Assembly="Microsoft.SharePoint.Portal, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<table width="100%" border="0" cellpadding="0" cellspacing="0" ID="Table2">
<tr>
<td width="100%" coldiv="4" height="14" class="spsHeader_Banner"></td>
</tr>
<tr>
<td width="40" height="80" align="center" valign="middle" class="spsHeader_Logo"><img src="/_layouts/images/Header_Left.gif"></td>
<td width="100" valign="middle" class="spsHeader_Name"><SPSWC:WebProperty Property="SiteTitle" runat="server" /></td>
<td width="99%" valign="bottom" class="spsHeader_Title">Home</td>
<td width="350" valign="bottom" class="spsHeader_Actions">
<table height="100%" width="100%" border="0" cellpadding="0" cellspacing="0" ID="Table3">
<tr>
<td coldiv="2" height="99%" valign="top" align="right" class="spsHeader_MySite" nowrap ><SPSWC:PageHeader id="PageHeaderID" runat="server" PageContext="SitePage" ShowTitle="false" Mode="LinksOnly" /></td>
</tr>
<tr>
<td width="75" valign="middle" align="right" class="spsHeader_Search">Search</td>
<td valign="middle" width="99%" align="right" class="spsHeader_SearchBox"><SPSWC:RightBodySectionSearchBox id="RightBodySectionSearchBoxID" runat="server" SearchResultPageURL="SEARCH_HOME" FrameType="None" /></td>
</tr>
</table>
</td>
</tr>
<tr>
<td coldiv="4" width="100%">
<div id="spsHeader_NavMenu">
<SPSWC:CategoryNavigationWebPart runat="server" id="HorizontalNavBar" />
</div>
</td>
</tr>
<tr>
<td height="1" coldiv="4" width="100%" class="spsHeader_Separator"></td>
</tr>
</table>

Note the page registrations at the top of the file - these provide access to SharePoint's built-in functions and the object model. On the default page, add a reference to the control like this:

<%@ Register Tagprefix="CUSTOMUC" Tagname="Header" src="/bin/Header.ascx" %>

Then insert the control reference in the body of the page, like so:

<CUSTOMUC:Header id="Header" runat="server"></CUSTOMUC:Header>

Once you have the control in place, you can add code to dynamically change style sheets. For example, let's assume that you have a style sheet for each standard portal definition - custom_sps.css, custom_msite.css, custom_topic.css, custom_news.css, and so on. In order for the header to have a different look for each area, the style sheet reference in the file must change based on which site definition the page being viewed is derived from. To make this happen, add the following code to the top of the control, just after the page registrations:

<%
if (SPControl.GetContextWeb(Context).WebTemplate == "SPS")
{
Response.Write("<link rel='stylesheet' type='text/css' href='/_layouts/" +
System.Threading.Thread.CurrentThread.CurrentUICulture.LCID + "/styles/custom_SPS.css'>");
}
else if (SPControl.GetContextWeb(Context).WebTemplate == "SPSMSITE")
{
Response.Write("<link rel='stylesheet' type='text/css' href='/_layouts/" +
System.Threading.Thread.CurrentThread.CurrentUICulture.LCID + "/styles/custom_msite.css'>");
}
else if (SPControl.GetContextWeb(Context).WebTemplate == "SPSTOPIC")
{
Response.Write("<link rel='stylesheet' type='text/css' href='/_layouts/" +
System.Threading.Thread.CurrentThread.CurrentUICulture.LCID + "/styles/custom_spstopic.css'>");
}
else if (SPControl.GetContextWeb(Context).WebTemplate == "SPSNEWS")
{
Response.Write("<link rel='stylesheet' type='text/css' href='/_layouts/" +
System.Threading.Thread.CurrentThread.CurrentUICulture.LCID + "/styles/custom_news.css'>");
}
else
{
Response.Write("");
}
%>

To add additional site definitions, insert an extra "else if" statement for each definition name (WSS sites use the STS definition). The key to this script is the value of GetContextweb(Context).WebTemplate method. This method returns the site definition name for the page being viewed. For individual WSS site collections, you can also use GetContextWeb(Context).Site.RootWeb method. What makes this method even more useful is that the site definition/root web value persists on administration pages (see Extreme SharePoint Design: Customizing SharePoint Administration Pages for detailed instructions on how to employ user controls on administration pages).

Pages which call the new header will inherit the base styles, the custom styles applied at the portal level, and the definition-specific file referenced in the dynamic style sheet script. Due to the cascading principle of CSS, the last-referenced file takes precedence, insuring that the proper style is displayed. By utlizing dynamic style sheet switching you will create a more consistent user experience and reduce the amount of maintenance required for custom site definitions.

Extreme SharePoint Design: Customizing SharePoint Administration Pages

2006-01-26T11:18:00.000-08:00

Administration pages in SharePoint are often the Achilles heel of a customized portal design – they exist outside of the site definition framework, they don’t inherit templates, and they implement a confusing array of shared code structures. This can create usability issues as users switch from a cohesive design on default and list pages to the default GUI and navigation when trying to create a new list or add an alert.

Depending on your design, customizing administration pages can quickly become a nightmare – if just modifying the header is not enough then you’re in for a bumpy road ahead. Here are a few tips that can help you get from stock to custom without the need for a morphine I.V. drip:

Primary Page Structures

There are 215 .ASPX files in the /layouts/1033 directory. Seventy-eight percent of these fall into one of two primary code structures. For simplicity, we’ll call them the ‘SPS’ style and ‘WSS’ style. The SPS style relies upon a server-control structure to render page content; the WSS style uses more traditional HTML code to display content.

The following code renders the page header in the SPS style:

This is how the same header is retrieved in the WSS style:

The most important difference between the two files is the WSS style’s utilization of the AlternateHeader property. The code first checks to see if an alternate header exists – either PORTALHEADER.ASPX or ALTERNATEHEADER.ASPX – and, if so, retrieves the code from the file and renders it; if not, it renders the code between the if…else blocks. This is a useful mechanism because the alternate header files function the same way as a user control – a central file that can be modified to match the new portal design scheme and is accessed from many pages – but it’s only applicable to the WSS style. How do we apply this same concept to the SPS style?

User Controls

Directly modifying the SPS style pages to replace the header is pretty straightforward – just replace the contents between the SPSWC:PageHeader tags (if you aren’t going to use the SPSWC:CategoryNavigationWebPart control in your code, be sure to leave it in place and comment it out). The problem is that there are 67 of these files so maintaining the customized code can become an issue. The solution is to implement a user control to replace the default code and duplicate the alternate header functionality. But there is a catch (naturally).

Pages in the /layouts/1033 directory can utilize external code files but only if they reside in the same directory. So, unlike site defintion files, for which user controls are normally stored in the virtual server /bin directory, any controls created for administration pages must be stored in /layouts/1033; otherwise, the process is the same. Create the replacement code, save it in an .ASCX file in the /layouts/1033 directory, and reference it from each administration page.

First, remember that when creating a user control you need the correct page registrations for any code contained within the file. The standard registrations are:

<%@ Control Language="c#" AutoEventWireup="false" TargetSchema="http://schemas.microsoft.com/intellisense/ie5"%>;
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>
<%@ Register Tagprefix="SPSWC" Namespace="Microsoft.SharePoint.Portal.WebControls" Assembly="Microsoft.SharePoint.Portal, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>

You’ll also need to register the new user control at the top of each administration page, like this:

<%@ Register Tagprefix="CUSTOMUC" Tagname="spsPortalHeader" src="spsPortalHeader.ascx"%>

You can then call the code from within the page by placing the user control reference between the SPSWC:TopPageSection tags. For example:

<CUSTOMUC:spsPortalHeader id="spsPortalHeader" runat="server"></CUSTOMUC:spsPortalHeader>

Of course, you still have to modify all 67 SPS style pages but by implementing user controls you only have to do this once; after that, you make changes only to the .ASCX file and they will be propagated automatically.

Beyond Headers

Sadly, replacing headers is the easiest part of administration file customization. Beyond that you enter into the realm of painful line-by-line replacement. WSS style pages are a bit easier as you have direct access to the page body code, which can be edited easily enough (user controls can also save you some headaches here), but watch out – the structures change slightly from page to page and there are often hard-coded elements (such as page titles) so be careful how much editing you do. The same can’t be said for SPS style pages – they use nothing but server controls to render code.

The good news on both fronts is that creative manipulation of style sheets can overcome most design challenges, as long as you’re willing to live with the boxy and boring standard white content area. The primary styles in play here are ms-nav, ms-navframe, ms-titlearea, ms-titleareaframe, ms-titlearealine, ms-verticaldots, ms-colspace, ms-pageidi, ms-pageidpt, and ms-pageidta. You’ll also have to deal with the stock images at the top of the left column by moving them around or making them disappear altogether. Assuming you’ve already modified the styles for the navigation frame on the left and the associated menus, you should be well on your way to improving the bland look of those finicky administration pages.

Happy SharePointing!

UPDATE: Need to get rid of that pesky image at the top of the left column in the SPS style? Try Mike Rundle's text-hiding method. Add this to your style sheet:

.ms-pageidi
{ text-align: -100px }

Image be gone! (Note: it's still there, the text-align setting just moves it off the page where it can't be seen)

SharePoint UK User Group First Meeting

2006-01-24T09:16:00.000-08:00

Nick Swan has done a tremendous job putting together the SharePoint UK User Group. They’ve got a great site with some really good info for UK SharePointers. Their first meeting is being held Monday, February 13th. I know how much work goes into organizing these events so hats off to Nick and his team. If you live anywhere close to Thames Valley Park in Reading you should make every effort to attend (there are also some great pubs nearby so it’s definitely worth the trip).

Go here for all the information.

I do a fair amount of business in the UK and they really have a thriving SharePoint community. It’s great to see them getting support from Microsoft. Unfortunately I’m on a project Stateside all through February or I would be there to support the group. Have a pint of Abbott Ale for me, mates!

SharePoint Communities

2006-01-18T09:02:00.000-08:00

Lately, there’s been a great deal of debate about forming communities to centralize/aggregate/organize SharePoint-related content. I think every one of us who pontificates on SharePoint has lamented the lack of a distinct community structure at some point. There is no doubt that it’s frustrating, especially for new users, to find SharePoint content, tips, tricks, advice, code, best practices, and the like. There are blogs, aggregators, community sites, MSD2D, newsgroups – the list goes on and on. Now that’s the definition of confusion.

No one can really agree on how best to approach this problem – although we’re all aware that there is, indeed, a problem – but there seem to be three main approaches:

1. Centralization

Proponents of this approach believe that the only way to tame the beast is to bring all of the various resources together under one roof (which usually means THEIR roof) to provide a one-stop-shopping approach. While this initially sounds like an attractive proposition, there are all kinds of issues, like: Who controls the platform? Who determines format? Who maintains the directory? Who has final say on contributions and content? Is somebody profiting disproportionately from it? How are contributors engaged? Who gets the AdSense revenue?

One very important shortcoming of a centralized resource is that a structured framework by its very nature is anathema to creativity. Most community contributors see their sites/blogs as labors of love and means of expression – they don’t want to use somebody else’s template or format or rules. Centralization is their kryptonite – they work under too many restrictions from day to day and free expression of their ideas is a constructive outlet. The overall community may not need yet another WSS site with a fancy template and a bit of original content but the person who built it needs it for their own personal satisfaction and edification. This is a powerful factor that cannot be overlooked (and too often is).

And let’s not be so blind as to think that there is not a profit motive behind many of these efforts; often times somebody, somewhere, wants to get paid (which is neither good nor bad, it’s just reality). There’s a natural level of distrust between the community and the people who run commercial enterprises; they assume, whether right or wrong, that the business owner wants their content for the sole purpose of enriching themselves. In truth, that’s probably a rare occurrence (I can’t think of one example in the SharePoint community where this is absolutely the case), but the perception still exists. This is the true Achilles heel of centralization.

Then, of course, there is Microsoft’s centralization effort, which you would think lends itself most to the profit motive argument but in reality is probably the least likely to support that hypothesis (Microsoft is going to sell lots of CAL’s regardless of what all of us post on the web). There’s lots of distrust here too but for a different reason – people are worried that Microsoft will police their contributions, stifling dissent and revoking it’s favor (like MVP status) for those that don’t toe the line. I don’t know if this will really happen or not but I will admit that it concerns me – how long do you think my Extreme SharePoint Design series of posts would last on an MS sponsored site? They’d never make it past the editors, I would imagine, because they show users how to solve problems or overcome inbuilt limitations that don’t necessarily jive with what MS defines as a ‘supported’ solution.

Having said all that, what are the advantages of centralization? Ease of use, for one, especially for new users. Efficiency as well, in that we would all spend less time searching for what we need to know. I suppose a certain level of consistency would also be achieved along with elimination of duplication if everyone is aware of what other contributors are saying. There’s probably a bit of esprit de corps that would go along with being on the same team and enthusiasm, as we all know, is infectious. And let’s not forget that together we could probably achieve more in one form or fashion than we could each working on our own.

So are the benefits enough to outweigh the disadvantages? I suppose the community at large will decide, or they may choose…

2. Decentralization

This model leaves things just as they are. Lots of different content islands floating around the SharePoint ocean with no direct links between them. Users leverage existing tools like Google, MSN, Yahoo!, Technorati, Feedster, and RSS feed readers/aggregators to find what they’re looking for. Convenient? No. Efficient? Not even close. Effective? Hardly. But it is easy, as no one has to build or maintain a centralized resource, and it doesn’t require users to do anything different than what they already do when looking for other types of information.

This model is already in place and, if it were working well, I imagine that fewer people would be decrying the current state of affairs, so something is rotten in Denmark (my express apologies to our Danish friends for that turn of phrase). I know how confusing it is for new SharePointers – I hear from my clients all the time about how hard it is to find good information. Frankly, there’s just too much out there for them to catalog and synthesize. It’s second nature to us because we live and breathe this stuff every day but they have real jobs with other responsibilities. And I know lots of people want access to more resources because the most popular feature on my web site is my blogroll (I wish it were the description of my service offerings or my contact page but sadly it is not to be).

It’s also very hard to discover new content in a decentralized model. When all the information is pulled instead of pushed you have to know exactly what you’re looking for. Free association is no strong point here – if you’re looking for needles, that’s what you’re going to get, even if a match stick might work better. It’s no secret that you always find what you were looking for yesterday when you’re looking for something else today. By way of example, Heather has one of the best resources on the web for SharePoint customization but people still post questions to the newsgroups that she has long since answered in-depth. I wish more people would use SharePoint BlogSearch but they don’t – it’s mostly a handy tool for me to find postings from other bloggers without wading through Technorati’s endless parade of irrelevant results. And just a few months ago I had a user point me to one of Bil Simser’s posts on automating list metadata from Word documents that I was unaware of – and I read Bil’s blog religiously! Talk about an embarrassing moment; if I don’t know these things off the top of my head, how on earth is Joe SharePoint Administrator supposed to cope? There’s just too much out there for anyone to get a good handle on.

Which leads us to…

3. Affiliation

This is a middle-of-the-road approach that places more importance on the connections between contributors than it does on command and control. A Federalist solution, this model encompasses as many content islands as everyone can build so long as there are good links between the islands, perhaps with a DNS-root-server type of directory listing hosted somewhere. This is in line with the organic growth model of most online communities and eschews any sort of governance other than mutual accountability.

As with any group of city-states, the overall economy of the region is only as good as the trade routes between destinations. In other words, if we can’t all agree on some uniform method of linking to each other and cross-publishing then the whole garment will unravel. We know the ‘web ring’ concept doesn’t really work, so we’ll have to come up with a better method of maintaining the roadways between our islands. And there still has to be a unified directory somewhere, which opens up the same control issues as complete centralization.

This method does seem, at least on the face of it, to blend the best of both the centralized and decentralized approaches. Yes, we all have to agree on some way to keep traffic flowing between us, but it would sure make the task of finding information easier. And contributors would be free to exercise their creative talents. The directory is a problem, if for no other reason than someone is going to have the task of maintaining it, and it will have to contain real or near real-time information. No easy task, to be sure.

So what’s the final solution? I don’t know any more than you do. Personally, I think the Affiliation model works the best but I could be wrong – I know several of my clients would much prefer Centralization because it makes their work lives easier but many community members are staunch adherents to the Decentralization metaphor. The two constituencies seem to be at opposite ends of the spectrum. Judging by the community reaction to any proposition for centralization, I doubt we will see this happen any time soon so it may become the de facto loser, with decentralization winning by default since it requires no additional effort on our part (I sure hope that’s not the reason but we can’t rule out general sloth as a factor). One thing’s for sure – spirited debate on the subject isn’t about to die any time soon!

SharePoint BlogSearch Update

2006-01-17T12:45:00.000-08:00

I have updated SharePoint BlogSearch with a bunch of new blogs (see a complete list of included blogs here). I've also modified some of the search parameters to return more relevant results and better default groupings. Incremental updates are now being done weekly to conserve bandwidth; hopefully, this won't cause adversely affect any search results. Should you notice something missing that needs to be there just email me and I'll check it out.

I've also added a BlogSearch form to the main page; just go to The eGroup Web Site and you'll see it on the right side of the page. If you'd like to use this form on your web or blog site, copy and paste the following code into your HTML (style references are included so you can add them to your default CSS and change them accordingly):

<form method="get" action="http://www.theegroup.net/search.aspx" target="_top">
<table width="250" border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="left" valign="bottom" style="padding-right: 3px"><img src="http://www.theegroup.net/_layouts/images/SPSSearch2.gif"></td>
<td align="left" valign="bottom" style="font-weight: bold; font-family: verdana, arial, helvetica, sans-serif; color: #1B6E89; padding-bottom: 3px; font-size: 8pt;">SharePoint BlogSearch</td>
<td></td>
</tr>
<tr>
<td></td>
<td align="left" valign="bottom" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 8pt"><input type="text" name="k" size="35"/><input type="hidden" name="s" value="SharePoint%20Blogs"/></td>
<td align="left" valign="middle" style="padding-left: 3px"><input type="image" name="Submit" src="http://www.theegroup.net/_layouts/images/icongo02.gif"/></td>
</tr>
</table>
</form>

As always, let me know if a blog is missing that should be on the list or if you would like your blog excluded from the index.

Happy blogsearching!

SharePoint Forge Opens Its Doors

2006-01-12T06:45:00.000-08:00

Many of us have complained in the past that there is no central repository for SharePoint knowledge, code, web parts, techniques, etc. Well, those days are over. Bil Simser's SharePointForge is now open for business.

Go check it out and let Bil know how much you appreciate his hard work.

An Open Letter to SharePoint Recruiters

2006-01-11T08:07:00.000-08:00

I get a lot of emails from recruiters looking for SharePoint resources. I welcome every message and try my best to connect the people I know with each opportunity that comes my way. One thing that I see over and over again is a job requirement that demands top-notch coding skills alongside advanced design/customization/deployment/project management knowledge. This is like asking the guy at GM who designed your SUV to also be the mechanic - they are two completely separate disciplines and anyone who claims to be good at both is going to be horrible at each one.

When was the last time you saw an architect framing a house and doing the brickwork? Or a graphic designer building a server farm? Or a nurse doing brain surgery?

Software architects and software developers have completely different skill sets. Yes, some skills overlap to a small degree, and knowledge of one discipline can make you better at the other, but to be really good at something you have to focus on that skill to the detriment of all others. I don’t write code not because I can’t but because there are people out there who can program circles around me with their eyes closed - but ask those same superstar developers to manage an end-to-end portal implementation or do all the design and customization work to take a project from mock-up to production and you’ll get that deer-in-the-headlights look. They’ll tell you straight up that’s not what they do, that’s what architects and designers do. And if they don’t then they are a) lying and b) bad developers. Don’t hire them. Period.

So please, to every recruiter out there, stop trying to shoe-horn two bodies into a single position - it won’t work and your client will definitely not be happy with the result. If you get a requisition with this type of ridiculous stipulation it’s your job to tell the hiring manager that he/she needs two experts, not one, and you’ll be happy to go find them both. Let people do what they do best - good personnel placement is about fitting round pegs into round holes not drilling out bigger holes to make room for triangles, squares and octagons.

</rant>

SharePoint User Interface Customization

2006-01-11T07:48:00.000-08:00

Heather has a great new article on customizing the SharePoint user interface. Like her, I wish I could give you a step-by-step guide on how to do it but there's just no simple solution (here are a few tips to get you started ). In Heather's words:

Customizing SharePoint is like riding a bike, it is very hard to tell someone how to do it, and that person really just has to try, fall down, try again, and they will figure it out.

I couldn't agree more.

Extreme SharePoint Design: Custom MySite Titles, Part 2

2006-01-10T11:32:00.000-08:00

In a previous post I demonstrated how to create custom titles on MySite pages that display the site owner's name and link back to the public view if the viewer is just a reader and the private view if the viewer is the site owner. The example used the Title property of the SPControl.GetContextWeb(Context) method to retrieve the site owner's name from AD. This works fine if the correct fields in AD have the right information in the right format (i.e First Name, Middle Initial, Last Name) but not so well if they don't. In many cases, the system returns the user name in the Windows default format of [Domain]\[Username].

Fortunately, SharePoint user profiles contain the user's full name, which is rendered in the <SPSWC:PersonalSpaceMainHeading> control; unfortunately, this information is not directly accessible via the object model and, like the Title property, the name is displayed in the 'Last Name, First Name' format. To further complicate matters, the PersonalSpaceMainHeading control insists on displaying an icon that indicates whether or not the user is logged into the system, even if the RenderPawn option is set to 'False'.

To circumvent these issues and insure that the user name is rendered as 'First Name, Last Name' in all instances, we'll first hide the <SPSWC:PersonalSpaceMainHeading> control on the page, then access it's innerText property to get the user name. Then we'll parse the user name into the correct format and apply logic to determine whether the user is a reader or site owner and then write out the proper link.

First, create a blank user control (server and client-side code are blocked from execution in a standard portal page) with the following registrations:

<%@ Control Language="c#" AutoEventWireup="false" TargetSchema="http://schemas.microsoft.com/intellisense/ie5" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SPSWC" Namespace="Microsoft.SharePoint.Portal.WebControls" Assembly="Microsoft.SharePoint.Portal, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Store the control in the /bin directory of your SharePoint virtual server. For this example, the control is named 'spsTitle_MySite.ascx'.

Next, create the container code for the display of the user name. For this application, we are simply enclosing the user name in a table with two cells: one that reads 'Personal Site' and one that displays the user name. Place the <SPSWC:PersonalSpaceMainHeading> control into a hidden DIV so it can be accessed later in the code:

<table align="left" cellpadding="0" cellspacing="0" border="0">
<tr>
<td width="5"></td>
<td valign="middle" class="Mysite">Personal Site</td>
<td valign="middle" class="Mysite_Title"><div id="PersonalSpaceMainHeading" style="display:none"><SPSWC:PersonalSpaceMainHeading RenderPawn="false" runat="server" /></div></td>
</tr>
</table>

Next, combine a server-side 'If...Then' statement with client-side Javascript which extracts the innerText of the PersonalSpaceMainHeading control and renders the user name and correct link:

<% if (SPControl.GetContextWeb(Context).CurrentUser.LoginName == SPControl.GetContextWeb(Context).Author.LoginName) { %>
<script>
var strFullName = document.getElementById("PersonalSpaceMainHeading").innerText;
var intLength = strFullName.length;
var intLocation = strFullName.indexOf(", ");
if (intLocation == -1)
{
strTitle = strFullName;
}
else
{
strTitle = strFullName.substring(intLocation + 1) + " " + strFullName.substring(0, intLocation);
}
document.write("<a href='/mysite/default.aspx'>" + strTitle + "</a>");
</script>
<% } else { %>
<script>
var strFullName = document.getElementById("PersonalSpaceMainHeading").innerText;
var strUrl = window.location.href;
var intLength = strFullName.length;
var intLocation = strFullName.indexOf(", ");
if (intLocation == -1)
{
strTitle = strFullName;
}
else
{
strTitle = strFullName.substring(intLocation + 1) + " " + strFullName.substring(0, intLocation);

}
document.write("<a href='" + strUrl + "'>" + strTitle + "</a>");
</script>
<% } %>

The first part of the 'If...' statement checks to see if the current user name matches the login name of the site author. Since personal sites are created by the user, the Author will always be the site owner. If the name matches, the subsequent javascript extracts the user name, parses out the comma and reverses the last name and first name (the full name is displayed in the 'Last Name, First Name' format by default). It then creates a hyperlink to the default (private view) of the personal site.

If the current user is not the author, the second javascript performs the same string manipulation then writes out the hyperlink using the public view URL (i.e. "/mysite/public.aspx?accountname=[UserID]"). This method will also work on shared and private libraries, personal pages, and lists, sending the user to the proper home page depending upon their role.

Now we'll need to call the user control from DEFAULT.ASPX and PUBLIC.ASPX. First, add a registration for your new control to the top of each page:

<%@ Register Tagprefix="UC" Tagname="spsTitle_MySite" src="/bin/spsTitle_MySite.ascx" %>

Next, call the control from the body of the page:

The final output looks something like this (you can modify the styles to render the link however you wish):

New SharePoint Discussion Forum Web Part

2006-01-09T07:29:00.000-08:00

Bil Simser has a new post describing a Discussion Forum web part he's working on. I can't tell you how many times I get asked about a replacement for the built-in discussion functionality. This is great news. I can't wait to get my 'grubby little hands' on it when it's finished.

Way to go, Bil!

Customizing the Built-In SharePoint Menus

2006-01-06T06:46:00.000-08:00

In previous posts (here and here) I’ve shown you how to build your own custom menus to relocate the standad Actions and Views menus. Great if you’ve got the time and the need to do so but what if all you want is a quick menu solution that looks and works just like the Modify Shared Page menu? Well, Gert van Bael has the answer. In this post he shows you how to duplicate the existing menu code to create a custom drop-down that supports nested menus.

Great tip, Gert!

Update: Dustin has a previous post on the same topic here.

Don't Fire the Messenger

2006-01-06T05:56:00.000-08:00

Recently I had a conversation with a prospective client in which it became apparent that a sales engineer had given them bad advice. It fell to me to explain the shortcomings of the SE’s recommendations, as gently as possible, to an IT manager who had only a very short time frame to impelement a large, customized SharePoint solution. He didn’t take it very well, so needless to say, I don’t think I’ll be getting the engagement.

I see this happen quite frequently and it always ends up with the consultant being the bad guy. I hate to break this to the world at large but SE’s aren’t always right; in fact, I used to be an SE and I’ll admit to being wrong on several occasions. The problem with the Account Manager/SE arrangement is that the two primary contacts the end user is engaged with have little, if any, real-world field experience. Their job is to sell licenses and be generalists; they have neither the time nor the motivation to be specialists with in-depth product knowledge gained by sweating it out in the trenches. I can tell you first hand that most SE’s work with the products they promote only in lab environments and have very little time for problem solving or immersive knowledge. I humbly admit to getting much of my knowledge during my SE days from product documentation and lab trials; I know for a fact that this is how it’s usually done.

Before all my SE friends flame me to death, understand that I’m not pointing fingers; it’s not your job to know this stuff, it’s my job - that’s why you sell the product and I make it sing and dance. Unfortunately, the client takes the SE’s words as gospel. On those rare occassions where the SE gets it wrong, I’m in a no-win situation - I have to tell the client that the solution is not going to work. There is no way to overcome the client’s response of “Well, that’s how Microsoft/Oracle/Cisco/IBM/Whomever said to do it” unless you have a long-standing relationship with that client. I can’t afford to nod my head and go along with it just to get the gig not only will it destroy my credibility with the client and eliminate any chance to do business with them again, it also means that I won’t be able to use that project as a reference (and we consultants live and die by our references).

So if you’re a consultant caught in a similar situation, what do you do? In my mind, there’s no question. You politely and respectfully tell the client why, based on your experience and knowledge, you think what they’ve been told is wrong. You also preface it by saying that you yourself may be wrong and there’s only one way to find out for sure - test the recommendations to see if they work. But you can’t dance around the subject or equivocate; doing so will eventually end your consulting career. You probably won’t get the assignment, but you will have a clear conscience and, when the client does try to implement the misguided suggestions and fails, your stock will go way, way up (no, they won’t call you in to fix it, but they might call you for the next project - just be sure to avoid the irresistable urge to say “I told you so”).

The Great Metadata Debate

2006-01-05T11:11:00.000-08:00

Dustin Miller kicked over the anthill when he ranted against subfolders in document libraries. Bil Simser concurs and stirred up some more dust with his post on the subject. Of course, some folks take exception to all this, preferring to do things the old-fashioned way, but the real question is: what good are subfolders, anyway? Do they help us categorize information? No, they do not. Do they help users find documents easier? Absolutely not. Are they intuitive? Not really. Do users know what to do with them? Ah, and there's the rub - users are comfortable with folders and they know how to use them. Now ain't that a bummer???

While Dustin and Bil are most certainly correct - metadata is by far the best way to categorize and display information in SharePoint - it turns out that there's a lot to be said for giving users something they're used to amidst a sea of change. Think about it for a minute: we toss around terms like 'metadata', 'lists', 'views', 'libraries', 'categories', 'content', 'areas', etc. like they're second nature to everyone but the truth is they only mean something to US. Your average user doesn't understand any of this and, what's worse, they don't even care. Here's a neat little trick - want to immediately turn a room full of professionals into a group of slack-jawed zombies? Use the word 'metadata' three times in one minute and see what happens. They instantly tune you out. I've seen it happen many times.

It may just be that we're asking people to digest more than they have an appetite for. Not only do they have to get used to all this SharePoint mumbo-jumbo but now they have to give up their folders too? For Pete's sake, it took them five years to learn what a network share is and now everything goes back into one directory? I swear I can hear the gears in their brains grinding to a halt when I get to this portion of the training.

Rarely do we have time to fully train (and re-train) every user before the new portal goes live. And even if we did, it's just too much for them to absorb. So we make a judgement call and weigh the options - do we have all these nice little categories that please our analytical minds or do we have immediately productive users? Every client I've ever had opts for the latter and rightly so - no organization can afford that much disruption.

Here's the other problem with metadata that nobody's talking about: it takes a lot of time to make it work right. Not only do we have to decide upon our categories but then we have to create lookups, add list definitions, modify views, group, sort, filter and generally yank, pull, twist, poke and wiggle until it all looks right. Then we need another library to do the same thing - but just a little bit different, of course - and we're at it again, like an army of SharePoint worker bees, buzzing around our little libraries being busy, busy, busy. Meanwhile the users are putting documents back into folders on the network 'cause that's what they know and all this SharePoint stuff is just too hard.

So what do we do? WE know metadata is good but user's don't. WE know it streamlines indexing and retrieval but they could care less. WE know folder structures are the worst way to organize information since, well, folder structures but nobody's listening. A bit of the ol' rock-and-a-hard-place, isn't it?

Well, here's an idea. Give 'em both. Give your users metadata AND folders. Let 'em store stuff the way they always have (at least for now) but also enforce metadata rules. Create standard list definitions and views for each document library that contain all the basic metadata fields that map directly to Word/Excel/etc. so they can fill out the fields in Office and don't have to fiddle with web forms (if you haven't done that yet, you're missing the boat. Read this immediately). Customize the base defs/views only when you have to. Let users upload docs into whatever folder structure they desire until it comes time to ween them off; say six months, or even a year, when they can hear 'metadata' without their eyes glazing over. You can always move the docs out of folders and into the base library later on (I know, I know, some links will be broken but your views will still be intact).

In other words, feed them the elephant one bite at a time so they get used to the taste then invite them to the banquet. Users will be much happier and they'll actually stick with it since the new has now become the old. You'll still have a contingent of naysayers who'll put up a fight when it's time to yank their beloved folders out but by that time they'll be a distinct minority instead of a vocal majority. It'll save you a lot of headaches and them a lot of frustration. That's a win-win if I ever heard one.

UPDATE: For more on metadata and how to use it, see Ian Morrish's post on Sharepoint and metadata.

UPDATE 2: Daniel McPherson links back to an older post on the same subject. His real-life example is dead on.

Extreme Sharepoint Design: Modifying User-Defined Web Part Pages

2006-01-05T08:07:00.000-08:00

User-defined web part pages allow web designers and portal members to create isolated pages with the same basic functionality as a standard area or site page. Because they are stored in document libraries instead of the area or site collection hierarchy, they can be created, deleted, and modified without affecting portal navigation, taxonomy or search results. They serve as an effective, low-impact method for enabling user creativity.

Customizing user-defined web part pages is not quite as tricky as overhauling a complete site definition but they do present the designer with a few unique challenges. For one thing, there are several types in every definition and each one is slightly different. For another, they have a few built-in limitations that will cause problems if you don't know what to watch out for. Coordinating the look and feel of these pages with the overall portal design will improve consistency and encourage users to create their own pages without impacting the portal architecture.

User-defined web part pages are stored in the DOCTEMP\SMARTPGS directory of each site definition, named in ascending numerical order (SPSTD1.ASPX, SPSTD2.ASPX, and so on). Each numbered file is directly related to an option in the Web Part Page Creation Wizard (SPCF.ASPX) section titled "Layout". The 'Choose a Layout Template' select box contains eight options for page layout, from a simple, single-column design to a complete, multi-zone web part page. Should you choose to edit Web Part Page Creation wizard page to add or remove items to/from this list, you will notice that the options are out of order in the select box code (line 251 of SPCF.ASPX):

<SELECT id="onetidWebPartPageTemplate" name="WebPartPageTemplate" size="8" onchange="DoTemplateOptionChange()">
<OPTION value="1">Full Page, Vertical</OPTION>
<OPTION value="3">Header, Left Column, Body</OPTION>
<OPTION value="4">Header, Right Column, Body</OPTION>
<OPTION value="2" selected="true">Header, Footer, 3 Columns</OPTION>
<OPTION value="5">Header, Footer, 2 Columns, 4 Rows</OPTION>
<OPTION value="6">Header, Footer, 4 Columns, Top Row</OPTION>
<OPTION value="7">Left Column, Header, Footer, Top Row, 3 Columns</OPTION>
<OPTION value="8">Right Column, Header, Footer, Top Row, 3 Columns</OPTION>
</SELECT>

The options relate to each page in the site definition as follows:

Option 1 -> spstd1.aspx -> Full Page, Vertical
Option 2 -> spstd3.aspx -> Header, Left Column, Body
Option 3 -> spstd4.aspx -> Header, Right Column, Body
Option 4 -> spstd2.aspx -> Header, Footer, 3 Columns
Option 5 -> spstd5.aspx -> Header, Footer, 2 Columns, 4 Rows
Option 6 -> spstd6.aspx -> Header, Footer, 4 Columns, Top Row
Option 7 -> spstd7.aspx -> Left Column, Header, Footer, Top Row, 3 Columns
Option 8 -> spstd8.aspx -> Right Column, Header, Footer, Top Row, 3 Columns

In addition, each option has an animated GIF of the same name associated with it that provides a thumbnail view of the page design. These images are located in the 60\TEMPLATES\LAYOUTS\1033 directory. Display of the thumbnails is controlled by the following script at the top of SPCF.ASPX:

function DoTemplateOptionChange()
{
var index = document.frmWebPage.WebPartPageTemplate.selectedIndex;
document.frmWebPage.PreviewImage.src = strImagePath + "spstd" + document.frmWebPage.WebPartPageTemplate.options[index].value + ".gif";
document.frmWebPage.PreviewImage.alt = document.frmWebPage.WebPartPageTemplate.options[index].text;
}

These images may be replaced with a custom animated gif that reflects the new page design or directed to another file name by editing the DoTemplateOptionChange() function.

Modifying the pages themselves is done in much the same manner as any other definition file - start with the default code and add or remove tags and HTML code as necessary - but there are a few issues to bear in mind when working with web part pages:

1. Web part zones in the page body (excluding the TitleBar zone; see below) are contained within a specific set of table cells which are referenced by a script that determines whether or not to display the cell based on it's contents (or, more accurately, the lack thereof). To recreate this functionality, be sure to place your web part zones inside the following cell:

<td id="_invisibleIfEmpty" name="_invisibleIfEmpty" valign="top" width="100%">

It is also necessary to include the following script somewhere on the page (the default location is just after the closing row tag in the parent table for the web part zones):

<script language="javascript">if(typeof(MSOLayout_MakeInvisibleIfEmpty) == "function") {MSOLayout_MakeInvisibleIfEmpty();}</script>

2. By default, the TitleBarWebPart is added to each web part page when it is rendered. This web part displays the page title and 'Modify Shared Page' menu link. This web part is NOT specified in any SCHEMA.XML file and cannot be disabled. Furthermore, it's target is the TitleBar zone and this zone must exist on the page or an error will occur after page creation. The zone can be located anywhere on the page (it does not have to exist in the "_invisibleIfEmpty" table cell). To hide it from view, it can be placed within a container DIV whose 'display' style is set to 'none', but doing so will require the addition of the Settings Link control (<WebPartPages:SettingsLink runat="server" />) in the title area.

3. If the portal design incorporates custom menus, those menus changes will cascade down to the web part pages. Incorporate any definition-specific menu options into the corresponding web part pages and remove any elements with localized dependencies (such as <SharePoint:RelatedTasks>, which depends upon the <Toolbar Type="RelatedTasks"> section in SCHEMA.XML) or context-sensitive options.

4. Web part pages in each definition are similar but not exactly the same. Take note of the different controls used in portal definition pages and STS definition pages; for example, pages in SPSPERS use <SPWC:PersonalSpaceNavigation> while pages in STS use <Sharepoint:Navigation>. Similarly, the HTML layout code may change from page to page, with DIV's, Tables, and other elements in unusual locations. As with any site definition modifications, when copying and pasting code be aware of the differing page registrations for each definition type and any tags which that definition relies upon for proper page rendering (like <SPSWC:PersonalSpaceNavigation runat="server" /> on personal site pages).

To implement web part page modifications, simply copy the modified files to the target server(s). Since there are no XML files associated with this page type, changes will be seen immediately without having to reset IIS.

UPDATE: Dennis has a great post on adding your own custom templates to the 'Create' page in SPS/WSS.

The Blog Editor Blues

2006-01-05T06:57:00.000-08:00

Riddle me this: Why is it so hard to find a blog editor that does everything most bloggers want in a single package? After fiddling for weeks with every editor out there I’m ready to pull my hair out by the roots. Some give you decent editing options but weak post management. Others are good at managing previous posts but don’t have nearly enough formatting options for new posts. Some are good at text, others at HTML. Do the people that develop these apps actually spend any time managing a blog? I’m thinking not.

Maybe I’m asking for too much. Here’s my list of requirements:

Consistent formatting - A paragraph tag should be a paragraph tag no matter what. For some reason every editor handles tags differently; what looks right in one rich text designer looks terrible in Blogger and then gets even further garbled by Feedburner. Why can’t HTML just be HTML?

Automatic Text Replacement - Is it really so hard to catch a less than/greather than symbol and replace it with properly encoded chracters while I’m typing or as soon as I cut and paste? We can figure out how to turn a computer into a virtual Bobby Fischer but we can’t get on-the-fly replacement to work? What the heck am I missing here?

Post Status Handling - If I mark something draft that means I want it to be a draft when it’s uploaded not a regular post. When I switch it from draft to publish status it should post immediately without further action on my part.

Outlook-Style View - I should be able to see previous posts in a pane on the left and the body of the post on the right. That way I can switch back and forth between posts without having a bunch of windows open.

Search - I’m forever linking back to previous posts and looking for information. I should be able to search those posts to find what I want and link to it with a single click. Speaking of...

Link URLs - Linking to posts should be easy; a single click and I’m done. The editor should insert the proper permalink from the blog address. This must be part of the same rocket science as text replacement because it doesn’t work right in any editor. I always seem to end up with some goofy address that has no bearing on reality. What gives?

Tags and Keywords - I want to set up a list of keywords and have the editor automatically catch those words in my post and insert the proper Technorati tags. No further effort on my part required. When I tag a word manually, the editor should find subsequent instances of that word and insert the same tag on it’s own.

This post is being written in Anconia RocketPost, which does a fair job but won’t replace my text on the fly (even though it says it will), doesn’t have a split-pane view, doesn’t handle post status properly (even though the options are there) and still garbles up my HTML between editing and posting. I’ve also tried BlogJet, w.Bloggar, Quamana and Ecto, which all fall short in various areas.

So I’m putting out a plea to the community at large. What do you use? Have you found anything that meets all these requirements? Am I just in outer space or what? Leave a comment and steer me in the right direction...

SharePoint RPC Methods

2006-01-04T12:06:00.000-08:00

I was browsing through Heather's list of SharePoint resources when I found this link to an RPC method that I was unaware of. That led to this article that documents the various RPC methods and provides even more links to other information.

If I'm not mistaken, isn't this just the sort of "associative trail" that Vannevar Bush had in mind all along???

UPDATE: Bil Simser has a great post on this topic that is a must read. Go check it out!

Top Ten Tricks for Customizing SharePoint

2006-01-04T06:30:00.000-08:00

In the spirit of helping new SharePointers along (see this post from Bil and this one from yours truly), here's a Top Ten list to start the New Year off on the right foot. For anyone about to dive into heavy SharePoint customization, this is a good list to keep handy (or to use for lining your cat's litter box, whichever you find more appropriate).

1. Simple HTML
Keep your HTML layout code as simple as possible. Use the minimum number of formatting elements (DIV’s, SPANs, Tables, etc.). SharePoint creates a tremendous amount of extraneous code at runtime; the less you add, the less chance for something unexpected to happen. Also, you’ll be cutting and pasting a LOT of code; fewer lines means fewer mistakes.

2. User Controls
Reuse as much code as possible by placing repetitious elements into user controls. Rather than repeating the layout code that defines web part zones and code areas on page after page, place it in an ASCX file, register the file location at the top of the page, and reference it in the page body. This creates a template-like effect for site definition pages in which you only have to modify one file to have a global effect. An added benefit is that code which cannot be executed within presentation files can be executed within a user control.

3. Custom User Menus
SharePoint menus take up a great deal of valuable screen real estate. There’s nothing magical about the left-hand navigation area; extract the menu elements and place them into collapsing DIV’s or pop-outs. While they’ll never be perfect, a basic set of menu layouts can free up 125 – 300 pixels of screen width. Place them in user controls to simplify maintenance.

4. Nested Style Sheets
SharePoint style sheets are a confusing maze of endless CSS code. Nest common code elements in your custom style sheets just like you would with HTML; create parent styles, indent each child style, and keep everything together in logical groupings. Copy existing styles from OWS.CSS and SPS.CSS into your custom sheet to overwrite the defaults and maintain compatibility.

5. Minimal Site Definitions
There are few occasions where more than one or two custom site definitions are necessary (in addition to the required SPS, SPSMSITE, SPSPERS, SPSSITES and STS, all of which can be replaced with a custom definition by modifying the WEBTEMP files). Each definition exponentially increases the amount of customization and future maintenance. Use the bare minimum number of definitions to meet the requirements.

6. Server Controls
Custom code elements that do not require user manipulation should be implemented as server controls instead of web parts. The layout is easier to design with fewer web part zones, the code is much more compact, and render times are much faster. Store them in the /Bin directory along with the user controls for layout.

7. Preserve Zone Names
Some functions, such as ‘Edit in DataSheet’ require a specific zone to be present on the page. To avoid erratic behavior, preserve the default zone names whenever possible but change their location to meet your requirements. This also reduces the amount of edits to the various SCHEMA.XML files.

8. Comments Before Deletions
Before deleting existing code, comment it out and test it with your modifications. Once you have a working page, go back and delete the extraneous elements one by one. There are some pages that absolutely must have certain elements in place – even if they’re hidden - or they won’t render properly. You’ll save yourself a great deal of frustration by working backwards through commented code than trying to add it back in later.

9. Assumption = Frustration
Never assume that the modifications you make in one definition will work in another. This is especially true of SPS and its deviations; the root portal definition is quite different from the subarea definitions. Diff the original files extensively before copying changes to a new definition. This rule applies in spades to administration pages, where there are multiple shared code structures and many one-off files.

10. Make CAML Your Friend
Much of what drives SharePoint lives in ONET.XML and SCHEMA.XML. The more extensive the modifications, the more you’ll need to work with these files. Learn the ins and outs of CAML and how to tweak it to meet your needs. Although at first intimidating, it’s nothing more than a structured XML superset. Begin by adding list definitions and move from there into creating custom lists and mastering views.

Happy SharePointing!!!

SharePoint RPC Methods

2005-12-30T11:12:00.000-08:00

Extreme SharePoint Design: Adding a Second 'Save and Close' Link to Surveys

2005-12-29T17:45:00.000-08:00

Surveys are usually short and to the point but sometimes they can be quite long, especially if there a large number of multiple-choice questions. Users often complain about having to scroll back up to the top of the page to save their responses after filling out the form (this is true of any list, not just surveys). Adding a second 'Save and Close' link to the bottom of the page is an effective solution for improving usability.

Like everything else in SharePoint, implementing this functionality is not quite as simple as it might first appear to be. First off, the pages that display the 'Save and Close' link, newform.aspx and editform.aspx, are just container pages for dynamically-rendered CAML (Collaborative Application Markup Language, that tangle of XML gobbledygook that makes SharePoint go). The real meat is in SCHEMA.XML under /Lists/Voting in the various site definitions (60/Template/1033/SPS and so on). This means that there is no direct HTML for you to edit; you have to modify the proper sections in the schema file.

To begin with, locate the following line:

<Form Type="EditForm" Url="EditForm.aspx" WebPartZoneID="Main">

This is the beginning of the definition section for the Edit Response form on EDITFORM.ASPX. There are four main sections which define the form display: <ListFormOpening>, <ListFormButtons>, <ListFormBody>, and <ListFormClosing>. The HTML for the toolbar that contains the 'Save and Close' link is found in the <ListFormButtons> section. If you haven't worked with CAML before this can be a bit intimidating. It helps to keep the following in mind:

1. It's just XML. Fancy XML, yes, but still XML. All the same rules apply. What's different is the terminology and a whole slew of new tags.

2. All presentation code is encapsulated in <HTML></HTML> tags, and the code itself is encoded within <![CDATA[ blocks. Once the proper tag elements are in place, it's regular old HTML in between.

The first code you will see following the section open tag for <ListFormButtons> is an If...Then expression that checks to see if content approvals are enabled. The <Switch> tag is much the same as an "If" in VB, C# or JavaScript; the <Expr> tag (for 'Expression') is the actual expression and the <Case> tag is the comparison value. The <Default> tag then contains the "Else" value. So, another way of writing this:

<Switch>
<Expr><ListProperty Select="ModeratedList"/></Expr>
<Case Value="0"/>
<Default><HTML><![CDATA[<p>Hellow World!</p>]]></HTML></Default>
</Switch>

Would be this:

function CompareValue()
{
if ModeratedList.Value = 0
{
return;
}
else
{
document.write("<p>Hellow World!</p>");
}
}

For this example, we'll leave the expression in place but take out the messages pertaining to content approvals; since the button at the top of the page will already contain this information, we don't need to repeat it. Removing the redundant code is easy - just strip out everything between the HTML tags so the resulting code looks like the following:

<Switch>
<Expr><ListProperty Select="ModeratedList"/></Expr>
<Case Value="0"/>
<Default><HTML></HTML></Default>
</Switch>

NOTE: Generally, it is a good idea to leave as much of the original code in place as possible. For one thing, you don't know what other elements on the page might be affected (such as nested TD's or DIV's) as it is nearly impossible to read the HTML structure within CAML; for another, a control on the page might rely upon the element to work properly. In this case, the table is stand-alone and there are no ID or NAME tags for a control to reference so the HTML code is obviously discrete and can safely be removed.

Next, we'll copy the toolbar code and append it to the end of the <ListFormBody> section. Cut and paste the following block of code just before the closing </ListFormBody> tag:

<HTML><![CDATA[ <TABLE class="ms-toolbar" style="margin-left: 3px;" cellpadding=2 cellspacing=0 border=0> <TR> <TD class="ms-toolbar"> <table cellpadding=1 cellspacing=0 border=0> <tr> <td class="ms-toolbar" nowrap> <a tabindex=2 ID=diidIOSaveItem class="ms-toolbar" title=]]></HTML><HTML>"Save"</HTML><HTML><![CDATA[ ACCESSKEY=S href="javascript:SubmitForm()" target="_self"> <img src="/_layouts/images/saveitem.gif" ID="tbbuttonstart1" alt=]]></HTML><HTML>"Save"</HTML><HTML><![CDATA[ border=0 width=16 height=16></a></td> <td nowrap> <a tabindex=2 ID=diidIOSaveItem class="ms-toolbar" ACCESSKEY=S href="javascript:SubmitForm()" target="_self"> <LocID ID="L_EditFormSave">]]></HTML> <HTML>Save and Close</HTML> <HTML><![CDATA[</LocID> </a> </td> </tr> </table> </TD> <TD class=ms-separator></td><TD class="ms-toolbar"> <table cellpadding=1 cellspacing=0 border=0> <tr> <td class="ms-toolbar" nowrap> <a tabindex=2 ID=diidIODeleteItem class="ms-toolbar" title=]]></HTML><HTML>"Delete"</HTML><HTML><![CDATA[ ACCESSKEY=X href="javascript:DeleteItem()" target="_self"> <img src="/_layouts/images/delitem.gif" ID="tbbuttonstart1" alt=]]></HTML><HTML>"Delete"</HTML><HTML><![CDATA[ border=0 width=16 height=16></a></td> <td nowrap> <a tabindex=2 ID=diidIODeleteItem class="ms-toolbar" ACCESSKEY=X href="javascript:DeleteItem()" target="_self"> <LocID ID="L_EditFormDelete">]]></HTML><HTML>Delete Item</HTML><HTML><![CDATA[</LocID></a> </td> </tr> </table> </TD> <TD class=ms-separator></td> <TD class="ms-toolbar"><table cellpadding=1 cellspacing=0 border=0><tr><td colspan=2 nowrap><a tabindex="2" class="ms-toolbar" ACCESSKEY=G ID=diidIOGoBack href="]]></HTML><ListProperty Select='DefaultViewUrl'/><HTML><![CDATA[" ONCLICK="javascript:GoBack(']]></HTML><ScriptQuote NotAddingQuote="TRUE"><ListProperty Select="DefaultViewUrl"/></ScriptQuote><HTML><![CDATA[');return false;" target="_self"><LocID ID="L_EditFormGoBack">]]></HTML><HTML>Go Back to Survey</HTML><HTML><![CDATA[</LocID></a></td></tr></table></TD><td width=100%><img src="/_layouts/images/blank.gif" alt=""></td> </TR> </TABLE> <table width=100% border=0 cellpadding=0 cellspacing=2> <tr> <td colspan=5 height=3><img border=0 width=1 height=3 src="/_layouts/images/blank.gif" alt=""></td> </tr> </table><font size=1><br></font>]]></HTML>

Now we need to reformat the toolbar code to get rid of the 'Go back to the survey' link and shorten the length to the size of a normal button. Here is the altered CAML (you might want to cut and paste each block into an editor, restore the formatting and diff the files to see the changes):

<HTML><![CDATA[ <table width="100%" cellpadding="0" cellspacing="0" border="0"> <tr> <td width="100%" height="20"></td> </tr> </table> <TABLE class="ms-toolbar" style="margin-left: 3px;" cellpadding=2 cellspacing=0 border=0 width="115"> <TR> <TD class="ms-toolbar"> <table cellpadding=1 cellspacing=0 border=0> <tr> <td class="ms-toolbar" nowrap> <a tabindex=2 ID=diidIOSaveItem class="ms-toolbar" title=]]></HTML><HTML>"Save"</HTML><HTML><![CDATA[ ACCESSKEY=S href="javascript:SubmitForm()" target="_self"> <img src="/_layouts/images/saveitem.gif" ID="tbbuttonstart1" alt=]]></HTML><HTML>"Save"</HTML><HTML><![CDATA[ border=0 width=16 height=16></a></td> <td nowrap> <a tabindex=2 ID=diidIOSaveItem class="ms-toolbar" ACCESSKEY=S href="javascript:SubmitForm()" target="_self"> <LocID ID="L_EditFormSave">]]></HTML> <HTML>Save and Close</HTML> <HTML><![CDATA[</LocID> </a> </td> </tr> </table> </TD> </TABLE> <table width=100% border=0 cellpadding=0 cellspacing=2> <tr> <td colspan=5 height=3><img border=0 width=1 height=3 src="/_layouts/images/blank.gif" alt=""></td> </tr> </table><font size=1><br></font>]]></HTML>

In essence, all we've done is shorten the original toolbar, removed the separator and second link, and added a second table that acts as a spacer (a DIV or clear gif would work just as well). Once finished with EditForm.aspx move on to NewForm.aspx and repeat the process (don't just cut and paste the modified code from EditForm - the two files work a bit differently).

After modifying these two sections, save the file and copy it to the site definition directory on your front-end web server(s). Remember, when altering any of the XML files, you must perform an IISRESET on each FE to see the changes. After resetting, view any survey to see the results. You should have a survey form that looks similar to the following:

This same technique can be used for any list with forms that extend beyond the fold and you can always modify the HTML code apply a different style to the toolbar (like, for example, the wizard buttons in SharePoint) or add javascript drop-downs, mouseovers, etc.

How To or What For?

2005-12-21T12:20:00.000-08:00

Shane believes we need more end-user material on the web. Heather thinks thats all fine and well but nobody would use it. Who's right?

For once, I agree with them both (see, I can be agreeable from time to time. It is Christmas after all). One of the most frustrating aspects of new portal deployments is end-user training; there's so much to teach in so little time. Users only retain a fraction of what I show them and, if they don't go use it right away, forget the little that they did learn. I've wanted to put together a bunch of short tutorials for well over a year on SharePoint basics but just can't seem to find the time.

On the other hand, I've also had Heather's experience; what I have created is rarely used by anyone. Users ask for guidance but what most of them really want is for you do it for them. Let's face it; the average job description doesn't include "wrestling with SharePoint" in the 'Duties and Responsibilities' section.

So what to do? Perhaps the best solution is to publish what we've got, expose it to the users, and if they learn from it, fine; if they don't, hey, we tried. If we all contributed a bit here and there to some central blog somewhere we could probably cobble together a good resource in a jiffy. Nobody would have to take on the whole responsibility and we could all syndicate the content via XML to our individual portals (like an FAQ, of sorts, but shared by everyone). Set some categories, let all the SharePointers post to it, and see how it flies. Track it via Google Analytics and see if anyone is using it.

I'm game. I'll even go first with a few short step-by-step tutorials. I can't manage the blog though - too much on my plate right now. Anybody else want to chip in???

Enabling the 'Modify Item-Level Security' Link for Document Libraries

2005-12-20T11:45:00.000-08:00

A common method for handling list item access in public lists is to restrict users to viewing/editing only those items they have created. Each SharePoint list, with the exception of document and picture libraries, has a 'Modify item-level security' link on the left of the page, accessible from the 'Change permissions for this list' link in the 'Modify Settings and Columns' options. This handy feature prevents users from changing or viewing what other users have posted but allows them to freely edit their own items.

To enable this functionality for document/picture/forms libraries, you must edit the administration pages that control the display of list options. The first page, SHROPT.ASPX, is responsible for showing user permissions and the Actions menu for anonymous access, access requests, and item-level security. When this page is called from a document or picture library, the item-level security link is hidden. To display it, remove the lines 333 and 354:

Line 333 <% if ((m_auim == AclUIMode.LIST)&&(m_list.BaseType != SPBaseType.Issue)) { %>

...

Line 354 <% } %>

Leave the HTML code between the opening and closing curly braces intact. The item-level security link will now be displayed on SHROPT.ASPX for all document and picture libraries.

Next, you will need to remove several references to the document library type from LSTSETNG.ASPX. This file contains groups of menu items that are used for all types of lists; if...then blocks in the code control which options are shown for each list type. For example, the following block controls the display of the Document Version options for document libraries:

<%if ( iBaseType == SPBaseType.DocumentLibrary && !bIsCustomTemplate){%>
[HTML Code Removed to Conserve Space]
<%}%>

The function works by checking the base type of the current list against the list of base types in the object model; in this case, it checks to see if the current list type (iBaseType) is a document library (SPBaseType.DocumentLibrary). By removing references to SPBaseType.DocumentLibrary in key sections of the file, those elements will then be displayed on the page.

Begin by modifying line 630, changing it from this:

<% if ((iBaseType != SPBaseType.DocumentLibrary) && (iBaseType != SPBaseType.Issue))

To this:

<% if (iBaseType != SPBaseType.Issue)

Next, re-enable the hidden table row on line 646, going from this:

<% switch ( iBaseType ) { case SPBaseType.DocumentLibrary:%> <tr style="display:none;"><%break;default:%><TR><%break;}%>

To this:

<% switch ( iBaseType ) { case SPBaseType.DocumentLibrary:%> <tr><%break;default:%><TR><%break;}%>

Note: If you prefer, you can set the table row display to 'inline' instead of removing the style tag altogether.

Now do the same on line 654, changing it from:

<% if ((iBaseType != SPBaseType.DocumentLibrary) && (iBaseType != SPBaseType.Issue))

To:

<% if (iBaseType != SPBaseType.Issue)

That's it. You can now set item-level permissions for document, picture and form libraries. Test it by uploading a few items, changing the permissions, then logging in as a different (non-admin) user; if you set the view option to 'Only their own', the new user won't be able to see your documents. If you set the Edit option to 'Only their own', all users can see your items but when they try to save any edits they will be prompted for a login and thus prevented from making any changes.

Does SharePoint Play Well With Others?

2005-12-19T15:27:00.000-08:00

In the spirit of Bil Simser's advice for SharePoint newbies, here's my half-cent's worth of contributions for those just starting down our treacherous path:

A common mistake that I see organizations make with large portal implementations is succumbing to the mysteriously irresistible urge to add all sorts of custom, third-party and external applications to their SharePoint server farm. Perhaps because they have invested heavily in the hardware to scale their portal and want to wring every last drop of processing power from the cluster, or they have a desire to maintain some sort of URL continuity (like decreeing that all applications from this point forward will start with http://somecompanyportal/ whether they need to or not), or maybe because SharePoint exerts some sort of Bermuda Triangle effect on administrators, attracting web applications like giant moths to the flame, within a month of a new installation I invariably discover all sorts of strange things going bump in the front-end web servers.

While there is no set rule on what should and should not be added to a SharePoint server - and SharePoint certainly has the ability to live side-by-side with all other types of creatures - common sense should dictate that just because you can heap on every web app the company has ever developed into a tangled maze of unmanaged paths, that doesn't mean you should. There are a few important things to consider before you go installing that nifty new copy of Crystal Reports Server on your FE's:

1. ISAPI Filters

SharePoint works a lot of it's magic through a custom ISAPI filter called STSFLTR. This filter handles all incoming and outgoing traffic through IIS, passing requests to the proper DLL's and sending back customized responses (like alternate URL's). In order to redirect traffic around STSFLTR you have to create an unmanaged path; that is, a virtual directory that is not part of SharePoint. When STSFLT intercepts traffic to/from any virtual directory, it first checks to see if that path has been marked as excluded. If so, it stops processing and hands the traffic off; if not, it handles all traffic for that path. As you can imagine, the more unmanaged paths, the harder STSFLTR has to work. Since it already does a tremendous amount of heavy lifting, the more overhead you add vis-a-vis managed paths the greater the impact on performance.

As if unmanaged paths aren't bad enough, many applications install their own ISAPI filters. Depending upon what order these filters are in on any given virtual server, you may experience anything from the odd quirky page to complete portal failure. ISAPI filters exist for the very purpose of managing traffic before it gets to the web application; the more hurdles your traffic has to clear before getting to its destination, the greater the odds that something will get fall down along the way. While third-party ISAPI filters may or may not be a supported configuration, I can assure you that it is not a recommended configuration. I have yet to meet an ISAPI filter that has not wreaked havoc upon the portal at some point or another.

Bottom line - avoid adding any ISAPI filters to a virtual server running SPS or WSS. Capice?

2. Hardware Resources

Ever watched the performance counters on a medium server farm with 3000 users? All those people uploading files, making web-part connections, polling the virtual servers for web part galleries, querying web services for data view web parts, and the umpteen gazillion database calls make the trace grid look like a politician's polygraph in the last week of an election. Now image what might happen when you bolt on that payroll app that uses an ODBC client to suck every last byte out of the Peoplesoft Oracle database. It ain't pretty when all that CPU crunching brings the virtual server to its knees. About the time it starts taking users 20 minutes to add a content editor web part to their personal site is when your Blackberry starts smoking like a Rastafarian bus driver.

Network traffic is another hidden minefield for any portal administrator. Chatty programs are the death of web applications; all those bits running amok makes it hard for the good stuff to get through. Remember that pre-SP2 most SharePoint implementations used host headers, adding overhead to every web request handled by the FE's. Be wary of any applications which make too many TCP-based database calls or custom ports, which are often a good sign that a lot of yapping is about to occur. Http traffic is http traffic, and the more of it the NIC has to handle the less bandwidth available for those big portal pages (have you ever looked at the total size of a standard web part page when all the linked content has been rendered? Here's a hint - OWS.JS alone is nearly 400k. You do the math). Sure, you can put in gig switches and prioritize traffic and add NICs and so on but I've got a better idea: how about you just put that stuff on a different server and save yourself the headaches?

3. Service Levels

It never fails - users start screaming that the portal is down and everyone points their finger at the SharePoint admins. Like that data view web part you just added really caused all the WSS sites to implode like the outer wall during the battle of Helm's Deep. Please. While we may shoot ourselves in the foot from time to time as we try to figure out how to do something simple in the ever-so-elegantly-designed SPS admin pages (That's sarcasm, in case you missed it. Hello, Redmond, are you listening?), eight times out of ten some rinky-dink app has caused the worker processes to lock up and slammed the door on our highly-scalable, disaster-resistant, backed-up and failed-over portal cluster.

Is it really a good idea to jeopardize your hard-earned five nines with that ever-so-important holiday party RSVP app? If you absolutely have to know if Suzy Smartypants is bringing her husband and thirteen children to the summer picnic, is it too much to ask for the developers to write a web part instead of redirecting to a clunky ASP page? Last time I checked, Web Part Library is on the same page as ASP.NET Application under New Project in Visual Studio. Newsflash: SharePoint is an enabling platform; that means you can use it to D-E-V-E-L-O-P W-E-B A-P-P-S. Now quit asking us to add another virtual directory for your latest project "just this once" and learn what Protected Override Void RenderWebPart(HtmlTextWriter output) does. Got it?

Now, go forth and erect thy fortresses of SharePoint, letting no man (or wayward application) penetrate thy defenses...

UPDATE: After reading this post, a colleague pointed out that in some cases the business justification for a high-performance cluster includes the value of running other applications alongside SharePoint (as in "We need this hardware but we can't get it without giving some CPU cycles to the Finance app:). Okay, that's a fair rebuttal - it's harder than ever to get management to sign off on big capital expenditures so you do what you have to do to get what you need.

In such cases the argument shifts from how the SharePoint environment SHOULD be constructed to how much RISK you are willing to assume based on business needs. I don't have any solid metrics to apply here, but it should be fairly easy to come up with a quick value matrix that weights such factors as performance degradation, anticipated downtime, CPU cycles, disk cost, etc. and score each projected application using these factors. This would provide you with a rough idea of the impact each addition would have on your SharePoint environment. You can then respond to other stakeholders with that information and, depending upon the relative importance of each application, let the powers that be determine what level of risk they are willing to assume.

If you follow the guidelines mentioned here when designing your matrix and ensure that new applications do not violate any of these key factors (forcing all other apps to use their own virtual servers and application pools, for example, or adding bandwidth for chatty programs such as web services) you can at least minimize the impact of living with troublesome neighbors.

To Brand or Not to Brand...What Was the Question?

2005-11-29T12:35:00.000-08:00

While I was pontificating on the need for improved customization in SharePoint v.Next, Andy May suggests that it might be a good idea to find out if your client really wants to tackle the task of branding their portal. A fair question, and one that my clients have answered in multiple ways, from nothing more than an altered site logo to full, file-by-file customization of definitions and templates. As Heather points out, it's not that difficult to brand a portal implementation if you leave the underlying architecture definitions alone.

In my mind, there are three distinct types of scenarios:

1) Stock Portal - No branding or customization required. If you have limited resources or need to focus your resources elsewhere, such as application development or training, this might be the best option. This scenario is often chosen by those with little exposure to Intranet/Portal applications who just need a quick and affordable solution.

Example:

2) Branding - Applying a custom logo, colors, backgrounds, borders, fonts, buttons and other visual elements can be done in a few days from scratch or a few hours if you have a CSS template to work from. Assuming that time and resources are available, branding is an effective way to reinforce a corporate identity and create continuity with other line-of-business applications. Organizations with existing Intranets or portal-like applications often choose this route as it is both affordable and relatively painless. It is also a very good way to learn more about how SharePoint works behind the scenes.

Example:

3) Customization - Let there be no doubt: full portal customization is difficult, time consuming, expensive, and requires a high degree of skill and patience. Only clients who have deployed extensive portal solutions in the past request this level of modification, and rightly so; they have a solid understanding of the cost and risks involved. At best, a complete portal customization can be done in 30 days (I've done it and it was no picnic, believe me); at worst, it could take several months. And that's assuming that you're well-versed in all the mysteries of SharePoint; a neophyte who has to learn on-the-fly may never make it out of SharePoint Customization Hell alive (figuratively speaking, of course, and thanks to Heather for the highly appropriate terminology).

Example:

In the final analysis, it is up to you as the consultant or subject matter expert to explain these options to your client (or decision makers if you are part of the organization), make sure they understand the risk/reward ratio, and provide a realistic estimate of time and cost. One of the most common mistakes I see when consulting with clients regarding customization is the perception that SharePoint is limited in what you can do with the user interface. True, there are certain parameters which influence what the final outcome will be, but the truth is that there are very few things you can do with any web application that you cannot do with SharePoint.

I've discovered that even those who have worked with SharePoint for a good while are unaware of how extensively the product can be customized; not surprising, considering that most people probably give up after fighting with multiple site definitions, scads of similar-but-slightly-different list pages, CAML, never-ending XML files and a confusing maze of CSS. I don't blame 'em - it's enough to give anyone a headache (I keep an emergency supply of Advil on hand at all times).

Personally, I prefer a branded or fully-customized implementation over the stock look-and-feel simply from a business perspective. You wouldn't create an application or web site for a client without taking their corporate identity into consideration; the same applies to a portal implementation - you shouldn't avoid it just because SharePoint makes it more difficult than it really ought to be.

Here are a few tips to ease the pain:

1. Lean which CSS classes need to be modified to achieve your branding objectives and place them into a separate file, then use the custom CSS setting in portal admin to implement your alternate style sheets.

2. When overriding the default CSS classes, create a consistent structure that makes it easier to customize the files in the future (I like to nest related classes and define common elements, such as default fonts and colors, at the top of the file).

3. Once you've established the bare minimum required for branding a portal, use that CSS file as a template so you can apply it to subsequent implementations.

4. Study the Site Definition structures for patterns. Many of the files have similar code elements but for a few variances; learn what they are and where they occur. Once you have created a working definition, copying the files to new defs is mostly search-and-replace (your life will be much simpler with good diff and HTML search/replace tools; I suggest Beyond Compare and Search & Replace 98).

5. Do the same for admin pages in the /layouts/1033 directory. Take note of what works where (some pages are WSS only; others SPS; many are both). Learn which pages alternateheader.aspx works on and what it's limitations are.

6. Make extensive use of user controls (ascx pages). Like the include files of old, user controls give you the capability to modularize your definitions, sharing common code structures throughout the portal. All they require is a simple code registration in the header to tell the page where to find the file and what it's called. This can save you an immense amount of time and frustration. And, best of all, user controls allow you to execute code that may be blocked within certain files (did I mention alternateheader.aspx yet?).

7. Learn which web controls (<SPSWC:> elements) pages require and which can be deleted. Most pages can simply be wiped out and replaced with your own code but some, like txtlstvw.aspx, require fixed page elements in order to render properly (here's a hint: just comment them out, change the ID values, then substitute your own custom elements with the original ID's). Many Admin pages require the PortalHeader element but that doesn't mean you have to display it - just hide that pesky critter and go on about your business.

8. Watch those registrations! Some pages that look the same on the surface use different components to achieve similar results. Check the registrations at the top of the page to make sure that you have the right elements on the page. If you make extensive use of inline code blocks in user controls or admin pages be sure to include Microsoft.SharePoint.WebControls or the code will fail.

9. Look closely at the XML configuration pages. CAML is nothing more than a fancy superset of XML; anyone with a little bit of coding background can quickly determine what the programmer was trying to achieve and duplicate/alter it accordingly.

10. Get the SPS SDK and use it. It doesn't cover everything but there's a lot of good information in there that will help you out when you get into a bind.

11. Don't be afraid to break something! Test your changes extensively in an isolated sandbox that you can wipe out if things to awry. Keep a full copy of the original 60 hive handy to replace any modifications that don't work. Modify in small increments and test after each change, then proceed to more full-scale alterations.

12. Ask for help. There's no better resource at your fingertips than the SharePoint community. Yes, we all have day jobs, but we're happy to lend a hand if you need us. It takes time to maintain a blog or answer newsgroup postings; if we didn't care, we wouldn't do it. If we don't know the answer we can probably point you in the right direction.

Good luck!

List-Level Permissions in SharePoint Portal Server

2005-11-28T10:46:00.000-08:00

WARNING! WARNING! WARNING!

This may just be the most unsupported tip I have ever posted, and for someone who is known for finding creative ways to enable or implement features that often fall into the 'unsupported' category, that's saying quite a bit. I struggled with whether or not to post this for a few days but in the end I decided that the value outweighs the cost. You're all big boys and girls so you can make your own decisions on whether or not to implement this solution. If you do, you are completely on your own - although I've tested it in at least three scenarios without incident, that is no guarantee that it won't completely crash your portal implementation. So...

READ ON AT YOUR OWN RISK!!!

Now that the disclaimers are out of the way (this is serious - don't do this if you're uncertain of how it will effect your portal), let's get down to business. One of the most frustrating restrictions in SPS is the inability to assign list-level permissions to individual lists. Unlike WSS, SPS lists inherit permissions from the portal area they live in. This means that you must create a new subarea in order to implement individual list ACL's.

This limitation is enforced by the ExternalSecurityProvider value specified in the ONET.XML file for each site definition. According to the SDK, this COM GUID, which is static for all SPS implementations, defines the security context for the search crawler. Strangely enough, it is also referenced on line 522 of the listedit.aspx file, which obviously has nothing to do with search and indexing. When present, the 'Change Permissions for this List' link is hidden; when removed, it is displayed. By commenting out the associated 'if' statement (lines 522 through 537), the 'Change permissions...' link becomes active for all lists; clicking on it takes the user to the Change Permissions page (shropt.aspx).

Unfortunately, disabling the SecurityProvider check is not enough to enable list-level permissions. As one will quickly discover, clicking on the 'Add Users' button on any subarea (but not the root SPS area) will lead to an endless authentication loop. This confounded me as it seemed to work fine in the SPS definition but nowhere else. When the same issue came up with Jan Tielens' UserAlerts web part and some custom web parts a colleague was developing, I realized they were all related.

The difference is due to a small change to the ExternalSecurityProvider GUID in the ONET.XML file of the SPS site definition and all other definitions (STS, you will note, does not have such a setting). At the bottom of SPS ONET.XML file you will find the following entry:

<Components> <FileDialogPostProcessor ID="C6659361-1625-4746-931C-36014B146679" /> <ExternalSecurityProvider ID="A373E6A7-7A87-11D3-B1C1-00C04F68155C" Type="Microsoft.SharePoint.Portal;Microsoft.SharePoint.Portal.SiteData.
CategoryWebSecurityProvider" /></Components>

Look closely at the ExternalSecurityProvider ID value. For most of the other Site Definitions the first octet ends in an '8' instead of '7' (i.e. A373E6A8 instead of A373E6A7). Looking into the WEBS table of the _SITE database, I discovered that this GUID is stored in the SecurityProvider column for each area (interestingly, bucket areas have a '9' at the end of the first octect instead of a '7' or an '8'). Apparently, whenever the DLL retrieves this value from the DB, if it does not match a certain value range, access to the function being called is not allowed, which results in the authentication loop. At first, I assumed that this only applied to list permissions as listedit.aspx is the only file in which the ExternalSecurityProvider setting is referenced; however, I discovered that several object-model queries (user.alerts and user.roles) also share the same restrictions. Any code that accesses these methods from a portal subarea will fail.

The solution to these problems is simple yet potentially dangerous (if you are still reading now would be a good time to bail out). It involves modifying the listedit.aspx page (not supported), changing the GUID value in the ONET.XML file for your custom site definition (OK as far as I can tell - it's your definition, after all), and, if any areas have already been created, updating the WEBS table with the new GUID value (definitely not supported).
For the bold and brave, here's the procedure:

1. Modify the 'listedit.aspx' file by commenting out (//) lines 522 - 537, as follows:

// if (!spWeb.HasExternalSecurityProvider)// {%> <TR> <TD> </TD> <TD class=ms-propertysheet colspan=4><IMG SRC="/_layouts/images/rect.gif" alt=""> <A ID=onetidListEdit7 target=_self <% if (iBaseType == SPBaseType.DocumentLibrary) { %> HREF="ShrOpt.aspx?obj=<%SPEncode.WriteUrlEncode(Response, spList.ID.ToString("B").ToUpper());%>,doclib" <% } else { %> HREF="ShrOpt.aspx?obj=<%SPEncode.WriteUrlEncode(Response, spList.ID.ToString("B").ToUpper());%>,list" <% } %> ><% switch (iBaseType) { case SPBaseType.DocumentLibrary: if (SPListTemplateType.PictureLibrary == iServerTemplate) { %>Change permissions for this picture library<% } else if (SPListTemplateType.XMLForm == iServerTemplate) { %>Change permissions for this form library<% } else if (SPListTemplateType.ListTemplateCatalog == iServerTemplate SPListTemplateType.WebTemplateCatalog == iServerTemplate SPListTemplateType.WebPartCatalog == iServerTemplate) { %>Change permissions for this gallery<% } else { %>Change permissions for this document library<% } break; case SPBaseType.DiscussionBoard: %>Change permissions for this discussion board<% break; case SPBaseType.Survey: %>Change permissions for this survey<% break; default:%>Change permissions for this list<% break; }%></A></TD></TR><%// }

2. Change the first octet of GUID value in ONET.XML file from 'A373E6A8' to 'A373E6A7', as follows:

<ExternalSecurityProvider ID="A373E6A7-7A87-11D3-B1C1-00C04F68155C" Type="Microsoft.SharePoint.Portal;Microsoft.SharePoint.Portal.SiteData.
CategoryWebSecurityProvider" />

3. Run the following SQL statement on the SITE database in SQL Query Analyzer:

UPDATE Webs SET SecurityProvider = '{A373E6A7-7A87-11D3-B1C1-00C04F68155C}' WHERE SecurityProvider = '{A373E6A8-7A87-11D3-B1C1-00C04F68155C}'

That's it. You now have list-level permissions in portal subareas. As I mentioned, this may have unintended consequences; this value may by used elsewhere and cause something that was working to break or disable some dependent functionality. In my test scenarios I was unable to find any negative effects but that doesn't mean they don't exist. Try it at your own (considerable) risk.

BTW, if anyone from Microsoft reads this and knows what effect a change in the SecurityProvider GUID might have on portal operation, please enlighten us as it is not documented anywhere that I could find.

As an aside, I am certain that this post will officially exclude me from MVP consideration for the rest of my life ;-)

SharePoint v.Next Upgrade Issues

2005-11-28T08:16:00.000-08:00

Arpan Shah has a good post on things to consider in preparation for the upgrade to SPS/WSS 3.0. I generally make a concerted effort to toe the line with regards to guidelines from Microsoft but when something is seriously out of whack I have to take exception. Two of the 'Golden Rules' of SharePoint customization that Arpan repeats in his post have me seriously concerned that Microsoft is not taking into account their customer's desire to fully customize SPS in the next release; namely, 1) Database access, and 2) File/Definition modifications. As Arpan states:

1. Don't touch the database. Modifying is a big no-no... reading it -- there's no guarantee that the schema will be the same. If you want to ensure a smooth upgrade, don't touch it or use partner technologies that modify the database.

2. Don't modify out of the box files/directories/stylesheets, et cetera. Whenever possible, you should be creating copies and then modifying vs. modifying the out of the box files. Service Packs or future versions can overwrite files and you can lose your customizations. Net/net: follow customization guidelines!

This is all well and good but both of these 'rules' completely ignore the realities of full-scale customization. First, I defy you to create a portal-wide, collapsible, dynamic navigation menu (a la MSDN menus) or a nested drop-down navigation bar that includes both SPS areas and WSS sites without reading from the database. Sure, you can cobble together an object-model server control but it will be a) V-E-R-Y S-L-O-W and b) very buggy. Not to mention the fact that you can't make the association between WSS sites and SPS areas without reading from the WEBS and SITES tables. I completely support the notion that modifying the database is BAD IDEA but not being allowed to read from it overly restricts development and customization.

Second, you absolutely cannot deploy a fully branded and customized portal solution without modifying the SPS, SPSPERS, SPSMSITE, and SPSSITES site definitions. Add WSS sites and you must also customize the STS definition (although you can work around that limitation by getting fancy with the WEBTEMP.XML files). What good are stand-alone area customizations if they don't integrate with the rest of the portal? We're talking about customizations far beyond portalheader.aspx and alternateheader.aspx - full page layout and design changes cannot be achieved without editing the core definitions. (NOTE: You can modify WEBTEMPSPS.XML and replace the default definitions with custom definitions using the same ID but it doesn't always work right, especially when replacing the SPS definition, and besides, according to the guidelines, we're not supposed to modify the base XML files either).

Third, administration pages are a unique animal unto themselves. At last count I have discovered at least half a dozen shared code structures just for admin page headers (sorry to disappoint, but alternateheader.aspx only works in about a third of those pages, and it's functionality is limited at best) and a bunch of stand-alone configurations. Many don't include references to custom CSS files or all the code registrations necessary for including server controls (you do want a common navigation scheme at the top of ALL your pages, don't you?). Remember that many of these pages are accessed regularly by portal users - spsviewlsts, lstman, aclinv, catman, create, listedit, and so on - so modifying them is required if you wish to maintain any sort of continuity in portal design.

I understand that customization in the current product is tricky at best but v.Next is supposed to address that issue, is it not? I thought so but Arpan's post makes me wonder if that will be the case. Word to the mother ship - CUSTOMERS DEMAND CUSTOMIZATION!!! Neglect the ability to customize the product and customer satisfaction will plummet. I sincerely hope this requirement has been taken into consideration and the final release will take full advantage of .NET 2.0 features to provide scalable, extensible customization options without restricting the customer to a less-than-desireable mish-mash of 'works here but doesn't work there' compromises.

Don't get me wrong - SharePoint is a great product and I appreciate the customization flexibility that Microsoft has given us (even if some of it is inadvertent). I also appreciate the wisdom from on high provided by Arpan, Fitz, Maurice, and others. I just hope that the lessons of v2 influence the features of v3 inasmuch as customization is no longer an option but a requirement.

For those of you that have already done extensive customization to your portal deployment, here are some practical suggestions to prepare for the v.Next upgrade:

1. Insure that you have copies of all the original, unaltered files, definitions and directory structures.
2. Make a copy of all modified files, definitions and directories.
3. Make a copy of all database additions, such as stored procedures, logins and custom indexes.
4. Prior to upgrading, restore the original files/defs/dirs and remove any custom CSS files, images, etc. from the 60 hive.
5. Remove all database additions.
6. Perform the upgrade to a test portal.
7. Determine what impact the new changes have on your customization scheme and modify/redeploy accordingly (many of the hard-coded mods my no longer be necessary as Master Pages will replace much of the file-by-file alterations necessary in the current version).
8. Revise your database additions to account for any schema changes and redeploy.
9. Test and modify your web parts and server controls (especially those that read from the DB).
10. Test, test, and test again, then downgrade the live portal deployment to a basic install, upgrade to the new version, and deploy your customized portal elements.

Bear in mind that these are just suggestions - without having the new version to test against there is no way of knowing what the actual procedure will be. The more extensive the customizations the sooner you should begin testing and planning the upgrade to v.Next for your clients/organization.

Extreme SharePoint Design: Custom User Menus, Part 2

2005-11-23T07:59:00.000-08:00

In a previous post, I described at length the process for creating custom user menus in SharePoint. In the associated code samples, I neglected to account for windowed controls that might obscure the menu drop-downs on a page. As anyone who has designed extensively for IE knows, windowed controls (such as ActiveX or Select boxes) ignore the 'z-index' property assigned to DOM elements and take precedence in the display; that is, they are drawn on top of all other controls. If you use the hidden DIV method I outlined there are some instances, such as opening a document library in datasheet view, where the menu options disappear behind the web part.

There is no direct solution for this problem but there is a workaround using IFRAMEs and javascript. First, let's re-familiarize ourselves with the code that draws that the hidden div and the script that activates it when the user clicks the menu button:
Page Code (in DEFAULT.ASPX or a custom user control):

<td valign="top" align="right" nowrap onclick="SwitchMenu('ActionsMenu')" class="spsWPZ_ActionsMenu_Header">Actions<img src="/_layouts/images/menudark.gif" align="absbottom" > <div id="ActionsMenu" onmouseover="this.style.display='inline'" onmouseout="this.style.display='none'" class="spsWPZ_PageHeaderMenu_Div" > <table width="100%" cellpadding="0" cellspacing="0" border="0" class="spsWPZ_PageHeaderMenu">  </table> </div></td>

Javascript (in the page header or OWS.JS):

function SwitchMenu(obj){var el = document.getElementById(obj);var parent = el.parentElement;var x = getPageOffsetLeft(parent);var y = getPageOffsetTop(parent) + parent.offsetHeight;var p = parent.offsetWidth; if(el.style.display == "inline") { el.style.left = (x - (175 - p)) + "px"; el.style.top = (y - 7) + "px"; el.style.display = "none"; } else { el.style.left = (x - (175 - p)) + "px"; el.style.top = (y - 7) + "px"; el.style.display = "inline"; }}

The code above displays a table cell ('Actions') that acts as a menu button and creates a DIV element ('ActionsMenu') that is hidden when the page loads. When the user clicks within the table cell the SwitchMenu function is called, which activates the ActionsMenu DIV, positions it below the cell and displays it on the page. The onMouseOver and onMouseOut events cause the DIV to disappear when the user moves the mouse outside the DIV boundary, mimicking the behavior of a regular Windows menu.

This works just fine until a windowed control is placed on the page that intersects with the ActionsMenu DIV, at which time the control will obscure the DIV, making it impossible to access the menu functions. In some cases, the page becomes unusable because all the operations ('Modify Settings and Columns', 'Edit Page', etc.) are hidden. To resolve this issue an IFRAME must be placed immediately below the ActionsMenu DIV that is the same width and height and exposed in response to the user click on the table cell.

First, create a hidden IFRAME within the ActionsMenu DIV and place it immediately before the content table as follows:

<div id="ActionsMenu" onmouseover="this.style.display='inline'" onmouseout="this.style.display='none'" class="spsWPZ_PageHeaderMenu_Div" > <IFRAME style="display: none;" id="ActionsMenuFrame" name="ActionsMenuFrame" src="javascript:false;" frameBorder="0" scrolling="no" ></IFRAME> <table width="100%" cellpadding="0" cellspacing="0" border="0" class="spsWPZ_PageHeaderMenu">  </table></div>

The style of the IFRAME is set to "none" to keep it hidden until the DIV is exposed. The NAME and ID settings are important as these will be used in the SwitchMenu function later. The SRC property calls a dummy javascript instead of referencing a blank HTML file, which can lead to client-side security warnings in an HTTPS environment.

Next, update the SwitchMenu function with methods to display and position the IFRAME:

function SwitchMenu(obj){var el = document.getElementById(obj);var parent = el.parentElement;var x = getPageOffsetLeft(parent);var y = getPageOffsetTop(parent) + parent.offsetHeight;var p = parent.offsetWidth;var aFrame = document.getElementById('ActionsMenuFrame'); if(el.style.display == "inline") { el.style.left = (x - (175 - p)) + "px"; el.style.top = (y - 1) + "px"; el.style.display = "none"; } else { el.style.left = (x - (175 - p)) + "px"; el.style.top = (y - 1) + "px"; el.style.display = "inline"; aFrame.style.zIndex = el.style.zIndex - 1; aFrame.style.display = "inline"; aFrame.style.position = "absolute"; aFrame.style.top = "0px"; aFrame.style.left = "0px"; aFrame.style.height = el.offsetHeight; aFrame.style.width = "175px"; }}

The function now uses a variable called 'aFrame' to access the properties of the IFRAME('ActionsMenuFrame'). The IFRAME is then positioned one level below the DIV by setting the zIndex property. The display type is then changed to 'inline' and the IFRAME is set to the top and left position of the parent DIV. The most difficult part of positioning the IFRAME is matching the height of the parent object; because the ActionsMenu DIV does not have an explicit height setting (it expands or contracts based on the content in the child table), the el.style.Height value cannot be used; instead, the function uses the offsetHeight property, which is accessible once the control is drawn (which happens in the preceding IF...ELSE blocks).

The menu will now overlay all page controls, as IFRAME is a unique IE element that is aware of the zIndex values of both browser elements and windowed controls (the zIndex for the ActionsMenu DIV is set in a CSS file). The page will now render with the windowed controls on the bottom, then the IFRAME, then the DIV on top. This will prevent any ActiveX controls, select boxes, or other page elements from obscuring the menus and limiting usability.

Cracking Open STP Files

2005-11-11T08:10:00.000-08:00

Todd Bleeker has a great post on manipulating data within STP files. Timely information, as I was just working on a similar problem the other day. Thanks, Todd!

Changing the SharePoint Admin Password

2005-11-10T08:27:00.000-08:00

Before installing SharePoint it is important to give some thought to the account that will be used as the portal administrator. Not only is the admin account referenced throughout the portal (area/site ownership, document metadata, list properties, etc.) but it's also used for many basic functions that are central to portal operation - connections to the configuration database, content crawling, application pool identity, and so on. Because the portal administrator must have complete and total control over the SharePoint server(s), a good practice would be to use an account specifically for this purpose that has limited rights elsewhere in the domain.

Assuming that you have followed this methodology in your portal deployment, the next obvious question is: What happens when you change the portal administrator password? Alas, this is a simple question with a not-so-simple answer. There are several steps required to successfully implement this change and they must be done in a specific order. Download the following article which outlines the scope and implications of modifying administrative account properties and defines a procedure for implementing changes.

NOTE: This procedure has been tested for accuracy but each deployment is different; if you run across any variations please post comments and I will update the document accordingly.

Modifying Administrative Account Properties (PDF)

Extreme SharePoint Design: Validating Area Titles

2005-11-07T16:11:00.000-08:00

Most web-savvy tech types know better than to use "special" characters in URL fields - apostrophes, question marks, carets, ampersands, and the like. Unfortunately, this rule of thumb is lost on the average SharePoint user and an open text box with no validation is an invitation to wreak havoc on your carefully constructed portal navigation. IE will overlook most illegal characters but some third-party or custom developed navigational controls will not, so a good practice would be to discourage the use of symbols in Title and URL fields.

You can, of course, add big warnings to the admin pages warning against such malfeasance but we all know that the bigger the warning, the more often it is overlooked. So what to do? The best way to handle this situation is to check the user input against a list of disallowed characters and force text modifications before the field is posted. Fortunately, if your portal consists mostly of WSS sites, you've got it made - the WSS site creation form (scsignup.aspx) has built-in validation to prevent users from entering illegal characters in certain fields; however, if you make extensive use of SPS areas, the solution is not quite so simple. Here's how to replicate the WSS behavior in SPS:

First, create a script to check the user's input against your list of illegal characters, similar to the following:

<script>
function validateSiteName(ctlId)
{
var iChars = "!@#$%^&*()+=[]';,./{}\":<>?";
var ctlName = document.getElementById(ctlId) for (var i = 0; i < ctlName.value.length; i++)
{
if (iChars.indexOf(ctlName.value.charAt(i)) != -1)
{
alert ("The Title field contains special characters which are not allowed. Please remove them and try again.");
ctlName.focus();
return false;
}
}
}
</script>

This script defines the list of illegal characters (iChars), gets the ID of the input box (ctlName), then, if the text box isn't empty, steps through each character and matches it against the list. If a character matches one of the illegal characters, the script displays an alert box asking the user to remove the offending characters and returns the focus to the input field, preventing them from saving the form without fixing the problem.

Second, paste the script into the <HEAD> section of the area creation and modification pages (spnewcategory.aspx and speditcategory.aspx, respectively) or append the function to OWS.JS file (which is called from every page within the portal).

Third, call the script using the onBlur method from the form. Find the following code block on the page:

<SPSWC:InputFormTextBox
runat="server"
id="TextBoxTitle"
IsTextTrimmed = "true"
LabelTextLocId="SiteAdminCreateCategory_Title_Colon_Text" AccessKeyLocId="SiteAdminCreateCategory_Title_AccessKey"/>

Then add the onBlur event to the end:

<SPSWC:InputFormTextBox
runat="server"
id="TextBoxTitle"
IsTextTrimmed ="true"
LabelTextLocId="SiteAdminCreateCategory_Title_Colon_Text" AccessKeyLocId="SiteAdminCreateCategory_Title_AccessKey"
onBlur="validateSiteName(this.id);"/>

This will fire the validateSiteName function whenever the user clicks or tabs out of the input field.

Finally, save the modified pages to the 60\TEMPLATE\LAYOUTS\1033 directory and users will be unable to enter any illegal characters into the area title field, which is used by SPS to construct the bucketed URL, thereby preventing any incompatabilities with navigational tools and utilities.

MySite Permissions

2005-11-01T08:38:00.000-08:00

The MySite site definition (SPSMSITE) is intended to provide only the 'Private' and 'Public' page views for a user's personal site; all other functionality (lists, doc libs, etc.) is handled by the Personal definition (SPSPERS). When customizing these definitions (if you want to provide MySite functionality, you have no choice but to customize the existing definition - I know it's not supported but it's there just isn't any other way), it is important to remember that SPSMSITE is a full definition, with the same base set of included lists as all other defs.

While there are no direct links in the GUI for working with MySite lists, users can add list web parts from the tool pane and, by default, modify the list contents. Since MySite content is global (personal site content is localized to the individual user account), any changes to MySite lists will show up for all users; not an ideal situation.

To work around this issue, change the MySite permissions for Members and Contributors. Use the following URL syntax to access the MySite security page (there is no 'Manage Security' link for this area):

http://%lt;server name%gt;/mysite/_layouts/1033/spcatsec.aspx

Check the Contributor and Member groups (and any others you wish to modify), click 'Edit', and uncheck the 'Add Items' right under the Select Rights section. This will prevent users from doing and end-run around list security by dropping list web parts onto the MySite pages and modifying the content.

New Customer Success Story

2005-10-18T07:52:00.000-07:00

From time to time, when we're engaged on a project that is a bit out of the ordinary or involves a great deal of customization, I like to do a case study to highlight the challenges, achievements and lessons learned during the course of the engagement. We recently completed such a challenging assignment for a premier architectural services firm based in Ft. Worth, Texas. Their story contains valuable insights for companies of similar size who are considering a new portal implementation using SharePoint Products and Technologies.

If you, your firm, your clients, partners or other SharePointers are interested in reading the case study, it is available for download here.

If you have any questions or would like more details on the technical architecture/development/etc., feel free to post a comment with your email addy and I'll respond accordingly.

Extreme SharePoint Design: Custom MySite Titles

2005-10-10T16:32:00.000-07:00

When customizing personal sites (MySite), it is important to remember that you're really working with two site definitions - SPSMSITE (which provides the Public and Private default pages) and SPSPERS (which contains all the lists and libraries). SPSMSITE is nothing more than a launching pad for SPSPERS - the bulk of the functionality is in the personal site definition.

This is important to remember when modifying the menus, links and other navigational elements. In some instances, such as the public and private pages, you will be referring to MySite url's (/mysite/); in others, such as document libraries and lists, you will be referring to Personal url's (/personal/[username]/). This can be quite confusing when, for example, you need to create a site title that is displayed on every page and links back to either the public or private view.

The SharePoint object model has some built-in functions that help you determine your site context but they don't span multiple contexts (in other words, there's no way to know which mysite is associated with the current personal path a page is in) and they don't always expose data the way you need it. In the following example, we'll use various properties of the GetContextWeb method to create a personal site title based on the user's full name from Active Directory that, when viewed by the site owner, links back to the private home page, and when viewed by a reader, links back to the public page.

//Retrieve the site title, which should be the user's full name from AD
string strFullName = SPControl.GetContextWeb(Context).Title;
string strTitle;
int intLocation, intLength;

// Determine length of string, find comma separator if one exists
intLength = strFullName.Length;
intLocation = strFullName.IndexOf(", ");

// If a comma is not found (the user name is not separated into Last Name, First Name), set the Title value to the full Title from AD; otherwise, parse out the first name and last name, remove the comma and space, and reverse the strings to read First Name Last Name

if (intLocation == -1)
strTitle = strFullName;
else
strTitle = strFullName.Substring(intLocation + 1) + " " + strFullName.Substring(0,intLocation );

// Determine if the current user is the site author; if so, set the link href value to mysite and write out the Title. If the current user is only a reader, set the link href to the public url and write out the same Title value.

if (SPControl.GetContextWeb(Context).CurrentUser.LoginName == SPControl.GetContextWeb(Context).Author.LoginName)
{
Response.Write("<a href='/mysite/default.aspx'>" + strTitle + "</a>");
}
else
{
Response.Write("<a href='/mysite/public.aspx?accountname=" +
SPControl.GetContextWeb(Context).Author.LoginName + "'>" + strTitle + "</a>");
}

Note that you will only be able to execute this code from a user control; standard web part pages won't allow code execution. To call a user control from within a web part page, create an .ascx file, insert the required registrations (be sure to utilize Microsoft.SharePoint.WebControls) and code, then register the page location (usually the /bin folder on the virtual server), and call the registration from within the web part page.

Search Index Rules Syntax

2005-09-30T16:17:00.000-07:00

SharePoint does a pretty good job of handling long, complex or unique URLs within the interface; many lists use relative pathing, Area and Site URLs preserve spaces for easy readability, and so on. One instance where this is definitely NOT the case is the application of rules for inclusion and exclusion of content sources.

When creating a rule that references a URL path, such as http://servername/Area, you must replace any spaces and special characters (ampersands, apostrophes, commas, etc.) with the proper URL encoding (%20, %26, %2C, etc.). Otherwise, the MSSearch process will ignore the rule and continue evaluating results against valid rules.

Also, remember that the order of the rules is important. If you are trying to exclude the above URL, the Portal_Content index will have a default inclusion rule of http://servername/; any new rules you create will be processed after this rule is satisfied. Since the default rule includes all content, any antecedent rules will be ignored. To address this issue, simply move your exclusions to precede the blanket inclusion and the search service will properly exclude the specified content source.

Extreme SharePoint Design: 'Go Back To [Area/Site]' Link

2005-09-29T09:28:00.000-07:00

The ability to call pages in the /_layouts/1033/ directory is very convenient; all the administration pages can be stored in one location and referenced from any area or site within the portal. SharePoint uses the SPControl.GetContextWeb(Context) and SPControl.GetContextSite(Context) functions to determine what context the user is in when a page is called, then presents the appropriate content. Pretty slick.

There's just one problem: when accessing these pages, users often get lost with no way to return to where they came from. Nothing is more frustrating than finding yourself seven steps into a wizard with no way to bail out but to smack the 'Back' button repeatedly. The solution is a 'Go Back To [Area/Site]' link at the top of each administration page which gives the user one-click access to the place they started from.

Insert the following code into AlternateHeader.aspx or directly into your administration pages just after the PageHeader section (if you're using heavily customized Site Definitions as I often do, most of your admin pages will have header code in them to overwrite AlternateHeader and PortalHeader; just paste the following code into the appropriate section and format it as needed):

<%
try
{
Response.Write ("<a href='" + SPControl.GetContextWeb(Context).Url + "'>Go Back to " + SPControl.GetContextWeb(Context).Title + "</a>");
}
catch
{Response.Write ("Portal Administration Page");
}
%>

The 'try' block creates a link back to the root of the referring area/site using the title field as the link text. The 'catch' block writes out a general statement that you can replace with anything you like, just in case the link fails to render properly.

NOTE: In 'Extreme SharePoint Design: Creating Custom User Menus', I used the same function to replicate the behavior of the 'Home' button on WSS sites. Use SPControl.GetContextWeb(Context) anytime you want to refer to the root URL of an area or site; use SPControl.GetContextSite(Context) to reference the site collection the current site belongs to.

UPDATE: I forgot to mention that you'll need to insert the following code at the top of alternateheader.aspx in order for SharePoint to parse inline code blocks on the page (otherwise you will receive the dreaded 'External component has thrown an exception' error):

<%@ Page language="C#" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Updated SharePoint Resources List

2005-09-29T06:26:00.000-07:00

Heather has updated her SharePoint Resources List with a bunch of new content. This should be your first stop for tips, tricks, and general How-To's.

If you're looking for a list of tools and utilities, including commercial and non-commercial software, web parts, add-ons, and the like, I maintain a brief list here and Joris Poelmans has a monster list here.

BTW, whatever happened to the Sharepoint Template Project???

New Blog Template

2005-09-28T12:27:00.000-07:00

Shane was kind enough to let me know that the blog template I was using didn't render properly in Firefox, so I switched it up to something new. Not very compelling, I know, but I don't have time at the moment to whip up a better one (the stock Blogger templates just don't give you much to choose from).

Drop a comment and let me know if this one works any better...

Extreme SharePoint Design - Creating Custom User Menus

2005-09-27T11:10:00.000-07:00

Finally, after much delay, the lastest installment in the Extreme SharePoint Design series is finished. In this installment we will explore the creation of custom menus using the default Actions and Views menus in SharePoint Portal Server 2003.

Originally intended to be a much shorter article, I kept finding additional things I felt needed to be included to present a complete picture, so the final version is rather lengthy. Hence the linked PDF as opposed to one big blog post. Download the article here (right-click, choose 'Save Target As'):

Extreme SharePoint Design - Creating Custom User Menus (PDF, 464k)

Enjoy!

New SharePoint Features

2005-09-14T14:44:00.000-07:00

I'll take Heather's cue and refrain from judging the new SharePoint features until I've had a chance to get my hands on them, but here are a few thoughts based on Fitz's post from PDC:

RSS. Everything about sites, lists, libraries, etc., can be syndicated via RSS automatically.
Blogs and Wikis. Templates and features in the box.

Excellent. This will save a great deal of frustration with email-based alerts.

Content Types. These aren’t just like SPS 2001’s document profiles. They define sets of metadata, but they also contain view information. And associated workflows. And events bound to them (synchronous or asynchronous). And you can have more than one in the same list/library.

Hmm...not sure. Will this help with the problem of retrieving views via web services?

Workflow. Windows Workflow Foundation is embedded in WSS. It’s used everywhere.

I want to jump up and shout for joy...BUT...if they don't include a visual designer embedded into the UI ala Nintex SmartLibrary then they will have completely missed the boat. LOB managers, content editors, and designers cannot AND WILL NOT be forced to rely upon developers to create workflows.

Recycle Bin. We did it. It’s scoped to a site and captures deleted documents, items, etc. It has a user restore and an administrative restore.

Now that deserves a jump and a shout (assuming, of course, that it applies to SPS as well).

Per-item security. Even on list items.

I can die happy now. Is it really true? Oh, please, let it be so!

FrontPage has evolved into a feature set that makes it truly a SharePoint site designer. (Ghosting’s still around, but it won’t be a problem anymore. I’ll explain why in an upcoming post.

Interesting. This could make the job of customization a bit easier, which would make my life a much better place.

Forms services in Office “12” servers. That’s right — design a form in the InfoPath rich client, publish it as a SharePoint site, and it can be either viewed/filled out in the full smart client or in a browser as HTML.

One word: S-W-E-E-T!

Search. Better APIs. Better results. Alternate search suggestions (misspelled words,etc.). A highly customizable default Web-based UI.

I'm definitely excited about this. Search is a bit of a blessing and a curse, so any improvement will be welcome.

Office “12” servers will also contain a Business Data Catalog, a facility that registers LOB application data and Web services. Once that’s happened, BDC-aware Web Parts can pull data from them, we can index them, and a lot more. There’s a session on this tomorrow.

Not sure about this one. Sounds interesting, though.

Office “12” servers will also be able to take a spreadsheet published to a SharePoint site and reneer it as an HTML application.

Like it but not sure how useful that will be...

Mobile views of SharePoint lists. That’s right, a way to render a list on a mobile device.

Very nice.

Lists now have a Business Data type that will use the aforemntioned Business Data Catalog

Unsure on this one. Need more info.

Access will be able to treat SharePoint site data as fulll-blown data sources.

Yeah, baby!

All in all, it sounds promising. So, looking back, how'd they do with regards to my various predictions, rants and ravings? Not bad, I'd say.

Extreme SharePoint Design: Modifying The 'Grouped By' Headers

2005-09-06T15:37:00.000-07:00

When applying grouping to a list view, the default style sheet prepends the field label and a colon to the group header. While this may be helpful in determing what category the data is grouped by it is certainly not the most visually appealing method. Fortunately, the style can be modified in the stdview.xml file located in the XML folder of your custom site definition (you are using a custom defintion, aren't you?). Locate the following code on or about line 278:

<GroupByHeader> <HTML><![CDATA[ <TBODY id="titl]]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA["><TR]]></HTML> <Switch> <Expr><GetVar Name="GroupByIndent"/></Expr> <Case Value="0"> <HTML> <![CDATA[ class="ms-gb" ]]> </HTML> </Case> <Default> <HTML> <![CDATA[ class="ms-gb2" ]]> </HTML> </Default> </Switch> <HTML><![CDATA[><TD colspan="100" nowrap><img src="/_layouts/images/blank.gif" alt="" height=1 width=]]></HTML> <GetVar Name="GroupByIndent"/> <HTML><![CDATA[><a href="javascript:" onclick="javascript:ExpCollGroup(']]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA[','img_]]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA[');return false;"><img id="img_]]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA[" src="/_layouts/images/minus.gif" alt="]]></HTML> <HTML>Expand/Collapse</HTML> <HTML><![CDATA[" border="0"></a> ]]></HTML> <GetVar Name="GroupByField" HTMLEncode="TRUE" /> <HTML><![CDATA[ : ]]></HTML> <GetVar Name="GroupByValue"/> <HTML><![CDATA[</TD></TR></TBODY>]]></HTML> </GroupByHeader>

Remove the field label and colon by deleting or commenting out the following code from this section:

<GetVar Name="GroupByField" HTMLEncode="TRUE" /> <HTML><![CDATA[ : ]]></HTML>

You may also wish to change the drab gray style by modifying ms-gb and ms-gb2 or assigning a class in a custom style sheet.

Once you're finished editing the file, save it and reset IIS. Note that this is a global change that will affect all lists in the definition. For localized changes, create a Data View Web Part and modify the XSL accordingly.

Compiling Locally Without SharePoint Installed

2005-09-06T12:33:00.000-07:00

A vexing issue for SharePoint developers is the need to have WSS installed on your development machine due to DLL dependencies. Anyone who has tried to compile a web part in a stand-alone environment has run across the following errors:

The dependency 'Microsoft.SharePoint.Security' could not be found.
The dependency 'Microsoft.SharePoint.Dsp' could not be found.
The dependency 'Microsoft.SharePoint.Library' could not be found.

To circumvent this issue, extract the underlying DLL's from the GAC and copy them to your local machine. You'll need to perform the copy from the command prompt as Windows Explorer does not expose the full directory structure for the GAC. Each DLL resides in a directory with a path similar to the following:

c:/windows/assembly/gac/[Strong Name]/[Version Number]__[Public Key]/[Strong Name].dll

Once you have the DLL's you can include them as a reference in your project and compile without errors.

SharePoint Blogsearch Expands to Mexico

2005-08-30T15:27:00.000-07:00

For our friends from Latin America, Luis Du Solier's Spanish-language blog has just been added to the SharePoint Blogsearch index. As I grew up in El Paso (which is right on the Mexican-American border), I am quite fond of our neighbors to the south and glad to see Luis is making a contribution to the SharePoint community. If I continue to get multilingual submissions I'll create a content source for each language to make native searches a bit easier.

Para todos nuestros amigos latinos, bienvenido por favor Luis Du Solier a la familia de SharePoint Blogsearch. Como soy de EL Paso, Tejas y orgullosa de nuestros vecinos al sur. Estoy alegre ver que Luis está haciendo una contribución a la comunidad de SharePoint. Su blog es muy bueno, Luis!

Database Permissions

2005-08-25T14:14:00.000-07:00

I'd been wondering for a long time how the ACL's in the SharePoint database work. In fact, I was just discussing the issue this morning with a colleague when - voila! - Paolo posts the answer.

Now that's what the blogosphere is all about!

Working with SharePoint Lists

2005-08-23T11:57:00.000-07:00

A colleague of mine is working on a custom application which makes extensive use of SharePoint lists to store data. He has written a webpart that rolls-up the XML data from various lists, transforms it with XSL, and renders it in a way-cool tabbed control. While putting this together, he found this link on Using Data from Sharepoint 2003 Lists. Very cool and a big thanks to Paul Ballard for his post.

Perhaps if we needle him enough, Scot will be nice enough to post his nifty code and show us how it's done. Or, he could just get a blog and start sharing his wizardry with the rest of the world, eh???

Hiding the Site Settings Link

2005-08-23T06:35:00.000-07:00

One of the most common user complaints in new implementations is links that are exposed to users who don't have rights to access the content - like the 'Site Settings' link at the top of every page. Heather Solomon has figured out how to hide that pesky critter for good.

Where does she find this stuff? More importantly, how on earth would I make it through the week without her blog???

Heather for MVP!!!

SharePoint Templates Article

2005-08-21T10:44:00.000-07:00

While following up on a comment from Claudia I found her article on WSS themes. Good stuff - go check it out.

Extreme SharePoint Design Series

2005-08-19T18:24:00.000-07:00

Site definitions and custom templates are essential to delivering a customized SharePoint experience. While there are several good resources for information on how to deploy a custom site definition, such as the SDK, MSDN, and Heather Solomon's excellent site, there aren't many in-depth examples of custom code for UI modifications. It's time to change that, don't you think?

Over the next few months I'll be presenting "Extreme SharePoint Design", a regular blog series with advanced tips and tricks for designers. Topics won't be in any particular order, just cool stuff as I come across it with lots of code to copy and paste. Watch this space for updates, often daily but sometimes weekly, depending upon my travel schedule.

As always, feel free to share your thoughts or suggest ideas.

UPDATE: I'll be posting a lengthy article next week on customizing various context menus (Actions, Views, etc.) - it's a bigger task than I thought at first but well worth the effort. Stay tuned!

Extreme SharePoint Design: Site Definition File Differences

2005-08-16T06:38:00.000-07:00

Creating a custom site definition from scratch can be a daunting task. Each file in the folder structure serves a particular purpose and many of them vary slightly from folder to folder - allitems.aspx is not the same in DOCLIB as it is in VOTING (see Heather's post for a complete list of files in each folder). Due to slight variances, there is no way to do a global search and replace to copy your customizations. Getting the correct code in each file is essential to maintaining SharePoint's functionality. Isn't there an easy way to solve this problem?

The answer is - sort of. First, begin with a blank template file that has all the necessary components for that type (allitems.aspx, for example). Remember that many page elements require specific registrations and script files, so make sure your [HEAD] tags include all the necessary code blocks. Once you have a working template file, copy it into each directory, then add the code necessary for each list type.

I have compiled a list of each file type along with the code elements that are unique to each list (folder) below, using the SPS site definition as a baseline (60\templates\1033\SPS). The code goes in various places but I tried to keep it sequential; that is, the first code block (individual blocks are separated by ***) goes first, then the second, and so on. Some are contextual (they contain more than just the unique code) to make searching and replacing easier. I also tried tgo keep all script elements together to insure that no code gets orphaned. Once you've modified a couple of files you'll know exactly where to place each block.

Site Definition Original Code (SPS)

Please note that I did not include files that are specific to a certain list type (such as calendar.aspx in EVENTS) only those that recur in multiple folders. In a subsequent post, we'll look at how these files differ from those in STS to show how a custom deployment can seamlessly incorporate both SPS and WSS in a unified design.

NOTE ON CODE SAMPLES: Few things frustrate me more than not being able to cut and paste HTML code into Blogger's editor. You would think they could solve this with a special tag like many discussion forums do, but if they have I sure don't know about it. Until such a thing comes along, all <> tags will be displayed as [ and ]. Sorry for the inconvenience.

Optimizing External Site Crawls

2005-08-05T10:02:00.000-07:00

After launching SharePoint Blogsearch, I discovered (with some help from Greg) that the SharePointPSSearch (SPSSearch) service needs a few tweaks to work well on external web sites. After doing some digging around in the documentation, looking into the packets with a protocol analyzer, and generally scratching my head in confusion, I learned a few things:

1. SPSSearch does not always honor robots.txt files (this is a text file placed in the root directory of a web site that tells crawlers how to behave). Yes, the documentation says it does, and you can modify the id string in the registry, but it doesn't always seem to work. I'm still trying to come up with an answer to this one.

2. By default, the crawler will request as many documents from the target site as it can fit into the available threads or until it starts receiving TCP errors; in other words, it will hammer an external site into submission. Fortunately, you can control this errant behavior. Go to SharePoint Central Site Administration Manage Search Settings. In the 'Site Hit Frequency Rules' section, click on 'Manage Site Hit Frequency Rules'. Click 'Add Update Rule' on the toolbar. In the Site Name field, enter "*" for all web sites (you can also set rules by explicit name, domain, etc.). Next, click the 'Limit number of documents requested simultaneously' radio button and enter a small number (minimum is 1, max is 999, I used 5) in the Number of Documents field. This will significantly reduce the load on target servers.

3. Incremental updates are SUPPOSED to ignore content that has not been changed, crawling only those docs that have changed. In reality, this is not the case. I noticed that all documents were being processed even though the content was static. I tested a full update and incremental update on a static site and the exact same load was generated (packet count, bytes, etc.) in both a full and incremental update. This could be a bug or it could be some hidden registry setting somewhere that I haven't found yet. Any ideas would be appreciated.

4. Adaptive updates only appear to work on SPS/WSS sites. According to the docs, adaptive updates make an educated guess, based on historical patterns, as to what content may have changed on a site. In theory, this should greatly reduce the load on a crawled site and it may very well work that way in SPS/WSS. It doesn't seem to have any effect on other types of sites but my test configuration was limited so I may not have all the data. Again, if anyone has any ideas, please share.

More on this topic as I continue to tweak the settings.

Update: If you want to learn more about search optimization, here is a KB article to get you started.

Update 2: Here's another tip. When creating an inclusion rule for a subdirectory on a site the default behavior is to also include the parent site. For example, a new inclusion rule for http://www.theegroup.net/blogs/ would create two entries - one for the full path and one for the parent http://www.theegroup.net. This means that any links to other URL's on the same site would be processed which greatly expands the scope of the crawl. To restrict this behavior, change the parent rule to an exclusion and leave the child URL as an inclusion. This will restrict the crawler to links under the child URL.

Custom Lists Article

2005-07-31T18:07:00.000-07:00

Here's a fantastic article from Heather on adding custom lists to a site definition.

Useful Shortcuts

2005-07-29T07:15:00.000-07:00

I love it when I'm just wandering around and find something truly useful (OK, I wasn't wandering - I used SharePoint Blogsearch to find one thing and stumbled across another). Here's a post from Todd Bleeker regarding javascript links that toggle page modes in SPS and WSS. I already new about appending ?toolpaneview=2 to the URL but this is even easier - and he explains what all the options are. Very cool. I had no idea you could do this with IE favorites.

Also, here's a great post from Serge van den Oever on FrontPage and Data View Web Parts. Very thorough and a must read.

Sharepoint Resource List

2005-07-28T07:57:00.000-07:00

While responding to a post from Heather on the proper uses of FrontPage with SPS 2003, I discovered her list of SharePoint resources. Very handy. Thanks, Heather!

SPS Report Utility

2005-07-25T16:12:00.000-07:00

Ryan has posted a cool new utility for gathering SPS and system info. Get it here.

TechEd 2005 SharePoint Webcasts Online

2005-07-25T10:19:00.000-07:00

The webcasts from TechEd 2005 are now online. Get them here.

SharePoint Blogsearch

2005-07-21T17:54:00.000-07:00

While Feedster and Technorati do a fine job searching general blog content we SharePointers are a bit out in the cold when it comes to searching posts from our fellow bloggers - not all posts have the keyword "sharepoint" and there is no way to set up a group of blogs to search. What are we to do?

Well, thanks to the much-maligned-but-ever-so-useful SPS search, we have an answer. I've taken my blogroll and created content sources and a new search scope on my website. Just select the 'SharePoint Blogs' scope and go to it. Incremental updates run every 4 hours - I'll adjust it as necessary depending on search results and bandwidth consumption.

If you've got a blog you want added to the list, email me and I'll add it. Also, if you want to access the indexes (or any web services, for that matter) from your site and need a login account, just let me know.

Happy searching!

The SharePoint Vision

2005-07-21T09:00:00.000-07:00

Heather kicked-off a mini-tsunami with her post on the SharePoint vision. Andrew then jumped in with a few more thoughts (here and here). Bil's got a few ideas in his response to Heather's article (see her original post).

This is a good discussion. Anytime we stop writing code and start talking about the user is a step in the right direction. Heather has some very good points but one in particular is striking enough for me to add my two cents (I think we're up to a buck by now with everyone's input - or about 50 pence for my friends across the pond). She wonders why there aren't more general use web parts available to the SharePoint community. It's a good question with some uncomfortable answers:

1) Skilled SharePoint developers are few and far between. Sure, there are lots of people who have worked with SharePoint in some capacity but very few who know what they are doing and are actually good at it. This is by far the most common complaint I hear from clients and one that causes me a great deal of grief when trying to find adequate resources for a project. We NEED more and better training. We NEED SharePoint certifications (Are you listening Microsoft? Four years on the market and no cert track? Are you kidding me?).

2) The object model is preposterous. Yes, I know SPS was cobbled together quickly to meet market demands and WSS is just not that mature (props to MS for delviering a good product under those conditions despite what Mike Drip may think); however, they've got to clean up the OM in the next release. I've seen firsthand how it frustrates many .NET programmers who could otherwise be writing good code instead of wrestling with SharePoint nuances. Simplify and productivity will improve.

3) Due to #1 and #2 commercial web parts are very expensive. Solve these issues and the number of web parts will increase dramatically with a corresponding drop in prices. Developers should always be encouraged to profit from their efforts, so let's not expend a bunch of energy arguing about open source, community, freeware and so on. The profit motive is the most effective, so let's continue to encourage commercial development and take advantage of basic supply and demand principles - the more providers the lower the price. In fact, I'd like to see MS encouraging the Micro-ISV concept with new partner programs and support.

4) No centralized web part repository. As Bil astutely points out, we have to scour the web to find web parts like we're caught in some gigantic SharePoint treasure hunt. We need a better way to organize, categorize, rank, and share feedback on every web part out there. MS has taken a good first step with the component directory but it's just cut-and-paste marketing speak - no objective reviews or comments. I'm all for Bil's SharePointForge idea.

5) Corporate intellectual property restrictions. Many organizations don't want the result of their employee's efforts released into the wild without compensation. I see this happen more often than you might think. Right or wrong, and it's often a mix of both, they worry that competitors will benefit from their investment or that employees will spend their time supporting people other than their own internal users. Not to mention the most significant concern of all - liability. All it takes is one lawsuit to stop the flow of good code altogether. This is mostly a corporate culture issue but could be solved in some instances by better communication with management and pre-authorization from legal and marketing.

Those are just a few of my thoughts. I encourage the community to keep this discussion fresh and in the fore.

UPDATE I: While I'm on this soapbox, allow me to put in a plea to the developer community for standardization in product packaging. It's not that hard to compile a CAB file - don't make users jump through hoops to implement your code. Perhaps this should be a requirement in whatever centralized directory scheme is (hopefully) implemented - poor packaging equals poor ranking and fewer downloads. Some sort of incentive system for highets rankings and most downloads would be great as well.

UPDATE II: For anyone that is interested I would be willing to host the directory on my SharePoint server (c'mon, it has to be in SharePoint, doesn't it?). I don't think I can handle the storage and bandwidth for all the downloads but I would be more than happy to host and maintain the code. Any takers?

Site Navigator v2.0 Beta

2005-07-21T06:43:00.000-07:00

Advis has just released a beta version of Site Navigator v2.0. This is by far my favorite site navigation web part. Download the free beta release now (registration required) and post some feedback to the Advis team - they're a crack bunch who really want to hear about any product issues and/or feature requests.