Openfire: Effectively Managing Users

Despite the way it sounds, managing users isn’t an all-involving activity—at least it shouldn’t be. Most system administrators tend to follow the “install-it-forget-it” methodology to running their servers. You can do so with Openfire as well, but with a user-centeric service such as an IM server, keeping track of things isn’t a bad idea. Openfire makes your job easier with its web-based admin interface.

There are several things that you can setup via the web interface that’ll help you manage the users. You can install some plugins that’ll help you run and manage the server more effectively, such as the plugin for importing/exporting users, and dual-benefit plugins such as the search plugin, which help users find other users in the network, and also let you check up on users using the IM service.

In this article, we will cover:

• Searching for users
• Getting email alerts via IM
• Broadcasting messages to all users
• Managing user clients
• Importing/exporting users

Searching for Users with the SearchPlugin

Irrespective of whether you have pre-populated user rosters, letting users find other users on the network is always a good idea. The Search Plugin works both ways—it helps your users find each other, and also helps you, the administrator, to find users and modify their settings if required.

To install the plugin, head over to the Plugins tab (refer to the following screenshot). The Search plugin is automatically installed along with Openfire, and will be listed as a plugin that is already installed. It’s still a good idea to restart the plugin just to make sure that everything’s ok. Locate and click the icon in the Restart column that corresponds to the Search plugin. This should restart the plugin.

The Search plugin has various configurable options, but by default the pluginis deployed with all of its features enabled. So your users can immediately start searching for users.

To tweak the Search plugin options, head over to the Server | Server Settings |Search Service Properties in the Openfire admin interface. From this page, you can enable or disable the service. Once enabled, users will be able to search for other users on the network from their clients. Not all clients have the Search feature but Spark, Exodus, Psi, and some others do.

Even if you disable this plugin, you, the admin, will still be able to search for users from the Openfire admin interface as described in the following section.

In addition to enabling the Search option, you’ll have to name it. The plugin is offered as a network “service” to the users. The Openfire server offers other services and also includes the group chat feature which we will discuss in the Appendix. Calling the search service by its default name, search.< your-domain-name > is a goodidea. You should only change it if you have another service on your network with the same name.

Finally, you’ll have to select the fields users can search on. The three options available are Username, Name, and Email (refer to the previous screenshot). You can enable any of these options, or all the three for a better success rate. Once you’re done with setting up the options, click the Save Properties button to apply them.

To use the plugin, your users will have to use their clients to query the Openfire server and then select the search service from the ones listed. This will present them with a search interface through which they’ll be able to search for their peers(refer to the following screenshot) using one or more of the three options (Username,Name, Email), depending on what you have enabled.

Searching for Users from Within The Admin Interface

So we’ve let our users look for their peers, but how do you, the Openfire admin, look for users? You too can use your client, but it’s better to do it from the interface since you can tweak the user’s settings from there as well. To search for users from within the admin interface, head over to the Users/Groups tab. You’ll notice an AdvancedUser Search option in the sidebar.

When you click on this option, you’ll be presented with a single text field withthree checkboxes (refer to the previous screenshot). In the textfield, enter the user’sName, Username, and Email that you want to find. The plugin can also handle the * wildcard character so that you can search using a part of the user’s details as well.For example, if you want to find a user “James”, but don’t know if his last name isspelled “Allen” or “Allan”, try entering “James A*” in the search field and make sure that the Name checkbox is selected. Another example would be “* Smith”, which looks for all the users with the last name “Smith”.

The search box is case-sensitive.

So why were you looking for “James Allan”, the guy with two first names? It was because his last name is in fact “Allen” and he wants to get it corrected. So you find his record with the plugin and click on his username. This brings up a summary of his properties including his status, the groups he belongs to, when he was registeredon the network, and so on. Find and click the Edit Properties button below the details, make the required changes, and click the Save Properties > button.

Get Email Alerts via IM

Instant Messaging is an alternate line of enterprise communication, along with electronic ones such as email and traditional ones such as the telephone. Some critical tasks require instant notification and nothing beats IM when it comes to time-critical alerts.

