For The User

A few months ago I talked about the growing community of SharePoint professionals and users who were joining the conversations at Twitter:

/fortheuser/archive/2008/04/21/meet-me-on-twitter.aspx

I still use Twitter quite a bit (in spite of its seemingly continual technical issues and outages), and it is still a great place to interact with other people out there who use SharePoint on a regular basis.  But I wanted to take a quick second to mention another social network that I think you should definitely check out if you're looking for new sources of SharePoint information, or just information in general: FriendFeed.

FriendFeed is an interestingly versatile tool.  It's a social network, RSS feed aggregator, instant messenger, and forum all rolled up in one.  I've configured my FriendFeed page to aggregate the output of my activities on this blog, Google Reader, Twitter, and many other websites, so that it's all available in one place if someone wants to see it.

But let's face it, I'm not that interesting, and I'm certainly not writing this post to ask you to pay attention to what songs I've bookmarked on Pandora or the latest article about the Indianapolis Colts that I've shared on Google Reader, and this isn't a blog about either of those two things either.  This is a blog about SharePoint, so let's talk about how it relates to what you can find on FriendFeed.

The social networking aspects of FriendFeed means that you can subscribe to the FriendFeeds of anyone else on the site, so you can now track and see what other people on the site are reading, commenting, and sharing about SharePoint.  And yes, once you sign up for the site, you can comment on any item anyone posts and mark the posts you "Like", providing more insight and metadata about the content than you could get from a standalone RSS reader like Google Reader.  And the comments are threaded, acting as a discussion forum about the article, which is nice because the discussion is centralized on FriendFeed rather than spread across several different sites.

The real hook for FriendFeed with regards to SharePoint is the Rooms feature. There are a couple of SharePoint-specific rooms that you can participate in and see content provided that is specific to SharePoint:

SharePoint Talk: http://friendfeed.com/rooms/sharepointtalk
SharePoint River: http://friendfeed.com/rooms/sharepointriver

SharePoint Talk is the place to go when you've found a great SharePoint article that you want to share with other people or if you want to start or engage in a discussion about a post already found in the room.  Anyone who wants to can join the room and share articles in it, we only ask that the content is relevant to SharePoint in some way.

SharePoint River is a source of SharePoint content from around the Internet, aggregated from several automated sources.  It's best used to see what kind of SharePoint-specific noise is going on throughout the Internet and to find articles or sources that you might not have otherwise come across.  I would warn that if you subscribe to that room that you probably don't want to have it put its articles on your FriendFeed home page, because it generates a lot of postings in a hurry and can be hard to follow.

Additionally, you can cross-post articles from your home page to your rooms, and vice versa, with ease.  So if your normal feeds find something of interest that you want to add to the SharePoint Talk room, you can easily do that from your FriendFeed home page.

There are some drawbacks to FriendFeed, the biggest one being that you'll only see the headlines for the articles in your feeds, it doesn't give you any previews.  So you'll have to work a little harder to find out what's actually in the article, but that can be a good thing too

All in all, I've really enjoyed the experience on FriendFeed, and much like Twitter, I encourage you to check it out if you're looking for new sources of SharePoint information and interaction. Feel free to subscribe to my feed if you want, although I'm going to warn you that it's not 100% SharePoint stuff and like I said, I'm not that interesting.

http://friendfeed.com/ferringer

p.s. FriendFeed has a much better performance track record so far than Twitter does, but I don't want to make a big deal out of that or turn this into a "Twitter is down" complaint, so that's all I'm going to say on the matter.

A while back a friend of mine was getting frustrated with a news site he was trying to get set up in MOSS and asked me for some help.  His issue seemed pretty straight-forward, he wanted to add an Announcements web part to the main page of the site but couldn't find the web part anywhere in the site's web part gallery to be added.  I'm a little embarrassed to say that the solution to our problem didn't immediately come to me, but at the same time when your brain is working in a certain direction it's all too easy to overlook the simple solutions.

My first instinct was to check his site's Site Features and Site Collection Features in the Site Settings to see what was activated or deactivated.  His Enterprise features were enabled, as were his Standard features and Team Collaboration features.  So this wasn't a case of available functionality being disabled so that the web part couldn't be used.  Next I checked the file server of our SharePoint front end server to see if the files associated with the Announcements web part had been removed, which would prevent the web part from being in the site's gallery and could not find the files I was expecting to see.  It was at this point that I realize the folly of my actions and the fact that I was going about this situation all wrong.

