Why UAC Is Good, after All


New Event Viewer

Here's a good surprise: the Event Viewer has had a complete reengineering. The new Event Viewer:

  • Can collect events from many systems to one system's log, allowing you to centralize event logs.

  • Lets you easily tell it what to do if particular events occur, like telling it to send you an e-mail, run a program, reboot a system, or the like.

  • Allows you to create custom queries so you can essentially tweak Event Viewer to show you just the things that you want to see.

  • Event Viewer Reports its data in XML.

It's beyond the scope of this book to go into Event Viewer in detail, but I'd like to show you a bit of what I think you'll like about the new Viewer, in ascending order of importance from my point of view. But before we go any further, let me show you how to start Event Viewer. As with all Windows things, there are several ways.

  • If you reenabled the Start image from book Run command as I suggested earlier in this chapter, just click Start/Run and then fill in eventvwr and click OK.

  • If you restored Administrative Tools to your Start menu, then just click Start image from book Administrative Tools image from book Event Viewer.

  • Alternatively you'll need to do a little spelunking in Control Panel: click Start image from book Control Panel image from book System and Maintenance and, under "Administrative Tools," click "View event logs."

As some have observed, "Vista: it's everyone's 10 favorite user interfaces."

XML Format Comes to Event Viewer

Woo, hoo, XML! Wait, wait, don't flip the page

Yes, I know, you've heard the abbreviation "XML" far too often, but here's a case where you'll like it. Let's take an example event, a simple security event that reports that the system's time was successfully changed. The event looks graphically like Figure 1.9.

image from book
Figure 1.9: Typical Vista event

This is an event generated in the Security log because I've just logged on with a username of "Mark." You'll note at first that Event Viewer presents the event in a different format than the one that we've seen since NT 3.1. Notice that there's a button that's actually labeled "Copy" instead of hoping that you just somehow know that the button on the XP Event Viewer that looks like two pieces of paper means "click this and the relevant stuff from this event will be copied in ASCII text format to the Clipboard."

You can't see it because the text in the box is pretty big and scrolled out of the visual part of the box, but here's some of it:

 This event is generated when a logon session is created. It is generated on the computer that was accessed. The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network). The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on... 

I've looked at "logon type" in logon events in Windows for years and never bothered to look up what a "logon type" is. In contrast, Vista tells me. I didn't copy all of the information from the message, but it goes on to explain what a logon GUID, package name, and bunch of otherwise-cryptic stuff was. Very nice. In another event, one reporting that the system time changed, the explanatory text goes on to basically say "look, system time updates happen normally, so you can probably ignore it. But there are reasons why bad guys might try to change a system time."

If you click the Copy button and paste the results into Notepad, you get a lot of information. It starts off looking like event logs have always looked, telling you where the event came from, its ID and so on. Then it starts with a bunch of XML, which, shortened a bit, looks like

      <Data Name="TargetUserSid">S-1-5-21 …-1000</Data>      <Data Name="TargetUserName">mark</Data>      <Data Name="TargetDomainName">VISTA64</Data>      <Data Name="TargetLogonId">0x20788</Data>      <Data Name="LogonType">2</Data>      <Data Name="LogonProcessName">User32 </Data> 

What's this mess? It's all of the pieces of data specific to this particular event log entry. Now, event log items have always kept this kind of information, but it hasn't been very useful for two reasons. First, it's been hard to export this kind of data out of the event logs for use in scripts or other homegrown tools that might increase the value of the data in the event logs, and, second, it's hard to know what the data means. You can fairly easily write a script that grabs "data item 1," "data item 2," "data item 3," and so on from a given event, but what is data item 1? Well, it depends on what particular event you're looking at. But not with Vista. By storing the data in XML and making that data easy to get to from scripts or even right from the Event Viewer-you can right-click any log in Vista and choose "Save events as," and you're offered to save the files as either text files, XML files, or comma separated variable files-then not only can you get to the data, but the data identifies itself. That's the beauty of XML; the line

 <Data Name="TargetUserName">mark</Data> 

is XML-ese for "there's a piece of data in this event named the ‘TargetUserName,' and the value of that data in this case is ‘mark.'" But you needn't export the data to look at it; you can always click the Details view in any given event log entry to see something like Figure 1.10.

image from book
Figure 1.10: An event log entry's details

A moment's glance will show you, I guarantee you, that this will be a jumping-off point for a lot of neat event log management tools. But this was the least interesting of the three things that I wanted to cover about Event Viewer; let's move on to the next one.

Custom Queries Lets You Customize Event Viewer

It's always been possible to filter items in Event Viewer in a simple way by right-clicking in the Event Log, choosing New Log View, and then adjusting its filter properties. But Vista's Event Viewer takes it a bit further. To see how, take a look at the Event Viewer when started up in Figure 1.11.

image from book
Figure 1.11: The Event Viewer

Like the old Event Viewer, you get a pane down the left-hand side listing the logs that you can peruse. But instead of the standard Application, System and Security, Vista's Event Viewer fine-tunes your events into dozens of smaller "sub-logs." You can see in its right-hand pane a summary of entries and, you'll note, there are more levels of event than Information, Warning, Error, Audit Success, and Audit Failure; now there's also Critical. But look in the upper left-hand corner and you'll notice a folder called "Custom Views" and, inside that, a folder named "Administrative Events."

