|
|
|
|
|
|
|
|
|
|
|
|
| Making Sense of the SharePoint World |
6/26/2009
![MCSY00579_0000[1]](/Lists/Posts/Attachments/44/MCSY00579_00001_1_3DAC3789.png "MCSY00579_0000[1]") "You Are Now Free to Upgrade Your Servers..."
Several weeks ago, Microsoft released Service Pack 2 for SharePoint. It was great! SP2 fixed many problems, large and small, as well as introduced a feature to scan your environment for potential upgrade issues.
There was just one problem. If you were running anything other than plain Windows SharePoint Services (WSS), SP2 would trip an expiration flag that made your computer think you were running an evaluation version. For many users this was just a little inconvenience. You could simply re-enter your product key, and the timeout would be removed. Unfortunately, users of Microsoft Search Server 2008 Express (MSSX) were in a pickle. For you see, MSSX doesn't have a license key.
Of course, MSSX user or not, Microsoft didn't plan for SP2 to do this. So they have been working diligently to come up with a patch to resolve the issue. As of last night, that patch has been released. You can read about the details, and/or download it, on the SharePoint Team Blog, or KB Article 971620.
So, install the patch, apply Service Pack 2, and the April 2009 cumulative update package, and you'll soon be SharePoint-ing your way into the future!
6/18/2009 ![MCj03347000000[1]](/Lists/Posts/Attachments/43/MCj033470000001_thumb_3B95D018.png "MCj03347000000[1]")
What Makes The Sanity Point Run? Today I'm going to give you a little peek under the hood of my new site. I'll compare what I used before, and what I have now, and how that impacts what I could do. Then I'll go into some technical detail about my current environment, and point out a few things to look for when selecting your own provider. Finally, I'll show you how I customized what I got from the ISP to produce The Sanity Point you are reading now. The Importance of Dedication Although I have brought most of my articles over from my previous blog, in many ways this site is the polar opposite of what I had before. The biggest change, of course, is that I have moved from a shared hosting environment (Office Live and Windows Live Spaces) onto a dedicated server. The key difference is, as its name implies, on a shared environment, your web site is using the same hardware as other users - potentially many others; while on a dedicated server, you are the only person on the box. This greatly impacts what you are allowed to do with your site. Virtually all shared hosting providers pre-configure their servers with a selection of templates, tools, and utility applications (e.g. eStores, blog software, etc...). The usually allow (but don't always encourage) you to upload your own pages and images (typically via FTP or FrontPage extensions), and may offer connectivity to some shared database resources for server-side scripting. However, because you are sharing the host with other users, you won't usually be allowed to create compiled applications, or install and use components that the ISP hasn't already provided. With a dedicated server, on the other hand, the ISP usually sets up a box, installs an OS, maybe some Antivirus software and a few free utilities, and hands you an administrator password. From then on, it is essentially "your box". Unless you buy enhanced support, the only thing they'll do is poke the power switch if you accidentally shut it down or otherwise lock it up, reset the admin password, or replace a component that gets fried. Otherwise, you are on your own and free to install any (legal) software, and customize the environment to your heart's content. Yes, Virginia... You can Run SharePoint on Windows Web Server Of course, with that freedom comes additional responsibility. Since only you know what you plan to do, you have to be careful in choosing options. Ordering a dedicated server is just like buying one for your own office. You need to consider: - The Operating System (Windows or a Linux/Unix variant)
- The CPU
- How much memory to order
- How much network bandwidth you expect to use
And, of course, all of this is tempered by how much you can afford. Dedicated servers can get very expensive. If you look around, though, you can find some decent deals. The provider I chose, for example, (APlus.net) offers dedicated servers for as little as $45 a month. In my case, since I wanted to run SharePoint, my first requirement was running Windows Server. That slimmed my choices a little, but not by much. Since I was only going to get a single box, for Internet-only users, and wasn't going to be running a domain, that made the obvious choice Windows Web Server 2008. I can hear some of you saying "But wait! You can't run SharePoint on the Web Edition of Windows!!" Well, I'm pleased to say, that isn't entirely accurate. There has never been any restriction against running SharePoint on any edition of Windows Server. However, with Windows Server 2003 web edition, you weren't allowed to install a database server on that edition. This meant you needed at least two boxes in order to run SharePoint, which made dedicated hosting prohibitive for most users. The good news is, with Windows Web Server 2008, Microsoft no longer has that restriction, so now you can effectively create a low-cost single-box SharePoint environment for Internet sites with either Windows SharePoint Services, or Search Server Express. That's what I've done here. While you can technically install WSS on 512MB, it really doesn't work very well, so I bumped the memory up to 3GB (the most SharePoint can effectively use on 32-bit Windows). I'm also running a dual-core CPU. This results in the Windows about page shown below: 
Note: APlus doesn't offer Web Edition in 64 bits, but for my usage, 32-bits is fine. By the time SharePoint 2010 rolls around with its 64-bit requirement, I'll be ready to replace this server. Installing My Stuff After sitting down and figuring out my realistic usage, I decided to directly install SQL Server 2008 Express and do an advanced Search Server 2008 Express installation, rather than setting up a basic Windows SharePoint Services install first. While this does limit me to 4GB per database, even for the WSS content databases, it also allowed me the full flexibility to set my service accounts and decide how to manage my databases. Rule #1: Default Settings + Internet Facing = Bad Move! Once I had SharePoint (well, MSSX) installed, all that gave me is the default stuff of SharePoint: 
Now, that's all great, but if I just wanted the stock SharePoint look, I could have used a shared hosting provider. So next I added the Community Kit for SharePoint: Enhanced Blog Edition (CKS:EBE), and a few other goodies that I wanted to use in my sites. I've used the Intensive Theme in the past: 
But again, I wanted something a bit more unique. So, with SharePoint Designer in hand, I took creating and applying a theme I call "Sanity Road", which is the theme you see today. 
Going Beyond Of course, going to a dedicated server is usually overkill if you only have one site, and can be a little flexible in your demands for customization. In my case, however, I'm going to use the server for some other things, such as demonstrations, and hosting other personal and community sites not necessarily related to SharePoint. In this article, I've tried to give you a feel for the tasks involved in selecting and setting up hosting on a dedicated server. I hope you have found it helpful! 6/17/2009![MCj04379900000[1]](/Lists/Posts/Attachments/42/MCj043799000001_1_2DD7091F.png "MCj04379900000[1]") A Taste of "Professional SharePoint Designer"
I am pleased to announce that Microsoft has posted two chapters from "Professional Microsoft Office SharePoint Designer 2007" on MSDN. This is the book I spent the better part of last year writing, along with Asif Rehmani and Bryan Phillips. In the approximately six months since its release, Pro SPD has received excellent reviews, now you can see why for yourselves with the following chapters: Chapter 11: Advanced Data Access: External Data and More Chapter 15: Creating Workflow Elements in Visual Studio These two chapters give you a taste of the breadth and depth you will find in the book, including creating views of complex hierarchical data from Web services, and how to extend the power of SharePoint Designer's workflow capability with custom Actions. Now that Microsoft has made SharePoint Designer available as a free download, having good documentation available is even more important than ever. I'm sure once you have checked out the samples, you're going to want to buy the rest! 6/14/2009
![MCj01051840000[1]](/Lists/Posts/Attachments/41/MCj010518400001_1_7A87F172.png "MCj01051840000[1]")
Congratulations! You've found my new site.
This article is just a place-holder while I'm waiting for DNS to update world-wide. Then I'll be able to update my RSS feed and get back into the swing of things. Until then, I've copied over most of my articles (even with their original publish dates). I'm still updating tags, my blog roll, etc... so you may see some more changes in the left column, but the main stuff is all here.
Enjoy!
6/4/2009
![MCPE03789_0000[1]](/Lists/Posts/Attachments/40/MCPE03789_00001_7074D4BB.png "MCPE03789_0000[1]") Getting Ready to Move...
I've always been a proponent of sites about SharePoint using SharePoint for hosting whenever possible. In fact, The Sanity Point was hosted on SharePoint for a long time. A few months ago, though, I moved my site onto Office Live hosting and started using Live Spaces for my blog.
Now, Office Live is (sort of) based on SharePoint. The problem is, on OL, I don't have full access to the SharePoint functionality I want. For example, it doesn't include SharePoint blogging, hence the Spaces-sourced blog.
Now I'm getting back on SharePoint. I've got my host, and I'm starting to get things set up the way I want them. So, watch this space! Something new is on the way...
5/15/2009
![MCj04346750000[1]](/Lists/Posts/Attachments/39/MCj043467500001_thumb_4FF294DE.png "MCj04346750000[1]") What a Week! - A Tech-Ed Wrap-up
Microsoft Tech-Ed North America 2009 is over, and despite the economy, it was another great show. I spent most of my time in the Technical Learning Center, or TLC, answering questions about SharePoint.
Most days I also, along with co-author Asif Rehmani, gave away and autographed dozens of copies of our book, Professional Microsoft Office SharePoint Designer 2007. All together, we (well, Microsoft) gave away almost 450 books. I want to take this opportunity to thank everyone who stood in the long lines, braving attacks by the flying monkeys, for their support and interest.
Speaking of flying monkeys, these were probably one of the most popular SWAG items at the show...
They came with three costume colors, Red, Black, and Blue. But their main claim to fame was that their arms are elastic, and when stretched and released, not only do the monkeys "fly", they also scream (don't worry, I'm a fan of the "silent" web - no sound effects will disturb your office here!)
The Big Announcements
Though you may have seen these before, no show report would be complete without the big Tech-Ed announcements:
- It is official - Microsoft SharePoint Server 2010 (no "Portal" or "Office" in sight) will be 64-bit only all the way through the stack. You will need to be running 64-bit Windows Server 2008 or Windows Server 2008 R2 in order to install it (no 2003 allowed). In addition, you will need 64-bit SQL Server (2005 or 2008) as well.
- All TechEd attendees will be included in a (semi?) private Technical Preview of the Office 2010 client applications.
- There will be a SQL Server 2008 R2
- Windows Server 2008 R2 is also 64-bit Only.
- The Groove 2010 client has been renamed SharePoint WorkSpace 2010. I'm not sure whether it is an attempt to pick up on the glow of the SharePoint brand, or there is some seriously tightened integration coming, but I'm looking forward to finding out!
So the watchword is, no more SharePoint installs on Windows Server 2003 or using 32-bits. Stop Now. Do it right, and save yourself the grief when the new version comes along.
5/7/2009
![MCj03002750000[1]](/Lists/Posts/Attachments/38/MCj030027500001_1_6E255267.png "MCj03002750000[1]")
Discovering the Setup User Account - A SharePoint "Whodunit?"
It was a dark and stormy night. There were SharePoint problems in The City. Lots of them. And it was my job to track 'em all down. I'm a consultant. No problem is too big or too small. It's what I do.
This is the story of one of those problems...
I was hard at work at my desk when the phone rang. Even before he told me, I could tell from the sound of the caller's voice that he had a big problem. His name was Steve. Not the problem - the caller. Turns out Steve's SharePoint guy, Ben, was on the lamb. Ben ran into some Girl Trouble, you see, and he wasn't coming back. Now all Steve had was a SharePoint farm, a scrap of paper, and some half-linked wiki pages.
While I couldn't do anything about filling out his content, at least he used a SharePoint wiki, so his users could pick up the slack there.
I turned my attention to the only clue - that scrap of paper. Turns out, it had a hand full of account ID's written down. It didn't take a genius to figure out that these were the accounts he used when setting up his farm. There were more than three of them, and it was good. Unfortunately, these were all code-name accounts like s23365, and k45321. No way to tell which account was which. That was bad. For all we knew, Ben had used the same account for all three of the major functions (Setup User, Server Farm, and Content Access). Or maybe they were all individual service accounts, and he had been logged in with his own account when he set up SharePoint.
The Big Deal
Why is this so important, you ask? Well, if you've read "Taking Accounts into Account", you'll know that the Setup User has special status - essentially this ID has full control over the SharePoint installation, even if you take it out of the administrator groups. Generally, it is also a good idea to use this same ID when update time rolls around.
The problem is, there is no way to tell directly which account was the Setup User. Sure, you can tell what accounts are used for the services, and Default Content Access is particularly easy, just go to the Search Administration page. But although you can see the accounts in the Farm Administrators group, as noted above these can be changed, so that doesn't necessarily tell you who did the setup.
It was time for the thinking cap. Brainwaves are generated by caffeine and sugar, so I sent Steve for some coffee and donuts while I hashed things out. Since SharePoint wasn't going to help me here, I had to go outside the box. Or rather, straight to the box. I harkened back to my Windows admin days, and thought about what is actually happening when you install software. Registry changes, folders created, files copied, etc...
Chasing a Wild Goose
Half a cup of Columbian and a French cruller later, I thought had it. Files! Folders! When you install a program - especially one as big and powerful as SharePoint, you are creating files left and right. When you put a file into Windows, loads of information about it gets stored - its name, when it was created, and who has access to it. But more than that - Windows "knows" who created the folders and put the files in them.
I started looking in the same place you look for almost anything related to SharePoint configuration. An infamous little hangout called the 12 hive. So I started Exploring. I followed a sort of convoluted path - "C:\program files\common files\microsoft shared\web server extensions", but in the end, I found what I needed. And there was my witness - an unsuspecting little folder, called simply "12". Sure, she was cute, but I knew under that simple yellow exterior bubbled a mass of information.
I decided to be gentle at first. I gave the folder a little right-click and whispered "Properties" in her ear. She was compliant, and engaged in a simple dialog. I changed the subject to security:
I knew I was getting warm when she let slip that she knew the Creator/Owner. But she wouldn't tell who it was. I applied a bit of "Advanced" pressure, and finally got her to fess up. She showed me the owners, and there was... the Administrators group. A dead end. I had high hopes for this one.
You see, the creator of the file or folder automatically gets ownership-level rights. This means that they can do anything to it an administrator can. This is also one reason the Setup User in SharePoint gets so much power. Since they are the creators of the files that make up SharePoint, they can always access them, no matter what SharePoint's internal permissions say. Unfortunately, Windows Server automatically assigns Ownership to the Administrators.
The Light at the End of the Tunnel
Then I had another thought. The other thin the Setup User does is creates the Central Administration web site. Like I said before, you can't just check the Farm Administrators group. But there is another way to check for "special" users. The STSADM command has a way to list users who have been assigned direct permissions to a site collection. Central Administration needs someone to access it before all of the groups are built, so I thought, why not see if the Setup User was hiding there.
I opened up a command prompt. Central administration is configured on a random port at setup, so first thing I did was look up the port that was in use with the command:
stsadm -o getadminport
Once I had that, I used the "enumusers" operation. Since the name of the server with Central Administration on it was "canon", the command (including the port found above) was:
stsadm -o enumusers -url http://canon:8585
And there it was - a user explicitly granted permissions. It even had a reasonable id: "SPAdmin".
I gave Steve the good news - the Setup User wasn't one of the accounts on the scrap, nor was it Ben's own account. Fortunately, Ben hadn't used it for any of the services. He had used an easy-to-remember name, SPAdmin. I suggested that Steve change the password, but otherwise he shouldn't have any trouble.
Elementary? Not Really, My Dear Watson...
While the story you have just read is fictional and somewhat tongue-in-cheek, all of the technical elements are true. The Setup User is a very powerful account. It should not be assigned to any of the SharePoint services, and shouldn't be anyone's "day to day" account. And, as you have seen here, there is no way to determine with certainty what account was used to set up SharePoint after the fact.
What we did here was look for ways to infer the account name. I have tested this method on several different SharePoint installations, and it has been accurate on the systems I had available. While there may be other ways beyond the one I used, none of them (even this one) are particularly robust. For example, although it is almost never done, you can explicitly assign rights on Central Administration to other users, or remove the Setup User's default explicit permissions grant (Note, as described in the story, this is NOT in the Farm Administrators group, and does not actually remove the Setup User's power). This will change what users are returned by the enumusers operation.
The moral of the story is that you need to keep a log of the accounts you use in your SharePoint configuration.
5/1/2009
![MCj02330810000[1]](/Lists/Posts/Attachments/37/MCj023308100001_1_26D93A78.png "MCj02330810000[1]") Although I'm normally holed up in a little cabin in the wilderness of northern Indiana (well OK, Silver Lake isn't exactly the wilderness...), I do get out of the house from time to time. For those who are interested, I'll be appearing at a couple of conferences in the next few months.
You probably know by now, I'm doing a couple sessions at the SharePoint Technology Conference in Boston.
But now, I can also let you know that I'll be at the Microsoft TechED 2009 conference in Los Angeles next month. (May 11-16). Although I won't be presenting any sessions, I'll be working several shifts at the TLC (Technical Learning Center). And that's not all - Microsoft will be giving away copies of my book - Professional Microsoft Office SharePoint Designer 2007. We'll be set up for autographs, both from me, and from my co-author, Asif Rehmani.
Here are the details:
Professional Microsoft® Office SharePoint® Designer 2007 – Free Books and Signing by Authors: Woody Windischman & Asif Rehmani
Where: Microsoft TechEd 2009 – Los Angeles Convention Center, Level 1
South Hall G&H, Technical Learning Center (TLC) Yellow Area – OFC (Office & SharePoint)
Monday, May 11, 2009 - 3:30-4:30PM
Tuesday, May 12, 2009 - 1:30-2:30pm
Wednesday, May 13, 2009 - 1:30-2:30pm
Thursday, May 14, 2009 - 1:30-2:30pm
Note: One book per person
4/21/2009
A Hidden Gem - the Preview Pane View in SharePoint
Toward the end of my wiki article last week, I showed a web part added to a SharePoint wiki page. While people liked the idea of adding web parts to a wiki, what got even more reaction was the web part itself.
The web part, shown below, contains a list of the pages in my wiki. That's nothing new, but what got folks excited was the ability to roll-over the titles, and see a preview of the contents of that page. People are looking all over the place for the "Preview Pane" web part, and asking me where to find it.
Well, I have a confession to make - there is no "preview pane web part". Per se.
But wait - don't run away! I wouldn't be here very long if I went around faking up web pages to make a point. That view is very much a part of SharePoint - even WSS. I just said it wasn't a web part. And that's why people can't find it.
So how do you get a preview pane? Here's the secret - although the preview pane isn't itself a "web part", it is available as a style in almost any list view!
How to do it
The example in the other article was a wiki, but it didn't need to be. You can use a custom list as well. To show how this works, I'll start with a site's home page.
I select Edit Page from the Site Actions menu, and click Add a web part. I'm going to select the Songs list. This is just a custom list that has some content in it on my site. It could have been a wiki, Announcements, or any other list. This list just happens to have some useful content.
Notice that this is starts as simply a standard view of the list.
Now the fun begins! Select Modify Shared Web Part from the web part's menu:
In the task pane, select "Edit the current view." (Note: I also changed my toolbar type to summary, to make it smaller.)
On the Edit View page, scroll down towards the bottom, and expand the section entitled "Style". There you will see a number of display formats. One of them will be the "Preview pane":
Select it, and Click OK. Click OK in the task pane, and your view will be updated with the rollover and preview!
Other Aspects
Since this is just a view style, you can use it on almost any list or library. In addition, you don't need to create a web part first. You can just add this as a view on your list's settings page.
When you create the view, make sure you choose the "Standard" view as the base format:
Once you do that, you will see the same view settings screen described earlier.
Conclusion
SharePoint offers a lot of different ways to look at the information in your sites. One of the most interesting is the Preview Pane view. Although it doesn't show up as a web part on its own, you can use it in almost any list or library simply by modifying the view settings.
I hope this article has encouraged you to explore this, as well as some of the other view formats available to you!
4/14/2009
![MCj02337790000[1]](/Lists/Posts/Attachments/35/MCj023377900001_1_6E6743B5.png "MCj02337790000[1]") Wiki-in-the-Box - Is SharePoint Wiki Really that Bad?
Today I'm going to get off the SharePoint Designer shtick, and go back to SharePoint basics. In particular, I want to take a closer look at SharePoint's built-in wiki functionality.
SharePoint's wiki has taken a lot of grief online lately. Some people look at various dedicated wiki systems, then at SharePoint, and come to the conclusion that SharePoint's wiki just doesn't measure up to the "best of breed". There is a big difference, however, between "not the best" and "totally inadequate".
The Real Question
If you use SharePoint in your company, and are considering whether to purchase a third-party wiki replacement, the question you really need to ask isn't, "Is SharePoint's wiki the best there is?", but rather "Will SharePoint's wiki do the job I need done?"
To help you answer that question, we'll take a look at what a wiki is, what you might want it to do, and what SharePoint's Wiki offers "in the box" to answer those needs. I'll also check out what simple enhancements are available (both within SharePoint, and via add-ons) to extend that built-in functionality.
Just What is a Wiki, Anyway?
Creating pages for the web has historically been a complicated process. It required page creation and editing on a client computer (usually with a specialized tool), and then uploading the finished pages to the web site. Linking required knowing where the target pages were going be relative to the current page.
Wiki-wiki is Hawaiian for "quick". The first wiki was designed to make it quick and easy to create and edit web pages, as well as the links between them. Rather than force users to understand HTML markup, and site structure, a wiki lets them create a link, and if the target page doesn't exist, it will be created automatically when the link is clicked for the first time. Combined with in-place editing, this effectively makes a wiki a form online content management system.
As noted earlier, a user doesn't need knowledge of HTML markup to use a wiki. However, because wikis historically have used plain text boxes for entering content, over time conventions have developed for a "wiki markup" for such things as bold and italic text, intra-page section headings, etc... I'll talk about this in more detail in the next section.
Note: WikiWikiWeb, the software created by Ward Cunningham for that first wiki, used a different syntax from most modern wikis when it comes to links. WikiWikiWeb used compressed text (i.e. Leading-cap words with no spaces between) to indicate text was a link. Current wiki markup convention calls for intra-site links (also known as wiki links) to be defined with [[double square brackets]].
In addition to being quick and simple, there is another, non-technical, aspect to a wiki - something of a "wiki philosophy". This philosophy holds that a wiki should be open to modification by anyone who has something to contribute - even anonymously. Most public wikis hold to this philosophy, however it is not without its problems. For example, while the desired benefit - people with actual knowledge of a subject contributing and correcting inaccurate information - is clearly achieved, it is just as easy for others to post deliberately incorrect information, or even vandalize sites.
While such defacement is just as easily corrected, most modern wiki systems do incorporate certain safeguards - such as authentication, change logs, and approval processes - which can be implemented at need. Indeed, even WikiPedia, the most prominent wiki site on the internet, treats authenticated and anonymous contributions differently, and allows article (page) creators to prevent anonymous edits.
SharePoint Wiki - On the Surface
Now that you know basically what a wiki is, and how they were created to make it easy for non-technical users - and particularly subject matter experts (SMEs) - to create and manage web content, let's take a look at a SharePoint wiki site.
Note: SharePoint has two things called "wiki". The Wiki Library, and the Wiki Site template. A Wiki Library can be created on almost any SharePoint site, and is accessed through quick-launch just like any other SharePoint list or library. When you create a Wiki Site, a Wiki Library is created in it automatically, the site is set to use the Wiki Library's home page as its default, and a Wiki Pages section is created in the Quick Launch bar. The behavior of the Wiki Library itself is otherwise identical.
In most respects, a SharePoint Wiki is very similar to any other SharePoint site, as shown below. However, when you look a little closer, you start to see some differences:
- Wiki Toolbar - The wiki toolbar gives you direct, 1-click access to editing a page, viewing its change history, or discovering what other pages in the wiki link to it.
- Quick Launch Bar - Notice the Wiki Pages section. This is created in a Wiki Site only. Other "normal" sections (e.g. Lists, Discussions, etc...) are generated as needed if you add them to the site. On non-wiki sites to which a Wiki Library is added, this section is not created automatically.
- Recent Changes Bar - The Recent Changes bar lists the last five pages that have been updated.
Whether stand-alone, or part of a wiki site, two pages are created by default in a SharePoint wiki library - the Home page (shown above), and "How to use this Wiki" (the text varies slightly to reflect the library or site context). While wikis, by definition, are very easy to use, a quick glance through the "How to" page can still be very helpful. It provides quick tips on the two elements of a SharePoint wiki that are not "obvious", especially to new users - the [[double bracket]] wiki link syntax, and how to create new pages.
To help prevent the creation of orphan pages (those with no incoming links), users are encouraged to grow the site organically, by editing an existing page and adding wiki links. Recall that, if you create a wiki link to a page that doesn't exist, a new page will be created when that link is first clicked.
Getting Started
The first thing you will probably want to do, is edit the home page to reflect your purpose in creating the wiki site, and create some "seed" links to get your users started.
Notice how I have "set the stage" for my users. I haven't actually entered any information yet, but by creating these links and a description, I have let people know the purpose of this site. Now, anyone with write permission can click on one of the links with dashed underlines, and they will be able to create content.
Which brings us to the first area of concern in many environments - if "anyone" can go in and modify these pages, what if someone totally messes things up? This is where the page history comes into play. By clicking the History button in the wiki toolbar, I can easily see what changes have been made over time. For example, in the screenshot below, you can easily see the changes I have made to the home page from the default, with added and deleted text highlighted in different colors from that which was unchanged:
Because in most environments SharePoint is used with authentication, you will know not only what changes were made, and when, but by whom.
The Editing Experience
One of the complaints often leveled against SharePoint's wiki is its lack of support for "wiki markup" beyond intra-site page links. While this is true as far as it goes, it doesn't consider what that markup is designed to do - compensate for the plain-text editing features of most wiki systems. For example, to make italic text in many wiki systems, you enclose the text in ''double apostrophes''. Yet while there are some conventions, there is no true "wiki markup" standard.
Here is an example of the page editing experience in a SharePoint wiki:
Notice that SharePoint's wiki actually provides a full rich-text editor, with direct toolbar-based access to text formatting, external hyperlinking, etc... The results from these tools are stored as standard HTML markup. This strongly mitigates the need for specialized wiki markup beyond the already included internal linking.
Note: Out of the box, the rich-text editing experience is only provided for users of Internet Explorer. If you have many non-IE users, I strongly suggest that you download and install Telerik's RadEditor Light. This is a free tool, the use of which is fully supported by Microsoft. I have provided a detailed write-up of it in an earlier blog post. Even if you do use IE, RadEditor Lite provides many other features that are particularly useful in a wiki environment.
Digging Deeper
So, looking at the "wiki" features of SharePoint's wiki, we see a very easy to use system, which, while it may not offer everything a competitor's wiki has, isn't too bad. But the story doesn't stop there. The other side of the "SharePoint Wiki" equation is SharePoint itself. As a part of SharePoint, the wiki library comes with a number of very useful capabilities, especially around site management.
Much of the "SharePointiness" of the wiki library is suppressed from the default page views. Nevertheless, it is in there, just below the surface. The easiest way to access it is to click the "View All Pages" link in the Recent Changes bar. This brings up a standard SharePoint view of your wiki library:
From here, you have access to all sorts of abilities:
- Setting Alerts to be notified of changes
- Setting the permissions of the library, or even individual pages
- Adding metadata fields - for example, subject tags, or even links to supporting documents
- RSS feeds
- Requiring approval and document check-out for changes.
- Creating different views of the information
In addition, because wiki pages are considered individual files by SharePoint, they have individual URLs, making it easy to provide "friendly" links to users, as well as get detailed usage reports.
Because a wiki page is a "page" in SharePoint, you have a second editing option, under the Site Actions menu. This edits the SharePoint, rather than Wiki aspects of the page, and allows you to add web parts to a page in your wiki. These parts will only appear on that specific page, but can be used for virtually any purpose. For example, here I've added a web part that is a view of the wiki library which displays a page preview when you roll over a title:
Content in a SharePoint wiki is also automatically included in SharePoint searches, making it easy to find information even if you don't know exactly where in the wiki it is.
Conclusion
SharePoint's wiki features are a bit like Rodney Dangerfield - they "don't get no respect". Yet, while on their own they may not be best-of-breed in the wiki world, they are still quite useful. In addition, they do something no other wiki system does, they bring the rest of SharePoint, with all of its power and flexibility, along for the ride.
If you are considering deploying a wiki in your company, and you are already using SharePoint, look beyond what a wiki purist might see as perfection, and consider your actual needs. You will probably find that SharePoint's wiki will fulfill them.
|
|
|
|
|
|
|
|
 |
|
|
|
|