When you install Chat Service, a chat community named Default-Chat-Community is automatically created for the First Administrative group. You can rename the community if necessary, and you can also create additional chat communities under other administrative groups.
To create a chat community, start the Exchange System snap-in, right-click Chat Communities, point to New, and then choose Chat Community. As you can see in Figure 18-5, you can modify several important properties.
Figure 18-5. General tab of a chat community's property sheet.
On the General tab, name the new community. Remember that the name must not contain any spaces or end in a number. The title of the community should be short yet descriptive. The title appears in the tab heading in the client chat window and is a friendly name for the chat community. It is limited to 63 characters. The topic of a specific channel within the community can be longer, indicating more fully what the chat discussion is about. The topic is available to chat clients if they look at the room properties.
You can also set your connection limits on this tab. Be sure that the value set for Maximum Anonymous Connections is less than the one for Maximum Total Connections. The default for both is 10,000, and the range for both is 0 to 99,999,999.
Finally, you can specify whether you want client DNS names resolved. This can be considered a security measure. In the drop-down list, you can choose between Disable, Attempt, and Require. Selecting Disable directs the server not to attempt IP-to-host-name resolution of the chat client. This is the least secure option, especially if the community is available to clients on the Internet.
The Attempt selection directs the server to try host-name-to-IP resolution. If a valid DNS name is returned, the server allows the client to connect to the chat community.
Finally, the Require selection directs the server to look up and resolve the IP address of an incoming chat client. If no valid DNS name is returned, the client connection is refused. This is the most secure option.
Figure 18-6 shows the Channels tab. Use this tab to configure channel defaults and to allow dynamic channels for a chat community. The Language field identifies the default language for the chat community. Use the language codes specified in International Standards Organization (ISO) 639. If needed, you can also include the ISO 3166 country code. The entry is limited to 31 lowercase characters.
When selected, the Allow An Owner Or Host For Channel check box permits any user who creates a persistent or dynamic channel to become the channel owner or host.
The Number Of Users Allowed In Channel field allows you to set the maximum number of users allowed on any dynamic channel in the chat community. The default is 25. The value must be between 0 and 99,999. A value of 0 permits unlimited membership in the channel.
The Chat Sysop Joins As Owner check box grants owner status to chat users with sysop permissions when they join a dynamic channel. Registered channels are not affected by this setting.
Figure 18-6. Channels tab of a chat community's property sheet.
On the Messages tab (Figure 18-7), you can specify a message of the day or a message to be displayed to users who issue the Admin command. The latter message should display information about the server.
Figure 18-7. Messages tab of a chat community's property sheet.
The Authentication tab is used to configure the authentication methods for the chat community. These methods use Active Directory security features for all user accounts.
The next step in creating a chat community is to connect the chat community to a server. In the Exchange System snap-in, navigate to the IRCX container under the server object that will host the chat community, right-click IRCX, and choose Properties. On the property sheet (Figure 18-8), click Add. In the Add Community list, select the name of the chat community you want added to the server. Select the Enable Server To Host This Chat Community option. In the IP Address field, be sure to enter a unique IP address for each community. The default TCP port is 6667.
Figure 18-8. Connecting a chat community to a server.
Each chat community will need at least one channel through which chat conversations can occur. You can create secure and/or cloneable channels. (For a discussion of these concepts, please see the section "Channels," earlier in this chapter.)
To create a new channel, open the Exchange System snap-in, right-click the Channels container under the chat community, point to New, and then choose Channel. The property sheet for the new channel appears. On the General tab (Figure 18-9), you will need to name the channel and enter the topic, the subject (if needed), and the content rating of the channel.
By selecting the Create This Channel When The Service Starts check box, you will ensure that the channel is always available when Chat Service is running. If this box is not selected, the channel will become visible only when someone joins it.
MORE INFO
For more information about content ratings and the Platform for Internet Content Selection (PICS), please go to http://www.w3.org.
Figure 18-9. General tab of the property sheet for a new channel.
A channel name can contain between 1 and 200 characters. If the channel is cloneable, avoid ending the name with a number to prevent name conflicts with cloned channels.
NOTE
If the chat client supports the IRCX protocol, the channel name can include double-byte character set (DBCS) characters. Names made up of DBCS characters are limited to 100 characters.
Each channel name must begin with a valid prefix (#, &, %#, or %&). A prefix consists of one or two characters that identify the type of channel:
NOTE
IRCX supports the use of Unicode characters encoded in UTF-8. Because Unicode provides an extended character set, users running an IRCX-compatible client can participate in chat sessions in any language.
You can configure four channel modes on the Access tab (Figure 18-10). These modes control a channel's visibility to users. They are as follows:
Figure 18-10. Access tab of the property sheet for a new channel.
You can configure additional channel modes on the Modes tab (Figure 18-11). Among the settings you can configure are the following:
Figure 18-11. Modes tab of the property sheet for a new channel.
Access to a channel can also be limited to invited users or to authenticated users. These settings allow for a persistent yet private channel that is available when needed.
On the Extensions tab, you can employ a profanity filter on a channel to block objectionable language during the chat. If a profanity filter is not listed on this tab, no words will be banned in conversations on this channel. This filter can ban words in all messages, including whispers and invitations on both dynamic and registered channels. At the server level, you can also apply individual filters to private messages, invitations, quit messages, part messages, channel names, and nicknames.
To use the profanity filter, you must first create a list of restricted words. After creating this list, you can apply the filter to an individual registered channel or you can filter conversations on all of the dynamic channels in the chat community. When a message is sent that contains a filtered word, the entire message is blocked and a private message is sent to the channel member who sent the message, warning that an offensive word was used and requesting that the word not be used again. To create a list of restricted words, perform these steps:
As Figure 18-12 shows, you can create additional filters and then apply them to various types of chat communications. This gives you flexibility as to which filters are applied to which kind of chat communication. In the figure, we have set up an obscenities filter for private messages, a crude filter for channel names, and a slang filter for nicknames. The default filter applies to all dynamic channels.
Of course, you can set up multiple filters for different kinds of languages and different groups. For example, you might set up one filter for the entire company listing certain kinds of words, such as obscenities, for all types of chat messages. A second filter could be set up just for nicknames. The point here is that each filter has a different word list, so anytime you need to apply a different word list to messages in your chat network, you'll need a different filter.
Figure 18-12. Chat filter properties for different chat groups.
Chat Service has a transcription extension that will transcribe conversations that occur on one or more registered channels and then save these transcriptions to a directory named after the community. Each transcript file is saved to a folder with the same name as the channel.
Each transcript file contains all messages sent publicly to a channel within a 24-hour period (12:00 a.m. to 11:59 p.m.). Because some characters allowed in channel names are not allowed in directory names, characters are replaced as shown in Table 18-4. Figure 18-13 shows part of a typical transcript.
Table 18-4. Characters replaced during chat transcription
Character | Replaced With |
---|---|
\ (backslash) | ~1 |
. (period) | ~2 |
(quotation mark) | ~3 |
/ (slash) | ~4 |
[ (open bracket) | ~5 |
] (close bracket) | ~6 |
: (colon) | ~7 |
; (semicolon) | ~8 |
= (equal sign) | ~9 |
, (comma) | ~10 |
~ (tilde) | ~~ |
Figure 18-13. Example of a chat transcript.
To set up transcription for a chat community, add the Tscript extension to the community, in the same manner as described for the profanity filter in the previous section.
When a user first joins a channel that has transcription enabled, the user is informed of that fact immediately upon entering the chat room (Figure 18-14). By default, the transcripts are placed in the C:\Exchsrvr\Chatdata\Transcript folder. You can change the location of your transcripts in the channel transcript extension properties. Once you've made the change, you must stop and restart the Microsoft Exchange Chat Service before the new configuration will take effect. Also by default, only public messages are transcribed.
Figure 18-14. Message indicating that transcription has been enabled.
Although it is beyond the scope of this book to offer an exhaustive review of all of the counters for Chat Service, several are noteworthy. Tables 18-5 and 18-6 indicate which objects and counters you should employ to monitor different aspects of your Chat server. Be sure to set up capacity and performance logging at the same time so that you can analyze both sets of data simultaneously.
In the two tables, you'll notice that we rarely give numeric benchmarks against which to judge your numbers. Instead, you should establish your own baselines by regularly monitoring these counters on your servers. For instance, you might want to schedule monitoring for the second Monday through Wednesday of every month. Doing so will enable you to judge what values are high for each counter.
Table 18-5. Monitoring physical resource capacity
Counter | Description |
---|---|
% Processor Time (Processor object) | This counter should not exceed 90 percent. It measures the percentage of time that the CPU is engaged in processing nonidle threads. Chat Service is CPU intensive, and excessive usage indicates an attack on the server or a need for additional hardware. Compare this counter with other counters discussed here and in Table 18-6. |
Available Bytes (Memory object) | This counter shows the amount of physical memory available to processes running on the server. If less than 10 percent of the memory is available, it can indicate excessive processing, a software error, or a need for additional RAM. |
Table 18-6. Monitoring Chat Service
Counter | Description |
---|---|
Authentication Failures (Microsoft Exchange Chat Community object) | This counter shows the total number of failed authentication attempts by users trying to connect to the Chat server. A high number may indicate an attempt to breach security on your server. |
Active DNS Logon Threads (Microsoft Exchange Chat Service object) | This counter shows the total number of worker threads waiting to process DNS lookup requests. A high number may indicate a DNS server failure. |
Client Timeout Related Disconnects (Microsoft Exchange Chat Service object) | This counter indicates the total number of clients disconnected because of a PING timeout. A high number may indicate a network lag or a client computer malfunction. |
You can remove a chat community from a server in one of three ways. The method you choose will depend on the outcome you desire. All three methods will disconnect current users from the chat community.
If you want to remove a chat community's association with a server, remove the chat community from the IRCX property sheet by selecting it and clicking Remove, as shown in Figure 18-15. If you want to disable a chat community temporarily, retaining the community's association with the server and also retaining the community and its configuration for future use, clear the Enable Server To Host This Chat Community check box in the property sheet for the chat community. Finally, if you want to remove a chat community entirely from a server, delete it from the chat community's container.
Figure 18-15. Removing a chat community from the IRCX property sheet.
There may be times when you want to disable a particular community without deleting it. You can do this by clearing the Accept New Connections check box, as illustrated in Figure 18-16. You can put the community back into service again by selecting this box. This process is dynamic and does not require stopping and starting Chat Service.
Figure 18-16. Disabling a chat community by clearing the Accept New Connections check box.