I didn't create that, it was already built in Vista. It collects all of the events from all logs that are Critical, Error, or Warning. In short, it's one-stop-shopping for keeping an eye on what's broken. But what if we wanted the "auugh! log," a collection of just the Critical stuff? Simplicity itself. Just right-click the Custom Views folder and choose "Create custom view…" and you'll see a dialog like the one in Figure 1.12.

image from book
Figure 1.12: Creating a custom view in Vista's Event Viewer

With this dialog, it's simple to see how Microsoft prebuilt the "Administrative Events" log. To create a "Criticals only" log, I'd change the dialog like so:

  • Leave "Logged:" as "Any time;" this means to show any events in the log. (Remember that by default Windows only keeps as many events as it has storage to hold.)

  • In "Event level:," check only "Critical."

  • Choose the radio button between "Event log:" and "By log," and click the drop-down box to the right of them. Check the boxes next to "Windows Logs" and "Applications and Services Logs" to choose all logs.

  • Click OK and when you get the dialog that says that this might be a bit slow and are you sure, click "Yes." You'll see a dialog like Figure 1.13.

image from book
Figure 1.13: Name your new custom view

Here, I've filled in "Criticals Only" in the Name: field, and "Shows critical events for all administrative logs" in the Description: field. Click OK and you'll see the new view. And by the way, that's not a silly example. After running just a few days, my Vista system has generated tons of event log entries of varying levels of importance. But the "Criticals Only" log has just a dozen events in it, and they were all interesting. (My favorite was a message telling me that a particular program was "slowing down the Windows Shell," presumably meaning that shutting off this badly written program, whatever its name was, would make things faster. The program? Explorer.exe. Who says programmers lack senses of humor?)

Once you've created your ideal custom view, it's easy to back it up or spread it around. Just right-click it and export it. And guess what kind of file it creates? Yup, you got it: XML. (Perhaps they should have named Vista "Windows XML?" Then it would have sounded more like an upgrade from "XP.")

Generating Actions from Events

XP and 2003 brought a really nice feature called "event triggers." The idea was that you could use a command-line tool called "eventtriggers.exe" to instruct the Event Log service that if a particular kind of event occurred then the Event Log service would start the application of your choosing. Not many people seemed to discover it, but I wrote about it in a few magazine articles and suggested that you could build a pretty neat system for alerting you to problems in the network. There were three ingredients:

  • You'd need a cell phone that could receive text messages via e-mail. For example, my cell carrier is Verizon Wireless, and you can send an SMS text message to any Verizon cell phone by sending e-mail to cellphonenumber@vtext.com.

  • You need a program that can send simple e-mails from the command line. There's a free one called "blat" at http://www.blat.org.

  • You need XP or 2003, as they support event triggers.

I put this all together by suggesting that if there were particular events that you were concerned about-say, an account lockout happened-then you could use eventtriggers.exe to tell the Event Log service, “if an account lockout happens, run such-and-such blat command line to send me an alert on my phone as a text message. It worked pretty nicely but was, admittedly, cumbersome. So the new "Attach task to event…" option is a real blessing.

To see this in action, open up the Application log and look at the events in it. If this is your first look into Vista's Event Viewer, look in the folder "Windows Logs"-it's probably already open, if not then open it-and notice that these logs bear the familiar names of Application, Security, and System, as well as two new ones named "Setup" and "ForwardedEvents." Click the Application folder in the left-hand pane and in the right-hand pane (I always close the Action pane because I think you'd need a computer with a screen that isn't just in "landscape" mode, you'd need one in "panoramic mode" in order to make use of MMC 3.0's three panes) you'll see the events in that log.

Right-click any one of them and you'll see in the resulting context menu that you've got a new option, "Attach Task To This Event…;" click that, and you'll see a wizard page like the one in Figure 1.14.

image from book
Figure 1.14: Starting the Create Basic Task Wizard

Why a wizard? Well, as it turns out, Vista's Event Viewer offers you several options on how to respond. (They even simplified setting up my suggestion about e-mailing admins when an event occurs, as you'll see.) Click Next to see a figure like Figure 1.15.

image from book
Figure 1.15: Event Viewer offers three kinds of responses.

First, as with eventtriggers.exe, you can specify any given application. Or you can send an e-mail, or display a message on the server's desktop. I'll consider all three options in a moment, but for now, I'll click the radio button next to "Send an e-mail" and then Next to see something like Figure 1.16.

image from book
Figure 1.16: Setting up an e-mail notification

This page looks very much as you'd expect, allowing you to punch in a from address, to address, subject, and text. It even lets you add an attachment, which is a nice touch, and specify the name of the SMTP server to use to send the e-mail.

Warning 

Be sure to configure the SMTP server to accept e-mails from this server, or you'll never get an alert via e-mail. All well-configured SMTP servers nowadays have strict rules restricting SMTP relaying and would probably reject the e-mail that the Event Log service tried to send to the SMTP server. And setting up random extra SMTP servers without all of those strict rules is a really bad idea, as it's one way that spammers send all of that junk but don't get caught.

