Spinning a Web of Control
Now that the real millennium is upon us, it’s time to
properly administer our Web sites—and ADSI IIS Provider
is just the tool to make it happen.
Happy millennium! No, I haven’t been in a coma for the
past 12 months. As all real geeks know, the 21st century
officially starts Jan. 1, 2001. Time flies, doesn’t it?
Why, it seems like only yesterday I was holed-up in my
Y2K bunker — with extra water and ammunition by my side
— working on how to jockey for the best position in the
“new world order” that would arise from the imminent destruction.
What a disappointment Yawn2K turned out to be! Oh well,
no such plans this year. Once bitten, twice shy.
Since the 21st century will likely go down in the annals
of history as the time our society truly realized the
power and potential of a connected world, what better
topic for this — my first column published in said century
— than a tool that’ll help make it all happen: The ADSI
IIS Provider! OK, I realize that it’ll be IIS, not the
IIS provider for ADSI that actually wields the power of
the World Wide Web; but ADSI will allow you to script
the administration of Web sites, so that’s sort of revolutionary,
Oh, What a Tangled Web…
As with the WinNT provider, the IIS provider exposes vast
amounts of functionality for administering your IIS Web
servers. Indeed, I could devote an entire series of articles
to any one of the ADSI providers. These are the things
700-page books are made of. Since I only have two or three
more months budgeted for this topic, I’ll try to cover
the highlights and give you some good foundations for
future exploration. Let’s get started.
|Reader Chris Lightner asks
for a script that lets him "cycle
through all servers and have CACLs replace
the Everyone group and add Users only
if Everyone currently has rights to the
directory or files." What he can
use is a utility called DumpACL (click
here to get it), which can be used to
create a list of ACL permissions on any
machine. You can use it to write a script
using CACLs or a third-party ACL utility.
For any given IIS server, there are several global settings
that we can access via ADSI. These include log file settings,
MIME mapping information, and bandwidth throttling. Let’s
take a look at the latter.
IIS allows you to configure a limit to the amount of
bandwidth used by the WWW and FTP services. There may
be many reasons why you’ll want to do this, not the least
of which is to test site performance for clients. When
you’re creating your Web sites, it’s easy to forget that
you’re connected via LAN speeds to your server. This can
often cause you to include dynamic content that works
fine locally, but can cause a remote site visitor to lose
interest before your page finishes loading. By configuring
a limit, you can see how your site will respond to clients
on a slower connection, like 56K or even DSL (yes, DSL
is slow compared to the 100Mb speeds common on today’s
LANs). Let’s see how our site performs over a 56K connection.
4778? I thought we were slowing it down to 56K! Yes,
we are. Remember that network bandwidth is measured in
Kbits per second. The MaxBandwidth setting is in bytes
per second. In order to accurately simulate a 56K dial-up
connection, we must convert Kbits into Kbytes, remembering
also to account for modem sync information. Since there
are eight bits in a byte, you’d think we’d simply divide
56 by eight to determine the number of kilobytes to set
the throttle to. However, don’t forget that part of the
56K bandwidth is dedicated to keeping the connection up
and not used for data. As such, we actually divide 56
by 12 to arrive at the correct number. We then multiply
by 1,024 to turn Kbytes into bytes. This results in 4,778
and change. You can keep the change.
Once we’ve completed our testing, we can turn off bandwidth
throttling by setting MaxBandwidth to -1.
After changing the bandwidth throttling
settings, you’re required to stop and
restart the service for them to take
effect. This is accomplished easily
enough using the Internet Service Manager
MMC snap-in. Your homework this month
is to write a script to do this.
I’ll give you one hint: It doesn’t
involve the IIS provider.
What’s This Site For?
We’re now ready to look at our individual sites. To do
this we need to bind to the IIS site we wish to manage.
This requires a bit of advanced knowledge about the Web
server to which we’re connecting. As any of you who’ve
performed administration on IIS know, there can be several
WWW “Virtual Servers” running on a given IIS computer,
each with its own IP address and virtual directory hierarchy.
Also, you can extend IIS through the use of host headers.
In this case, you assign several DNS names to a single
IIS IP address. Each inbound packet has the destination
host name embedded in its header. IIS then uses this information
to direct the packet to the correct Web site.
As each virtual server is created, it’s assigned an index
number. The default site is 1; subsequent sites are assigned
2, 3, 4, and so on in the order that they’re added. It’s
with this index number that you bind to the correct site.
What’s that? You say you forgot to write down the order
in which your sites were added? No worries! We can get
that information from ADSI.
Dim objWWW, colSites
For Each colSites in objWWW
If IsNumeric(colSites.Name) Then
Wscript.Echo "Site index:"
& " Site Name:"& colSites.ServerComment
Since ADSI “sees” the site name as the index number,
in order to equate it to something more memorable, we
must look at the ServerComment property. Remember that
this is only for our edification so that we know which
site we’re dealing with. When we reference it in code,
we must use the index number, not the “friendly name.”
Next month, I’ll look at creating, editing, and managing
virtual directories for both FTP and WWW services. So
crawl out of that bunker, donate all the canned goods
you’ve been hoarding, and get back to doing what you’re
good at: server administration!