Windows Foundation

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
• 01/01/2003

Last month, 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:

1. 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."

2. 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 place—SPS 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.

3. 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 content—chances 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.

Project Team
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 room—people 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 center—not just a Web site. A Web site is about content, a portal is about providing a place where people can work.

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.

Server Installation
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 words—this 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 run—even 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 for.

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 welcome—I'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 important—make 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.

Post-Setup Shots
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 http://www.microsoft.com/sharepoint/downloads/
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 page.

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 order here.

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.