If I click Next, I get a summary screen like the one in Figure 1.17.

image from book
Figure 1.17: Summarizing the trigger

This is a nice summary of what's going to happen once I click Finish, although truthfully it's not necessary. An administrator can always modify or delete an event task, as you'd expect. Ah, but where you modify or delete that event task, that'll surprise you. When I click Finish, I get the message box in Figure 1.18.

image from book
Figure 1.18: Changes? Off to the Task Scheduler

This seems like a bad idea to me. Vista's user interface does a fairly decent job of providing what Microsoft has come to like calling "discoverability," which is their recently coined term for "a user interface that makes figuring out what you can do with a GUI program easier." So here you've created an event task in the Event Viewer; you'd think that you could modify or delete it in the Event Viewer. But no, instead Microsoft's got you going to the Task Scheduler to do that.

Telling the Event Log Service to Display Messages

I highlighted sending a piece of mail, but Vista's Event Viewer offers a couple of other options as well, as you may recall from Figure 1.17. The "Start a program" option is pretty straightforward, so I needn't really discuss that, given that I'm not covering this in minute detail, but I wanted to talk about the last option: "Display a message." On its face, it's pretty simple; it just asks you what text to display. When the corresponding event occurs, the Event Log service just pops up a message box with whatever text you specified. But the fact that the option existed puzzled me, at first. What real good did this offer? But then it hit me.

You see, ever since I started with NT, I've always had a bit of trouble getting used to the "chatter level" that NT offers. I'd spent years working with various microcomputer operating systems designed with the point of view that well, heck, if they're having a problem, no matter how small, then they want you to know about it, and now with at minimum a message box and at maximum a "system modal dialog," one of those big annoying things that can't be resized or minimized. And, in fact, some of Windows' behavior is still like that, but in an uneven fashion. If a document doesn't print, then you get a big can't-miss-it pop-up in the system tray to that effect. Windows applications are just as bad as Windows itself, and I offer Adobe Acrobat Reader as Exhibit A. When Adobe Reader decides that you're gonna get an update, then while you're getting it, Reader puts this huge dialog box on your screen with status information, a dialog box without a "minimize" button.

But what's always puzzled me about Windows' "chatter level" is that there are things that it doesn't say a blessed thing about, but that might be useful. For example, I had a workstation a few years ago whose hard drive failed. I got it running long enough to get what I needed off of it and, as I waited for the files to copy, I noticed that the Event Viewer had been logging disk failures for weeks. "You'd think that might merit a pop-up box," I grumbled to myself. There are, similarly, a handful of Active Directory events that are downright scary, things that portend long-term unhappiness if not seen to posthaste, but does AD pop up a dire warning message? No, instead AD just quietly issues an event, sort of like an unhappy employee petulantly writing memos "to the record" to cover his backside when his company turns out to be the next Enron-"I told them so," he anticipates saying with disguised glee. (Okay, in reality I imagine that the AD coders assume-probably correctly-that, again, most domain controllers don't have people sitting and watching the DC's desktops all the day long.)

Okay, so why is Windows so schizophrenic about what it shouts and what it whispers? Simple: it's not like there's a central User Interface Message Approval Board at Microsoft. If Janet's working on the file sharing client and Peter's working on the shell hardware detection module (the thing that pops up a box asking you what to do every time you plug a USB device into your computer), then Janet gets to control the degree of shrillness or demureness the file sharing client displays to the user, and Peter likewise can dial up or down the hysteria level of the warnings and errors that the shell hardware detection module displays. (In my opinion Peter needs to consider more decaf, as the fireworks that start every time a USB stick drive is plugged into a system is a bit overmuch.)

The cool thing about the "Display a message" option is that it lets you increase Windows' hysteria level about any event or events that you choose. Never again will I miss a disk error that formerly would have secreted itself in the logs and, when Server 2007 comes out with the same Event Viewer, never again will I pass over a message to the effect that a particular domain controller hasn't talked to the rest of the family for a few weeks.

Forwarding Events from One Computer to Another

I imagine that I needn't explain my reasoning in saying that my number one favorite new Event Viewer feature will probably be everyone else's favorite new Event Viewer feature: event forwarding. It's always been true that NT systems have had event logs, and that those event logs are completely decentralized: if you've got 500 XP boxes that someone's been trying to hack and you want to look at all of the failed logon attempts for all of those 500 boxeswhat do you do?

Well, you could walk around to 500 systems, or buy a third-party tool, or use a serviceable and nicely priced-free-but slightly rough-edged tool called eventcombmt. It's sort of amazing, but after 13 years of NT, we still don't have a built-in method of centralizing events from the event logs of scattered machines. Unless, of course, you've got Vista. It offers something called "event forwarding" that lets you collect events from other Vista systems to one single system. Just tell all of those 500 systems to report logon failure events to one of their own, and then all you need do is to sit down at that system, open up a folder called "ForwardedEvents," and it's all in one place.