For example, most critical server software applications, especially the ones facing outwards on to the Internet, are configured to send an email to the admin in case of an emergency—for example, a break-in attempt, abnormal shutdown, hardware failure, and so on. You can configure Openfire to route these messages to you as an IM, if you’re online. If you’re a startup that only advertises a single [email protected] email address which is read by all seven employees of the company, you can configure Openfire to send IMs to all of you when the VCs come calling!

Setting this up isn’t an issue if you have the necessary settings handy. The email alert service connects to the email server using IMAP and requires the following options:

• Mail Host: The host running the email service. Example: imap.example.com
• Mail Port: The port through which Openfire listens for new email. SSL can also be used if it is enabled on your mail server. Example: 993.
• Server Username: The username of the account you want to monitor.Example: [email protected].
• Server Password: The accounts password.
• Folder: The folder in which Openfire must look for new messages. Typically this will be the “Inbox” but if your server filters email that meet a preset criteria into a particular folder, you need to specify it here.
• Check Frequency: How frequently Openfire should check the account for new email. The default value is 300000 ms which is equal to 5 minutes.
• JID of users to notify: This is where you specify the Openfire Jabber IDs(userids) of the users you want to notify when a new email pops up. If you need to alert multiple users, separate their JID’s with commas.

But first head over to the Plugins tab and install the Email Listener plugin from the list of available plugins. Once you have done this, head back to the Server tab and choose the Email Listener option in the sidebar and enter the settings in the form that pops up (refer to the following screenshot). Click the Test Settings button to allow Openfire to try to connect to the server using the settings provided. If the test is successful, finish off the setup procedure by clicking the Save button to save your settings. If the test fails, check the settings and make sure that the email server is up and running. You can test and hook them with your Gmail account as well.

That’s it. Now close that email client you have running in the background, and let Openfire play secretary, while you write your world domination application!

Broadcasting Messages

Since Openfire is a communication tool, it reserves the coolest tricks in the bag for that purpose. The primary purpose of Openfire remains one-to-one personal interactions and many-to-many group discussion, but it can also be used as a one-to-many broadcasting tool.

This might sound familiar to you. But don’t sweat, I’m not repeating myself. The one-to-many broadcasting we cover in this section is different from the Send Message tool. The Send Message tool from the web-based Openfire administration console is available only to the Openfire administrator. But the plugin we cover in this section has a much broader perspective.

For one, the Broadcast plugin can be used by non-admin users, though of course, you can limit access. Secondly, the Broadcast plugin can be used to send messages to a select group of users which can grow to include everyone in the organization using Openfire.

One use of the broadcast plugin is for sending important reminders. Here are some examples:

• The Chief Accounts Officer broadcasts a message to everyone in the organization reminding them to file their returns by a certain date.
• The CEO broadcasts a message explaining the company’s plans to merge with or acquire another company, or just to share a motivational message.
• You, the Openfire administrator, use the plugin to announce system outages.
• The Sales Department Head is upset because sales targets haven’t been met and calls for a group meeting at 10:00 a.m. on the day after tomorrow and in forms everyone in the Sales department via the plugin.
• The intern in the advertisement department sends a list of his accounts to everyone in the department before returning to college and saves everyone a lot of running around, thanks to the plugin.

Setting up the Plugin

To reap the benefits of the Broadcast plugin, begin by installing it from under theAvailable Plugins list on the Plugins tab. This plugin has a few configuration options which should be set carefully—using a misconfigured broadcast plugin, the new guy in the purchase department could send a message of “Have you seen my stapler?” to everyone in the organization, including the CEO!

The broadcast plugin is configured via the Openfire system properties. Remember these? They are listed under the Server tab’s System Properties option in the sidebar. You’ll have to manually specify the settings using properties (refer to the following screenshot):

