Cross Collaboration

Setting up a common area for sharing resources is easy. Here's how to do it with SharePoint Portal Server.

• By Bill Heldman
• December 01, 2002

Got an intranet? If so, then what is the value-add that you're giving to your users with your intranet? If it's merely content (that doesn't change very often), then we've got to talk because you could be giving so much more to users. You should be concerned about Customer Experience Management, the experience that the client has when he or she surfs to your intranet. You, my friend, need a portal.

What does a portal bring to an intranet? I like the way that some Gartner Group portal experts have put it: "A [Microsoft SharePoint Portal (SPS)] portal is a thin coat of paint that binds different intranets together under one roof." It's a single source for documents, applications, and the linking together of disparate sources of information for the one-stop-shopping enjoyment of the user. It's a knowledge center. The Gartner experts use the German word über, meaning "over" or "above" to describe the service that an SPS portal provides: It's acting as a single covering for a bunch of different information sources.

If you'd like to see some Internet-class portals that are in existence today and extremely viable (also very SPS-like), just look to my.lycos.com or my.yahoo.com. Government has also gotten involved in this portal craze—check out http://www.ca.gov/state/portal/myca_homepage.jsp for a high-quality example of where portals can take a surfer. The California site, ironically, is called "My California." Hmmm…this My Portal nomenclature seems to be catching on. (But the URL? Yikes! Surely www.mycalifornia.com isn't taken, is it?)

Let's talk about how to get from a standard corporate intranet to an enterprise-class portal using SPS and other technologies. First we must understand why portals are in place.

Document Hell
The Internet as well as corporate intranets have, as one of their primary elements, containers that house thousands of documents. When you begin to talk to business stakeholders about what they'd like to put on their corporate intranet, you'll likely have people tell you that they'd like to put the corporate rule-book (procedures and policies) and other business-oriented documents online. While this is a great thing and certainly a wonderful use for intranets, it's also a very dull thing that's privy to inattention and slippage in the freshness and currency of the information. Additionally, it's difficult for content creators to figure out how to publish stuff to an intranet. Microsoft FrontPage and tools similar to it make things easier but, for the average user, this is pretty high-tech stuff.

Portal Authors
Microsoft's SharePoint Portal Server can immediately help you out with this problem. SharePoint Portal Server uses Exchange 2000's Web folder technology to provide a place where users can place ordinary Office 2000 documents that can then be referenced and published on the portal. When users who will be publishing documents to the portal (called "authors") install the SPS client software, they'll notice the addition to their Office 2000 and Explorer toolbars. For security purposes, SPS supports three internal roles: coordinator, author and reader. Authors are those who will be placing content onto the Web folder for subsequent publishing. Coordinators publish content and manage the portal. Readers are the ordinary folks hitting the site and reading the material.

Note that the NTFS permissions for Web folders are also in effect, so you have very fine granularity in terms of security within the portal system—not only the internal SPS roles but also the security structure that SPS rides on. Also, SPS supports the ability to prohibit users from viewing or even being aware that documents are available, even though the stuff is published on the page. So, if you're a reader who does not have access to some specific documents, even though they're published on the intranet portal, you won't know they're there. The documents are made invisible to those without the rights to read them.

SPS also indexes the smart-tag information for the documents posted to it and can quickly find a document based upon keywords included in the smart tags. The flip-side: As authors publish documents to the portal, one of the additional steps they'll have to go through will be to accurately and completely fill in the smart-tag sheet, so that documents can be indexed correctly. That done, users can find a document quickly by searching for relevant key words.

Publishing Content
Once a document has been placed in a Web folder, coordinators are able to publish it to the portal. A document that has not been published isn't visible by any readers until the coordinator publishes it. The first time a document is published, SPS begins a revision history on it. At each succeeding re-publication of the document (e.g. Susie, an author, checks out a published document, works on it, then puts it back, after which the coordinator publishes it anew) the revision marker is updated. The coordinator can select how many revisions of documents are kept within a given folder, the range being from none to infinite (i.e. how much disk space do you have?)

