If you would like to read the other parts in this article series please go to:
- How Longhorn Server’s Server Manager will Change Server Management (Part 1)
- How Longhorn Server’s Server Manager will Change Server Management (Part 3)
In Part 1 of this article series, I talked about some of the ways that the Server Manager could be used to manage roles on a Longhorn Server. In this article, I want to continue the discussion by talking about how the Server Manager can be used as a troubleshooting tool.
If you expand the Server Manager’s Troubleshooting container, you will see that it is divided into three primary sub-containers, as shown in Figure A. These sub-containers include Event Viewer, Services, and Performance Diagnostics.
Figure A: The Troubleshooting section includes containers for the Event Viewer, Services, and Performance Diagnostics
At first it probably appears that there is nothing new here and that these various tools are left over from previous versions of Windows Server. Although each of these essential tools certainly existed in previous Windows Server versions, Microsoft has made some enhancements to them that I think that you will be very interested in.
The Event Viewer
If you have worked with Windows Server products for a while, then you know that the Event Viewer has remained largely unchanged since the days of Windows NT. It seems that Microsoft has finally seen fit to redesign the Event Viewer. When you click on the Event Viewer container, you will see the screen that’s shown in Figure B.
Figure B: You can now see a summary of events across the server
As you can see, the Event Viewer now gives you an aggregate view of events across the server. Previously, events were separated into individual event logs. For example, if there was an error that showed up in the Application log, you would never even know about it unless you went to that specific log file. The Application, System, and Security logs still exist, but this initial screen is designed to give you a consolidated view of the overall health of your server from an event point of view.
You can expand the various containers and see individual events. For example, if you look at Figure C, you will see that I have expanded the Error container. The Event Viewer is showing me all of the error events. Notice that the Log column shows which log the event is actually logged in. Another thing worth noting is the Last Hour and the Last 24 Hours columns. These columns tell you how many times each event has happened in the last hour and in the last 24 hours.
Figure C: This is a consolidated view of all of the errors from the various log files
If you expand the Event Viewer container and then expand the Windows Logs container, you will see something that looks a lot more familiar. As you can see in Figure D, the Application, Security, and System event logs still exist and the events within those logs are still presented in the usual format.
Figure D: The Application, Security, and System event logs still exist and the events within those logs are still presented in the usual format
If you look closely at Figure D, you will see that Microsoft has added two new event logs to the list. These two new event logs are the Setup log and the Forwarded Events log. The Setup log contains information regarding changes to the way that the system is configured. For example, if you were to promote the server to a domain controller or add the DNS server role, these types of configuration changes would be logged to the Setup log. Don’t expect the Setup log to give you detailed information of these types of configuration changes. Instead you will simply see an event telling you that a role has been added.
The Forwarded Events log needs a bit more explaining. The idea behind the Forwarded Events log is that it can contain event log entries from another system. Longhorn Server is still in beta testing and I have not actually been able to get the Forwarded Events log to work correctly on my test network yet. What I can tell you, is that the configuration process involves creating a subscription to an event log on another system, filtering the event log that you have subscribed to so that only the desired events are shown, and placing those events into the Forwarded Events container.
Applications and Services Logs
The next thing that I want to show you is the Applications and Services Logs. The logs that I talked about in the previous section are general in nature. For example, just about any event related to the Windows operating system would end up in the System log. In the past, if you wanted to get more specific information then you just had to dig through the event logs and search for events related to the particular issue that you were trying to troubleshoot.
Longhorn Server now categorizes and sorts events. For example, if you wanted to see all of the events related to the Active Directory, you could simply look at the Directory Service log, shown in Figure E.
Figure E: The Applications and Services logs categorize the various system Events
You will notice in the figure that there are only five logs shown in the Applications and Services section. One thing to keep in mind is that this collection of logs changes as roles are added to or removed from the server. For example, the server that I am using in my screen captures is running the Domain Controller and the DNS Server roles, hence the Directory Service and DNS Server logs.
If you look at the bottom of the list, you will notice a container named Microsoft. If you expand this container, you can see information related to individual Windows components. In Figure F, I have the Group Policy log selected, but as you can see, there are lots of other logs available to you.
Figure F: Longhorn Server maintains logs of individual Windows components
The last thing that I want to show you is the new Custom Views feature. As you have seen, Longhorn logs a tremendous amount of information related to various Windows components, applications, and security. Although the new Event Viewer interface makes it a lot easier to drill down to the event information that you need, there is still a chance that you may need to analyze some subset of event information for which the Event Viewer does not provide a pre-defined view.
This is where the Custom Views container comes into play. The Custom Views container is designed to allow you to view event log information based on dynamic queries. You can create a custom view by right clicking on the Custom Views container and selecting the Create Custom View option from the resulting shortcut menu. When you do, you will see the Create Custom View dialog box that’s shown in Figure G.
Figure G: The Create Custom View dialog box allows you to create query based event log views
In all honesty, I could probably write an entire article on this one dialog box. For now, I just want to point out some of the highlights. You can see the check boxes that allow you to select the types of events that you want to view (warnings, errors, etc.). Just below the Event Level check boxes is an Event Log drop down list.
As you might expect, the Event Log drop down list allows you to select which event logs you want to view information from. What’s unusual about this is that a drop down list usually only allows you to select a single option. This particular drop down list is actually a combination drop down list and group of check boxes. What this means is that you are able to select any combination of event logs that you want.
Further down the dialog box you have the option of filtering by Event ID, category, keyword, user, or computer. These types of filters are especially useful for searching through massive security logs. For example, if there was a particular user that you suspected of malicious behavior, you could create a filter that shows you any security event log entry related to activity from that user.
In this article, I have shown you that the Event Viewer has been completely redesigned. Microsoft has completely rewritten the Event Viewer to make it easier to use and to make it possible to look at events across an entire system rather than just the events contained within a single event log.
In Part 3, I will continue my discussion of the Server Manager’s troubleshooting capabilities by discussing the Service Control Manager and the Performance Diagnostics tool.
If you would like to read the other parts in this article series please go to: