Our first order of business is Windows Server event logs. So, event logs track
events in Windows Server, but of course, what is an event?
An event is simply a notification of a state change,
simple as that. When a computer starts, that's an event.
If a computer stops responding, that's another event.
The idea here is that the events don't arise out of thin
air. They've all been explicitly accounted for and
programmed by an application developer.
Windows engineers, of course, concentrate on event streams for events that
occur within the Windows OS, and then as you layer on software,
those separate software vendors have their own
developers who create event streams.
We have in Windows a number of built‑in logs.
There has been the standard ones that we've had for many, many years.
Here is a screenshot of Event Viewer,
the traditional Win32 app, and we can see we've got extensibility. We've
got the Windows logs, which I have here not highlighted,
but you can see it in the image, Application,
Security, Setup, System, and then the extensibility
means applications and services logs.
So as you install roles on your servers, oftentimes
they will have related event logs.
Event Viewer is a nice convenient place to round up those
events, but when you're managing multiple servers,
especially in a hybrid cloud environment, ain't nobody got time for
individually connecting to machines with Event Viewer.
You'll see that the highlight annotation I've made on this slide
highlights a folder called Subscriptions. We'll have more to say
about event log subscriptions momentarily.
Besides the graphical Event Viewer,
we can query our event logs on Windows Server systems using PowerShell.
In the first example here, get‑winevent is for log management where you
can take a look at the size and the log mode and the log name and the
record count for your logs.
You'll want to use Group Policy to centrally control those properties.
Actually, you could do that with PowerShell as well. As far as
being able to parse the logs and retrieve events, you can use
Get‑EventLog, and as you see here,
I'm looking at the System log and grabbing the newest five entries.
You'll notice that there's a standardized format for these.
There's importantly an event ID and then there's an associated
message that goes along with those.
Therefore, a large part of troubleshooting Windows Server
is looking in the event logs for particular ID numbers,
and then you know what I do,
I do the same thing you probably do, I hit up Google, looking up
those event IDs, and go to Stack Overflow and other sites and
figure out what the problem is, what the most likely explanation
is, and then go from there.
Server Manager is a, in my opinion, sometimes neglected,
sometimes ignored, graphical server administration tool,
but it's convenient,
inasmuch as for one or more servers you can look at individual roles
and features, like here I've highlighted DHCP, and you can see related
event log entries right there per service.
So the Server Manager event logs is a bit easier to navigate
than Event Viewer because it's a parsed or a pre‑parsed view,
or a subset of only related events.
The latest frontier in Windows Server administration is
this Windows Admin Center web console.
In here, I'm showing you a screenshot where we're dialed into a particular
server, and of course, in the Tools list we have events that give you
access to look in and do searches on those events.
Now, generally speaking,
I know I've mentioned this before in my training, generally
speaking, Windows Admin Center contains a subset of the
management options that you have in the main graphical user
interface tools, like Event Viewer.
But one nice thing that Windows Admin Center has in its side is it's
much more rapidly developed, or at least potentially more rapidly
developed than those built‑in MMC consoles.
You'll find that all of these modules,
these tools in WAC, are built or implemented as extensions that you can update
and keep current, just like you can your browser extensions,
your Visual Studio extensions, your VS Code extensions, and the Microsoft and
third‑party engineers sometimes will offer a public preview mode that you can
opt into to take a sneak peek at upcoming features.
Now, principally,
like I said before, the rubber meets the road with
event logs in two main situations.
One, at least this is the world according to Tim; one, you're
troubleshooting a specific problem with a specific machine. There,
you can use any of the aforementioned tools to go searching for event
IDs, and then you'd go take your research from there.
But what about proactive log management across an
entire fleet of Windows Servers, dozens,
hundreds, thousands,
tens of thousands? What are our options for making this process easier?
Well,
I'm going to stay with first‑party Microsoft solutions because that's what
AZ‑801 is, it's a Microsoft certification exam. As I mentioned, we can
control event logs in terms of their maximum size, their circularity with
Group Policy, so that's a starting point.
Event log subscriptions are, what do I want to say about that?
It is a way to consolidate event log entries from multiple
servers, but its downside is that unless you use
scripting, it's not very scalable.
System Center Operations Manager, if you're doing
on‑premises, and nowadays System Center works in an Azure
context as well, come to think of it,
but you can use scum to do centralized event log management. And
we'll learn more about log analytics a little bit in this module
and certainly a lot more in the next one,
but it definitely makes it easier to aggregate the event log at scale and then
to be able to report an alert on those event log entries.
I think you'll be impressed if you're not already familiar with log analytics.
Lastly, there is third‑party independent software vendors, or ISVs.
There's plenty of players in this arena who have various desktop and
browser‑based tools that have as their advantage, in some cases,
easy setup,
agentless set up, and you can aggregate and report on event logs on multiple Windows Server systems at scale.