Using the Administrative Tool is recommended due to the filtering mechanisms built into it. If you use Event Viewer to open the Office Communications Server event log, you will, by default, see all the events recorded in that event log. However, suppose you were interested in only a subset of events—for example, suppose you wanted to see only events related to the operation of a Mediation Server. To view a subset of events in Event Viewer, you need to go to the View menu, click Filter, and then create an event filter that prevents the display of any events that do not have an event source equal to Mediation Server.

This is not a hard task, but you will likely find yourself creating filters similar to this each and every time you run Event Viewer, which can get tedious. More important, even this might not give you the information you’re interested in. For example, an Event Viewer filter enables you to select events from only a single event source. Is that a problem? It can be. For example, server applications for Office Communications Server use multiple event sources, including these:

Therefore, the only way to get a comprehensive look at server application events by using Event Viewer is to create at least three different filters, one for each event source. In addition, you’ll have to view the events returned by these filters one at a time: first the Applications Module events, then the Client Version events, and finally the Intelligent IM events. You cannot select multiple event sources when creating an event filter.

In addition, Event Viewer also assumes that you know which three event sources are used for Mediation Server events. If you don’t have this information at hand, you’ll find it difficult to create filters that help you focus on the Mediation Server. And if you have more than one Mediation Server, you’ll need to create another instance of the Event Viewer snap-in to be able to switch back and forth between the event logs for the two computers; Event Viewer can show events from only a single computer at any given time.

By contrast, the Administrative Tool has some intelligent filtering built into it. By default, using the Administrative Tool to access the event log will show you the 10 latest events (regardless of event source or category) recorded for that server. But as you will see, you’re not limited to that default dataset. Nor do you need to run multiple copies of the tool just to view events from multiple computers. For example, suppose you have more than one Mediation Server. All you have to do is click the node for a different Mediation Server. All your servers will appear in the Administrative Tool, and you can easily access the event logs for any of them.

As mentioned earlier, the Administrative Tool, by default, shows the 10 latest events recorded for a server. To see more than just the last 10 events, that default view can easily be changed by expanding Event Log Filter in the right window pane and then using the filter-setting user interface.

The Administrative Tool offers a considerable amount of flexibility in selecting which events will, or will not, be displayed. For example, you can select any (or all) of the standard event types: Information, Warning, and Error. You can limit the returned events to just those records written after a specified date and time, and you can specify the number of events to view up to a maximum of 999.

Perhaps even more important, you can also filter events by event category. It should be noted that the event categories the Administrative Tool uses are different than the event categories Event Viewer uses. If you look at an event log in Event Viewer, you’ll notice that each event source has been assigned a numeric Category value—for example, Office Communications Server has a Category of 1000, and the Office Communications Server Protocol Stack has a Category of 1001. In the Administrative Tool, the Event category typically encompasses multiple event sources and event categories. For example, the Server Applications category found in the Administrative Tool includes such event sources as the Office Communications Server Applications Module (Category 1010), the Office Communications Server Client Version Filter (1041), and the Office Communications Server Intelligent IM Filter (1025). In other words, all the events related to a general category—such as Server Applications—can be viewed at the same time using a single filter. Remember when we said that Event Viewer requires you to write multiple event filters to view events from multiple event sources? The Administrative Tool makes it easier to work around that limitation.

As if that weren’t enough, the events and event categories have also been prefiltered for you based on server role. For example, if you click a server in the Standard Edition Servers node, you will see categories similar to the following (the actual categories will vary depending on the different roles that server plays):

By contrast, clicking on this same server in the Archiving Server node reveals the following categories:

Why so few categories? Because these three are the categories most relevant to the server’s role as an Archiving Server. Other categories (such as IM and Telephony Conferencing) don’t apply to the archiving service and thus do not appear in the Event Categories drop-down list. Therefore, the total number of events that can be viewed from the Event Log tab will also vary depending on server role. For example, on one test computer, viewing the Event Log tab under the Standard Edition Server node revealed 999 events (the maximum number of events that can be viewed in the Administrative Tool). By comparison, this same server listed only 169 events under the Archiving Server node and just 151 under the Monitoring Server node. The difference has to do with the number of events relevant to a given role. And that’s good; after all, if you’re interested in the Monitoring Server, all you really need to see are the 151 events that pertain to the Monitoring Server. The other 848 events in the event log (the ones that the Administrative Tool filters out) just make it harder for you to locate relevant information.

Incidentally, the Administrative Tool has another useful feature: the Expand All Records option. One weakness of the Event Viewer is that events can be displayed only in a spreadsheet-type view; if you want to see the detailed description for an event, you must double-click that event and open the record in a separate window. By contrast, if you select Expand All Records in the Administrative Tool, each event will automatically be expanded to show the event description. This makes it easy to scroll through the list and see the actual reason for each event.

The Administrative Tool provides a quick and easy way to get an overview of the Office Communications Server event log. However, this convenience does come at a small price: Despite its many advantages, the Administrative Tool does have a few limitations when compared to Event Viewer. For one thing, the Administrative Tool is limited to 999 events; if you need to see more than 999 events, you must use Event Viewer. Unlike Event Viewer, the Administrative Tool does not enable you to sort events by fields such as Source or Event ID; instead, you are limited to sorting events chronologically (in either ascending or descending order). In addition, events viewed in the Administrative Tool cannot be saved as a text file or comma-separated values file; that can only be done using Event Viewer.

Scripting—using VBScript, Windows PowerShell, or another Windows scripting language—provides another approach to accessing the events in the Office Communications Server event log. Using the Windows Management Instrumentation (WMI) class Win32_NTLogEvent, administrators can write sophisticated SQL-like queries that make it easy to search the event log for specific events. This information can then easily be exported to a text file, a database, or a spreadsheet. With WMI eventing, administrators can also receive immediate notification any time a particular event (or type of event) is recorded in the event log. For example, you could write a script that alerts you any time an error event is recorded or any time an event with a specified event source is recorded.

A complete explanation of accessing event logs by using scripts lies outside the scope of this chapter. For additional information and for sample scripts, please see the Office Communications Server Tech Center at http://go.microsoft.com/fwlink/?LinkID=133618.