This document revision thing reminds me of Microsoft Visual SourceSafe, a code repository program that allows developers to check their code in and out of the repository and keep a revision history. Perhaps Microsoft "borrowed" the code used in VSS to drive the SPS document check-in/check-out revision history element.

Users see only the document that is currently published—they do not see previous revisions, or documents newly posted to the portal by authors but not yet published.

So document management is at the heart of SPS. "But wait…", as the late-night cheesy commercial announce says, "…there's more!"

SPS brings to the user the "digital dashboard" concept that had been bandied about Microsoft internal-land for several years. Figure 1 shows the basic unconfigured SPS digital dashboard. You can tell that my role is coordinator by noting that the upper right-hand section of the page shows the menu items "Content", "Layout" and "Settings". Readers and Authors do not see these menu items. To adjust these I simply click one of the items and I'm taken to a new page where I can make adjustments. The Content menu allows me to add to or take away content for this particular page (see Figure 2). The Layout menu (see Figure 3) lets me change the layout of the page. The Settings menu (see Figure 4) gives me the ability to change the name of the page, apply a style sheet and add a caption and description, among other things.

Figure 1. SharePoint Portal Server uses a digital dashboard interface. (Click image to view larger version.)

 

Figure 2. You can edit content on a page just by clicking on it; doing so opens up the page in a new window. (Click image to view larger version.)

 

Figure 3. SPS Layout menu provides simple design editing capabilities. (Click image to view larger version.)

 

Figure 4. You can easily change settings, apply style sheets, and add other features to each document being published via SharePoint Portal Server. (Click image to view larger version.)