See, I was forgetting that there is no such thing as an Announcements web part in SharePoint. "But John!" you're saying… "What about the Announcements web part that is automagically added to my site's home page any time I create a new team collaboration site?" And that's the crux of the problem…what appears to be a web part specifically for Announcements (or a Calendar, or Linkset, etc) is actually a pretty general web part that SharePoint makes available anytime you create a new list within your SharePoint site.  This web part is added to your gallery to provide you with a view of your list's contents, and depending on the list template you used to create the list will format the lists contents in different ways.  Links will be shown hyperlinked, Announcements will be shown with headlines and summaries in chronological order, Calendars will be shown in a standard calendar format, and so on.

My point is that to fix my friend's problem I didn't have to do anything more complex than create an Announcements list for his site; once I did that its associated web part appeared in the site's gallery and could be added to the page.  This is a pretty cool but often overlooked aspect of SharePoint, anytime you create a list SharePoint will automatically create a web part for that list which allows you to view its contents from somewhere other than the list's page itself.  And you can customize the data shown by that web part through the creation of custom views and filters for the list.  Pretty cool, huh?

"A-B-C. A-Always, B-Be, C-Closing. Always be closing, always be closing."

These are the words of Blake, Alec Baldwin's character in the movie version of "Glengarry Glen Ross" (http://www.imdb.com/title/tt0104348), as he talks to (more like rants) a group of real estate salesmen about the art of deal.  This scene popped into my head a few days ago as I was working on a customized Internet-facing publishing site in MOSS.  Why? Because when it comes to getting new content into your publishing site, it's "A-B-P. Always Be Publishing."

Why is this important?  If you don't, your updates won't show up and your rank and file users won't be able to see them, it's just that simple.  MOSS's content management system for publishing sites is configured so that unless your content has been checked in, published, and approved it will not be visible to anyone not in your site's authoring or approval groups.

If you're editing content in a MOSS publishing site (often used for Internet facing websites), always make sure that you have published all of your updates.  This includes, but is not limited to, changes to your master pages, page layouts, pages, lists, web parts, and much more.  If you are working on items that require approval, you must confirm that workflows for those approvals have been started and completed in order for them to be visible to all of your site's users. (NOTE: with publishing sites you can also schedule content to start and end on specified dates, which also change the visibility of your content) 

How do you do that?  There are a few different techniques I recommend using; you should try to do at least one of them every time you update your site and should probably do most of them together.