• plugin.broadcast.serviceName— This is the name of the broadcast service. By default, the service is called “broadcast”, but you can call it something else, such as “shout”, or “notify”.
• plugin.broadcast.groupMembersAllowed— This property accepts two values—true and false. If you select the “true” option, all group members will be allowed to broadcast messages to all users in the group they belong to. If set to “false”, only group admins can send messages to all members of their groups. The default value is “true”.
• plugin.broadcast.disableGroupPermissions— Like the previous property, this property also accepts either true or false values. By selecting the “true” option, you will allow any user in the network to broadcast messages to any group and vice versa, the “false” option restricts the broadcasting option to group members and admins. The default value of this group is “false”. As you can imagine, if you set this value to “true” and allow anyone to send broadcast messages to a group, you effectively override the restrictive value of the previous setting.
• plugin.broadcast.allowedUsers—Do not forget to set this property! If it is not set, anyone on the network can send a message to everyone else on the network. There are a only a few people you’d want to have the ability to broadcast a message to everyone in the organization. This list of users who can talk to everyone should be specified with this property by a string of comma-separated JIDs.

In most cases, the default options of these properties should suffice. If you don’t change any variables, your service will be called “broadcast” and will allow group members to broadcast messages to their own groups and not to anyone else. You should also add the JIDs of executive members of the company (CEO, MD, etc.) to the list of users allowed to send messages to everyone in the organization.

Using The Plugin

Once you have configured the plugin, you’ll have to instruct users on how to use the plugin according to the configuration. To send a message using the broadcast plugin, users must add a user with the JID in the following format @. (refer to the following screenshot).

If the CEO wants to send a message to everyone, he has to send it to a user called [email protected], assuming that you kept the default settings, and that your Openfire server is called serverfoo. Similarly, when members of the sales department want to communicate with their departmental collegues, they have to send the message to [email protected].

Managing User Clients

There’s no dearth of IM clients. It’s said that if you have ten users on your network, you’ll have at least fifteen different clients. Managing user’s clients is like bringing order to chaos. In this regard you’ll find that Openfire is biased towards its own IMclient, Spark. But as it has all the features you’d expect from an IM client and runs on multiple platforms as well, one really can’t complain.

So what can you control using the client control features? Here’s a snapshot:

1. Don’t like users transferring files? Turn it off, irrespective of the IM client.
2. Don’t like users experimenting with clients? Restrict their options
3. Don’t want to manually install Spark on each and every user’s desktop? Put it on the network, and send them an email with a link, along with installation and sign-in instructions.
4. Do users keep forgetting the intranet website address? Add it as a bookmark in their clients.
5. Don’t let users bug you all the time asking for the always-on “hang-out”conference room. Add it as a bookmark to their client!

Don’t these features sound as if they can take some of the work off your shoulders? Sure, but you’ll only truly realize how cool and useful they are when you implement them! So what are you waiting for? Head over to the Plugins tab and install the Client Control plugin. When it is installed, head over to the Server | ClientManagement tab. Here you’ll notice several options.

The first option under client management, Client Features, lets you enable or disable certain client features (refer to the following screenshot). These are:

1. Broadcasting: If you don’t want your users to broadcast messages, disable this feature. This applies only to Spark.
2. File Transfer: Disabling this feature will stop your users from sharing files.This applies to all IM clients.
3. Avatar/VCard: You can turn off indiscriminate changes to a user’s avatar or virtual visiting card by disabling this experimental feature which only applies to Spark.
4. Group Chat: Don’t want users to join group chat rooms? Then disable this feature which will prevent all the users from joining discussion groups, irrespective of the IM client they are using.

By default, all of these features are enabled. When you’ve made changes as per your requirements, remember to save the settings using the Save Settings button.

Next, head over to the Permitted Clients option (refer to the following screenshot) to restrict the clients that users can employ. By default, Openfire allows all XMPPclients to connect to the server. If you want to run a tight ship, you can decide to limit the number of clients allowed by selecting the Specify Clients option button. From the nine clients listed for the three platforms supported by Openfire (Windows,Linux, and Mac), choose the clients you trust by selecting the checkbox next to them.If your client isn’t listed, use the Add Other Client text box to add that client. When you’ve made your choices, click on the Save Settings button to save and implement the client control settings.

The manually-added clients are automatically added to the list of allowed clients. If you don’t trust them, why add them? The remove link next to these clients will remove them from the list of clients you trust.