Admin Arsenal Blog

The Windows Event Log is a tool that most administrators have at least a passing familiarity with. It's one of the go-to places to look when troubleshooting a computer. It's very handy to be able to look at logs on remote computers, or to have event logs shipped from one computer to another. In doing so, you may have run across the dreaded "The description for event ID from source AAA cannot be found." What causes this?

The good, bad, and ugly of message files.

The event log in Windows is a bit different than the event log in UNIX. In UNIX, the log is simply a text file (or files) with a particular format. In Windows, however, the event log is stored in a database with individual events making up the records. Events follow the message file programming model that the Win32 API does. This model was designed to make translation to other languages easier.

What is a message file? These are typically .DLL files that contain nothing but text resources for use by other programs. Each piece of text in the file is referenced by a unique ID making it quick to extract one of them for display to the user. One of the resources may look like "Error writing to drive %s, it is full." At run time the %s is replaced by the name of the drive which failed, so all that a program needs to do is call a function such as ShowMessage(ID_DISK_FULL, "C:") to display the message. The advantage to this model is that just by swapping in a different message file, the program can be translated into another language and the program doesn't need to change at all.

Event log entries work the same way. Each entry has a set of values which are combined with the messages from a message file to generate the text you see. This works great, as long as you have the proper message file. There are two scenarios where this might not be the case:

1. You are looking at a remote event log and the admin shares are unavailable.
2. You have saved the event log and are looking at it on a different computer, one where the application that generated the events isn't installed.

In the case of #1, Event Viewer tries to open the message files on the remote computer, using one of the admin shares (admin$ or c$, for example). If the files can't be accessed, then the messages can't be shown. The only solution is to open up access to the admin shares. Even if the application is installed locally, Event Viewer won't look for the local message file.

With #2 you can install the application on your computer, but this isn't always feasable. There is, however, another solution. If you have access to a message file from the application, you can "trick" Event Viewer into using it. This involves a change to the Registry, so all of the standard caveats and "don't-do-this-at-home"  and "we-told-you-so" apply. The key you're looking for is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog

The screenshot shows all of the individual Event Logs. Underneath each of these are more keys, one for each Event Log Source. These are what you need. In Event Viewer you can see the Source for each event. Event Viewer looks for one of these keys to find out where the message file is. In my example, the source is PowerShell under the Windows Power Shell log.

