Windows Foundation
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
- 12/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.