After months of work, the new SharePoint Report 2008 has been released. I collaborated with CMS Watch to develop a full 190 page research report that exposes what SharePoint does well, its limitations and what businesses of all sizes need to do to be successful when implementing the tool.
I encourage you to review the sample content and review the TOC.
If you have feedback on the report, I'd love to hear it.
We recently undertook a project to develop a global intranet for a relatively large organization. As part of the requirements of that implementation, the client wanted to create a highly customized My Site experience. As anyone who has delved deep into My Site customization knows, it's not straightforward, easy and may create maintenance issues long term.
Ultimately, after working through the challenges with the client, we collectively agreed to back off the more grandiose My Site customization plans in lieu of a more simple approach. The reasons for this change centered around the following:
So while the we didn't create the highly customized My Site, we still implemented some limited customization that delivered a custom theme, master page and some unique navigation (to tie in the rest of the portal). We used a technique called "feature stapling" to make that happen and ensure "compatibility" with what Microsoft would like to see in SharePoint implementations.
If you're interested in a really good set of explanations of both the My Site architecture, see a blog entry from Mark Arend. If you are looking for the best practice approach to modifying the My Sites, see the SharePoint Product Team's blog entry.
Many of our customers ask how they can spur adoption of new portal technology. In cases where the IT department is leading the charge, we see a lot of "build it and they will come" approaches. In much the same way Kevin Costner's character in Field of Dreams built a baseball field on his farm to encourage ghosts of baseball players to visit and play the game, IT groups hope that by simply exposing portal functionality to their end users, those same users will figure out what to do with it. The trouble is that most employees are too caught up in their daily tasks to focus on the use of yet another tool, let alone see the opportunities for making their lives easier.
Portals technologies and other "productivity" tools come and go. There have been lots of them over the years. The prime example would be word processing software. Does anyone remember the resistance to computer-based word processing over a typewriter? Does anyone remember the fights that erupted in the executive offices when word processing centers (that existed in many large companies) were replaced by a far fewer number of individual secretaries armed with tools like the DOS-based Displaywrite word processor (an IBM created word processing packages from the early to mid-80's), WordPerfect or any of the other word processing packages of that era? Or how about when the concept of an executive doing their own typing was introduced! <GASP!>
The difference between a word processor and a portal is the number of functions. More than likely, anyone familiar with a typewriter can guess how a word processing package functions. And, with minimal fiddling, could probably figure out how to type out and print a document.
By contrast, portal technologies encompass a number of functions -- some of them not so obvious. The fact is and remains that IT or any organization pushing the adoption of a portal product, must help their user community. This help comes in many forms, but here are some best practices for not only helping introduce the portal, but driving usage:
While this list contains just six best practices, they are probably the most frequently ignored. And, obviously, these best practices represent only a segment of what you should be doing overall. However, from what we've observed, just doing these six things well will vastly improve your overall success.
I just finished my time at the 2008 SharePoint conference in Seattle (admittedly a little early). By all accounts, this conference was well attended with over 3800 participants. Keynotes at the conference were given by Bill Gates, Kurt DelBene and three-time Tour de France winner (and first non-European winner) Greg LeMond. In addition there were a whole slew of sessions on everything from Search Server 2008, Branding SharePoint and Microsoft's latest technology acquisition search vendor Fast.
Most significantly, Microsoft made a few announcements/general statements -- some surprising and some expected:
Beyond the announcements, the conference was full of the usual information sessions. Microsoft seemed to have a good mix of services partners, ISVs and Microsoft employees (both Microsoft Consulting Services and product team folks).
I was able to attend a number of sessions, but was generally dismayed at the lack of real depth or new material. As mentioned earlier, the Fast search sessions were only slightly better than marketing pitches for their software. Sessions on best practices rehashed the same stuff that virtually anyone in this space would know and has already heard a dozen times. If you had attended the previous SharePoint conference, it seemed like many of those sessions were repeated at this event (more than a year later). And, in what seemed like a bizarre event, other attendees reported that in one session, two speakers began to disagree with each other during their presentation and the talk degraded into unintelligible babble.
There were a few bright spots however. The sessions on the new Search Server 2008 struck a nice balance between technical detail and actual usage. Customers like EasyJet and Chesapeake Energy did a good job of relating how their SharePoint implementations progressed and the value that they received (a similar presentation by Best Buy for Business was less interesting though). Finally, the session on the latest version of the Community pack for Wikis was quite interesting, if only to demonstrate how SharePoint can be extended beyond it core competencies, as well as the community support behind the product.
In all, the conference wasn't a waste of time, but I would have preferred better material. I would have liked to have seen deeper material around all of the topics (in fact for developers, the Office Developers Conference earlier this year in San Jose was the place to be). Better titles for some session would have also helped -- a sessions titled "My Content is in SharePoint, now what" sounded like it would have been about adoption or user experience, but really ended up being about securing content. A good topic, to be sure, but poorly "branded." Finally, the best practices session is something everyone wants (the room was packed), but they should have focused more on the specific challenges in running a SharePoint implementation like: provisioning (the explosion that can occur), the challenge around taxonomy development, when to create site definitions vs. site templates, how to train users, dealing with varying levels of Office and so on.
If you were at the conference, I'd love to hear your feedback. Like it? Thought it was a waste of time? Were there particular sessions that piqued your interest?
Like many of our clients, Consejo uses SharePoint to collaborate -- both with our clients and amongst our employees. As a result, it has become a critical service to maintain -- thereby making it critical from a business continuity planning perspective as well.
Recently a number of clients have all asked the same question: how can we easily create backups of our SharePoint sites so that we can restore them in the event of a disaster? While there are some good backup options built into SharePoint and some commercial vendors like AvePoint that provide backup and restore solutions, there are some relatively simply approaches that will provide baseline protection in the event of a disaster.
To begin, you should really read this post from Microsoft's SharePoint Developer Documentation Team blog on the various backup mechanisms and elements that need to be protected. The blog entry does a great job of highlighting all of the moving parts, but doesn't provide a straightforward approach to getting the basics. What we've tried to do, below, is provide you with an easy mechanism to automate and schedule backing up SharePoint site collections. These backups can easily be restored in the event of a disaster. To be clear, this approach is kind of the sledge hammer approach for site collections only and may not be right for the needs of individual sites. However, this represents the very least you should have in place for your SharePoint environment.
NOTE: The backup process described will backup only the site collections specified in the backup routine. As the Microsoft article suggests, there are a lot of other parts to a SharePoint environment. When designing your complete disaster recovery/business continuity plan, please ensure you have all of your bases covered.
Depending on the type of SharePoint environment you have, your complete SharePoint environment will have one or more site collections. When using the approach illustrated in this post, you must backup each site collection separately (or include them in a single job). In any event, you should inventory the various site collections you want included in the backup routine. If you're unsure what collections exist, you can look them up in the Central Administration tool by going to the Applications tab and clicking on the Site Collection List option under the SharePoint Site Management category (show in figure 1-1).
Figure 1-1 The site collection list for a given SharePoint application
If the site collections that appear aren't what you expect, make sure that you've selected the right web application, using the drop down list just above and to the right of the site collection list.
If you have found the right set of collections, take note of all the ones that are important to include in your backup routine. You'll need the URLs to each of the collections. Because you can have multiple collections off of the same web application, SharePoint may only show a relatively URLs; make sure that you know the full-qualified URL for this backup process.
To create some basic automation and logging, we're going to create a CMD file that contains all of the commands necessary to use the STSADM command-line utility to backup one or more site collections and add some basic logging to a text file.
CMD code
The code in the CMD file should contain at least the following:
@echo off
echo --------------------------------------------------------------------- >> SharePoint_backup.log
echo SharePoint Backup Began >> SharePoint_backup.log
date /t >> sharepoint_backup.log
time /t >> sharepoint_backup.log
"c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm" -o backup -url [URL TO YOUR SITE COLLECTION] -filename [PATH TO BACKUP FILE] -overwrite >> sharepoint_backup.log
if errorlevel 0 goto finish_backup
:error
echo An error has occured and the backup did not complete properly >> sharepoint_backup.log
goto end
:finish_backup
echo The backup completed successfully >> sharepoint_backup.log
:end
echo SharePoint Backup Finished >> sharepoint_backup.log
date /t >> sharepoint_backup.log
time /t >> sharepoint_backup.log
Keep in mind that the code contains bracketed text (like [URL]). This bracket text should be replaced with settings specific to your environment, like the URL to your site collection or the path to your backup file.
Once you've made the modifications to your specific site, save the file to a directory on your SharePoint server; keep in mind that the log file will be written to the same directory and will collect entries over time.
Before proceeding, I would recommend testing your finalized CMD file to ensure it operates as you expect. Once it does, proceed to the next step.
Scheduling the CMD File
There are a number of ways to schedule a process to run on a server, but Windows has a built-in scheduling system that you can use for this purpose. The service is the Windows Scheduled Tasks. A scheduled task can be created and run on a specific period and within the context of a given user. To create the backup scheduled task, using the following instructions:
To confirm that the job runs as expected, you can reopen the Scheduled Tasks option in the control panel and right click on the new job. From the context menu, pick RUN.
After you have your job scheduled, your SharePoint site collection(s) will be backed up every time the job runs. I would recommend at least once every 24 hours.
NOTES:
I'd love to hear your feedback on this approach and/or whether this was helpful to you.
Microsoft has finally released the new service pack for SharePoint 2007. The individual downloads for WSS and MOSS can be found here:
We will be upgrading our own servers and will post our findings shortly.
If you haven't seen it, Microsoft recently released some information on the upcoming service pack 1 for SharePoint (both WSS and MOSS). This new service pack not only includes a number of hot fixes for both platforms, but introduces some new functionality. In addition to Server 2008 support, Microsoft is now officially supporting AJAX-enabled web parts. They've also included some new STSADM commands (and who doesn't like STSADM).
Unfortunately, Microsoft has only really stated that it will be released by 2008. Recently, Arpan Shah posted in his blog that the service pack could be released "anytime between now and Q1 of 2008." So, for those of you waiting for your issue to be corrected or some of the new features, you now have a potentially four month window to sit patiently...
Back in Office 2003, Microsoft introduced the concept of the "task pane." The task pane was a panel that appeared on the right side of the Office interface (at least for the "first class" Office products). The task pane represented a few different functions -- from showing the status of a document in SharePoint, to allowing you to manage permissions on a document. Included with these functions was something called the "Research" task pane.
The Research task pane allows you to search various information sources using basic keyword-type searches. For example, if you highlight a word in a document and right click, you see a function called "Look Up." When you select that option, the feature searches through the dictionary (for example) for the definition of the term you highlighted. You can see this function in figure 1-1.
Figure 1-1 The context menu allows you to lookup a term in Office 2007
When you execute this function, the Research task pane dutifully appears on your right. By default, the task pane appears to the right and displays the search result. In addition, it exposes a number of other sources that the search can be executed against (shown in figure 1-2).
Figure 1-2 The task pane and the content sources.
When I first saw this feature, I thought it was a way to extract additional dollars out of buyers of Office, since a good number of the research sources were premium sites that wouldn't allow you access to the content without a subscription. However, I then noticed a link at the bottom of the task pane labeled "Research Options." Clicking on this link allows you to control what sources are included in your task pane, as well as allowing you to add addition sources as shown in figure 1-3.
Figure 1-3 The Research Options dialog
As it turns out, it's easy to add your own sources, in addition to enabling ones already defined within Office. In fact, one of the best sources of "research" is SharePoint. SharePoint's own search web service is already setup to be included as a search source (MOSS, not WSS).
To add your SharePoint site as a search source, follow the instructions below:
Once you've added your own internal search as a source, any lookup done within first class citizens of Office (Word, PowerPoint, Excel and Access), can use that source to look up terms and return search results, just as any other source. When users click on a search result, Internet Explorer automatically opens, preserves the search results in pane on the left side of the interface and show the specific, chosen result in the main window (as shown in figure 1-4). Now, all users have to do is navigate the various results until they find the one they feel meets their requirement.
Figure 1-4 Search results preserved in IE
This feature is particularly valuable for organizations that need to connect employees with content throughout the enterprise. In addition, it adheres to a good rule of thumb about portals: don't make your employees leave the applications they're comfortable using -- surface the functionality in the applications where they do their work
[UPDATED: 25 November 2007 - Slight flow changes to the content]
I've just returned from the IIR/SharedInsights Portals, Collaboration and Content Management conference. While I've been speaking at this conference for a few years, this year's conference was a bit unique. Unlike past conferences, where the vast majority of the attendees were more business oriented and "non-denominational" when it came to technology, this year's attendees were more technical and were very interested in specific technologies -- a good many of them interested in SharePoint. It seemed that many of the attendees were either starting to implement or had implemented "phase 1," a smaller percentage were making their final decisions around what portal platform they would implement in the coming months -- almost universally, SharePoint was in the product mix, if not the chosen portal platform (hence the interest). However, there still seemed to be a lot of basic questions about how SharePoint would fit in the enterprise. To that end, I wanted to recommend a book written by some former colleagues of mine. It's called Essential SharePoint 2007.
|
What makes this book somewhat unique in the space (since there are absolutely tons of book on SharePoint 2007) is that it takes a less technological route. The book focuses on business usage more than technological implementation. I would recommend it as good starting point for anyone interested in SharePoint -- whether or not you're technically inclined. In addition, CMSWatch also has a number of reports which compare SharePoint to other tools in the ECM/Portal space. These reports would also be valuable for anyone considering SharePoint.
Now, even in the SharePoint 2003 days, there was great interest in SharePoint -- organization's interest in 2007 is not really unique. In a good majority of the cases, the Windows SharePoint Services component was and is a very big leap in accessible (easily obtained and easy to install) collaborative technology, but it is also just darn easy to use for the vast majority of typical Office users. Contributing to this ease of use is the fact that the technology is directly integrated with Office -- even people with older versions of Office can use it (you don't have to match SharePoint's version with your Office version). However, the 2007 version (and WSS v3) seems to have created a great deal more buzz.
From what I heard from attendees, most organizations were hoping to leverage the portal capabilities found in MOSS. There was a slightly smaller group interested in pure team collaboration management -- project teams need a place to deposit assets and work from one "song book." Finally, there were those groups who felt that SharePoint was almost a "blight," but needed to figure out how to manage it (my guess is that these individuals got caught in the WSS explosion that occurs in many organizations).
If I were to identify the biggest changes/advantages, it would be in two categories: 1) expanding content management capabilities and 2) improved extensibility. On the content management side, web content management tops the list. This feature allows you to manage traditional web sites using SharePoint. In addition, Microsoft has added new forms of contribution with the addition of Wiki and Blog templates. When you add these capabilities to the business intelligence and forms processing features, Microsoft has taken SharePoint native content management function to a whole new level.
For the developer types, 2007 represents a leap forward in extensibility, where almost everything inside of SharePoint is accessible through the object model. For example, you can write your own authentication provider, to enable SharePoint to use something other than Active Directory to authenticate users (unheard of in SharePoint 2003). It's also now possible to easily add new interface elements to native SharePoint administrative screens using the "features" capability.
For those of you who might be interested in some of the content at the conference, IIR has posted some podcasts on their web site. More podcasts will be posted as time goes by (include my own). If you're interested in attending the spring conference, you can find more details on the IIR web site (you may want to wait a few days before searching around, since the current conference is still running as of 8 November).
A new service pack has been released for both SharePoint Portal and Windows SharePoint Services (2003/v2). The KB article on the update can be found here: http://support.microsoft.com/kb/923643.
Thank you to Ian Morrish at WSSDemo for posting a link to the KB article.
While I'm not a huge fan of simply re-posting content originating on other individual's blog, this particular re-post is warranted, if for no other reason that it was a bear to find the solution. My hope is that more references to the posting will increase the likelyhood that someone else will spend less time finding the answer in the future.
Now, effectively the problem I encountered was an "Access is Denied" message when trying to schedule a search crawl in Office SharePoint Server 2007 (RTM). While, I could manually start a crawl and it would successfully complete, I was not able to create a schedule for either an incremental or a full crawl. Apparently, the trouble was missing permissions on the Tasks folder in the Windows directory; the "WSS_WPG" group (created by SharePoint during installation) needed read and write access to the folder.
It totally makes sense that SharePoint would leverage scheduled tasks to kick off scheduled crawls, but I would have hoped that the installation process set this for you. In my case, the server I dedicated to the index function was a "recycle" and was never reloaded with the OS -- the prior implementation of SharePoint was uninstalled and I re-installed the new implementation over top. In hindsight, this may not have been such a good idea, but we live and learn.
Here's the article that saved me the trouble of rebuilding my machines (yes I was that frustrated): http://www.folin.se/index.php/category/microsoft-office-sharepoint-server-2007/
Many thanks to Michael Folin for posting such a great tip!
In a previous post, I described a panel that I participated in where each of three consultants presented what they liked an didn't like about SharePoint. In that post, I gave you my "likes;" in this post, I'll continue the discussion with what I think are SharePoint's disadvantages or shortcomings. While the product is quite good, there are definitely areas where it could improve -- some of those areas have more to do with the way Microsoft markets the product than the product itself; none-the-less, they are disadvantages.
SharePoint Disadvantages
Ultimately, I must admit that I like SharePoint. I think it's a great product, despite what I perceive as its failings. The Office product team at Microsoft should be commended for producing a tool that is quite broadly useful. I would encourage anyone who hasn't used SharePoint to download the trial version of MOSS or simply install WSS on their Windows server. I think you'll be impressed with its ease of use and tight integration with Office; as a colleague of mine was famous for saying -- it just works. That said, you need to understand how you'll use the product and in what context; understanding both what SharePoint does well and what it doesn't will help you avoid a bad implementation that doesn't add value to anyone's work day.
Give me feedback. Tell me I'm wrong or simply give me more examples for either list. I would love to hear from you.
Since this is the first post on Consejo's blog, I thought I'd start by digging into a topic we often discuss with our customers -- does SharePoint fit their organization or should they look at other technologies. The "easiest" and most consultant-like answer is: it depends. Now, after you've stopped rolling your eyes, you'll (hopefully) realize that this answer is the only one possible with a such a generic, blanket question. However, what most people want is a quick comparison between what they need to accomplish and where SharePoint might fit.
As it happens, I've just returned from the Gilbane Group's conference (in partnership with CMSWatch) on Content Technologies for Non-Profits and Government Agencies. My role at the conference was to be a panelist discussing "Everything You Ever Wanted to Know about SharePoint 2007." While this is a pretty broad topic, given only the hour for the discussion, the format allowed each of the three SharePoint consultant 15 minutes to discuss what they liked and disliked about SharePoint; in effect, we could discuss how SharePoint fit or didn't fit into various business scenarios. The other two panelist were Randy Woods, President of non-linear creations and Russel Stalters, Chief Technology Officer of Applied Information Sciences. Each consultant primarily focused on Microsoft Office SharePoint Server 2007 (MOSS), but a great deal of content could equally apply to Windows SharePoint Services (WSS), since MOSS incorporates everything that is WSS.
I can't take credit for either Randy's or Russ' presentations, so I've not provided their comments herein. However, I am providing the list I presented during the panel, with a summary of my verbal comments. Since a single post would be pretty long, I've broken it up; this post contains the "what I like" list and the subsequent post will contain the "what I don't like" list.
What I like about SharePoint
The list I've provided above is just a few of the areas where I believe SharePoint really shines as product. SharePoint is certainly packed with lots of features that I haven't mentioned here, but this list represents the majority of what I've found is most valuable to customers.
In a follow-up post, I will give you the counterpoint to this list. Interestingly, some of what I've listed here as strengths can also be weakness, as in the broad partner community, but that is for a different discussion.
I'm interested in your thoughts. What do you think are SharePoint's greatest assets? What makes the platform valuable to your organization or what do you see as its best features?
Amazon.com: Essential SharePoint 2007: Books: Scott Jamison,Mauro Cardarelli,Susan Hanley