If you have an event log from another computer, and its corresponding message file, all you need to do is to create a registry key under any of the event logs (it doesn't really matter which, but I usually use Application) and give it the same name as the source. In the key, create a single string value called "EventMessageFile" and point it to the message file you copied. Presto! Event Viewer will now be able to show you the event messages in all their expanded glory.

The strange case of .NET

Interestingly, Microsoft has actually pulled away from message files in the .NET Framework. When .NET applications write to the event log, by default they all use a single message file with a single resource. That resource is a simple %s which just displays the single value within the event log entry. This means that most .NET applications won't have problems with event logs on different machines. Even if you're looking at the log without access to the message file, you'll still see the full message below the paragraph warning you about the missing message file.

The mechanisms for the event log can at times be irritating, but a good understanding of what's going on under the hood will smooth over the rough spots.

OK, so your manager asks you the question: How many computers don’t have Symantec Antivirus (SAV) installed?

You reply that you will find out and get right back to her. You open up Admin Arsenal and then just kind of stare at your screen. Hmmm, how are you going to display all computers that DON’T have SAV installed? Isn’t that kind of like a professor asking all people who aren’t present to raise their hands? There are two roads that we can take to show systems without SAV. Both include using Dynamic Collections.

First Road:

1. From your main Admin Arsenal window select New Dynamic Collection from the Container menu.
2. Give the collection name something useful such as: "Systems WITHOUT SAV".
3. Change the match operator to “Not Any”.
4. In the main filter body change the first filter to “Software Name” and use the operator “contains”. In the field following “contains” type in: "Symantec Antivirus".
5. Save and close your new collections window.

When you highlight your new collection you will see all machines that do not have Symantec Antivirus.

Second Road:

You can get the same result as our first example using two collections. While, on the face of it, it would seem asinine to create two collections when you can get the same results from one, there may be times when you will want to create two collections. Suppose you would like a collection that shows all systems WITHOUT SAV as well as a collection that shows all systems WITH SAV.

1. Create two Dynamic Collections and name them something like “Systems with SAV” and “SystemsWITHOUT SAV”, respectively.
2. In the "Systems with SAV" add the filter:  "Software Name contains Symantec Antivirus".
3. In your second collection (the "Systems WITHOUT SAV"), change the filter to show collection with the operator “not member of”. You can select the appropriate name of the collection from the drop down list.

The second collection will simply show all computers that are NOT members of the collection “Systems with SAV”. Since the “Systems with SAV” collection only reports computers that have Symantec Antivirus installed, then creating a collection to display only computers NOT in the “Systems with SAV” will show you all computers that do not have Symantec Antivirus installed.

Clear as mud? Try it out. Of course you can substitute SAV with any application you want. Remember, collections are here to make your job easier.

We've been working with some clients on their upcoming requirements to support Internet Protocol version 6 (IPv6) compatible software. Over the past year I've fielded a ton of questions about why it's a good idea to be ready for IPv6. When I came across IT Dojo's piece (video) on the most common questions that they've received about IPv6, it brought back the past twelve months quite vividly.

It's a great video. It includes tips on shortening the new addresses as well as calming fears about co-existence between IPv4 and 6.

Video: Answers to five questions about IPv6

One of the more requested features in Admin Arsenal is the ability to work with more than one Active Directory container at a time. Up to version 1.4, Admin Arsenal only supports a single container. This works great if you have only a single domain or your tree is organized in a certain way – in other words, not everyone.

We’ve heard your requests and will have you covered in version 2. Not only will you be able to specify multiple containers and domains, but you can select containers to exclude, giving you a great deal of control over what Admin Arsenal sees. Consider a simple example:

When it comes to employing Enterprise Systems Management (ESM) solutions, too many pointy-haired bosses fall into the same trap the third grade teachers in my elementary school fell into during the annual Kickball tournament: they got lazy when assigning the "unglamorous" positions.

Kickball in my elementary school was the Bomb. It was thesport for the boys. We all loved it (except for a kid named Ben who was always hanging around with the girls playing dolls and four-square) and I am sure we all thought that we would go pro. My class won the championship. We even beat the older grades. Why? Certainly not because of me. No, the kudos need to go to my teacher, Ned Aikau. He was serious about the game. All the teams had good pitchers and basemen. The throw-away positions were the outfield and, for some reason, catcher. EVERY other team had an apathetic girl play catcher. (I should state that playing kickball was pretty much mandatory so all students had to play, even the bored ones). Usually, playing catcher in elementary school kickball is not at all like playing catcher in baseball or softball.  But Mr. A took the second best "jock" in the class and made him play catcher. That was Randy. If some baserunner rounded third you could bet Randy was waiting with a smile. He could catch any ball thrown and he would mercilessly throw the ball at the oncoming runner. Mr. A made the only girl who seemed to like sports play shortstop. He had me play right field ( a place where the lethargic team members usually congregated to talk about anything but the very game they were playing). Every position that was usually given to the bored or throw-away students was given to a capable player. As I mentioned, we won every game.

ESM is often the catcher position. Management has already purchased data-center servers and had a collective heart attack when funding last OS upgrade. Trying to get them to pay for Systems Management can be pretty dangerous. I once heard a pointy-haired boss say "I have real issues with paying for tools that make your job easier. With the money we pay you, you should be able to do all this stuff without these expensive purchases". He wasn't actually speaking to just me, but to a team of us. I remember one tool I had requested was WinBatch from Wilson WindowWare. I ultimately got the software, but I'm still not proud of how low I had to go to get it (but that's for another post).

Think about the urgent demands that you face every week. Make a list... it might look something like this:

1. "Find all the software that is loaded on our company's computers. I heard some companies are getting busted for having pirated software!"
2. "Why the hell are games loaded on our computers? I thought we didn't allow that! Remove the games now."
3. "We have some new time-management software that we need installed on all the company's computers. And we need it installed now so that we can process all of our current timecards in the new system."
4. "I just read an article that said too many users have Administrative permissions on their work computers. Do our users have Administrative permissions?"

That is just a very simple, ordinary list. Whether you are an administrator of 23 or 2300 computers, you have probably had similar demands made of you. All of these are common dilemmas resolved in some fashion by ESM. Some administrators use "point solutions" to solve these. Some administrators use "all-in-one" solutions. And some administrators use self-made scripts, GPO's and perhaps a touch of sneaker-net to get the job done. All four points can be accomplished with Admin Arsenal which is available for $999.

A well maintained Systems Management environment would be able to fulfill requests 1 & 4 immediately and requests 2 & 3 within a day or two (depending on how much testing you like to run through before uninstalling or installing software.)

If you are storing lists of installed software in an Excel spreadsheet that you maintain, then STOP. Software in your company is constantly being installed, upgraded, removed or replaced. Trying to keep up with such a dynamic environment with such a static approach will burn you sooner, rather than later.

If you have no idea which users have local administrative access to your company's computers then you have a new priority. Actually two. Thumping yourself on the head is the first one. Remedying the situation with a tool (or tools) that provide this data is your second priority.

Installing and removing software across your computing environment is one of the most in-demand tasks asked of administrators. So many applications can easily be installed or removed en-masse that if you still approach these tasks via sneaker-net, then you either need to A) get with the program, or B) send me a picture of the boss that denied the purchase of the software installation tool. I think I used to work for him.

Some days, I wish my boss was Mr. Aikau. He would expect hard work and competency from the whole team, but he would also make the tough call to put Randy in as catcher.

We’re very pleased with all of the feedback we get from users about Admin Arsenal. It’s feedback that tells us what’s important so that we can concentrate on the features that are most important to you. Feedback can also tell us where we’re going wrong. In that vein, there’s one message that’s been coming through loud and clear.

We’ve noticed a lot of questions about features and functionality that already exist in Admin Arsenal but are obviously too well hidden. It’s unlikely that all of the questioners simply decided to send in a question without first trying to find what they were looking for. No, it’s more likely that what they wanted wasn’t very discoverable or was visible in way that was too obscure to make its use obvious.

This leads me to tell you about a new focus we’ll be having for the next few releases of Admin Arsenal: Usability.

Usability isn’t about making things “easy to use,” though that is usually a way to describe the benefit. Instead usability is about bringing the interface in line with how you, the user, thinks. A system with perfect usability will not require the user to ever think about how the software works, but only think about the problem that they’re trying to solve. Our goal will be to reach that programming nirvana of software that doesn’t make you think.

To that end, please feel free to tell us all about the times when Admin Arsenal was confusing, or surprised you, or in any way required something from you that it should have been able to get itself. We’ll try to shut down the egos here so that we can take the criticism, which shouldn’t be too tough. We all come from backgrounds supporting the big-boy ESM tools, so we’re used to frustrated users :-)

Keep watching this space for updates as we move down this road. We’re hoping it’ll be valuable for us all.