All of the Internet portals I gave you earlier use this idea (though not necessarily Microsoft's software) in their portals. The idea is that you give the reader a vast array of elements in one or two different pages, including, but not limited to:

• Framed pages that allow various elements to be placed on the page in strategic places—SPS, by default, breaks the page down into five sections—North, South, East and West (if you will), plus a middle section. You can place different elements in any of these sections through SPS' friendly drag and drop methodology.
• Tickers such as weather, stocks, news, sports, etc.—SPS comes with some built-in tickers that you can link to for MSNBC news, weather, stocks and other pertinent info. More on these "web parts" in a moment.
• Applications pertinent to the audience—In a corporate intranet portal you might supply a link to a web-based time-entry program, for example, or to a mainframe session. You and your staff are responsible for creating the applications and linkages that SPS can use on the dashboard.
• E-mail—If your users have Office 2000 (including Outlook 2000), they will be able to get their e-mail from the digital dashboard on your SPS intranet portal. They will also be able to pull up their calendar and contacts. This might be extremely useful to you, especially in shops where you're trying to come up with a one-stop-shopping environment for your users. (e.g. You've got a group of salespeople who don't really need a computer for much else than sending out a few e-mails in the morning, and a quick run through a client contact program such as SalesLogix.)
• Other company intranets—Remember that your goal is to build an uber portal in which you provide a singular starting point for the company. If Monica in Marketing, for example, has a little FrontPage web that she's whipped up you could easily link to it from your intranet (probably called "MyCompany") and readers could quickly see what Marketing was up to. All Monica has to do is update her content to keep her end of the site fresh.
• Extranets—SPS has the ability to play with Microsoft Internet Security and Acceleration Server to provide an extranet solution for your B2B or G2B partners.
• Categories—Grouping of content information into logical sections.
• Subscriptions—Readers can have the system email them when a document they're interested in changes.
• Indexing/crawling—SPS not only indexes its own content, it can be set to "crawl" and index other sites. For example, suppose your company is into electronics manufacturing. You could have SPS crawl a vendor's Web site so that when a reader is on the intranet and is looking for some specific info, some links to your vendor's site will come up.
• Message approval and routing—SPS has the ability to forward a document to an approver or group of approvers for acceptance and further forwarding. Approvers are presented with an e-mail that tells them there is a document for them to read and approve or disapprove plus a URL pointing them to the document. When working with groups of approvers, you can set it up so that only one approver needs to approve or reject the document, or all approvers in the group must approve in order for the document to proceed on. This technology can be extremely useful for things like routing of vacation requests, time cards, and other approval-oriented materials.

Workspaces
Additionally, SPS utilizes different areas, called "workspaces" that you can set up for different portal usages within your company. Suppose you have a need for four or five portals, each of which is dedicated to a different arm of your company? You might require a portal for manufacturing, one for sales, one for marketing, one for HR and one for admin, and so on. You could set up five workspaces, assign the coordinator role to the designated administrative entity for each area and then let each coordinator manage his or her workspace. Each workspace must be accessed by including the root name plus the workspace name.

Let's say you created a new workspace called Sales. For readers to access the Sales portal on MyCompany, they'd bring up their browser and key in the address: MyCompany/Sales. This would take them to the Sales workspace. You can have around 20 workspaces per SPS server. However, if you're also letting the server do the indexing (you can offload the indexing to a separate box), you should consider the processing you're doing on the system. It could impede performance significantly with a lot of users hitting various workspaces, plus the overhead of the indexing.

Clustering
SPS doesn't support clustering, so you'll have to buy separate computers for the various portal implementations that you want to bring up, especially if you've maxed out the number of workspaces you're running on one machine or look into upgrading to SPS' big brother, Microsoft Content Management Server. You could conceivably have a farm of SPS boxes that crawl one another's content and link to one another, utilizing a separately dedicated indexing server. This would create a seamless environment for readers and allow you to scale the farm.

Figure 5. In an extranet environment, SPS2 could crawl certain SPS1 folders for representation to Internet clients. SPS3 and SPS1 are both indexed by a stand-alone indexing server and available to intranet clients.

Web Parts
A Web part is a Web component, whether actually built for the Web or a "Webified" application that can be run by SPS. Called "widgets" in other portal implementations, all a Web part really consists of is some sort of program, applet, Web page or other coded activity that can be pulled up and run by a Web browser.

Let's suppose that your applications department wrote a javascript applet that runs a motor fleet application, where the transportation department can keep track of the cars and trucks that are due for service. As long as an ordinary browser can pull up the program and run it, SPS can host it. You could offer this link to your transportation users who could, in turn, run it from a desktop or laptop or even a PDA that was able to wirelessly connect to the intranet.

Microsoft Mobile Information Server
Which brings up the next idea—getting portal content to your wireless users. One of the problems with content that users download to a cell phone or PDA is that the browser can only display so much text at a time. If the content hasn't been specifically designed for small device users, your users will have to navigate your information using lots of vertical and horizontal scroll bars—the reading can get tedious in such a small space. This, in times past, meant that your Web programmers had to develop two sets of pages, one set sized to fit ordinary browsers and another to fit the pee-wee devices.

Microsoft Mobile Information Server 2003 fixes that problem by autosizing the screen for PDA users. Very cool, except that Exchange 2000 and a Windows 2000 forest are required. If you're not well along in your Win2K deployment plans, you'd better get moving or get those pages right-sized for the PDAs. In spite of all the obstacles, it is well worth a company's time to investigate wireless technology coupled with PDAs for empowering employees who need to be places to get things done and who would benefit from connecting to the corporate network to run apps, check email or schedules and things like that. In all of these aspects, SPS can assist you with your goals.

Share and Share Alike
Installing and using SPS is very easy. The software's job is so big that you need to install it on a robustly outfitted high-end server. This isn't the stuff of workstation-class computers acting as servers. You should give the machine plenty of RAM and processing horsepower. Additionally, if you have robust intranet plans, I'd seriously consider up-front the acquisition of a second computer strictly for indexing of the SPS materials.

SPS requires IIS, so you're going to have to continue fighting the good security fight. IIS is a huge target for hackers because it and Apache have the most market share, so naturally it's going to be far more privy to penetrations (with Microsoft subsequently releasing security patches) than other products.

Some of the big-league portal products are very expensive to own and operate. Products such as PeopleSoft, SAP, Siebel and others require big operational departments in terms of people—and computer power. Which, in the strictest sense of the portal world, may be fine if you already have those implementations in house and a CIO or CEO is willing to dedicate the resources to get things going. But if you're considering some sort of intranet/portal venture in which the stakes are small, the results large and the outcome is rapid in its fruition, then I'd stake my claim on SPS.