Deploying and Maintaining
the Workgroup Web
 |
White Paper
Table of Contents............................................................................................................ 1
Introduction.................................................................................................................... 1
Planning a Workgroup Web.............................................................................................. 1
Designing a Workgroup Web Structure........................................................................... 2
Centrally Administered Workgroup Webs.................................................................... 3
Workgroup-Administered Workgroup Web.................................................................. 4
Jointly Managed Workgroup Web................................................................................. 5
Configuring Discussions and Subscriptions..................................................................... 6
Web Components........................................................................................................... 7
Security Settings............................................................................................................. 8
Version Control.......................................................................................................... 10
Deploying a Workgroup Web......................................................................................... 12
Managing a Workgroup Web.......................................................................................... 13
Management Tools.................................................................................................... 13
Managing Performance.............................................................................................. 16
Training Strategy........................................................................................................... 16
Conclusion..................................................................................................................... 17
More Information.......................................................................................................... 18
Appendix A: Hardware and Software Requirements...................................................... 19
Appendix B: Office Server Extensions Installation......................................................... 21
Appendix C: Definition of Key Terms............................................................................. 23
Appendix D: Frequently Asked Questions...................................................................... 24
Deploying and Maintaining
the Workgroup Web
White Paper
Published: February 1999
For the latest information, please see http://www.microsoft.com/office/
As corporate intranet usage increases, intranets are changing from repositories of non-critical, static information to places where businesses publish information that is both critical and dynamic. Microsoftâ Office 2000 builds upon this trend to turn the intranet into a collaborative workspace. Teams can publish and find documents, take part in document-related discussions, and analyze corporate data via a Web browser and the familiar Office environment. We call this concept the workgroup web. The workgroup web is a place on an intranet where teams can easily and interactively share ideas and synthesize team knowledge, leading to better decision-making and results.
This paper explores how to plan, configure, deploy and maintain workgroup webs. It will show how you can easily build this collaborative environment upon an existing intranet and create an environment that is both flexible enough to meet workgroup needs and stable enough for IT to manage.
Workgroup webs are built on Microsoft Office 2000 technologies, including the Microsoft FrontPageâ Web site creation and management tool , Office 2000 Server Extensions, Office Publishing, and Office Web Components. This paper assumes a general understanding of those technologies. For references to more information about Office and related products see the “More Information” section at the end of this document.
For an overview of workgroup web hardware and software requirements, see Appendix A. For Office Server Extensions installation procedures, see Appendix B. For definitions of key terms, see Appendix C. For answers to frequently asked questions, see Appendix D.
Use the planning stage to define the workgroup web’s key requirements. Here are some of the important issues to consider:
· Workgroup structure. Before you can design an effective web, you need to make sure you understand the workgroup or workgroups the web will support. A workgroup can be defined as a team of people who work together on projects and tend to share and discuss documents. Once you know how a workgroup will be organized, a web can be structured to support it.
· Workgroup web structure. A good web structure accommodates the need both for administrative control and for workgroup flexibility. Three types of web structures can be deployed: centralized, decentralized, and jointly managed. Each of these structures delivers a different level of central control and workgroup autonomy in managing content, structure, and security.
· Discussion, subscriptions and web components. Web structure affects access to web discussion functionality, so in the process of choosing a web structure, you should determine who needs to have access to which discussions. In addition, you may want to enable subscriptions and provide access to web components.
· Security. Security should provide users with access to information while still maintaining the necessary restrictions. Office Server Extensions security is based on Windows NTâ security mechanisms and provides users with access rights via roles such as Author, Administrator, Collaborator and Browser.
· Deployment. How you deploy a workgroup web depends on its security settings and on whether you’ve chosen a centralized, decentralized or jointly managed web structure.
· Management. Once the workgroup web is deployed, you need a strategy for keeping it up and running—a way to maintain features, flexibility, and performance. Again, this strategy is dependent on web security settings and on its structure.
· Training. Users may need training to publish and edit documents on a web site, participate in discussions, receive notifications, and use web components. Since this functionality is built into the familiar Office environment, training costs are much lower than if a new, unfamiliar system were put in place.
Within a Web site with Office Server Extensions (OSE), the basic unit of management is a web. A web is like a directory, and can be arbitrarily located within a URL hierarchy. There is always a root-level web within which other webs can be nested. A web nested within another web is called a sub-web. Sub-webs can nest within other sub-webs, any number of levels deep. Like directories, webs and sub-webs contain documents and subdirectories. A workgroup web is simply a web or sub-web designed for use by a workgroup.
Workgroup web administration can be set up to be either centralized, decentralized, or jointly managed. Each option is described in detail in this section.
A centrally administered web structure gives central administrators the most control and workgroups the least flexibility. In this scenario, administrators create a large internal site that encompasses a complete web structure. The Web site structure may consist of multiple webs and sub-webs. Each sub-web may be assigned to a workgroup and may have a separate set of permissions for browsing, editing, and discussions. Discussions are housed at the root-web level, and anyone given at least Collaborator access to the root web can participate in them. The central administrator manages access throughout the web, and therefore only the central administrator, not the workgroup members, will be able to administer each workgroup web or sub-web. Workgroup members will only have Author, Browser or Collaborator permissions, so they will only be able to publish, add, delete, view, discuss, or subscribe to information on workgroup webs the administrator has given them access to.
The following table shows an example of a centralized web structure:
|
Web Structure (URLs) |
Contents includes: |
|
Root web:
|
C:\InetPub\wwwroot Autonavigation Page OSE Admin Pages OSE Start Page |
|
Marketing web: http://Adventureworks/MTKG |
C:\InetPub\wwwroot\MKTG |
|
Teenage promotions project: http://Adventureworks/MTKG/ Teenageproj |
C:\InetPub\wwwroot\MKTG\Teenageproj |
|
Tent project: http://Adventureworks/MKTG/Tents |
C:\InetPub\wwwroot\MKTG\Tent |
Table 1. Typical configuration of a centralized workgroup web
Common characteristics of a centralized workgroup web site include:
· One or more Web servers per company or division.
· Root web maintained by a central administrator.
· Discussions are on the root web, so they can be shared by anyone who has at least Collaborator permission on the root web.
· One sub-web per workgroup or team.
· Sub-web content managed by a central administration team.
In the sample web structure shown in Table 1 above, the Marketing web is a sub-web of the root web, with departmental and project information stored in sub-webs and nested sub-webs. This intranet could also house other departmental sites, such as Human Resources or Finance. In the scenario above, a variety of Web site permissions are used. Everyone in the organization has permission to view and discuss all the content, but only team members can publish to their webs, as shown in the following table:
|
Intranet information |
Who can collaborate |
Who can author |
Who can browse |
|
Adventure works root web |
Everyone in the company can take part in discussions |
Only server administrators |
Everyone |
|
Marketing web |
N/A* |
Only Marketing Team |
Everyone (can be restricted) |
|
Teenage Project web |
Only those on teenage project |
Everyone (can be restricted) |
|
|
Tents web |
Only those on Tents Projects |
Everyone (can be restricted) |
Table 2. Typical access rights of a centrally administered intranet with workgroup webs
When a workgroup administers its own web, the workgroup has maximum control, and central IT administrators have minimum control. In this scenario, a workgroup creates its own small internal site and has complete control over it. One user in the group may set up the workgroup web, with one or several users managing the site via FrontPage. This site will probably provide services to one or a few workgroups. Central administrators can have Administrator permission for these workgroup webs using Windows NT domain rights.
The following table shows an example of a decentralized, workgroup-administered web structure:
|
Web Structure (URLs) |
Content includes: |
|
Root Web: |
C:\InetPub\wwwroot Autonavigation Page OSE Admin Pages OSE Start Page Departmental content |
|
Teenage Promotions Project: http://MKTG/Teenageproj |
C:\InetPub\wwwroot\Teenageproj\ |
|
Tents Project: http://MKTG/Tents |
C:\InetPub\wwwroot\MKTG\Tents\Default.htm |
Table 3. Typical configuration of a decentralized Workgroup web
Common characteristics of a decentralized workgroup web include:
· One workgroup web per workgroup or department.
· The root web and content managed by workgroup members for whom web management is only a small part of their job.
· Discussions are stored on the root web, so they can be shared by anyone who has Collaborator permission on the root web, usually members of a department only.
· One sub-web per department or project. For example, the Teenage Promotions project and Tents project each has its own sub-web nested in the department web.
In the sample web structure shown in Table 2 above, the contents of each web are stored on the same machine as the root web, in sub-webs and nested sub-webs, just below the root web’s folder. In this scenario, a variety of permissions are used to provide workgroup members the ability to administer, author, collaborate, or browse information—as shown in the following table:
|
Intranet information |
Who can collaborate |
Who can author |
Who can browse |
|
Marketing web site |
Everyone on the Marketing Team |
Only Marketing Team |
Everyone (can be restricted) |
|
Teenage Project Web Site |
N/A* |
Only those on teenage project |
Everyone (can be restricted) |
|
Tents Web Site |
N/A* |
Only those on Tents Projects |
Everyone(can be restricted) |
Table 4. Typical access rights of a workgroup-administered intranet with workgroup webs
A jointly managed workgroup web provides a central administrator with some control and a workgroup with some autonomy over its workgroup web. In this environment, a central administrator sets up a large internal web site much like the centrally administered web site in Table 1 above. This site encompasses the complete web site structure, but gives at least one member or each workgroup Administrator privileges to set up and manage a workgroup web. This type of structure provides workgroup control of content and access rights, but preserves the central administrator’s control over server configuration.
Common characteristics of a jointly managed workgroup web include:
· One or more Web servers per company or division.
· Root web maintained a central administrator.
· Discussions are stored on the root web, so they can be shared by anyone who has at least Collaborator permission on the root web.
· One sub-web per workgroup or team.
· Content managed by workgroup members for whom web management is only a small part of their job.
The following table shows the permissions structure for a jointly managed web:
|
Intranet information |
Who can collaborate |
Who can administer |
Who can author |
Who can browse |
|
Adventure works root web |
Can take part in discussions |
|
No one |
Everyone |
|
Marketing web site |
N/A* |
Members of the Marketing team |
Only Marketing Team |
Everyone |
|
Teenage Project Web Site |
N/A* |
Members of the Teenage Project team |
Only those on Teenage Project |
Everyone |
|
Tents Web Site |
N/A* |
Members of the Tent project team |
Only those on Tents Projects |
Everyone |
Table 5. Typical access rights of a jointly managed intranet with workgroup webs
In any of the administration scenarios described in this section—centralized, decentralized, and jointly managed—administrators may want to set up multiple Web sites with Windows NT Server’s Internet Information Server (IIS) technologies or root webs per physical server in order to decrease the proliferation or dispersion of CPUs. This technique is particularly useful in the centralized control or jointly managed scenarios, where administration is already centrally controlled. For information on how to set up multiple IIS web sites on one machine, see the IIS documentation.
Once you have created an overall Web site structure, you are ready to make decisions regarding the discussions and subscriptions features of OSE. Discussions and subscriptions allow teams to collaborate more effectively. Issues to consider include: access to discussions, storage of discussions, and other discussion and subscription options
Discussions are separate from document and stored in a separate database. This architecture allows users to conduct discussions on content that may not reside on an Office Server Extensions (OSE) server. You can discuss content stored on any web or file server. Also, discussion database security is set separately from file permissions. Users can be given rights to browse a Web site and participate in discussions without being given additional rights on the server. Likewise, separately stored discussions allow users who do not have write permission for a given document to browse the document and participate in a discussion, because the document is never altered.
An organization can decide to have one central discussion server so that everyone in the organization can participate in discussions together. This structure allows users to participate in discussions without much administrative work. Discussion servers are set up and secured on an IIS-web-site level, so if you want to limit who can participate in specific discussions, you need discussion databases set up on different IIS Web sites. You can set up more than one IIS web site on a server. For information on how to set up multiple IIS web sites on one machine, see the IIS documentation.
You can store discussions in the Microsoft Data Engine (MSDE), a SQL ServerÔ compatible data engine, or in a SQL Server 6.5 or later database. The benefit of using MSDE is that it is an out-of-the-box solution that can be stored on the same local server as discussions, thus avoiding an extra net trip. MSDE is also self-maintaining, with a back-up utility available. The downside is that MSDE doesn’t offer the performance of SQL Server, and includes no built-in management tools. By default, OSE installs MSDE for discussion data if SQL Server is not already installed on that web server.
Using an existing SQL Server database for your discussion database allows you to administer the discussion database along with the data already in your SQL Server database. Should you later decide to change from the MSDE to SQL Server 7.0, you can do so simply by installing SQL Server 7.0. For more details on configuring a discussion database, see the Microsoft Office 2000 Resource Kit.
You can set other discussion options, such as whether users can conduct discussions on documents on remote servers. By default, Office Server Extensions allow this, but you may want to limit remote document discussions to control the size of the discussion database. Another way of controlling database size is to use Automatic Deletion. Simply choose a maximum age for discussion items and they will automatically be deleted when that age is reached. For example, if your time-out is 90 days, then any discussion older than 90 days is automatically deleted.
You can use the OSE Administration Home Page to set options on subscriptions, such as to enable or disable subscriptions, specify the name of the SMTP mail server that will originate update e-mail, and the From and Reply-To addresses that will be used on update e-mail. In addition, you can determine the time intervals users have to choose from for their notification e-mail. The options are within a few minutes, once a day, and once a week. You can also determine what time notification e-mail is sent; you can schedule e-mail for off-peak times to reduce the possible impact of additional traffic. Finally, you can also view all active subscriptions, deleting individual ones if necessary and filtering on various characteristics.
If you do not have an SMTP server or are concerned about network traffic, you can disable subscriptions.
Next, consider how to enable Web components. Web components are not Web-server dependent. The capability to view and interact with web components is installed with Office 2000, or when the user browses to a Web page with a component on it. The Microsoft Internet Explorer component download mechanism can be set up to automatically download the components. The component download mechanism is for users who are licensed for Office 2000 through an Enterprise agreement but have not yet installed it. To make this possible, administrators check the Enable Auto-Download option of the Office Web Components page of the Custom Setup wizard and make sure that the Web Components automatic installation files (Msowcin.cab and Msowc.cab) are available on an Office installation server.
Once the web structure, discussions, subscriptions, and web components are configured, you’re ready to deal with security settings. Web content security is based on the Windows NT and its IIS web server’s security system. Office Server Extensions build upon this system to define several roles within the workgroup web.
The first step in accessing the server is authentication, to establish a user’s identity, based on checking a username and password against a pre-defined username-and-password database. Office Server Extensions rely upon the IIS web server to authenticate users, and you therefore need to configure IIS to have the right level and method of authentication for your needs. The type of authentication you choose is likely to be influenced by which browsers are in use and the level of network security required.
The Authentication Methods dialog box in the IIS 4.0 MMC snap-in.
There are three levels of Web authentication:
· Anonymous. Any request to the Web server from any client is honored without requiring that the request log in with a known username and password. Anonymous access is common on the Internet for public sites and may be appropriate for intranet sites for browsing, but usually anonymous access is not appropriate for authoring.
· Basic. Basic authentication forces the browser to log in with a username and password, but overall security is low because the username and password is sent over the network as clear text. Basic is the most common type of authentication scheme. It will work with any type of browser and will work when accessing a server through an Internet proxy server.
· Windows NT Challenge/Response. With Windows NT Challenge/Response authentication, users leverage their pre-existing login to WindowsÒ Networking. Browsers do not require that users re-type their usernames and passwords to access the web server, rather their logon credentials, established when the user logged into the Windows-based network, are sent to the Web server. Passwords are not sent over the network using Windows NT Challenge/Response. Windows NT Challenge/Response requires Internet Explorer on the client; Windows NT Challenge/Response will not pass through an Internet proxy server.
Windows NT Challenge/Response authentication is the recommended web authentication for workgroup webs. Windows NT Challenge/Response authentication simplifies logons and is the most secure authentication.
You can increase the security of network traffic by requiring that access to a server, or part of a site, use the Secure Sockets Layer (SSL). SSL encrypts information sent over the network, including both the username and password when using Basic authentication, as well as the document content. But SSL may significantly impact the performance of both clients and servers due to encryption/unencryption overhead.
Once a user is authenticated on a server, his or her access to the files on the server is determined by Windows NT File System (NTFS) ACLs on the server file system. These ACLs are automatically set up and managed by Office Server Extensions so that users fall into broader roles. The available roles are:
· Admin. Can create and administer OSE webs and sub-webs and can change web settings. Can also manage discussions and subscriptions. OSE Administrators are not necessarily Windows NT Administrators, although Windows NT Administrators are automatically OSE Administrators.
· Authors. Can publish and manage content.
· Collaborators. Can participate in discussions and subscriptions.
·
Browsers. Can read published content.
This illustration shows the User Groups window in the Windows NT User Manager. The circled groups—ALEX2000 Admins, ALEX2000 Authors, ALEX2000 Browsers and ALEX2000 Collaborators—are the groups installed by Office Server Extensions to establish roles on the ALEX2000 root web.
The Browser, Author, and Admin roles are cumulative, in that any Author is automatically a Browser, and any Admin is automatically an Author and a Browser. For maximum flexibility, the Collaborator role is independent of the Author or Browser roles, although on a given server Authors are usually going to be Collaborators as well.
Roles are implemented using Windows NT groups. Membership in roles is granted or removed by adding or removing Windows NT accounts (or groups) from the role groups that are created are installed when Office Server Extensions are installed.
The Browser, Author, and Admin roles are scoped to the web or sub-web level. Each sub-web on a server can have a distinct set of Browser, Author and Admin groups. A sub-web can also inherit the roles of its parent web. The best way to achieve finer grained security—to limit access for a subset of documents to a subset of users— is to create a nested sub-web to contain the documents. This sub-web will get its own set of role groups, which means that browsing, authoring, and administrative access can be constrained to the selected subset of users.
The Collaborators group is slightly different in that it is scoped to the web-site level. This is because the discussion store exists at the web-site level, not at the sub-web level.
Although the roles are the recommended mechanism for managing security on the workgroup web, it is possible to manage publishing security at a lower, more granular level. Roles are expressed using NTFS ACLs on the server file system. Expert server administrators can directly manipulate NTFS ACLs themselves, bypassing the role groups. The advantage of working directly with NTFS ACLs is that you can control access on a per-file or per-directory basis. With OSE role groups, you can control access only on a per-web basis. There are a number of disadvantages to direct NTFS ACL manipulation, however, including performance impacts, increased ongoing maintenance burden, and the possibility of compromising the server’s security or breaking OSE functionality altogether due to incorrect of NTFS ACL configuration. The advantages and disadvantages, as well as the mechanics, of setting NTFS ACLs, are discussed in detail in the Office Resource Kit.
· To make use of Windows NT Server security and consequently the Office Server Extensions roles, you must use the Windows NT File System (NTFS). If you use the FAT file system, the OSE roles do not apply and the server’s content can be anonymously authored. For more information on role-based security, see the security white paper on www.microsoft.com\frontpage.
Office Server Extensions and Office 2000 applications support several levels of version control and contention management. Simple multiple-user edit contention management is always enabled, and is essentially the same set of features that have been available in previous versions of Office. This functionality warns the user when another user is actively editing a document on the server, and gives the second user the choice of opening the document read-only or making a copy of the document. When the first user closes the document, the second user is notified that the document is now available for read/write editing. A document is locked only as long as an Office application has it open for editing. If the document is closed, the Office application is closed, or the network is disconnected (for example, the user takes a laptop offline), then the lock on the document is released.
Office Server Extensions also provides long-term document locking and full version control functionality. Three options are available:
· None. This is the default for Office Server Extensions. Short term locking as described above is enabled, but there is no way to lock a document for a longer period of time across several editing sessions, and there is no history or rollback capability.
· Lightweight check-in and check-out. A simple solution to enable long-term locking of documents. Lightweight check-in and check-out enables a user to check out a document, or reserve and lock the document for long-term editing. When a document is checked out, no other user can edit it. Lightweight check-in and check-out requires no additional software on the server; it is enabled by setting a configuration switch using the OSE Administrative tools. Office 2000 applications respect check outs, but you cannot use Microsoft Word or the Microsoft PowerPointâ presentation graphics program to perform a check-out; check-out and check-in must be performed using the FrontPage-based client. Lightweight check-in and check-out provides one level of rollback, so that if a series of changes are made to a checked-out document, those changes can be discarded and the document rolled back to the state it was at the time of the check-out. Complete version history is not maintained. Lightweight check-in and check-out is a low-overhead solution that will not affect server performance or add additional maintenance tasks.
· Visual SourceSafeä integration. Full version-control functionality. Office Server Extensions integrate with the Visual SourceSafe version control system on the server to automatically place document versions into the Visual SourceSafe document store whenever documents are changed on the server. Long-term check-outs are also enabled as described above for lightweight check-in and check-out, but multiple levels of rollback are available and a full document version history is maintained. Visual SourceSafe provides the most version-control functionality, but requires the most server resources and maintenance. Using Visual SourceSafe on the server requires that the Visual SourceSafe client be installed on the server, that Visual SourceSafe document stores be created for the web, and that Visual SourceSafe user accounts be created for all web authors. Using Visual SourceSafe slows down OSE authoring operations because each document save must not only update the web server’s file system, but must also update the Visual SourceSafe document version store.
When either Lightweight check-in and check-out or Visual SourceSafe integration is enabled, the Office application user will probably not notice any difference. [AP1]
If an Office user opens a document, and the document is not checked out, the user can open it with read-write access; when changes are saved, an “auto-checkout” of the document is performed. When performing an auto-checkout Office Server Extensions implicitly check out the document, save the changes, and then immediately check in the document, but no long-term lock occurs. Note that with auto-checkout functionality the Office user can participate in a web that has versioning enabled even though he or she may not be able to explicitly check out documents themselves using the FrontPage-based client.
Although you have many choices for customization when you deploy a workgroup web, your deployment procedure will be dictated primarily by the web structure and security settings you choose. The following are procedures for deploying a centralized, decentralized, or jointly managed web structure.
Central Administrators will roll out this environment with complete control of each workgroup web’s structure and security. Accordingly, the central administrator may then go through the following steps:
1. Create one or more workgroup web servers.
2. Extend the web server with Office Server Extensions, which enables the web server for publishing, discussions, and subscriptions.
3. Using FrontPage or the Office Server Extensions administration tools, create webs and sub-webs on a central server.
4. Give users permissions as Authors, Browsers, or Collaborators on the appropriate webs (and sub-webs for Authors and Browsers).
5. Roll out publishing places and discussion server locations with Office 2000 Office Profile Wizard and the Custom Installation wizard
Workgroup members may use FrontPage to create graphical web pages to publish to their publishing site, but they will probably not have any administrative privileges on their workgroup webs and therefore will not be able to manage their webs.
In this environment, workgroups have almost full autonomy. To deploy a workgroup web in this scenario, a member of the workgroup may go through the following steps:
1. Create a workgroup web server. The central IT administrator can set up an Office Server Extensions install with a preset “script,” so that workgroups can install the consistent configuration from a central location, or a workgroup can install OSE directly from the Office CDs. The OSE setup enables both publishing and discussions and subscriptions.
2. Using FrontPage or the OSE Administration tools, the workgroup administrator can create webs and sub-webs on the workgroup server. The workgroup administrator may create a customized home page for workgroup.
3. The workgroup administrator gives members of the workgroup permissions to administrate, author, browse, or collaborate on one or more webs and sub-webs.
4. The workgroup administrator notifies other workgroup members about publishing places and discussion server locations.
In this environment, workgroup members will use IIS, OSE Administration tools, as well as FrontPage to set up and manage their web sites. For some IT administrator control, the central administrator can be given rights to the Web server for troubleshooting.
In this environment, workgroups can be given autonomy in their section of the web, but IT retains control of the overall web structure and security. IT administrators and members of the workgroup may go through the following steps:
1. The central administrator rolls out a centralized web structure and gives workgroup administrators Administrator privileges to their sub-webs.
2. The central administrator gives workgroup members Collaborator permissions to their IIS Web site for discussions and subscriptions and gives workgroup administrators Administrator permissions to specified sub-webs.
3. The workgroup administrator will give workgroup members permissions to be either Administrators, Authors, or Browsers to sub-webs.
4. Workgroup administrators then have complete control of the setup and maintenance of their sub-web. They can manage their portion of the Web using FrontPage 2000.
For details on each step of the deployment, see the Office Resource Kit.
Once the workgroup web is deployed, it needs to be managed. There are two main areas to manage in a workgroup web:
· Structure and content. You may need to reorganize web structure to mirror organizational changes—to create new webs or consolidate existing ones. As webs grow, content will naturally change as well.
· Discussions and subscriptions. An administrator may want to monitor and optimize the database. Over time, subscription needs will change as well
This section describes tools for managing a workgroup web. It also discusses performance issues and expectations. See Appendix D, “Frequently Asked Questions,” for ways to convert file servers to web servers and to take multiple webs and centrally administer them
Useful management tools for workgroup webs can be found in four different products: FrontPage, Office Server Extensions (OSE), Windows NT 4.0, and Internet Information Server (IIS).
FrontPage provides comprehensive and easy-to-use tools to manage content and web structure. You can easily view a web’s navigational structure, directories of information, hyperlinks, hyperlink status, or all files at once. With reports showing inefficient pages and broken links and automatic hyperlink maintenance, you can make changes to optimize a page’s performance and not worry about broken links. With site-wide thematic styles, you can update a site's look with the click of a button. Flexible collaboration features, such as check-in/check-out, task lists, and remote or local authoring, provide the ability to work with others to create and manage your web.
Because Office Server Extensions are built upon FrontPage Server Extensions, Office Server Extensions provide publishing tools (from FrontPage Server Extensions) as well as tools to manage discussions and subscriptions. A Web-based administration interface is included, along with a Microsoft Management Console (MMC) snap-in and a command-line tool.
· Publishing extensions MMC snap-in. The publishing snap-in is integrated with the IIS management snap-in and appears as an additional tab in IIS Web-site, folder, and file property sheets. The publishing snap-in must be run on the server; remote administration of publishing is not enabled through MMC.
The Server Extensions tab in the IIS Web site property sheet.
· Fpsrvadm.exe. Administers the publishing component of the Office Server Extensions through a command line interface. The fpsrvadm.exe tool can be used for automation in batch files. Fpsrvadm.exe must be run on the server.
· Publishing HTML forms. An HTML-based interface to administer publishing. It can be used from any web browser, including remote computers. The administration forms are copied to your Web server during OSE Setup.
· Discussions and subscriptions HTML forms. An HTML-based interface to manage discussions and subscriptions. From the Administration Home Page, you can monitor discussions and delete either a single discussion or all the discussions associated with a document. You can also monitor subscriptions and remove them if necessary. An administrator can always change the subscription and discussion options initially set.
Workgroup webs rely on Windows NT tools to manage such features as security and IP addresses.
· Windows NT User Manager. As discussed above in the “Security Settings” section of this document, the Office Server Extensions Browser, Collaborator, Author, and Administrator roles are built on Windows NT groups. Use the Windows NT User Manager to add and remove users from the OSE roles by adding and removing user accounts from the Windows NT groups created by OSE for each role.
· Control Panel. Use the Network settings in the Windows Control Panel to configure Windows NT to accept Internet connections on a particular IP address. Once Windows NT is configured to accept connections on a particular IP address, create a web site to host your workgroup web using IIS and OSE tools.
· Windows Shell. As discussed in the “Security Settings” section of this document, expert web server administrators can choose to manage OSE security using NTFS ACLs, though this is generally not recommended. The simplest way to set NTFS ACLs is using the Windows shell. Other tools such as Cacls.exe are also available to manage ACLs.
· ADSI. The Active Directory Service Interface (ADSI) provides automation of tasks that would normally be performed by hand using the Windows NT User Manager. Scripts run from the Windows Scripting Host or from an ASP page can use ADSI.
You can use the following IIS management tools to create Web sites and configure authentication:
· IIS Microsoft Management Console (MMC) snap-in. Also known as the Internet Service Manager. Administers IIS using a graphical user interface console. Used to create new web sites, set web server authentication options, and fine-tune web server settings. The OSE Publishing extensions snap-in is integrated with the IIS snap-in.
· IIS HTML-based management. Administers IIS using a HTML-based interface accessible from a web browser. Used to create new web sites, set web server authentication options, and fine-tune web server settings.
· Mdutil.exe. Command line administration of IIS. Used to set web server authentication and fine-tune web server settings.
· Automation. Administration of IIS from scripts that can be run using Windows Scripting Host or ASP pages.
An intranet that supports workgroup webs may service one or many workgroups. To deliver a solution to meet end users’ performance expectations, an administrator needs to gauge web site usage and calculate hardware needs. Web-site usage can be estimated through monitoring the number of participants and their activity level. From this understanding, administrators can estimate the types of clients and servers needed to meet end user expectations.
Publishing performance depends on the number of items published to a web, the size of those items, the frequency with which items are published, and the structure of the web. Sub-webs help optimize publishing performance. For more information on publishing performance, see http://microsoft.com/frontpage.
Storing discussions and serving them to clients is generally not very CPU intensive. The client can provide the greatest performance gains; a faster client can mean improved discussion rendering.
The performance and the scalability of your servers is likely to differ from the results described above, since these numbers are dependent on many factors, including software and hardware configuration, network structure, how many URLs are on each server, how big each piece of content is, how many discussions are in a database, and how many discussions are on each piece of content being rendered. For these tests, there were 25,000 URLs on the server, with each piece of content taking up 200k. The documents that were rendered had 100 discussions on them and were part of a 150,000-discussion database. The database resided in MSDE on the server.
You may need to educate users on where they save information to publish it to their workgroup web, and where they can conduct discussions. Since this functionality is built into the familiar Office environment, training costs are much lower than if a new, unfamiliar system were put in place.
Using the Custom Installation Wizard, Office can be deployed so that web sites are mapped to the FileOpen dialog box and discussions servers are set up. This arrangement makes it easy for users to find webs they can publish to and servers to conduct discussions.
In the FileOpen dialog box above, the development and marketing web sites are listed, making it easy for users to navigate to their workgroup web to save information.
The dialog box above shows the discussion server Offdog set up, so that end users only have to choose the web discussion button to take part in discussions.
If you set up Office Server Extensions after you have deployed Office 2000, you can send e-mail or a link to a web page that describes how users can map to a web folder and a discussion server.
The workgroup web provides exciting new ways to make an organization’s intranet a dynamic collaborative environment for the Microsoft Office user. Using the configuration, deployment, and management techniques described in this paper, corporate administrators will be able to deploy this exciting new technology while maintaining control over their intranet infrastructure.
For more information about Office 2000, including Office Server Extensions, see http://www.microsoft.com/office/.
For greater detail on Office and Office Server Extensions system requirements, security, administration, and configuration, see the Microsoft Office 2000 Resource Kit.
For more information about FrontPage web creation and management tools, see http://www.microsoft.com/frontpage/.
For information on Windows NT Server, see http://www.microsoft.com/ntserver/
For information on Windows NT Workstation, see http://www.microsoft.com/ntworkstation/
For information on IIS, see http://www.microsoft.com/ntserver/web
For more information on Index Servers, see http://www.microsoft.com/ntserver/web/exec/feature/
This appendix describes hardware and software requirements for workgroup webs. Workgroup web functionality is enabled by a combination of server and client software; there are hardware and software requirements for both.
A computer capable of running Microsoft Office 2000 or a browser equal to or newer than Netscape Navigator 3.0 or Internet Explorer 3.0.
The user experience depends on which version of Microsoft Office and what type of browser is installed. For basic functionality, a Web browser is the only software required. Some browsers may not support more advanced functionality, as described below:
· Viewing Web pages. Some functionality enabled in FrontPage 2000 cannot be viewed in some browsers. If you are developing web pages in FrontPage that will be viewed across different browsers you can turn off functionality that cannot be viewed by certain browsers.
· Participating in discussions and subscriptions. Users with Netscape Navigator or Internet Explorer 3.0 browser can access discussions and subscribe to Office documents through the Start Page via a frames-based version of the Discussions toolbar. Users with Microsoft Office 2000 and Internet Explorer 4.01 can access advanced functionality, including rich discussion, subscription, and all Web component features except Access Data Pages. Users with Internet Explorer 5.0 can benefit from Internet Explorer’s functionality to publish to a server that supports WebDAV.
· Viewing Web components. Should a web page use Web components, users of Internet Explorer 3.0 or earlier will see a static representation of the page. Internet Explorer 4.01 or later can access the rich features of all Web Components except Access DataPages. Access DataPages require Internet Explorer 5.0.
Server hardware requirements are largely dependent upon your specific situation. As a general rule, expect your hardware requirements to be similar to the requirements for running a web server. See the Office Resource Kit for requirements based on the expected number of concurrent users.
The following are the software requirements to enable publishing, web components, discussions, and subscriptions:
· Publishing. Publishing requires Office Server Extensions (or simply FrontPage Server Extensions), or a WebDAV-compliant Server. Office and FrontPage Server Extensions will provide users additional benefits over a WebDAV server including convenient management features such as document-level check-in, check-out, and link fix up.
· Web components. Web components have no server requirements.
· Discussions and subscriptions. Requires Office Server Extensions. The following are the software prerequisites for Office Server Extensions:
· Microsoft Windows 2000 or Microsoft Windows NT Server version 4.0 with Service Pack 4 or later, or Windows NT Workstation version 4.0 with Service Pack 4 or later.
Note: You can use OSE with file allocation table (FAT) file system, but this provides little access level security. It is highly recommended that you use the Windows NT File System (NTFS) before installing OSE. You can use Convert.exe to convert an existing volume from the FAT file system to the NTFS file system. For more information about Convert.exe, see the Windows NT System Guide.
· Microsoft Internet Information Server 4.0 or later and Index Server (optional for searching), both installed from the Windows NT Options Pack. or Windows NT Workstation 4.0 with Personal Web Server for Windows NT Workstation 4.0.
· Internet Explorer 4.01 or later
· Office Server Extensions. Customers must own an Office 2000 license for each web server with Office Server Extensions installed. However, a client can access discussions and subscriptions via a browser and without an Office 2000 license.
· Office Web Components. Customers must own an Office 2000 license in order to browse a Web page interactively using Office Web Components. Organizations that own an Enterprise Agreement for Office 2000 and that plan to deploy Office 2000 in phases can enable early adopters of Office 2000 to share component-based Web pages with users who haven’t yet installed Office 2000. They do this by enabling auto- downloading of the components via the Microsoft Internet Explorer built-in component installer.
Office Server Extensions (OSE) provide the tools needed to create a complete workgroup web, including publishing, discussions and subscriptions. The following describes OSE installation and options. For complete step-by-step instructions, see the Microsoft Office 2000 Resource Kit.
Microsoft Office Server Extensions Setup is a separate application from Office 2000 Setup. OSE is not an add-on to FrontPage; it is a stand-alone product. The OSE Setup application is named Setupse.exe and is available either from Microsoft Office 2000 Professional (Disc 1) or Office 2000 Premium (Disc 3).
If you launch OSE setup from Autorun.exe on Disc 3 of Office Premium, setup detects whether you do not have the OSE prerequisites—Internet Explorer 4.01, NT Options Pack, and Windows NT SP4—and installs these components for you, if necessary. (Note that the autodetect feature of OSE setup is not available on Office 2000 Professional.)
OSE setup then runs the OSE configuration wizard, which configures Office Server Extensions and enables your web server for publishing, web discussions, and web subscriptions. When the wizard is completed, your web is ready for Office 2000 users to publish and collaborate around Office documents and web pages.
You can configure OSE setup to run in quiet mode so that it does not require any user interaction. This is convenient when you need to configure several Web sites at a time or to develop a standard installation configuration. Using quiet mode, you can provide workgroups with a standard installation from a central install point. A workgroup member can then install OSE with the correct corporate defaults.
By default, discussions are stored in the Microsoft Data Engine (MSDE), a SQL-Server compatible data engine. MSDE is installed as long as there is no SQL Server on that Web server. If Setup detects SQL Server 6.5 or later on the server, OSE will use the local SQL Server installation to store discussions.
If you have SQL Server 6.5 or later available on your network, you may want to use it to store your discussion data. Using an available SQL Server will allow you to administer discussions along with the data already in your SQL database. Should you later decide to change from the MSDE to SQL Server 7.0, you can do so.
The following describes what you’ll need to do to use SQL Server for your discussions:
· If you are using SQL Server on a different machine than you are installing OSE on, OSE can not detect SQL Server and will install MSDE. To turn off MSDE installation, install Office Server Extensions with the “no database” switch. The configuration wizard will then allow administrators to use a remote SQL database
· On a SQL Server 6.5 server, create a database for each Web site that will contain documents to be discussed. If you are using SQL Server 7.0, the OSE configuration wizard will create the databases for you.
· Give a SQL account full access to each database and then provide the OSE Configuration Wizard with the user account and password. If SQL Server 7.0 is on the local computer, the OSE Configuration Wizard creates the database automatically, but you need to give a user account full access to the database that the wizard creates.
· For more information about system requirements and installation procedures, see the Office Resource Kit.
IIS is capable of supporting more than one Web site on the same physical server. Each IIS Web site is assigned to either a different IP address, or a different “hostname,” using a technique called host-header addressing. The network infrastructure’s naming system must be configured with the various IP addresses and hostnames that a particular web server is supporting. How you do this depends on your network infrastructure, but it will probably involve a combination of DNS server configuration and WINS server configuration. Once the network infrastructure is set up, and the Windows NT-based server is set up with the different IP addresses in use, you can configure IIS by creating multiple web sites. Assign each web site its own IP address or host header name. Then extend each web site with OSE. Each OSE site will receive its own discussion database and be a distinct URL for publishing documents and collaborating.
Non-standard ports (ports other than the HTTP default of 80) are not supported by OSE.
· Anonymous authentication Allows any user access to the Web site, even those without a Windows NT account.
· Basic authentication Encodes but does not encrypt the user name and password. Many Web servers support Basic authentication, and IIS can pass the logon through to Windows NT Server. If you use Basic authentication in combination with Secure Sockets Layer (SSL), you can have secure and fast authentication. SSL encrypts the transmission, making it unreadable to network snoopers.
· Windows NT Challenge/Response (also called NTLM) A more secure authentication method than Basic authentication. When a user is authenticated using Windows NT Challenge/Response, the user is logged on to the Web server computer as a network logon. NTLM does not work over firewalls, which further improves security. It does not, however, pass the logon through to secondary servers, and requires Internet Explorer 4.01 or later.
· Office Server Extensions A set of Web applications built on the FrontPage 2000 Server Extensions, Active Server Pages, ActiveXâ Data Objects, and OLE Automation. They run on Windows NT 4.0 Workstation with Personal Web Server 4.0, or Windows NT Server 4.0 with Internet Information Server 4.0, to provide additional publishing, collaboration, and searching capabilities. Office Server Extensions work with client-side software in Office 2000, Windows Explorer, and the Web browser to provide these new capabilities to the user.
· Root Web Each FrontPage-based Web begins with a root Web, the top-level content directory of a Web server, or in a multi-hosting environment of a IIS Web Site server. A root Web can have many levels of subdirectories, which contain the Web’s content.
· Sub-web Sub-Webs are the FrontPage mechanism for breaking up a Web site so that different areas can be owned and maintained by different people or workgroups. A sub-Web is a complete FrontPage-extended Web that exists as a subdirectory of the root Web, or of another sub-Web. Each sub-Web can have many levels of subdirectories.
· Web Components Office Web Components are a collection of COM controls for publishing spreadsheets, charts, and databases to the Web. They take full advantage of the rich interactivity provided by Microsoft Internet Explorer. When you use Internet Explorer to browse a Web page that contains an Office Web Component, you interact with the page right in your browser—you can sort, filter, enter values for formula calculations, expand and collapse details, pivot, and so on. The COM controls provide the interactivity. The Web Components are fully programmable, enabling Office Solution Providers to build rich, interactive Workgroup Webs. The Microsoft Office Web Components include a spreadsheet, a PivotTableÒ dynamic view, a data source, and a chart.
1. How do I provide for roaming users?
The Discussion Server List on the client and Web folders shortcuts will roam.
2. What about multinational considerations?
The Microsoft Office MultiLanguage Pack includes plug-in Language features that allow users to change the language of the user interface. When you use Office Web features in an international environment you can conduct web Discussions in any available language and use localized versions of Web folders.
3. What is the difference between saving to a server with Office Server Extensions on it and a WebDAV server?
Saving is the same using either OSE or WebDAV. There are important differences, though, for site maintenance tasks such as file renaming and file moving. In those operations features like link fix up don’t exist on WebDAV servers. You also can’t use the FrontPage client for advanced HTML and site administration against a pure DAV server.
When the server supports OSE and DAV side-by-side (which is allowed), the Office client will prefer talking to OSE because it has better site administration and functionality, and also because OSE subscription notifications for document update, move, rename, or delete will only be sent if you use OSE to save, rename, move, or delete the document. If you update or manage the document using DAV, then no OSE subscription notification e-mail will be sent.
4. How and when should I convert my file servers to web servers?
You do not need to move all your file servers over to web servers immediately in order to take advantage of the Office Server Extension features. You can conduct discussions on Office binary files or HTML files whether or not they reside on a web server or a file server, as long as users have access to a discussion server. You cannot, however, subscribe to content that does not reside on a web server with Office Server Extensions on it.
The rate on which you move all of your Office binary and Web files to web servers or you tell people to save all new and updated content to web servers instead of file servers, is a decision that is dependent upon the environment.
5. How can you gain control of the many web sites in an organization and centrally administer them?
There are a few ways you can do this. If you are combining a number of sites with quite a bit of information on each site, this could take some time. It is not an easy task. Some suggested steps are as follows:
a) Make sure you have Administrator rights to the sites.
b) If you choose to combine the web sites onto one web server, you will need to create the web server structure you want to move the sites to, by creating the IIS Web Sites using IIS administration tools and extending them with OSE and then setting up the appropriate security and roles.
c) Using FrontPage, manually open the webs you want to move. Save them to the new site and perform Link Fix Up.
d) You may need to merge sub-webs together. In this case, you may need to convert existing sub-webs into simple directories of their parent webs. You can do this using the OSE Publishing snap-in. Similarly, you may need to convert existing directories into sub-webs. This task can also be accomplished using the OSE Publishing snap-in.
e) Discussion management. Publishing or copying a web’s documents to a new location does not automatically move discussions (only move/rename causes discussions to move with a document). To move web discussions to a new location along with the document content, you can use the OSE backup and restore tool for discussions.
f) When merging webs you may need to manually fix up navigation structure or reconcile varying themes across different content sources. Use the client running FrontPage to manage across all documents in your web. Use the FrontPage-based client’s report view to report and fix up broken links or orphaned files.
6. How do you take multiple Webs with OSE throughout an organization and centrally administer them?
a) To centrally administer content on the Web sites you would go through the steps described in the answer to the previous question.
b) If the sites you are moving already have Office Server Extensions on them and the workgroup is actively using discussions and subscriptions, when you move these sites, the discussions and subscriptions will be lost. You can combine the discussion databases onto one MSDE or SQL Server so that you will be maintaining one instance of MSDE or SQL Server with multiple databases, but you will not be able to combine the different discussions onto one discussion database. For information on how to combine discussions into one instance of MSDE or SQL please see the Office Resource Kit.
7. How do you provide Administrator rights to central IT in order to trouble shoot on web sites, without having IT centrally administer these web sites?
All IT needs to do in this scenario is make sure they are granted the rights of an administrator to Windows NT Workstation or Windows NT Server.
8. Is subscription and notification functionality affected by where documents and discussions are stored?
Office Server Extensions give users the flexibility of maintaining discussions and content separately. However, depending upon where documents and discussions reside, subscription and notification functionality will work differently:
· If documents and discussions reside on the same OSE server, all features will be enabled.
· If documents reside on a OSE server that is separate from the discussion database, users subscribed to a document or file will get full notifications but no link fix-up for discussions.
· If documents reside on a server that does not have OSE installed and the discussion database is on a separate server, users will receive notifications that discussions have changed. Link fix-up will not be enabled.
9. Since discussions and documents reside separately, what happens to discussions when I delete a document?
If the content being discussed resides on an OSE server, when you delete the content, both the content and discussions will be deleted.
If the content being discussed does not reside on an OSE server, there is no way to tell the OSE server that the content has been deleted; therefore only the content not the discussions will be deleted. If you use the Automatic Deletion option that deletes discussions after a certain period of time, these discussions will automatically be deleted over time.
uuuu
This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unpublished work. Ó 1999 Microsoft Corporation. All rights reserved.
Microsoft, ActiveX, FrontPage, the Office logo, PivotTable, PowerPoint, Visual SourceSafe, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.
Product and company names mentioned herein may be the trademarks of their respective owners.
[AP1]Para that I deleted repeats info already presented in this section.