Last month we explored some scripting with the idea of finding out things about
a machine that you normally would find out by right clicking this or that, choosing
Properties and staring at the screen. Seems like we're reinventing the wheel,
right?
Well, yes, it is but there's a reason for doing things this way. When you watch
real Enterprises operate, it takes very little time at all to realize that it
isn't possible for a 3 or 4 person staff to stand in front of the keyboard of
each machine in that 100 server farm and get the job done in a day. How are
they doing it?
Many Enterprises in the Windows world are completely dependent upon system
management software packages with price tags that approach the cost of the combined
staff's annual salary. No, really! What do these packages produce?
Many are ways of wrapping a pretty user interface around the kind of data I
showed you how to get with scripts. Most operate as services that continue to
run and monitor assigned systems even when no one is logged on. And all of the
good packages have one thing in common; they produce log files.
Log files are something the average computer user isn't really all that familiar
with and neither are many Windows administrators. In the Windows 9x world, a
log file is an anomaly. In the Windows NT world (and that includes you new Windows
XP Home users) the Event Log system is the FIRST place you go
to gather data about a system's health and any problems it is experiencing.
But those aren't the only logs you've got to work with. Additionally, working
with the NT Event Log system is kind of cumbersome because it requires
the use of another pretty interface. Those GUI interfaces represent a huge problem
in effectively managing systems that you can't stand in front of.
You're not limited to this style of logging, though. What if your survey scripts
were to produce their own logs? Last month, we created a log of sorts by redirecting
the output of our script to a text file. That method can be cumbersome, though,
and it also tends to make a mess of a directory structure. Hey!! We're managing
systems here so let's not make a mess!!
The next advantage of a text file is that it requires nothing but the most
basic software installed on your servers. In fact, if you merely want to read
the file, you can open a command prompt and type the file to the screen. At
the prompt, type:
TYPE <filename> /p
The command processor will present the text file to you one screen at a time.
Whenever possible, avoid installing standard user applications on a server.
There is significant risk attached to installing development environments like
Visual Interdev or applications like Excel on a server. Tools like this are
powerful and handy—and the cracker that exploits your server will love
finding environments like this installed as they represent another set of vulnerabilities
they can leverage against the system.
So it looks like your best bets so far are to script and to create log files
of useful data from those scripts.
Here's an example of a script that identifies all the Domain Controllers
in your domain and saves the list in a text file in the same directory as the
script itself:
'Option Explicit forces us to
'declare every variable we'll use
Option Explicit
'So now we declare them
'Nice stack of them, too, eh?
Dim oDom
Dim oComputer
Dim oUser
Dim lngFlags
Dim strDomain
Dim objFSO
Dim f
Dim LogFile
Dim strCurPath
Dim strScriptName
Dim strScriptPath
'These constants represent the different
'modes the FSO can use in opening a text
'file
Const ForReading = 1, ForWriting = 2, ForAppending = 8
'If for some reason one of our calls fails
'ignore it and continue processing
On Error Resume Next
'Using intrinsic WSH information about
'the script, we can figure out
'what directory the script is in
strScriptPath=Wscript.ScriptFullName
strScriptName=Wscript.ScriptName
strCurPath= Left(strScriptPath, _
Len(strScriptPath)-Len(strScriptName))
'Next two lines help us define
'the location and name of our log file
If Right(strCurPath,1)<>"\" Then strCurPath=strCurPath &
"\"
LogFile=strCurPath & "NTDCs.log"
'Next two lines give us access to the file system
'and tell the FSO to open a copy of our logfile.
'If the file doesn't exist, it will be created
Set objFSO=CreateObject("scripting.filesystemobject")
set f = objFSO.OpenTextFile(LogFile, ForAppending, True, -2)
'Replace YourDomainHere with the name of your
'own NT Domain
strDomain = "YourDomainHere"
'Connect to the domain with ADSI
Set oDom = GetObject("WinNT://" & _
strDomain & ",domain")
"Set a filter for machine accounts only
oDom.Filter = Array("Computer")
'For each Domain Computer account
For Each oComputer in oDom
Set oUser = GetObject("WinNT://"
& _
strDomain & "/"
& oComputer.Name & "$,user")
lngFlags = oUser.Get("UserFlags")
And 8192
If lngFlags = 8192 then
'If
the computer account
'has
a flag of 8192, log it. It's a DC
LogAction
oComputer.Name
end if
Next
'---------------------------------------------------
Sub LogAction(strEntry)
On Error Resume Next
f.WriteLine strEntry
End Sub
This time we're using another part of the Windows Script Host's scripting
runtime; the FileSystemObject (FSO). More about the FSO can be found
at http://msdn.microsoft.com/msdn.
I highly recommend learning about this object as you'll be using it over and
over again.
We're also using the WinNT provider of the ADSI or Active Directory Services
Interface. This object provides access to Directory Services from any registered
provider including Netware, Windows 2000 Active Directory and Windows NT domains.
Again, I won't try to teach you things that other people have done a better
job of explaining. Instead, I recommend that you take a look at Windows
NT/2000 ADSI Scripting for System Administration by Thomas Eck. In our
script we are doing something that Thomas doesn't describe in his book, namely,
identifying an NT Domain Controller based on value of a flag returned with the
domain account details of the computer. Microsoft Windows
2000 Server Resource Kit indicates that an NT Domain Member Server or Workstation
will have a flag value of 4096 and that Domain Controllers bear a value of 8192.
What we've done here is something you can't even do with Windows NT's Server
Manager utility. You may have noticed that this utility can show All, Workstations
or Servers but it can't limit its view to Domain Controllers only. Too bad.
We can.
In the script, we connect to the domain name specified in the variable strDomain.
You should replace "YourDomainHere" with the name of your own domain
(and be sure to surround that domain name with quotes in the script!)
When the script is done, you should see in the NTDCs.log file a list
of all your domain controller accounts—including the accounts of Domain
Controllers that are no longer present on the network but are still listed in
the SAM.
Maybe next month we'll learn how to identify old computer accounts in the domain—and
programmatically remove them while logging all our actions and the results?
|