So is it just Vista talking to Vista? I attended a briefing where a program manager for Vista's Event Viewer said that he thought it very likely that they'd have modules that you could add to earlier versions of Windows (I'm guessing XP and 2003) that would make it possible for a Vista system to collect events from those older OSes, so the answer seems to be "right now yes, it's just Vista, but there's a chance that earlier Windows may get event forwarders." But don't hold your breath. Back in 2002, Microsoft promised a free tool that would collect all of the Security events from 2000, XP, and 2003 systems into a centralized SQL Server. When they finally finished in late 2005, they said "oh, we changed our minds," and stuck it into Microsoft Operations Manager, which you probably know is most definitely not free.

Subscription Overview

Another Microsoft phrase for event forwarding is "subscription"-one computer "subscribes" to events from other computers. Here's basically how it works, in Microsoft "subscription terminology."

  • In a subscription, you designate one Vista system to collect events from one or more other computers.

  • That system is called the collector.

  • The systems from which the collector gets events are called the source computers.

Once you set up a subscription, the collector then polls the sources every 15 minutes or so for new events. By default, those events go into a folder called "ForwardedEvents" but that can be changed. And one more thing: subscriptions work a lot easier if the collector and the sources are in the same domain. It's possible to make it work between two systems in a workgroup, but it's more trouble. How you make all of this work varies, but here's the overview of how to set up a subscription in the easiest way.

Set Up the Sources

First, go to every computer that will be a source computer and enable a service that listens for the collector's requests for events. You do that with a command-line tool named winrm. Also, adjust the permissions on the event logs of all of the sources so that when the collector asks for those logs, then the sources are willing to cough up events.

Set Up the Collector

Then, enable the software on the collector so that it can, well, collect. Every Vista box comes with it, and it's called the "Windows Event Collector" service. Just start it and tell it to start automatically henceforth, as you'd do with any service. (Actually you needn't even do that because, as you'll see, the first time that you try to create a subscription, the Event Viewer asks you if you'd like it to configure the Windows Event Collector service for you.) Then create a new subscription. In that subscription, you tell the collector exactly which events to collect, and the names of the systems to request them from. In a little while, the events will start flowing into the collector.

Creating an Example Subscription

Let's walk through setting up a simple subscription. In this example, I'll have the following settings. If you'd like to follow along, just duplicate this setup:

  • Two Vista systems; one's named "Vista1" and the other will be "Vista2."

  • Both Vista1 and Vista2 are members of an Active Directory domain named "http://www.bigfirm.com." I'm doing that because it makes things a bit easier than connecting two systems in a workgroup would be.

  • When configuring both systems, I'll be logging on to them as an account named "mark@bigfirm.com," which is a member of the Domain Admins group.

My goal for this simple demonstration is to have the Vista1 machine act as the collector and the Vista2 machine act as its sole source. I'll have Vista1 collect all of the information-level Windows events from Vista2 machine. As I outlined before, I'll do this in two steps: first I'll visit Vista2, the source, to enable some services on it and adjust its security so that it'll let Vista1 extract events from it. Then I'll move over to Vista1, the collector, to turn on the Windows Event Collection service and create the subscription.

When we start out, I've got the two Vista systems running basically in an out-of-the-box configuration, although I've given them a very simple display theme to accommodate screen shots that are easier to read. Both have Windows Firewall up and, as is usual for Vista, WF by default has no exceptions enabled except for what it calls "core networking."

Step One: Set Up Vista2 for WinRM

First, we'll log onto Vista2, the system sending the events to the collector, and fire up the infrastructure necessary to allow it to respond to subscription requests from Vista1. In a sense, the fact that Vista2 is responding to requests from Vista1 for events makes Vista2, the source, something of a server-and so we'll have to start up a service to respond to those needs.

Microsoft built the event log stuff on top of a set of remote desktop management standards called "WS-Management," and Microsoft's name for their implementation of it is "WinRM," for "Windows Remote Management." Just fire up an elevated command prompt (right-click Command Prompt and choose Run as administrator, as always, and go ahead and respond as necessary to the UAC prompts), and type

 winrm quickconfig 

The Windows Remote Management Tool will respond like so:

 WinRM is not set up to allow remote access to this machine for management. The following changes must be made: Set the WinRM service type to delayed auto start. Start the WinRM service. Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. Enable the WinRM firewall exception. Make these changes [y/n]? 

Yes, you read that right: WS-Management runs on port 80 (that's the reference to "HTTP://*") but no, you're not setting up a web server on your Vista box, at least not a full-scale one. In response, I type y and Enter to get this response:

 WinRM has been updated for remote management. WinRM service type changed successfully. WinRM service started. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. WinRM firewall exception enabled. 

Once that's done, stay at the command prompt and give the collector computer the permission to look at events on this computer. You do that by putting the collector computer's computer account into each of the source computers' "Event Log Reader" groups-and as you've probably guessed, the "Event Log Readers" group is new to Vista. We could do this with the GUI, but quite honestly I find it easier to do from the command line. There's a NET (not a .NET) command that's been around NT for over a decade that lets you put a user account into a local group that we'll find useful here. Its syntax looks like

 net localgroup groupname accountname/add 

The group's name is, again, "Event Log Readers." But what's the name of the Vista1 computer? Well, we want to enter the name of the Vista1 machine's domain account. Ever since Windows 2000, machines have gotten Active Directory names looking like machinename$@DNSdomainname. Thus, a machine named "Vista1" in a domain named

"http://www.bigfirm.com" would have a domain account name of "vista1$@bigfirm.com." (The dollar sign suffix fixed a problem that popped up back in the NT 4.0 days whenever a user had the same name as her computer.) The command I'd type at the command line, then, would be

 net localgroup "Event Log Readers" vista1@bigfirm.com /add 

To which Vista2 should respond The command completed successfully. Vista2's ready, let's move over to Vista1 for Act Two.

Step Two: Create the Subscription on Vista1

Now I move to Vista1 and, again, log on as mark@bigfirm.com, a domain admin. Before we get into configuring Vista1, let's take a moment and verify that we've got connectivity to Vista2, and that it's running the WS-Management software. We can do that with a commandline tool, so start up an elevated command prompt on Vista1 and type

 winrm id -remote:vista2.bigfirm.com 

That's the winrm command again, but this time we're using the id parameter, which is basically nothing more than a "WS-Management ping." The -remote option identifies what system to talk to. Vista2 responds in a successful fashion with output that looks something like

 IdentifyResponse     ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd     ProductVendor = Microsoft Corporation     ProductVersion = OS: 6.0.5472 SP: 0.5 Stack: 1.0 

In contrast, bad responses would be something like "WS-Management could not connect to the specified destination." So now we know that we've got connectivity; excellent. We're ready, then, to set up Vista1 to collect.

On Vista1, we next start up the Event Viewer. Then we right-click the Subscriptions folder and choose "Create Subscription." As this is the first time that we've told Vista1 to create a subscription, we get a dialog box like the one in Figure 1.19.

image from book
Figure 1.19: Shall we start the Windows Event Collector service?

Click yes. If you'd wanted to set up the Windows Event Collector service beforehand, then you could have alternatively just opened up an elevated command prompt and typed wecutil qc. Had we done that, we'd not have gotten the dialog box in Figure 1.19. Anyway, after clicking Yes at the dialog box, we then get the quite formidable-looking Subscription Properties dialog box, as you see in Figure 1.20.

image from book
Figure 1.20: Creating a subscription, part 1

As you can see, I've started to create the subscription by filling in the "Subscription Name" and "Description" fields.

Warning 

And do yourself a favor: don't put any spaces in your subscription names. If you do, then some syntax gets ugly later.

But before this subscription will start working, we've got to tell the Event Viewer what kind of events to grab from Vista2 and oh, that's right, we need to tell it to specify that Vista2's the machine to get those events from. First, I'll specify what to look for by clicking the Select Events button. That'll raise a dialog box like the one in Figure 1.21.

image from book
Figure 1.21: More creation: pick the events to track

In this Query Filter dialog box, you see that you can choose the "fright level" of the events to grab (Critical, Error, etc.) with the check boxes next to "Error level:." I'll check "Information," as that's what I set out to collect. Above that, you can choose to collect every qualifying event in the source, or you can choose to only get events generated a certain number of days or hours in the past. For now, I'll leave it at "Any time."

Perhaps the biggest choice is "which logs to pull from?" A little browsing in Vista's Event Viewer will show that, as I've already mentioned, Vista has a whole lot more logs than the three or so normally found on a pre-Vista desktop operating system. If I click the drop-down box next to the "Event log:" radio button, I'll see something like Figure 1.22.

image from book
Figure 1.22: Just the Windows logs, please

If you're following along, then you'll just see the "Windows Logs" and "Applications and Services Logs;" I deliberately expanded the list a couple of levels to show you what's available. Nothing's checked by default-I checked all of the Windows Logs items except for "ForwardedEvents," as I had nightmare visions of accidentally setting up an infinite loop between Vista1 and Vista2 if I ever happen to set up Vista2 to grab from Vista1, instead of the vice versa situation we're setting up here. If this drop-down looks a little strange, it is-I don't recall seeing a structure like this on a Windows GUI before.

Look more closely back at Figure 1.23 and you'll see that you can continue to fine-tune the events that you want to grab. In sum, then, you could, if you wanted, only forward event ID 1030s but only when generated by the Group Policy service. Oh, and remember that XML centrism that we saw in Event Viewer before? You might have noticed the "XML" tab on the Query Filter page. If I click that, I see something like Figure 1.23.

image from book
Figure 1.23: XML-ese for the query

That's something called "XPath," an XML-renderable way of describing a query. Basically what Microsoft's done here is to offer us a moderately easy-to-use GUI to tell the collector what to grab from the source, but, if we really want to cook up an exotic filter, then we can skip the GUI and do it in XML. Or you can spend 30 minutes fiddling around with it in the GUI, but then you'd like to be able to reproduce it on demandso you just copy the XML to Notepad, save it somewhere, and then you can copy from the Notepad file sometime in the future and paste into the XML tab of some query that you'll create in the future. I'm not getting that fine-grained for this event forwarding tryout, however, so I'll just click OK to clear the Query Filter dialog and return to the Subscription Properties dialog.

In the Subscription Properties dialog, there's just one more thing I must do before I can take this subscription out for a spin: I've got to tell the Event Viewer where to draw the events from. That's easy; I just click Add and I'll get the standard Select Computers dialog that looks exactly like the one you'd see on an XP box, so I'll skip the screen shot. I just fill in the name "Vista2," click Check Names and then OK to end up with a Subscription Properties dialog looking like Figure 1.24.

image from book
Figure 1.24: Subscription setup before activation

I included this screen shot because the first time you've finished crafting a subscription, then you'll look at your dialog box one last time before clicking OKand feel your heart drop. Notice that in the "Source Computers:" field, Vista2's there, with "Unknown" next to it, and, below that, the grim report that says "[http://www.VISTA2.bigfirm.com]-Error: Source status unavailable." I mention that to let you know that you really needn't worry if you see that; it appears to be normal. Now that the subscription has been defined, I click OK.

Troubleshooting Subscription Delays

With that done, it's time to view the fruits of our labors. So we open up the ForwardedEvents log in Event Viewer, to seenothing.

But don't panic; that's apparently normal. Just give it about 15 minutes-Microsoft's golden interval, it seems-and the events start popping up. In fact, that's an important point about subscriptions. Working with them is similar to flying somewhere on an airline in that both have the same motto: "expect delays."

Adjusting the 15 Minutes

Now, you can change some of those delays, but not all. There are two main reasons for the delays that you'll see in Event Log subscriptions. The first reason explains our current wait: "the 15 minute rule." By default, Vista systems acting as event collectors only poll their source systems every 15 minutes. Now, you'd think that they'd do the first poll the very moment that you clicked that last "OK" to create the subscription, but Vista doesn't; it seems to just wait about 15 minutes before even starting to grab that data.

Now, if you like, you can change that 15 minutes to something shorter. You can't do it in the GUI; you need a command-line tool called wecutil-Windows Event Collector utility-to do the fiddling needed on the collector. You'll need to run wecutil twice. First, we'll use wecutil to tell the Event Log that we don't want the standard 15-minute cycle, and instead we want to customize the subscription. That command looks like wecutil ss subsname /cm:custom, where subsname is the subscription's name. The /cm is short for "configuration mode," hence the "custom." If you wanted to return your subscription to its original standard format, you'd just replace the /cm:custom with /cm:normal. The ss stands for "subscription settings." To shift the Vista2Test subscription to "custom" configuration mode, then, we could type

 wecutil ss vista2test /cm:custom 

Press Enter, and if you get no response, that's good. Clearly wecutil is of the class of command-line tools who are the strong, silent types. Now that we've freed Vista2Test from the iron constraints of "normal," we can change the polling rate. We do that with the command wecutil ss subsname /hi: milliseconds, where subsname is, again, the subscription name, and milliseconds is how much time to wait between polls, in milliseconds. Try it out by setting it to 10 seconds with this command:

 wecutil ss vista2test /hi:10000 
Tip 

If you're following along and want to try this out, then clearly you'll need a way to create an "information" event on Vista2. The easiest way I've come across is to open a command prompt of elevated privilege and type ipconfig /renew to renew Vista2's DHCP lease. That generates an "information" level event on Vista systems. Those events will appear on Vista1's ForwardedEvents folder nearly immediately, although you'll have to press F5 in Event Viewer on Vista1 to see them.

Understanding the "Reboot Delay"

The second reason you'll sometimes see subscriptions change slowly has to do with two services: the winrm service that provides the WS-Management capabilities on the side of the source computers, and wecsvc, the Windows Event Collector service on the side of the collector computer. Here's what you're likely to see: you boot up one of your source computers, and go over to the collector to start seeing events from that computer. So you look. And look. You check the parameters of the subscription, which you can do on the collector by typing

 wecutil gs vista2test 

If you do that, then you'll see, plain as day, that you've set the polling interval-wecutil calls it the "heartbeat interval"-to 10 seconds. By the time you do that, then clearly 10 seconds will have elapsed. More than a few times. And yetno events. What's going on?

It's all due to a change that Microsoft made to the way that some services start up. Microsoft is very sensitive to the fact that their operating systems tend to, um, take a long time to boot up. So for the past few years (XP was part of this) they've been trying to find things that they could kind of remove from the boot process-technically, anyway-and so make their OSes (particularly the desktop OSes) seem more sprightly. Their latest plan to make Windows seem to boot more quickly involves a new class of services.

If you've been following Windows (well, the NT side of Windows) for a while, then you know that Windows services have different startup classes. But most of the run-of-the-mill services are "automatic." That means that they all start up pretty much the same time as the GUI.

Most of them? Go ahead, count the number of services in Windows. And their size. You can see what Microsoft was thinking: "holy moley! About 40 percent of the stuff that slows down Windows boots are these service things!"

So they created a new class of services: "automatic…but delayed." They get the go-ahead to start up at the same time as the "automatic" services, but they have this special note on them that says "well, yeah, they're automatic, but…take your time." Any of these so-called delayed services start up in quite low priorities. And that can mean that, well, it may take a while for those subscriptions to pop up because, as you've probably guessed by now, winrm and wecsvc are both delayed services.

The bottom line is: don't be surprised if you don't get any updates from the source systems for (in my experience) seven or eight minutes. If that's annoying, you can always bump up the winrm and wecsvc services from "automatic-delayed" to "automatic," although I'd leave them alone. (And consider joining Peter in that switch to decaf.)

Event Forwarding in Workgroups

Before I leave this introduction to event forwarding, I want to provide a more complex example of event forwarding setup because it'll give me a chance to show you some more configuration options and, even better, more troubleshooting tools. First, let's review the steps that we employed to get the two domain members Vista1 and Vista2 to talk, so that we've got a starting point in explaining how to set up forwarding in a workgroup:

  • On the source computer Vista2, we started the winrm service so that the source computer could listen to the collector's requests.

  • On the source computer, we put the collector's machine account into the source's "Event Log Readers" group so that when the collector asked the source for its events, then the source computer was already configured with permissions allowing the collector to request those events.

  • On the collector system Vista1, we started up the Windows Event Collection service; we had to do that because wecsvc does the actual asking for the events from the source.

  • On the collector, we configured the subscription. And waited.

The difference in setting up a subscription between two systems that are not members of the same Active Directory forest lies in the security part. We can't just put Vista1's machine account in Vista2 because the two systems don't have any kind of trusting connection between themselves, as they would if they lived in the same AD forest. So we'll have to do some security adjustment.

To try this out, set up two systems named, again, Vista1 and Vista2. They should not be members of the same AD forest. (They can be members of domains, but not domains in the same forest or in forests that trust each other.) Ensure that the two computers can resolve http://www.vista1.bigfirm.com and http://www.vista2.bigfirm.com in DNS properly.

Once that's done, enable the Administrator accounts on both systems and set the password of the Vista1 administrator to "bigpebbles1" and the password for the Vista2 administrator account to "bigpebbles2." Now we're ready to start.

Step One: Configure WS-Management on Vista2

Just as we did before, we'll start by getting WS-Management running on Vista2, the source computer. Log onto Vista2 as its local administrator account. Start up an elevated command prompt and type

 winrm quickconfig 
Note 

Vista does not apply UAC to the default administrator account, so I don't actually have to explicitly raise the privilege on my command prompt when logged in as "administrator." But Vista can be configured to constrain the default administrator account as well and your system might be configured differently, so I'll keep reminding you to ensure that the command prompts are elevated.

Type y and Enter when it asks if you really want to set up WinRM, and you're done on Vista2.

Step Two: Tell the Collector to Trust the Source

Now move over to Vista1 and log on as its local administrator. Because Vista1 and Vista2 no longer share a domain relationship, we're going to have to see how to authenticate between Vista1 and Vista2. Open up an elevated command prompt on Vista1, the collector, and type this:

 winrm set winrm/config/client @{TrustedHosts="vista2.bigfirm.com"} 

That tells Vista1 that it's okay to, if necessary, attempt logging onto Vista2. This seems a bit odd to me-you'd think that you'd have to tell Vista2 to trust Vista1, rather than the other way around-but that's how winrm works.

That's something of a strange-looking command, so let's take a moment and understand it. winrm has a number of configuration parameters that you can examine and change. You can see them all by typing

 winrm get winrm/config 

You'll get about a screen's worth of output; here's what some of it looks like:

 C:\>winrm get winrm/config Config      MaxEnvelopeSizekb = 150      MaxTimeoutms = 60000      MaxBatchItems = 20      MaxProviderRequests = 25     Client         NetworkDelayms = 5000         URLPrefix = wsman         AllowUnencrypted = false         Auth              Basic = false              Digest = true              Kerberos = true              Negotiate = true         DefaultPorts             HTTP = 80             HTTPS = 443         TrustedHosts = vista2.bigfirm.com ... 

Notice that this information is presented with varying levels of indentation. That's intended to convey the hierarchical nature of these settings, which is referred to as the "WS-management schema." The first line, Config, is not indented because everything here is part of Config, the configuration information. The next line, MaxEnvelopeSizebk=150, clearly expresses that there's a parameter named MaxEnvelopeSizekb (and don't ask, because I have no idea what it does) with value "150." But then skip down a few lines to Client. That's a level down from Config and is a container or, rather, subcontainer of its own. Notice that TrustedHosts is a parameter within Config/Client.

You can use this hierarchy with a winrm get or winrm set command. For example, the winrm get winrm/config command showed the entire schema; to see just the items in config/client then you'd type winrm get winrm/config/client. That would look like this:

 C:\>winrm get winrm/config/client Client     NetworkDelayms = 5000      URLPrefix = wsman     AllowUnencrypted = false     Auth          Basic = false          Digest = true         Kerberos = true         Negotiate = true     DefaultPorts         HTTP = 80         HTTPS = 443     TrustedHosts = vista2.bigfirm.com C:\> 

You've already seen how to set a value in the winrm schema:

 winrm set winrm/place-in-schema @{parameter="value"} 

Where place-in-schema refers to wherever in the schema the parameter is stored. You can use "*" as a wildcard in the TrustedHosts value, and you can specify more than one item in the TrustedHosts parameter by putting a list of machines in quotes with commas between them. For example, this command would work fine to tell a system to trust both http://www.mypc.bigfirm.com and http://www.yourpc.bigfirm.com:

 winrm set winrm/config/client @{TrustedHosts= "mypc.bigfirm.com, yourpc.bigfirm.com"} 

That's all one line and do not put spaces between the machine names in the list. (Wondering why I'm spending so much time showing you how to configure and control winrm? Because all kinds of things in Vista and Server 2007 are built atop winrm. Trust me, you'll end up using this stuff.) And while you probably don't want to do this in a production environment, here's an example of trusting everyone:

 winrm set winrm/config/client @{TrustedHosts= "*"} 

Reviewing, then, the first thing that we've seen that's new in setting up event forwarding between two systems who lack a domain relationship is that we've got to use the winrm set command to add the source computer to the TrustedHosts list on the collector computer.

Step Three: Test WS-Management Connectivity

This step is not absolutely necessary, but I'm a big believer in a little belt-and-suspenders work up front to avoid pain later. Open an elevated command prompt and let's try a winrm's ping-like command. As before, type

 winrm id -r:vista2.bigfirm.com 

This time, however, it won't work. Winrm needs to know how to authenticate between systems. Now, if you don't tell it how to authenticate, then it'll just assume that it can use Kerberos, which worked fine when both systems were in the same domain, and that's why this command worked fine in the earlier example between domain members. That's not true any more, so we've got to tell it how to authenticate. The simplest way is to just say, "don't use any authentication." That looks like this:

 winrm id -r:vista2.bigfirm.com -a:none 

The option -a: is short for "authenticate." It takes several possible options:

  • -a:none means "don't authenticate." As the id command is pretty basic, the winrm service is fine with skipping authentication in this case, and the command will work. I mean, we folks with an interest in security are paranoid, but there are limits-I'm not ready for a "secure ping" or "authenticated ping" yet, although I fear that it may happen one day.

  • -a:basic says to authenticate using a cleartext username and password. This will not work by default, as winrm forbids all unencrypted logon attempts. You can change that with this command:

     winrm set winrm/config/client @{AllowUnencrypted="true"} 

    But I don't recommend it. You must follow a -a:basic command with a username and password that must be written as -u: domain \ username -p:password. We'll see an example of that soon.

  • -a:digest uses the same "digest" logon mechanism as the one that Internet Information Services has supported for years. winrm considers it an unencrypted logon method and digest logons will not work by default.

  • -a:kerberos says to use Kerberos authentication. This is the default behavior and, again, requires a domain.

  • -a:negotiate says to use a Windows NTLM-like challenge-response logon. It's encrypted and will work with winrm's defaults.

To make a negotiated logon work, add the -u and -p options. As we've set the Vista2 administrator's password to "bigpebbles2," we could make this winrm id work:

 winrm id -r:vista2.bigfirm.com -a:negotiate -u:vista2\administrator - p:bigpebbles2 

(That's all one line, even if it did break on the page.) That should work, and at the same time we've verified that Vista2 can accept logons with its administrator account from Vista1. Armed with that knowledge, we're ready for the next step.

Step Four: Set Up the Subscription

Still working at Vista1, set up the subscription just as we did before, except for two changes. First, you'll have to establish a connection of some sort with Vista2, or the Event Viewer won't let you even punch in "vista2" as a source computer. My answer was to briefly create an exception in Vista2's firewall for "file and print sharing." Then, from Vista1, I typed

 net use \\vista2\ipc$ /u:vista2\administrator bigpebbles2 

That connected me to Vista2. I was then able to specify "vista2" as a source computer. The second issue also concerned authentication. In the Subscription Properties dialog for the subscription that let Vista1 suck events from Vista2, there's a button labeled "Advanced…" Click it and you'll see a section in the resulting Advanced Subscription Settings dialog box labeled User Account. In there is a radio button Specific User. Click that radio button and you'll see a button labeled "User and Password…" Click it and you'll get a chance to punch in a username and password. Punch in vista2\administrator for the username and bigpebbles2 for the password. Wait the requisite 15 minutes and you'll have events!

To summarize, setting up a workgroup-based event forwarding differs from a domain-based one in a few ways.

  • You've got to add the source computers to the TrustedHosts parameter in winrm on the collector computer.

  • You've got to temporarily open up file and print sharing on the source computers and then connect in some way-I used the IPC$ trick-to establish a session with those computers. Then it's possible to add the computers to the list of source machines in Subscription Properties.

  • In Advanced Subscription Properties, you'll need to punch in the names and passwords of accounts on the source systems who are members of their local Event Log Readers groups.

In this chapter, I took you through a quick tour of some of what I call the Vista "small surprises." In the next chapter, we'll tackle our first big surprise-User Account Control.




Administering Windows Vista Security. The Big Surprises
Administering Windows Vista Security: The Big Surprises
ISBN: 0470108320
EAN: 2147483647
Year: 2004
Pages: 101

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net