Early versions of Microsoft's Site Server suite of Web creation and management tools were not much more than collections of software that Microsoft couldn't use elsewhere, so the company lumped everything into one package. However, Site Server 3.0 introduces a whole new ball game. Microsoft has refined parts of previous Site Server incarnations, but most of the latest software suite consists of new and useful applications. (For an overview of Site Server 2.0, see Paula Sharick, "Site Server 2.0," June 1998.)
Site Server 3.0 is a massive add-on to Internet Information Server (IIS) 4.0. By itself, IIS is a great Web server, and Site Server lets you add flexible and powerful applications to the core strengths of Windows NT and IIS 4.0. Site Server 3.0 includes several new features such as the Microsoft Site Server 3.0 Publishing Solution, the Microsoft Site Server 3.0 Knowledge Management Solution, and the Microsoft Site Server 3.0 Analysis Solution.
The Publishing Solution and Knowledge Management Solution are the most exciting new features. Microsoft has updated the Analysis Solution, which lets you create reports on Site Server 3.0 and Site Server 3.0 Commerce Edition applications (e.g., Ad Server and Membership Directory). The Analysis Solution is basically the same tool that Paula Sharick covered in the June 1998 issue, so I'll cover the Publishing Solution this month and the Knowledge Management Solution next month.
Publishing Web Content 101
The Publishing Solution is a multistep process that helps users submit, gain approval for, and deploy content on a company's intranet. Although some companies will use this application as a complete solution for managing all their intranet content, others will just want to plug some of the software's functionality in to their existing mechanisms.
Three groups within an organization play a part in the Web content publishing process: content authors, site editors, and site administrators. The content author submits the content to the site, the site editor determines whether the content is appropriate for posting, and the site administrator creates the functionality and the rules for posting the content.
The content author can either drag the content in its original form onto an ActiveX submission icon on the Content Management page, as Screen 1, page 188, shows, or double-click the icon and browse directories to locate the file for upload. After submitting the document, the content author must apply several site-specific tags to the document. The first tag is the content type (e.g., job postings or announcements), which lets you categorize and tag documents different people submit to the site. The other tags let you apply content attributes. The content author assigns a title, abstract, author, and editor if necessary. Site Server uses these attributes to manage and index the content. Based on the rules that the site administrator sets for different topics, the Publishing Solution might automatically publish some content on the site and prevent other content from going online until the site editor reviews the material. However, this review process, or Editorial View, is limited. The site editor can only approve the content, delete it, or edit the content properties, as Screen 2 shows; the site editor can't change the content. These same limitations apply to the content authors after they submit their content for review. As a result, the site editor can accept the content as is, recategorize and publish the content on the site, or delete the content and force the content author to start over.
Putting the Publishing Solution to Work
Now that you have a sense of how the Publishing Solution works, let's look at an example. Imagine that I want to use the Publishing Solution to manage the posting of the Windows NT Magazine UPDATE online newsletter internally. I can either edit the sample content file that comes with Site Server or create a new one. I decided to create a new file, which wasn't too difficult. I used the makecm.vbs script file that comes with Site Server to create my content project (i.e., the directories where you store the content).
The makecm.vbs file is in the \microsoft site server\ siteserver\publishing directory. To create the UPDATENews project, I opened the command prompt, changed into the directory where the makecm.vbs file resides, and typed
cscript makecm.vbs /s:ntwebtest /v:updatenews /a:updatenews /d:"c:microsoft site server\data\publishing\updatenews"
This command runs makecm.vbs, creates an UPDATENews application (/a) in a virtual UPDATENews directory (/v) on the ntwebtest server (/s), and places the UPDATENews application (i.e., the UPDATENews project) in the \microsoft site server\data\publishing\updatenews directory. After I created the new project, I used Site Server's WebAdmin browser-based administration tool to configure the properties for this new content area. These properties include setting the content types that content authors can apply to the content submissions and specifying whether the site editor needs to approve certain types of submissions before the content can go live. After I configured the properties for the new content area, I used an HTML editing tool to edit existing, and create new, content pages. Because the pages you're working with can contain so many page includes (i.e., pointers to other content areas), you'll probably find yourself repeating many of these steps.
After I finished creating my project from scratch, I tried editing one of the sample projects that comes with Site Server. In many ways, this approach is easier than starting a new project from scratch: At least you're not left hanging with missing files or code. If you're a Visual Basic Script (VBScript) or Active Server Pages (ASP) junkie, you'll have a blast with this method.
I thought I might be able to use the Publishing Solution in an Internet environment, but I changed my mind after trying it. By comparing the needs of my company's intranet with those of its Internet sites, I realized that the Publishing Solution is best for internal use when you're working with Word documents, Excel spreadsheets, or other self-contained formats where graphics and charts are part of the content. In this situation, the Publishing Solution is quick and simple to use. For example, I recently reviewed an article that referenced numerous separate screen captures. To make life easier, I dragged the screenshots into the Word document and saved them as one file. Then I made the article available on the intranet by going into the Content Management page, dragging the document onto the submission icon, and setting a few values to make the Word file available for everyone in the company. When I tried using the same process to publish an HTML file that contained eight graphics files, I needed to set individual values and associations for the HTML file and each graphics file.
As with any Web-based management tool, the Publishing Solution lets you submit, manage, and delete content from any computer with a browser. And because Microsoft built the software on NT, its security is as good as your knowledge of NTFS file and directory permission settings. By adjusting the permissions on the sample sites, you gain a sense for how you can lock down certain functions or areas of your intranet on the Content Management page.
Replication
After you submit the content you want to publish, you start to see where Site Server 3.0 really shines--in its deployment mechanism. Last year, I showed how you can easily mirror two Web machines at the directory level, using NT's replication (see "Convoy Cluster Software and NT's Directory Replication," August 1997). Now, with Site Server 3.0, you can take replication a step further.
Creating the right environment for replication is important because you never want to use your live server to update your Web pages or test changes. At a minimum, you need a staging machine. In an ideal Web environment, you have a development machine, a staging machine, and at least two live servers that you can use for load balancing and failover. Although you can use virtual servers to host the development content and the staging content on the same system (i.e., one directory structure holds the development content and another holds the staging content), separating the development and the staging content onto two machines is better in terms of resource sharing and fault tolerance. However, this latter arrangement can be a content-management nightmare when you need to move newer versions of content to the production machines. In this situation, Site Server 3.0's Content Deployment feature (Content Replication System in Site Server 2.0) comes in handy.
You have your choice of three interfaces to manage the Content Deployment feature: the Site Server Microsoft Management Console (MMC) plugin, a Web browser, or the command line. Although the Web interface lets you easily manage the process from any browser (or in my case, from any domain), the MMC, which Screen 3 shows, is the easiest interface to use. And unlike trying to manage different Web servers on different domains, managing publishing projects using the MMC is easy. To access the Site Server MMC plugin, go to the NT Start button and select Programs, Microsoft Site Server, Administration, Site Server Service Admin (MMC). After you open the MMC, you see the Site Server administration tools. You can now create, edit, and delete your Content Deployment projects. You can use these tools to start, stop, and roll back replications, and schedule a project to replicate content at a particular time.
To test Site Server's replication, I created a new ToProduction project using the MMC on a staging machine and two production machines. Next, I input the path of the staging machine's project directory that contains all the content I wanted to replicate and the names of the destination servers (i.e., the production machines) that will receive the content. If you're replicating content to just one machine, you simply input the path of the destination folder. I then selected the Security tab and entered a project-level authentication account. The staging and destination servers I used are on separate domains, so I had to enter a username and password with the proper permissions on each server taking part in this replication.
Next, I created a project with the same name, ToProduction, on each production machine, and entered the destination folder. To finish setting up replication, I entered the Projects area in the MMC, highlighted the ToProduction project, and clicked Start Deployment.
I've just described Site Server 3.0's straightforward approach to setting up content replication, but you can go beyond the basics. For example, you can schedule the replication to occur based on a time limit or on content changes. You can also add a filter to include or exclude certain directories and files from the replication. This ability to control what you replicate is useful when you want to replicate only a portion of your project content but don't want to create a new project. You can use the built-in email notification function to inform you whether the project successfully deployed, failed, or both. This notification is handy when you set projects to run during slow hours. If you have a telephone or pager that accepts email, you can set Site Server to notify you if a particularly important replication deployment fails.
To take content replication a step further, Site Server 3.0 lets you perform Metabase deployments. The Metabase is a file that contains all the information about an IIS server. This file includes information about your files, virtual directories, and the IIS server settings. By replicating this information, you can clone your Web servers. More specifically, you can duplicate all your permissions, virtual directories, and directory configurations to a separate server. In my previous example, I deployed the content to both production servers and then deployed the Metabase to these same servers to make both servers identical.
Site Server 3.0's Content Deployment feature is a great tool for creating a new Web environment and maintaining that environment. Now you can set up that multiple Web server environment in NT that'll let you have a staging machine and production machines. First, you replicate the content and Metabase of your live Web server to a separate staging machine. Then you make changes to the staging machine and use the Content Replication feature to move your files, directories, and IIS configuration changes back to your live Web server. To move your project manually, you'd have to replicate the content, add the virtual directories, confirm that all the files have the same permissions (such as having the files run as a script), and ensure that the directories contain the correct default documents.
Rollback
One final replication feature in Site Server 3.0 that can save a lot of time lets you roll back a deployment. Imagine you accidentally deployed a file that you were working on, and the new file overwrote a working copy of the same file on the live server. To fix the problem, you just go to that project on the live server and click Rollback. Site Server will roll back the entire project, and the previous version of the document will come back online.
You can set how many rollbacks you'll allow on each machine, but you can't set the number of rollbacks on a per-project basis. So if you set your site to allow four rollbacks, and you perform one rollback on four different projects, the server won't let you roll back any other projects. Finally, you can't roll back Metabase replications, so make sure you have your configurations set correctly before you deploy a Metabase replication.
Installation Issues
Although Site Server is a time saver, it's not perfect. I ran into a few problems when I installed the software for the first time. After I tried the installation a few times, I identified three problems.
First, the installation says you must have Internet Explorer (IE) 4.01 installed on your system. What the installation doesn't tell you is that you must also install Microsoft Outlook Express during your IE installation. Site Server needs to be able to find a Windows Messaging API (MAPI) associated with Outlook Express to send email from the Site Server applications.
The second problem I encountered was a mistake I made after correcting the first problem. After I discovered I didn't have everything I needed installed with IE, I reinstalled the Web browser. In small print, one of the Site Server manuals tells you that you can't remove and reinstall IE 4.01 after you install IIS. IIS won't function properly. To solve the problem, you have to remove and reinstall both IIS and IE 4.01 for everything to work. Keep my experience in mind when you install Site Server on your live server. If you don't have your IE and IIS installations in order, you have to start over.
Having botched my IIS installation, I wanted to find a way to preserve my current IIS configuration so that I could restore my IIS settings after I performed the reinstall. One way is to use the metabackup.vbs script in the Microsoft Windows NT Server 4.0 Resource Kit. You type
cscript metabackup
to create a samplebackup file. Then you run the restore script
cscript metabackrest.vbs
after your reinstall IIS, and you're back in business.
The third problem was something I just missed, but it was easy to fix. If you plan to use SQL Server 6.5 as your database, you must install SQL Server Service Pack 4 (SP4). But the part that's easy to miss is that in addition to running SQL Server SP4, you need to copy the updated version of sqlserver.exe from the Site Server 3.0 CD-ROM to your system.
One final installation consideration has to do with how you set up your destination machines when you deploy your Web content. Because you can use any number of configurations, you'll want to read up on the related licensing issues. One copy of Site Server 3.0 lets you install two copies of the Content Deployment feature: one copy on the staging system and one copy on the development system. This flexibility is good because you need to install the Content Deployment portion of Site Server 3.0 on each machine that is part of your deployment environment. Also, keep in mind that Site Server 3.0's Content Deployment installation is more than 70MB, of which 40MB is documentation.
From Publishing to Indexing
I think Site Server 3.0 has come a long way toward becoming a standalone product. It now contains features I want and will soon need to use on my Web site. Of the tools I've mentioned, the Content Deployment feature has the most potential for simplifying content management. Its implementation in a multiserver environment makes deploying and updating content easy and consistent, and it provides you with the ability to roll back a deployment if something goes wrong. Deploying multiple Web servers manually, especially the rollback, takes too much time and opens you up to more problems. Next month, I'll show you how the Site Server 3.0 Knowledge Management Solution can help you index different types of content and serve up that information to your end users easily and efficiently.
