Peer into the Portal
Now that you have an idea what SharePoint Portal Server can do, here's how to implement it and get users into collaboration mode.
- By Bill Heldman
, we looked at SharePoint Portal Server. Some of the up-front
work you need to do for an SPS deployment circles around making sure that
your stakeholders are aware of what you're doing and that they've sanctioned
the deployment. Otherwise it's like throwing a party where no one shows
up (or worse, they vomit on the carpet).
Chat the idea of an enterprise intranet portal around the various shops
that might be participating. You have several methodologies you can present
to people as you're describing your portal:
- Users in various departments can create their own intranet pages
and point to them with SPS. This is called "back-hosting" and implies
that you've got a lot of little different intranets sitting around that
are bundled under one roof (see Figure 1). Advantages include the diverse
look and feel that different intranets bring to the portal (that is,
it's not all the same boring page style). Disadvantages include the
links breaking for whatever reason (Molly leaves for vacation and powers
down her computer, not realizing that her machine indirectly acts as
the intranet "server" for her department). Also, SPS has to crawl the
various intranets to index relevant documents. Additionally, users might
not fill in smart tags for documents, so indexing isn't robust.
|Figure 1. Setting up SharePoint Portal Server
as a "back-host."
- You can set up workspaces on your SPS box corresponding to each
department or work unit desiring to participate in the portal project.
Authors place their documents in the workspace and coordinators
publish them to the workspace (see Figure 2). Advantages include the
fact that users all place their content in one placeSPS has no
difficulty indexing the content (provided, of course, authors are trained
to be thorough in filling in a document's smart tags). Disadvantages
include the fact that in larger shops you're likely to run out of workspaces.
|Figure 2. Set up workspaces on SPS box based
on departments and have coordinators from each unit publish to them.
- An intranet portal team is assembled and responsible for all design
elements of the intranet portal pages. Authors from departments
submit their content which is then posted by the intranet portal team.
Advantages to this include the fact that content and look and feel can
be closely controlled. Disadvantages circle around maintaining fresh
content on the pages. Because the intranet portal team is responsible
for bugging people to submit their contentchances are it won't
be as current and fresh as it could be if department stakeholders were
to directly place their own content on the site.
I'm a big proponent of IT project management, partially because
it helps create solidly deployed, well thought out systems, but also because
it engages key stakeholders in the decision-making process. If you get
a set of stakeholders in a roompeople who have a keen interest in
an intranet portal (HR, marketing, sales, etc.)and you begin to
talk about how you'd like to formulate the portal, you'll get all kinds
of input, counsel and advice.
IT project management requires extra time because you have to make sure
that you've included all stakeholders; that you have the buy-in from executives
(called executive sponsors) who can authorize that resources be expended
in the creation of the portal and that you get authorization to "make
go." Otherwise, your project is grassroots at best and won't be as viable
and usable as it could be. Better get some conflict-management training
under your belt because you're going to be presented with some arguments:
Why Microsoft's portal? There are other portals out there! Yes, but Microsoft's
is by far the cheapest and easiest to deploy. Further, it doesn't require
a cast of thousands to maintain.
Microsoft's portal isn't as in-depth and robust as other portals. Maybe
it doesn't have all of the bells and whistles of portal products two orders
of magnitude more expensive than it is, but then, who uses all those bells
and whistles? Likely you'll find, once you understand Web parts and how
your apps teams can integrate them into SPS, you can do just about anything
with SPS that its big step-brothers can do.
Why a portal anyway? Why not just a regular Web site using IIS? Great
idea, but this method only allows you to leverage content, not knowledge.
Remember that we're after an intranet that's more like an organism than
it is a program. What I mean by that is that users need to see value-add
in going to an intranet page. For example, if a user going to your portal
(remember we called it MyCompany) can launch email, calendar and contacts
in a one-stop shopping environment plus see daily news about the
company, perhaps the company's stock ticker, and other rich information,
then you've got a product that users want to use. Top that off with a
central repository for apps that are used by the corporate population
and you've got a knowledge centernot just a Web site. A Web site
is about content, a portal is about providing a place where people can
It might be helpful to think of a Web site as a bookstore where you can
only buy books. A portal is like a bookstore that also carries music,
software and has a coffee shop.
Additionally, it's important that you plan for someone to regularly,
religiously maintain your intranet portal so that its content is always
fresh, new and vibrant. Stale (or stagnant) content, inflexibility of
the pages (i.e. user can't customize anything) and lack of apps will kill
your intranet in about a week or less. It'll die of loneliness because
users simply won't hit it. Here are some things to consider:
- Maybe you would offer a news ticker that contains the company's latest
news for the day
- Weather, comics, relevant stock tickers could be provided. It might
be a good idea to give the user the option of being able to snap in
those components she wants to have on the page.
- A method for users to connect to enterprise apps (PeopleSoft, mainframe,
CRM, etc.) Identification of these enterprise apps should occur when
you meet with stakeholders and your project team.
- Private customizable pages could also be provided. The user hits the
main intranet page and is given the ability to set up a second page
that contains relevant things specifically suited to his needs or desires.
Note that you'll probably need several weeks of operating SPS in a test
environment before you go into production in order for your applications
folks to figure out how Web parts work (there's a software development
kit available for download from the Microsoft SPS site at http://www.microsoft.com/sharepoint/portalserver.asp
that will assist them. Making sure that your key apps have been identified
and that they work in SPS will be a milestone in your deployment project.
It's important to dedicate an enterprise-class computer to your
SPS implementation. If you're going to talk the talk, you've got to walk
the walk with this kind of deployment. In other wordsthis is powerful,
resource hungry software that demands good quality computing horsepower
to run on. You can't fool it with an older workstation-class computer
because it won't care. Your users will suffer, while your SPS installation
works as fast as it can. The customer experience quotient will be next
to nil because the dang computer can't get to all the requests fast enough
to bring up pages in a timely fashion.
Recall that SPS uses an indexing mechanism that automatically indexes
all of the documents posted to its workspaces, or those documents it has
found as it crawls other sites. The indexing service itself is resource-intensive
and, when coupled with SPS and IIS, presents the requirement for a robust
computer on which to runeven in smaller environments where only
a couple hundred users might be hitting it.
So the place to begin is to procure a good quality server-class box that
has plenty of processor power and disk. Also make sure the RAM is bumped
up on the computer so it has lots of virtual memory to work with. In larger
deployments it's not out of reason to consider a second computer for indexing
the documents on the SPS server.
Next install Windows 2000 and bring it up to at least SP2. As of this
writing I've heard of people who've run into trouble with SP3, so it's
best to experiment with the service packs in a lab before implementing
in production. As you install W2K, be sure to include the installation
of IIS as this is the underlying component that SPS uses for workspaces
and is its chief operating mechanism.
Purchase client access licenses (CALs) for all users utilizing the portal.
If you're hooked up with a Microsoft Enterprise agreement, talk to your
Microsoft representative about the kind of CALs you're currently covered
Install SPS and any relevant service packs or patches (Service Pack 1
as of this writing).
Update DNS with the portal's friendly name (i.e. MyCompany).
Create your workspaces.
Train authors and coordinators.
Install client software.
Point user's default page to the portal.
Then, market, market, market. Here are some ideas that you can think
about when considering the marketing of your deployment:
Hold a contest to name the portal-winner gets a dinner for two or something
like that and you get away from the ubiquitous "MyCompany" moniker. (My
personal opinion is that some researcher in a quaint region of the galaxy
came up with the idea that people like to associate media communications
with how it impacts their personal lives. Thus today we have TV weather
people saying "here's your weather forecast", radio traffic commentators
saying "let's give you your driving expectations" and enterprise portals
called "MyThis" and "MyThat". Of course, the reality is that your weather
is also my weather, so it's just generically weather. To me, ownership
doesn't have to be predicated on the use of personal pronouns. If this
didn't bother you before, it'll probably bother you now. You're welcomeI'm
happy to share.)
Hold focus groups to find out what kind of content users think would
be useful and relevant for them.
Purchase mouse pads or other little items that remind users of your intranet.
Have a graphics person come up with a snappy logo that can be instantly
recognized as the portal's.
Develop an "e-zine" that contains small information snippets from content
on the portal. Provide a more info button that users can click to point
them to the portal for the remainder of the content. Update and send out
the e-zine on a routine basis.
But most importantmake sure that executive stakeholders have bought
into the portal as the place where people are going to place company-wide
information and/or applications. It's key that management is unilateral
in their mandate to use the portal as much as possible as the primary
information source for the company.
Once you've got your main portal up and running there are several
things to consider as you go forward into this brave new world:
Integration with big honkin' portals such as Siebel, SAP, PeopleSoft
and Oracle and Plumtree. Suppose that your little SPS portal is a little
fish in a big pond and that other corporate IT entities have deployed
a different portal product. Microsoft has actually supplied Web parts
that will integrate with other portals. Some Web parts must be purchased,
others are free for the download. See Microsoft's Web Part Gallery at
webparts/introduction.asp. Operationally you should consider that
your portal will play in the sandbox with others using Web parts.
Security will be a key issue for you. Because IIS is the underlying engine
for SPS, you'll want to pay careful attention to security bulletins that
come out. Be sure to test any IIS patches you apply in your SPS lab before
you apply in production, or you may wind up with a very broken portal.
In bigger shops you may need to consider integrating with other SPS deployments
in other areas. This can be done simply by crawling other SPS installations'
content. I'd recommend, in scenarios like this, that you have a single
portal operating as the main contact point for users, then branch out
to your other SPS installations from there, using links on the main portal
You may want to consider a linkage with Microsoft Internet Security and
Acceleration (ISA) Server hosting a VPN. With a little testing and tweaking,
you could come up with a method whereby telecommuting users could VPN
in to the private network from home, then connect to the portal.
If you've got a Microsoft Mobile Information Server (MMIS) 2003 deployment,
consider how your wireless users are going to get to your portal and what
they'll experience when they get there. Ample integration testing is in
Finally, if SPS doesn't have enough horses under the hood for you, or
if you want to explore advanced options, consider Microsoft Content Management
Server (CMS). You can download an integration pack for the two software
products on Microsoft's SPS Web site.
In The Know
Remember that your main goal with an intranet portal solution is
to provide a place where users can go for corporate knowledge. Thus, your
focus shouldn't be as drilled in on technology as much as it is on customer
experience management (CEM). In other words, you should walk a mile in
your user's shoes so that you understand what your customers would like
to see the system do. It's not out of reason to expect some requests for
instant messaging (IM) and its accoutrements (such as virtual whiteboard);
requests for mainframe access; wireless usage, etc.
I believe that portals represent systems where IT shops have a chance
to really shine in terms of service delivery. If users think your intranet
portal deployment is wonderful, fresh and user-friendly, they're likely
to think that your backoffice stuff is just as remarkable.