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.
While I typically don't like to post consumer product reviews on our corporate blog, this one is different... really.
As a developer, I have fallen prey to what appears to be a stereotypical developer behavior -- listening to music while coding. Whether it's a behavior picked up through "peer pressure" or my own personal inability to focus without some sort of constant noise to block out my surroundings, I don't know. However, listening to music has become critical.
In addition to my music listening, I have also begun to extensively use Skype. Over the last two years, Skype has become an indispensable tool for all Consejo consultants to communicate with each other and our clients -- whether through VOiP, IM or file transfers; Skype just works.
As a result of all of these uses of audio with my laptop, I began searching for a decent set of stereo headphones that had an integrated microphone. For me, I was specifically looking for something that had the following characteristics:
Although I found a number of candidates, most had short runtimes, were too bulky to fit in my laptop case (since I travel extensively, this was also key) or were too expensive. Ultimately, I found the Insignia brand Bluetooth-attached headphones at Best Buy. At $49.99 and a 10 hour run-time, they fit the bill.
Figure 1 - Insignia Bluetooth Headphones (model: NS-BTHDP)
I have been using these headphones for about three months now. In that time, I've never run the battery totally down. In addition, they can pair with more than one Bluetooth device (e.g. my computer and my cell phone), making it possible to listen to music and, when a call comes in to my cell phone, switch to that device and then switch back when the call has completed.
Beyond all of this, here's what I really liked about these headphones:
Advantages
Disadvantages
So, in short, if you're looking for a pair of decent, reasonably priced, wireless headphones, you should consider the Insignia NS-BTHDP. If you have them, I'd love to hear your feedback as well.
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.
