Hi all! While I've already done my retrospective of the year 2008 in SharePoint, a lot of you have only recently started reading my blog. Because of paging, RSS limits, or other reasons, you may have missed some of the articles I've posted since re-launching. The following list isn't everything (I'm leaving out the shameless plugs for my book and the Best Practices Conference, and my walking tour of Barcelona, for example), but it does include the the ones I feel are key in helping you to understand SharePoint.
Just click on the title above each description to be taken to that article (All of these links go straight to my new site, so you dont' need ot worry about site hopping!):
SharePoint is big. Really big. So big, in fact, that it is very hard, some might say impossible, for any one person to fully comprehend. Now, I wouldn't go quite that far, but I will say that many people approach SharePoint in much the same way as the blind men approached the elephant.
If you have been using MOSS Search or Search Server, you have probably noticed that the Advanced Search page gives you lots of options to restrict results. From different word filters, to particular languages, to document types – even specific document properties. You may have wondered how (or even if) you could cut back the list of word filters. For example, you might only want your users to search for exact phrases. Or maybe you want the language list or document types to reflect the languages and documents actually in use by your enterprise, without reinventing the whole form.
This is the conclusion of a two-part article about customizing the SharePoint (MOSS), and Search Server, Advanced Search Web Part. In Part 1, you learned about the basic settings of the Web Part – which search options are shown, and how they are labeled. In Part 2, I'll show you how to change which language and document type filters are available to your users.
When I was speaking at the Wisconsin SharePoint Users Group, someone asked me: "How do you know when to choose SharePoint Designer or Visual Studio for a particular change to a site?" I explained that I had a sort of "Hippocratic Oath" for SharePoint customization.
When you are planning and configuring a SharePoint Server farm, you often take certain things for granted, or at least, have certain things pre-ordained. For example, most companies have standards in place for things like machine names and service accounts, and especially for the domain the servers live in. You follow your standards, configure your SharePoint portal with a site URL that users will know it by, and go on your way.
What happens when something really foundational changes? How will you adapt your SharePoint environment to the new situation? How can you adapt it to the new situation?
Last month, I talked about my SharePoint Hippocratic Oath, and using the right tool for the level of customization you are looking for. One of my key suggestions was using CSS (e.g. a SharePoint Theme) for the bulk of the work, and only moving into your Master Pages (or beyond) for those things that can't be accomplished via styling. In this posting, I will compare the what you can do with a SharePoint Theme and some minor Master Page tweaks (essentially "Redecorate and Remodel"), to what has been done with a completely green-field design (the "Tear-Down" approach).
If you have a web site, you need usage reports. You need to know how often people are visiting, what they're looking at, and where they're coming from. While this information is a kind of buried treasure in and of itself, I'll also show you how to get to some "bonus" usage reports in Microsoft Search Server.
Today's subject is something of a "back to basics" article. I talk about some very fundamental SharePoint concepts, but I'm adding a little bit of a twist. Lists and libraries, Views, and Web Parts are interrelated components. Sometimes it is hard to tell where one of them stops, and the next one begins. In this article, I'll try to make those boundaries a little easier to find.
Every service which runs on a Windows server requires an account. While there are built-in accounts designed to facilitate these services ("Local Service" and "Network Service"), many times you will find it is better to use a domain user account when setting up services. This is especially true with Microsoft SharePoint products and technologies.
Over the last few weeks, I have veered a bit "off topic". But now that TechEd is over, it is about time to bring things back on track. So today, I'm getting back down to the business of helping you to understand SharePoint with another "Back to Basics" article on the subject of Lists and Libraries.
In this article, I introduce you to some columns that SharePoint creates and manages automatically, and describe some of the ways these can be useful. In the process, you will see how to create a custom list or library view.
Today I'm going to walk you through setting up a Federated Location in Search Server and post-Infrastructure Update SharePoint. (Twitter fans, pay attention, as that's the service I'm using in these examples…) While that certainly qualifies as "Back to Basics", that's just "Part 1". I'm not stopping there. The second part of this article will to show you how to take it to the next level by using SharePoint Designer's XSLT Data View editing capability. I'm even making the Location definition files available for you to download and use in your own sites!
Welcome back! This post will be the conclusion of my Search Federation article. In Part 1, I talked about Federation in Microsoft Office SharePoint Server (MOSS) and Microsoft Search Server (MSS/X), and showed you how to create a basic Federated Location to query an external resource – in this case, Twitter.
While that Location definition is functional, it doesn't really bring the "feeling" of Twitter into your SharePoint search. Sometimes, that may be exactly what you need. However, today, I'm going show you how to take it to the next level by using SharePoint Designer.
"It's not just for Firefox anymore"
Today I'm going to talk about one of the earliest enhancements that was available for the current release of SharePoint. It has been around for so long, that it has either fallen off folks' radar, or has never made it onto the screen for newer users. That's a little sad, because it has always been a very useful component, and in its latest release is even more so. What is this magic add-on? The Telerik RadEditor Lite.
———————-
And that should bring you pretty much up to date! Everything else should be either still in the RSS feed, or within the first two pages of history (as of January 10, 2009).