 |
by
Tara
Hall
Level: Intermediate
Works with: QuickPlace 3.0
Updated: 09/03/2002
Inside this article:
2. Plan the upgrade of your Places
3. Connect your QuickPlace servers to your external user directory
4. Take advantage of the Place Catalog
5. Use QPTool to administer your Places
6. Cluster your QuickPlace servers
7. Set up a Domain Catalog server to implement Search Places
8. Integrate with Sametime 3.0
9. Create a qpconfig.xml file
10. Take advantage of your resources
Related links:
New features in QuickPlace 3.0
Performance perspectives: Comparing QuickPlace 3.0 with QuickPlace 2.0.8
Going (Quick)Places with Charlie Hill
Going more (Quick)Places
Domino 5 Administration Help
NotesBench Consortium
Sametime 3.0 documentation
IBM Redbook: Deploying QuickPlace
The QuickPlace DevZone
LDD QuickPlace page
Lotus QuickPlace home page
Get the PDF:
 (162 KB)
|
 |
Before you upgrade your servers or deploy QuickPlace 3.0 for the first time, there are a few things you should know. Whether you have been using QuickPlace since release 1.0 or are new to QuickPlace, you need the right information to plan an enterprise deployment. Knowing what is required and what is recommended will help ensure a successful deployment. In this article, we've compiled ten things that you should know—important pieces of information that will help you plan your deployment. This article is intended for both new and experienced QuickPlace administrators and developers. Note that the scope of this article is limited to providing an overview of changes, features, and technology. For more detailed information, refer to the QuickPlace 3.0 documentation.
1. Install your QuickPlace 3.0 server on a Domino 5.0.10 server
QuickPlace 3.0 is installed on a Domino 5.0.10 server, a configuration that is referred to as an overlay. In previous releases, a standalone QuickPlace that provided limited Domino functionality was available, but in release 3.0, the standalone server is no longer an option. By installing QuickPlace on your Domino servers, you can take advantage of Domino functionality, such as clustering and replication, to manage your Places.
If you are upgrading your QuickPlace servers to release 3.0, try to upgrade all servers in the domain at the same time. As you'll see in the next section, you can upgrade your QuickPlace servers without upgrading your Places, which significantly reduces the time in which your servers are down.
If you have an existing Domino environment, but are not running release 5.0.10, upgrade your Domino servers to the 5.0.10 maintenance release; then install or upgrade to QuickPlace 3.0. The Domino server type that you choose depends on whether or not you want to cluster your QuickPlace servers. QuickPlace takes advantage of Domino clustering functionality, so if you plan to cluster your servers, choose the Domino Enterprise server type.
If you have standalone QuickPlace servers, you need to migrate from the standalone server to the overlay. Migrating from a standalone server to an overlay configuration requires more steps than migrating from a previous version of QuickPlace already installed on a Domino server. To migrate to the overlay configuration, follow the procedure described in the QuickPlace 3.0 Administrator's Guide. Make sure to configure your Domino server before installing QuickPlace. For instance, if you want to support Domino Offline Services (DOLS), enable DOLS on the Domino servers and then upgrade to or install QuickPlace 3.0. There are several more Domino feature that you may want to enable mentioned throughout this article.
You should also install QuickPlace on dedicated Domino servers. For instance, do not install your QuickPlace and Sametime servers on the same machine. Your servers provide different services, and to best manage different services—mail, community and meeting, and Place—install them on different servers for three reasons:
- Service reliability
If you install QuickPlace on your Domino mail server and the mail server fails, you lose not only your mail service but also your Place service, or QuickPlace server.
- Service manageability
Installing services on separate servers also makes it easier to upgrade and manage those services. If you run more than one service on a single machine and need to take down the machine for maintenance of one service, all services become unavailable.
- Scalability and performance characteristics
Different servers have different scalability and performance characteristics. Some services are more CPU intensive or require more resources than others. Keep those services—and their characteristics—separate.
QuickPlace 3.0 supports Windows, AIX, Solaris, and iSeries (formerly AS/400). For more information about which versions of these platforms are supported and for hardware requirements, see the QuickPlace 3.0 Release Notes.
2. Plan the upgrade of your Places
In previous releases, when you upgraded your QuickPlace server, you also upgraded all Places on that server. Depending on the number of Places in your enterprise, upgrading them may have taken not hours, but days. In the meantime, your QuickPlace servers were unavailable. In release 3.0, server upgrade and Place upgrades are separate processes. When you install QuickPlace 3.0, you upgrade your server, but your Places remain unaffected. As soon as you restart the QuickPlace server after installation, users can access their Places. However, after you upgrade your server to release 3.0, your Places cannot take advantage of the release 3.0 features until your upgrade them.
To plan your upgrade, create a pilot program. In this pilot program, consider creating a test environment. The test environment may differ from your production environment. For instance, in a pilot program, you may install Domino 5.0.10, QuickPlace 3.0, and Sametime 3.0 on the same machine for test purposes; however, this configuration is not supported in a production environment. The goals of the pilot program vary from organization to organization, but there are two recommended goals for each pilot program:
- To create an upgrade schedule
- To test your Places
The upgrade schedule lists the order in which you upgrade your Places. To help you determine the upgrade schedule, select a few Places of varying size to upgrade and record the time it takes to upgrade them. Use this information to help you plan the order of your upgrades. For Places that take several hours to upgrade, you may want to upgrade them overnight or during a weekend. Other factors that you may want to consider:
- Is the Place mission-critical? If so, you may want to upgrade mission-critical Places first.
- Do your Places need to take advantage of new 3.0 features? If so, you may want to upgrade those Places early on in your schedule.
Which Places you choose to upgrade and when is up to you, and remember that while you upgrade your Places, your QuickPlace server is still available to your users.
You can use the new administrative tool, QPTool, to upgrade your Places. The following table lists the most common QPTool commands for upgrading Places and PlaceTypes. There are more arguments for the upgrade command in the QuickPlace 3.0 Administrator's Guide.
| Command | Description |
| qptool upgrade -p Placename | Upgrades a specified Place. To upgrade more than one Place at a time, list each Place name separated by a single space. |
| qptool upgrade -a | Upgrades all Places and PlaceTypes on a server. |
| qptool upgrade -pt | Upgrades all PlaceTypes on a server. You can also specify which PlaceTypes to upgrade by listing the PlaceType name or names separated by a single space. |
After you upgrade a few select Places, test them to ensure data integrity. Your upgraded Places should continue to function in release 3.0 as they did in previous releases, but always check your Places after upgrading to make sure that you did not lose any data.
3. Connect your QuickPlace servers to your external user directory
Directory planning is crucial to a successful deployment. Although it's possible to manage your QuickPlaces without a directory, when it comes to enterprise deployment of QuickPlace, that approach isn't always viable. Instead, you're best option is to connect your QuickPlace servers to an external user directory. Connecting to an external directory offers some major benefits:
- Centralized membership management
If you add users and groups from an existing directory to a QuickPlace, changes that you make to the user or group information are automatically reflected in the Place, so there's no need to make changes both to the directory and to the membership of the Place.
- Importing user and group information from a directory
After you connect your user directory to your QuickPlace servers, you can select users and groups from the directory to add to the Place as external members. When you select users and groups, QuickPlace imports user and group information, so you don't need to re-enter the information into the Place.
The only requirement for connecting to an external user directory is that the user directory must be LDAP-compliant, with one exception. For backward compatibility, QuickPlace 3.0 can connect to your Domino Directory via NRPC during the upgrade period until you move to LDAP. However, this protocol is supported for existing QuickPlace deployments only. If you are new to QuickPlace and want to connect to a Domino Directory, use LDAP instead of NRPC. If you haven't already, make sure to set up LDAP on your Domino servers. See the Domino 5 Administration Help for information about configuring LDAP on your Domino 5.0.10 servers. After you set up LDAP on your Domino servers, you can configure your QuickPlace servers to connect to a local or remote Domino Directory or to any LDAP-compliant directory, including iPlanet, IBM Secureway, and Microsoft Active Directory.
LDAP schema and filter mapping
To make it easier for you to connect to an external LDAP-compliant directory, QuickPlace 3.0 supports both schema and filter mapping. Schema mapping lets you map your LDAP directory attributes to the following QuickPlace Person fields:
- Common Name
- First Name
- Last Name
- Phone
- Email Address
- Display Name (the name by which a person is represented in a Place)
- Person Value (the objectclass value for a person in an LDAP directory)
It also lets you map LDAP directory attributes to the following QuickPlace Group fields:
- Group Name
- Group Display Name (the name by which a group is represented in a Place)
- Group Member (the value that represents members in an LDAP directory)
- Group Value (the objectclass value for a group in an LDAP directory)
Filter mapping lets you configure LDAP Search filters that QuickPlace uses for the following types of lookups:
- Person
- Group
- Authentication
- Group Membership
Schema and filter mapping require the qpconfig.xml file. We'll talk more about the qpconfig.xml file later in this article, but for additional information about schema and filter mapping, refer to the QuickPlace 3.0 Administrator's Guide.
After connecting your QuickPlace servers to an existing user directory, take advantage of such features as single sign-on to let your users sign in once and to access not only all QuickPlace servers in your domain, but also your Sametime servers. Configure single sign-on for each Domino server running QuickPlace and Sametime.
4. Take advantage of the Place Catalog
The Place Catalog is to your QuickPlace servers and Places what your user directory is to your users. The Place Catalog is an application that lists servers, Places, and members and helps you to manage your servers and Places. The Place Catalog defines a service, which is a collection of QuickPlace servers and Places on the same network—maybe in the same domain—that may be administered by the same team. How you define the service is up to you. You may choose to base your services on geographical location. For instance, if your organization has deployed QuickPlace servers in its headquarters in Chicago administered by one team and maintains a separate deployment in a sales office in Washington, D.C. administered by another team, then you essentially have two services, one in each location. You may want to define the service according to the domain. For instance, if you maintain two domains, one internal and one external, then you can define two services according to the domains to which the QuickPlace servers belong.
When you install QuickPlace 3.0, a Place Catalog is created automatically. Designate one Place Catalog server among your QuickPlace servers and configure the Place Catalog on that server. You can delete all other Place Catalogs. To connect your QuickPlace servers to the Place Catalog, use the qpconfig.xml file. QuickPlace servers connect to the Place Catalog server through HTTP or NRPC. Make sure to include the QuickPlace servers in the ACL of the Place Catalog and create a full-text index of the Place Catalog.
Cluster your Place Catalog server with at least one other server to provide failover. In general, apply the same practices that you use to manage availability of your user directory to the Place Catalog. Accessibility to your user directory and Place Catalog is critical to your service.
While implementing the Place Catalog is optional, you cannot take advantage of such features as My Places without it. You also lose QPTool functionality. When you implement the Place Catalog, keep in mind the following:
- If you have an existing QuickPlace deployment, you must register the existing servers and Places to the Place Catalog, because this will not happen automatically. Registering servers and Places adds them to the Place Catalog. QPTool can register your servers and Places using the following commands:
load qptool placecatalog -server
load qptool register -placecatalog -a
Before you register your servers and Places, make sure to upgrade them.
- If you create new Places after implementing the Place Catalog, QuickPlace automatically registers the Places in the Place Catalog for you.
Registration of new Places can occur as the Place is being created in real-time, when a scheduled task runs, or when a server task runs manually. Automatic registration prevents users from creating Places with duplicate names. One of the restrictions of the QuickPlace service is unique Place names. If registration occurs in real-time, then conflict between two Places created with the same name can be avoided immediately. If registration occurs as a scheduled task, then resolution of conflicting Place names requires manual intervention.
While your enterprise can have more than one Place Catalog, your servers should not belong to more than one Place Catalog at a time.
5. Use QPTool to administer your Places
QuickPlace 2.0.8 introduced the Admin Utility to help you administer your Places. Unfortunately, the utility ran only on the Windows NT platform. In release 3.0, the Admin Utility is replaced with QPTool. QPTool is a command-line administration tool that runs on all QuickPlace supported platforms. You use QPTool primarily to administer your servers, but QPTool also helps you to manage your Places.
QPTool is installed automatically after you install or upgrade to release 3.0, so you can use it immediately at the Domino server console, from the program directory, or from a batch file. The following table lists how to run QPTool from different environments and platforms.
| From the | Enter |
| Domino server console | load qptool command arguments |
| Domino program directory (Windows platform) | nqptool command arguments |
| Domino program directory (UNIX platform) | qptool command arguments |
For a full list of QPTool commands and arguments, refer to the QuickPlace 3.0 Administrator's Guide.
Like the Domino server console, QPTool can administer the server on which it runs as well as a cluster of servers. However, it cannot administer remote servers. In a server cluster, any command that you run on a Place is replicated to other Places in the cluster. For instance, if you use QPTool to upgrade a Place on one server in a cluster, the Place replicas will be upgraded as well when replication runs.
If you have a mixed-release environment, which you may have for some time during your upgrade period, use QPTool to administer your release 3.0 servers and continue to use the Admin Utility to administer your previously released servers.
One of the benefits of QPTool is that it can execute an XML file and log output in XML format. QPTool can also generate reports in XML format. When you generate a report, QPTool pulls information about servers and Places from the Place Catalog. QPTool can run a report on Places created in previous releases of QuickPlace as long as you have upgraded the Places. QPTool can generate reports that tell you the Place name, title, and size, which server the Place resides on, when the Place was last accessed or modified, and whether or not a Place is locked. The reports can also tell you server and cluster names and access protocol, TCP port, and URL prefix.
You can use the XML reports as input to execute XML commands. For instance, you can generate a report in QPTool that lists all inactive Places in the last 60 days. You can use this report to determine which Places to remove, delete, or archive. You can remove, delete, or archive a Place by creating an XML file that specifies one of those three actions using the QuickPlace XML API. For more information about the XML API and how to create XML files from it, refer to the QuickPlace 3.0 Application Developer's Guide.
6. Cluster your QuickPlace servers
Cluster support was introduced in release 2.0.8. If you haven't already clustered your QuickPlace servers, do so after upgrading them to release 3.0. Note that QuickPlace 3.0 does not support a mixed-release cluster. Administering a cluster of servers is as easy as administering individual QuickPlace servers, so you will not create more work for yourself or your team if you cluster your QuickPlace servers. Clustering provides high availability, load-balancing, and failover. Here are some things to consider when you plan your cluster.
Supported platform clusters
You can cluster all Windows NT servers together, all AIX servers together, and all Solaris servers together. You can also cluster you Windows NT servers with your AIX or Solaris servers, but you cannot cluster your AIX and Solaris servers together.
Capacity planning
To determine the number of servers you need, you must know the number of concurrent users that can be supported and your cluster type. To help you determine the number of concurrent users, refer to the LDD Today article "Performance perspectives: Comparing QuickPlace 3.0 with QuickPlace 2.0.8."
Types of clusters
Determining the purpose of a cluster can help you plan the cluster. The number of servers in a cluster can vary from two to six, depending on the purpose of the cluster. For instance, if you only want to provide failover, you could cluster only two servers so that if one server fails or needs to be taken offline, the other server is immediately available with no disruption of service. Keep in mind that when you have two clustered servers for failover, the intention is not to spread the load over two servers but to ensure that 100 percent of the maximum concurrent users supported by one server are supported by the second server as well.
If you plan your cluster for load-balancing, then the number of servers that you choose depends on the maximum number of concurrent users you support in the cluster. Generally, this cluster type contains more than two servers. For instance, if you support upwards of 5,000 concurrent users averaging 1,250 users per server, then it would appear that you need four servers. However, if a server should fail or be taken offline, the cluster could only support 3,750 concurrent users instead of the usual 5,000 users. You want to ensure that the cluster can support the maximum number of concurrent users at all times, so rather than cluster four servers, you would want to cluster five or more of them.
The big picture
In addition, don't forget to take into account your hardware and network bandwidth requirements. These requirements can affect your cluster planning. The NotesBench Consortium provides benchmark information about Domino server clusters that can help you determine your network requirements.
7. Set up a Domain Catalog server to implement Search Places
Search Places is a new feature of QuickPlace 3.0. In past releases, your searches were limited to one Place, but with Search Places, you can search across multiple Places in a domain—as long as you are a member of those Places and as long as you are an external user. Search Places requires that users authenticate with an external user directory. External users store their user name and password in a user directory. If an external user is a member of a Place, QuickPlace caches the user's contact information locally in the membership database (Contacts1.nsf). Local users store their user name and password in the membership database of a Place and so cannot be authenticated by an external user directory.
Search Places relies on Domino Domain Search, particularly the Domain Catalog server that indexes the databases in a Domain Search. If you haven't already configured a Domino Catalog server, do so before enabling Search Places. See the Domino 5 Administration Help for instructions on configuring Domain Search. After you configure the Domain Catalog server, install the QuickPlace server on the same machine. It's not recommended that you use the Domain Catalog server to host your Places. Doing so only uses resources that should be used to index the QuickPlaces on other servers in the domain.
If you have only one domain index that includes both Domino databases and QuickPlaces, Domain Search returns search results from QuickPlaces, but Search Places does not returns results from Domain Search. Search Places filters out search results from your Domino databases, but Domain Search cannot filter out Search Places results. If you perform a Domain Search from a Notes client, the search returns results from your QuickPlaces; however, your Notes client cannot access those QuickPlace results. To prevent this situation, you have two options:
- Use two Domain Catalog servers: one for Domain search and one for Search Places (of course, this also means using two separate domain indexes)
- Dedicate a domain for the QuickPlace servers
Which option you choose may depend on your existing environment. For instance, if you already have a separate domain for your QuickPlace servers, then set up a Domain Catalog server for that domain. If you have one domain for both your Domino and QuickPlace servers, you may not want to create a new domain, so instead implement two Domain Catalog servers. Also, consider clustering your Domain Catalog servers to provide failover.
You'll need the qpconfig.xml file to configure Search Places settings. The qpconfig.xml file enables and disables Search Places, allows anonymous users access to Search Places, and specifies a logging level for this feature. The qpconfig.xml file and an example of Search Places enablement are discussed later in this article.
Search Places is available through Advanced Search, a feature that has been enhanced for QuickPlace 3.0. Advanced Search lets you limit your search to a room, folder, or Place as well as expand your search across multiple Places.
8. Integrate with Sametime 3.0
QuickPlace 3.0 supports Sametime 3.0. In past releases, QuickPlace provided limited chat functionality, but it was not as robust as the functionality offered by Sametime. That QuickPlace chat functionality is no longer available in QuickPlace 3.0. Implementing Sametime for your QuickPlaces is optional. The latest Sametime version, release 3.0, is required if you want to integrate Sametime and QuickPlace. If you have an existing Sametime infrastructure, upgrade that infrastructure to Sametime 3.0 before you connect your QuickPlace servers to your Sametime servers.
Like QuickPlace 3.0, Sametime 3.0 requires that you install the Sametime server on top of a Domino server. It's recommended that you do not install your QuickPlace and Sametime servers on the same Domino server, except for testing purposes. (See the earlier section Plan the upgrade of your Places.) It's not necessary for QuickPlace and Sametime to run on the same machine to integrate the two products.
Sametime provides meeting, awareness, and instant messaging functionality in your QuickPlaces. Configure your Sametime servers as described in the Sametime 3.0 documentation. After you configure the servers, you can implement awareness and instant messaging in your Places by specifying the Sametime server names for awareness and meetings in the Administration Place.
Then you can use QuickPlace to set up meetings on your Sametime servers. The awareness feature lets you see who is online from any Place using the standard Sametime status icons. However, the awareness feature does not indicate whether or not the user is in the Place. The awareness feature shows external users only; it does not apply to local users.
Note that some Sametime settings are specified in the qpconfig.xml file.
9. Create a qpconfig.xml file
As you've probably noticed, the qpconfig.xml file is used extensively by QuickPlace 3.0. The qpconfig.xml file is not created automatically. For each QuickPlace server that you want to customize, create an qpconfig.xml file. QuickPlace 3.0 provides a sample XML file (qpconfig_sample.xml). This file contains all examples of all configurable settings. You can copy this file and edit it as necessary. Make sure to put the file in the Domino Data directory. The settings configured in qpconfig.xml are applied when you start the server. If the server cannot locate the file, it resorts to the default settings.
Below are few qpconfig.xml examples that address situations mentioned earlier in this article. These and a number of other settings, including enabling and disabling off-line services and Sametime settings, can be configured with a qpconfig.xml file. The qpconfig.xml file is used to customize your server and Places, and creating and using one is optional. If you choose not to create the file, QuickPlace uses default settings.
LDAP-directory schema mapping
The following example maps person information from an LDAP-compliant directory to QuickPlace:
<server_settings><user_directory><ldap>
<schema>
<user>
<common_name>cn</common_name>
<first_name>givenname</first_name>
<last_name>sn</last_name>
<phone>telephonenumber</phone>
<email>mail</email>
<display_name>cn</display_name>
<object_class_value>person</object_class_value>
</user>
</schema>
</ldap></user_directory></server_settings>
Connecting servers to the Place Catalog
The following example connects a QuickPlace server to the Place Catalog:
<place catalog enabled="true" log_level="0">
<place_catalog_servers>
<server>
<domino_server_name>servername</domino_server_name>
<nsf_filename>PlaceCatalog.nsf</nsf_filename>
</server>
</place_catalog_servers>
</place catalog>
Enabling Search Places
The following example enables Search Places on a QuickPlace server and allows anonymous access to Search Places:
<search_places enabled="true" log_level="0" anonymous="true">
<domain_catalog_server ssl="true">
<domino_server_name>DominoCatalogservername</domino_server_name>
<path_prefix/>
<hostname>server.domain.com</hostname>
<domain_catalog_server>
</search_places>
10. Take advantage of your resources
Few people take the time to read the documentation before installing or implementing a product, but doing so can help you plan your deployment. There are several resources available to help you familiarize yourself with QuickPlace 3.0. This article and others like it in LDD Today can help you get started. Check out the QuickPlace documentation: Administrator's Guide, Developer's Kit, Deployment Guide, and Release Notes for detailed descriptions of each feature and instructions on how to implement them. There is also an IBM Redbook, Deploying QuickPlace, available. Though this Redbook was written prior to the QuickPlace 3.0 release, you may find information that is still valid.
On the Web, check out the following sites:
These sites can provide information or links to additional technical information not only about QuickPlace 3.0, but also about previous releases.
Conclusion
QuickPlace 3.0 is enterprise-ready, so deployment planning for this release differs somewhat from previous releases. Significant changes to installation make the product easy to deploy in a Domino environment, and integration with other Lotus technologies like DOLS and Sametime enhance and extend the QuickPlace collaboration environment. You should familiarize yourself with the new features and technologies so that you can determine which ones you want to implement. |
|