• Use the MOSS Check for Unpublished Items tool:
1. Make sure the Authoring Toolbar is displayed for your site (you should see a menu across the top of the page showing the page's version, status, publication start date and some pulldown menus)
2. Click the Tools pulldown menu and select the Check for Unpublished Items option.
3. You will see a message in the Authoring Toolbar saying that it is checking for unpublished items.
4. If there are any, you will see a message stating !Unpublished items are detected on the page.  In the message, click the link full report to open a report of the items found.
5. For each item in the list, initiate the publishing process so that they can be displayed to all users
• Log in as an anonymous user, or as a user with limited rights to the site.  Then check the page for your new content.  If you don't see it, it needs to be published.  One trick I like to use is to make my updates in Internet Explorer and verify my content as an anonymous user in a different browser, like FireFox. This allows me to make sure everything's getting published and at the same time make sure that things look good in non-IE browsers as well.
• Andrew Connell's STSADM Custom Commands (http://www.andrewconnell.com/blog/articles/MossStsadmWcmCommands.aspx) includes an option to publish all items in a list, which is great when you've just uploaded a ton of documents or images into a list or directory and don't want to have to go through every single workflow for every single item. Just point the tool at the list and it will publish them all for you (NOTE: you will need to be a SharePoint administrator to install and run the tool).

So the next time you're authoring your MOSS publishing site and can't figure out why your new content isn't showing up for your users, check to make sure it's published.  And put that coffee down.  Coffee's for publishers only.

A couple of weeks ago I decided to take the plunge and join up at Twitter.  If you're not familiar with it, Twitter is often referred to as a "microblogging" service.  Basically, you can post anything you want to it, as long your post consists of all text and is less than or equal to 140 characters long.  So you can't post images or videos, but you can post links to those files if you want.

So how does this relate to SharePoint?  Well, I joined Twitter at a pretty opportune time, because there really has been a large up swell in SharePoint-oriented professionals who have started "tweeting" (that's what it's called when you post something to Twitter, don't ask me ) in general and about SharePoint specifically.  I've been really impressed by the discussions I've been able to catch by being on Twitter, not to mention the ones I've gotten to be a part of.

If you are on Twitter and want to follow me, my page is posted below.  I'll also post a couple of other good links for finding SharePoint folks who are on Twitter, I highly recommend following anyone who catches your eye.  And keep in mind that this is just skimming the surface of what you can do with Twitter, there's all sorts of search engines, localizers, tag clouds, meme trackers, etc also springing up around Twitter on a near-constant basis.

http://Twitter.com/ferringer
http://twitter.com/sptweeters
http://stevepietrek.com/twitter/

Enjoy!

P.S. – I've found that Twitter is much more enjoyable via a rich desktop client.  I've used Witty and really liked it, but I'm currently using Twhirl (it has way more features and functions than Witty currently does).

A while ago I mentioned in the MSDN forums that I had some sample questions for the 70-630 and 70-631 SharePoint Admin certification exams from Microsoft, and since that time I have gotten a few requests in my inbox for those files.  So I've decided to go ahead and post them online for your downloading pleasure, if you should want them.

• For exam 70-630 (Configuring MOSS 2007) – http://drop.io/70630Qs
• For exam 70-631 (Configuring WSS v3) – http://drop.io/70631Qs

Please keep in mind that these are not brain dumps, you will not see these exact questions in the certification exam.  Instead, they contain sample questions intended to give you an idea of what the exam will contain.

If you're looking for books, there is a book specifically for the 70-630 exam that just came out on Amazon:

http://www.amazon.com/MCTS-SharePoint-Configuration-Technology-Certifications/dp/0470226633/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1207315086&sr=8-2

The other resource that I recommend studying to prepare for the 70-630 exam is the MOSS Administrator's Companion from MS Press:

http://www.amazon.com/Microsoft%C2%AE-Office-SharePoint%C2%AE-Administrators-Companion/dp/0735622825/ref=pd_bbs_5?ie=UTF8&s=books&qid=1207315086&sr=8-5

Unfortunately, there aren't any published resources out there yet for the 70-631 exam, which is too bad because I really thought it was the more difficult of the two.

Best of luck on the exams!

I recently received a free copy of "The SharePoint Shepherd's Guide for End Users", by SharePoint MVP Robert Bogue, and I wanted to share my thoughts with you about the book.

The lack of good end user resources for SharePoint like the Shepherd's Guide is what prompted me to start writing this blog in the first place.  SharePoint is a vast, complex, and often difficult tool to use if you're not properly introduced to it.  Time and time again I have seen SharePoint sites wither on the vine from a lack of use, not because the opportunity for collaboration was not there but because the audience could not grasp everything they could do with their SharePoint site or how to do the most basic tasks.  But educating and training your users on SharePoint can be time-consuming and expensive.

For me, this book is like the end user manual that Microsoft never shipped with SharePoint but really should have.  Rob does a great job of identifying the core functions of SharePoint that users need to know, and covers them as easily understood common tasks.  I think this is a great way to introduce information workers to SharePoint, as a user my goal is to figure out how to accomplish what I need to do with a new tool not the intimate inner workings of the tool.  By distilling SharePoint's core collaborative functions into chunks that users can easily grasp, the book makes it much easier for a new user to get up and going with the platform.

Each task is clearly laid out with a descriptive purpose, so a user can identify whether or not the task described by the book is applicable to what they are trying to accomplish in SharePoint.  Rob then walks through the steps necessary to execute the task from start to finish, and includes very useful screenshots to guide readers through the SharePoint pages they should be seeing in their environment as they complete the task.  The book also does a good job of explaining why the task is being executed in a particular way and covering any limitations or gotchas that the reader may encounter.

The book covers a wide range of topics, including basics like using a SharePoint collaboration site and integrating with Outlook and the rest of the Office stack.  Rob also goes into some Microsoft Office SharePoint Server (MOSS) 2007-specific topics such as MySites and publishing sites.  One thing I would have liked to see Rob spend a little more time on is the difference between MOSS and Windows SharePoint Services (WSS); he does mention it briefly in the initial chapters of the book but when covering MOSS-specific tasks I would have liked to see him pointing out that features like MySites require MOSS and are not included in all versions of SharePoint.  But I know from personal experience that this is not an easy topic to cover briefly and understand why he took the approach he did with WSS versus MOSS in the book.

The Shepherd's Guide also includes some outstanding resources in its appendices.  The appendices cover Site Definitions, List Definitions, Web Parts, Views, and Permissions, and provide excellent descriptions of each SharePoint component within those groupings so that users can get a good understanding of what makes them unique as well as their common use cases.  I think it makes a lot of sense to include these in appendices, rather than trying to explain the components within the book's tasks.  This way readers are not getting overwhelmed by all the information and have an easy resource to flip to when they need it.  And I really like seeing everything covered so thoroughly, because these components are key elements to successfully using SharePoint to its fullest potential.

One last thing about the book I want to touch on is the multiple and innovative ways Rob is distributing and licensing the book for sale.  If you want to purchase a single copy of The SharePoint Shepherd's Guide for End Users, you can do so from Lulu.com.  Rob also reports that the book will soon be available from Amazon.com, I have linked to its page if you want to bookmark it for future reference.  But the option Rob is offering that I think is really interesting is the availability of corporate licensing programs for companies that would like to purchase multiple copies of the book for their end users.  To me, this gives a company the opportunity to provide the Shepherd's Guide to their information workers as an actual manual for SharePoint so they have a ready resource on hand when they need it, sparing the need for costly training resources and classes.  For more information about the corporate licensing programs, I recommend sending Rob an email with your request.

For my current project at work I've been customizing SharePoint's publishing template for an Internet-facing website built on top of MOSS 2007.  All in all we're really not doing anything too crazy with the site, but I did run into one roadblock that I think is worth mentioning here.  It may not be completely end-user related, but I do think it is a good thing to keep in mind if you're sitting down with your SharePoint administrator(s) to plan how you're going to create your company's website in SharePoint.

The client wants to display an RSS feed on the main home page that outputs their most recent press releases.  Using the RSS feed will cut down on the manual upkeep required to keep the content on the home page fresh and allow them to only have to maintain their press release information in a single place.  I've been creating the master pages and page layouts for this new site on a sandbox server I built, so that I can get the finished product to where it needs to be before we deliver it to the client.  I created a web part zone in the page layout of the home page, and then loaded up the page in IE to add the RSS Viewer web part to the page.  That's where I ran into trouble.

The first issue I encountered was that the RSS Viewer web part was not available in the web part gallery as I expected.  So I fired up a separate web application on that sandbox server, opened up one of its sites that did not use the publishing site template in IE, and checked the site's web part gallery.  Sure enough, the RSS Viewer web part was available.  That told me it wasn't a problem with the SharePoint install on the server.

Next, after some serious digging at SearchForSharePoint.com (sorry about the gratuitous plug), I went back to my publishing site and took a look at the XML Web Part.  My thinking was that I could still point that web part at the RSS feed, and then apply an XSLT stylesheet to it for formatting.  In fact, I went back to the RSS Viewer web part in my other site, copied out its XSLT and applied it to my XML web part.  This resulted in an error being displayed in the web part.  After checking online, the errors I was seeing in the browser and SharePoint's logs indicated that it was an issue with a proxy server not being configured for the server, which makes no sense because this sandbox server can reach the internet without the use of a proxy.

After ruling out the XML Web Part, I opened up the publishing site's Site Settings and took a look at the Web Part gallery list for the site.  I decided to see if it was possible to manually add the RSS Viewer web part to the site's gallery so I could put it on the page.  When I took a look at the list of available web parts I didn't see the RSS Viewer, but I did see a web part called "RSS Aggregator", which I had never heard of before.  I went ahead and added it to my site's gallery, then added it to the site's home page.  Once I configured it for the RSS feed, I saw pretty much the same errors as I did with the XML Web Part, ending that thread of investigation.

I then remembered that there are third party web parts out there, such as the Feed Reader Web Part from Smiling Goat, which I hoped would resolve my issue.  So I grabbed the installer from Smiling Goat and ran it on my server (I know there's a newer version of the web part out on CodePlex, but this version has worked for me in the past so I went with it), but ran into the same problems again and the feed would not render.

A coworker of mine has been doing a lot of work for a different client who is building several custom MOSS publishing sites, so I pinged him to see if he could duplicate my problem.  He opened up one of his sandbox publishing sites, checked the web part gallery and lo and behold, there's the RSS Viewer Web Part.  He added it to the page, pointed it at my RSS feed, and it rendered without a hiccup.  Needless to say I was puzzled and frustrated.

So we started looking at the configuration of his site, and immediately I noticed that he had some features enabled that I didn't in my publishing site, specifically the ones relating to Enterprise licensed functionality.  So I went back into my publishing site and enabled the following two Features:

• Office SharePoint Server Enterprise Site Collection features – this is enabled in the Site Collection Features link located in the Site Collection Administration section.  Enabling this feature is what put the RSS Viewer web part in my publishing site's web part gallery.
• Office SharePoint Server Enterprise Site features – this is enabled in the Site features link located in the Site Administration section.  You do not need to enable this feature to add the web part to the top-level publishing site, but I think it is a good idea to enable both of these features in tandem.

Once I had the RSS Viewer web part in my gallery, it was smooth sailing.  The feed displayed, and I tweaked the XSLT in the web part to customize its output to meet my design requirements.

I'm having a hard time understanding why I need the Enterprise features to get the RSS Viewer web part, but that's the case.  It just seems strange, since that web part is available in other Standard license site templates, that you can't get it in the publishing site template.  The only thing I can figure out is that it is assumed you'll be enabling the Enterprise features as a standard practice for publishing sites, which I guess I'll be doing in the future as a standard configuration step.

I just wanted to take a quick second to direct you to a post published today by Robert Bogue, a SharePoint MVP:

http://thorprojects.com/blog/archive/2008/02/12/737.aspx

The article covers Rob's views on the proper usage of SharePoint Designer (SPD) and how that usage should be governed by SharePoint administrators.  SPD is a great tool for the customization and modification of SharePoint, but when not used properly it can really generate some heartburn for you.  I highly recommend checking out Rob's article and taking his advice to heart; it may not be directly applicable to your situation but hopefully at least it will get you thinking about what kind of limits your organization needs around tools such as SPD.

Wikipedia defines Disaster Recovery (DR) as "the process, policies and procedures of restoring operations critical to the resumption of business, including regaining access to data (records, hardware, software, etc.), communications (incoming, outgoing, toll-free, fax, etc.), workspace, and other business processes after a natural or human-induced disaster."

In the world of IT, DR usually involves redundant hardware such as web server load-balancing or server clustering and data duplication via the creation and restoration of backup files.  Some companies will spend millions of dollars purchasing, developing, and testing a DR infrastructure that they fervently hope that they will never have to use.  All too many organizations risk the loss of crucial business information and capital by not having any sort of DR plans in place at all.

Often DR falls under the jurisdiction of your IT administrators, the same people who installed, configured, and keep your SharePoint system up and running.  But one fact about SharePoint that often gets overlooked is that out of the box it provides two tools to its users that can be used to save your content in the event that something unfortunate happens to it.  Granted, it may be a bit of a stretch to put these tools in the same category as enterprise-caliber tape backup hardware, but when used properly they can provide very similar capabilities with little IT professional intervention

First, let's talk about the Recycle Bin.  If you haven't spent a lot of time poking around a SharePoint site, the only Recycle Bin you're probably familiar with is on your Windows desktop.  But with the latest release of SharePoint, Recycle Bins are included and activated by default in every SharePoint site you create.  And they act very similarly to the local Recycle Bin on your desktop.  If you delete a file in your SharePoint site it is not gone forever only to be retrieved via some arcane voodoo act performed by your SharePoint administrator.  Instead, it is automatically sent to your site's Recycle Bin until the Bin is emptied.  The Recycle Bin can hold not only deleted documents, but also document libraries, list items, and lists that are deleted from a SharePoint site.

Here are a couple of things to keep in mind about SharePoint Recycle Bins:

• Although they are enabled by default in SharePoint, they can be turned off.  So if you don't see one in your site, ask your SharePoint administrator about its status.
• The items in your site's Recycle Bin will count against your site's storage quota.  So if your site is running out of space, check your Recycle Bin to make sure you're not tying up a bunch of storage with unneeded items.
• By default items will be deleted from the Recycle Bin once they've been in there for 30 days, but this value can be modified by your SharePoint administrator.

Finally, the SharePoint Recycle Bin is referred to as a "two-stage" Recycle Bin.  This means that when you empty your Recycle Bin, or an item is removed from it because its been in there for a while, it still is not gone forever.  In Windows, when you empty your Recycle Bin the items in it are gone forever (barring the use of a specialized recovery tool and some fervent hoping that the affected disk sectors have not be overwritten).  But in SharePoint when you empty a Recycle Bin, the items in it are moved to its parent Site Collection's top-level Recycle Bin, just in case you didn't really mean to delete it.  This means that while the item is in the Site Collection's Recycle Bin it can be restored by a site collection administrator.

Like the first-stage site Recycle Bin, items will be removed from the Site Collection's Recycle Bin once they have been in it past the Bin's retention period.  And, just like the first-stage Bin, by default that value is set to 30 days but it can be modified by a SharePoint administrator.  Once an item has been removed from the Site Collection's Recycle Bin, it's pretty much gone; the only way it can be retrieved is via a restore of a backup for the site (if such a backup has been made).

Since this post is already plenty long, I'll cover document versioning in a subsequent post.

I highly recommend taking a look at this post from the Joining Dots blog on how to add custom end user help information to web parts.  Extending your SharePoint environment with instructive content like this can go a long way towards improving your users experiences and increasing participation.

http://www.joiningdots.net/blog/2008/01/user-help-within-sharepoint.html

EDIT: My bad, I had a copy/paste error in the original post.  Thank you Joe for helping me get this fixed.