In-Depth
.NET Leap of Faith
Release of Windows .NET Server is getting close. Should your company consider moving? Windows Insider Bill Boswell makes a case for the upgrade to Microsoft’s newest operating system.
- By Bill Boswell
- 11/01/2002
After much delay and surprisingly little hoopla, Microsoft is poised
to release the next upgrade to the Windows family of servers, Windows
.NET Server 2003, previously code-named Whistler. The family includes
four products: Standard Server, Enterprise Server, Datacenter Server,
and Web Server, which has a shaved-down feature set designed to support
Web services and not much else. The features in these four products significantly
extend the functionality of Win2K while making your systems more secure,
more scalable, and much simpler to manage.
It may come as a surprise to realize that three years have passed since
the release of NT 5.0 build 2195, dubbed Windows 2000. The rate of adoption
has been slower than many analysts expected for a variety of reasons.
First, a vast amount of money and time was spent on preparing for Y2K
just as Win2K came on the scene. This depleted budgets for at least a
year. Then came the economic downturn as the tech bubble collapsed and
the economy slipped into recession, a situation made much worse following
the events of 9/11. But frankly, I think the real reason for the delay
is that many analysts simply underestimated the complexity of deploying
Active Directory, especially into large and complex environments.
If you’re an administrator in an organization that’s already deployed
Win2K and AD, you may be wondering if another round of upgrades is worth
the effort. If you’re an administrator in an organization that hasn’t
yet moved to Win2K, you’re faced with the end of Microsoft’s direct support
for NT in 2003. If you don’t want to stay with NT until drivers simply
aren’t available for your hardware, you need to begin evaluating an upgrade
path. Your upgrade decisions will take place during a time of historically
slim IT resource allocations. Organizations that once bought new technology
based on a few recommendations from a consultant and a front page write-up
in a trade publication now sharpen their red pencils and demand considerable
evidence of prompt (repeat prompt) return on investment for any purchase.
“Are you certain the rollers on that mouse are worn out?”
So, as you begin to evaluate the new features in .NET, you may find yourself
facing one executive after another who will all ask pretty much the same
basic questions. “What are you going to do with .NET? Is it something
we need to spend our money on right now? Should we really be thinking
about deploying a new Microsoft platform when Win2K is now a proven commodity?”
Your answers will vary depending on your role in an organization. With
this in mind, let’s look at the major new features and upgrades in .NET
Server with an eye toward deciding whether they make a sufficiently compelling
case for an upgrade.
Security Administrators: Rejoice!
If you like going to sleep at night knowing your systems are secure,
you’ll appreciate the new attitude toward security shown in .NET. In December
2001, Bill Gates did a fair imitation of Claude Raines in Casablanca
by issuing a memo stating that he was shocked—shocked!—to discover
security problems in his company’s operating systems and applications.
In February 2002, all production coding came to a stop on the Redmond
campus while the developers performed a detailed search for security vulnerabilities
such as buffer overflows, heap overflows, and other avenues for exploits.
Microsoft has integrated these processes and procedures into an on-going
security effort called the Trustworthy Computing Initiative.
The result? .NET Server represents the most secure operating system Microsoft
has yet produced. Granted, that’s not saying a whole lot from a historical
perspective, but it does represent a significant change in the company’s
attitude. Instead of striving to make Windows “work right out of the box,”
Microsoft is now striving to make Windows “secure right out of the box.”
This new attitude shows in many ways, some large and some small.
For example, the default NTFS security permissions have changed considerably.
The Everyone group now has only Read/Execute permissions by default on
new volumes compared to the Full Control permissions granted by Win2K
and NT. The Domain\Users group (essentially, anyone who has authenticated
at a domain member server or desktop) has Read\Execute, Create\Modify
Folders, and Create\Modify Files permissions. The lockdown is even more
restrictive on the %systemroot% folder, where only Administrators or administrator
equivalents have anything other than Read\Execute permission. Application-mode
terminal server operators will be pleased to note that this helps keep
users from modifying system files and folders.
The default permissions on share points have changed, as well. The Everyone
group is still the only default group on the share ACL, but it has only
Read permissions. This can be a little disconcerting until you get used
to setting the permissions manually. A new /grant switch for the NET SHARE
command permits you to set the share permissions at the command line.
.NET also blocks network access by users with blank passwords.
The default handling of anonymous logons has also changed. Past versions
of NT and Win2K gave credential-less connections (called null session
connections) an access token that included the well-known SID for the
Everyone group. This set the stage for a wide variety of exploits because
the Everyone group historically has been given quite a bit of access.
In .NET, null session connections are assigned only the Anonymous Logon
group SID and thus have minimal permissions. This eliminates the need
for elevated Restrict Anonymous=3 settings and the problems they cause
with classic trust relationships and Exchange. Figure 1 shows side-by-side
results of a NetBIOS service scan using GFI LANguard Network Security
Scanner performed against a standard Win2K domain controller and a standard
.NET DC. The Pre-Win2K Compatible Access group in both domains is empty.
| Edition |
Processor
Speed |
RAM
(minimum and maximum) |
Processor
Support |
| Standard Server |
550MHz |
256MB to 4GB |
2 |
| Enterprise Server |
733MHz |
256MB to 32GB |
4 |
| Data Center Server |
733MHz |
1GB to 64GB |
32 |
| Web Server |
550MHz |
256MB to 2GB |
2 |
|
 |
| Figure 1. NetBIOS service scans of .NET and Windows
2000 domain controllers. (Click image to view larger version.) |
Web Server Administrators: No More Apologies
With .NET, we finally get a Web server that we don’t feel we have
to apologize for using. The entire IIS infrastructure in .NET has been
reworked from the ground up. This new infrastructure forms a compelling
reason to upgrade your Web servers to .NET and IIS 6.0 even if you just
recently made the transition to Win2K and IIS 5.0. Here’s why.
By default, Web services in IIS 5.0 run under one or more instances of
Dllhost.dll, which then run under a single instance of Inetinfo.exe, a
user-mode application. This makes Web services somewhat unwieldy because
the Web sites and scripts within them must communicate with each other
either via shared memory or by interprocess communications via the Executive.
Running processes in shared memory means that if one crashes, it takes
the rest down at the same time. Keeping the processes separated inhibits
full functionality by limiting access to shared resources such as ASP
and Common Gateway Interface (CGI) processing engines.
In .NET and IIS 6.0, the underlying Web engine is a kernel-mode driver,
Http.sys, that controls access to all user-mode processes. Figure 2 shows
a process diagram. The driver is light and fast, really nothing more than
an application router. When messages arrive, Http.sys selects a destination
and dispatches the messages accordingly. Http.sys also handles making
and tearing down TCP connections, a computationally expensive proposition
for a user process. This dramatically increases the number of concurrent
hits a Web site can handle. Http.sys is also responsible for logging,
which has long been a weak point for classic IIS because of concurrency
issues. Since only one process owns the log, there’s no possiblity another
process will have the log locked when an important event occurs.
When it comes to scalability, IIS 6.0 also eliminates a critical limitation
in classic IIS, the inability to run more than one CGI application at
a time. The new support for asynchronous CGI means that you can host significantly
larger numbers of sites on the same Web server without worrying about
conflicts or race conditions.
 |
| Figure 2. The new IIS 6.0 process architecture
makes Web sites faster and more stable. |
Finally, IIS 6.0 sports a faster and more flexible management model with
a text-based Metabase file that uses XML rather than binary data for storing
configuration information. Changes to this XML metabase file take effect
immediately, drastically reducing the instances when a Web server must
be restarted.
| Worker
Processes and WAS |
|
The grunt work of handling Web messages is given over
to a user-mode application called a Worker Process,
which has multiple threads, each capable of hosting
one or more Web applications such as an ISAPI extension
or a piece of CGI code. Worker processes are grouped
into a common security and management structure called
an Application Pool. Each Application Pool runs under
a separate instance of an executable called W3wp.exe.
Application pools provide a boundary so that a misbehaving
worker process in one pool can't disturb or compromise
worker processes in other pools.
At first glance, Application Pools resemble the High
Isolation setting in classic IIS, where each application
is given its own instance of Dllhost.exe. The difference
is in the way the worker processes communicate with
the outside world. In IIS 6.0, each worker process communicates
directly to the Http.sys kernel driver and can be separately
started and stopped. This increases the resilency of
the system. Even better, each Application Pool is individually
monitored for proper operation by a service called the
Web Administration Service, or WAS.
The WAS continually "pings" each worker process to
verify that it's active. If a worker process crashes
or becomes unresponsive, or if all available threads
in the process are blocked, the WAS either stops and
restarts the worker process or it recycles the worker
process, meaning that it starts a new process before
retiring the old one, thus ensuring continuity of service.
The WAS also acts as a kind of psychoanalyst for ISAPI
extensions running in the worker processes. If an ISAPI
extension feels deprived of resources or becomes overworked
and stressed out or simply gets cantankerous, it can
ask the WAS for help and guidance. The WAS can then
restart or recycle the process before it becomes unresponsive.
In addition to imparting stability, the separate worker
processes in the application pools also represent a
big leap forward in Web security because each process
is assigned a separate user account to act as a security
context. .NET has three predefined user accounts: Local
System, Local Service, and Network Service. The first,
Local System, has full privileges and is avoided. The
other two have only the minimum privileges necessary
for operating a Web site. This prevents an attacker
from "getting root" if a Web site is compromised. The
Local Service and Network Service accounts have profiles
and SIDs, so they can be used to support n-tier applications
where a Web server attaches to a back-end database or
some other process.
|
|
|
System Architects: Flexible Functionality
If you’re responsible for designing or implementing AD forests,
you’ll get quite a bit more flexibility with .NET. Most of the new features,
though, require that all DCs be running .NET. Backward compatibility with
NT and Win2K is maintained using a flag called Functional Level. The Win2K
Mixed and Win2K Native Functional Levels mimic the operation of Mixed
and Native Mode in Win2K. When all downlevel DCs in a domain have been
upgraded or decommissioned, the domain can be shifted to the .NET Functional
Level. When all domains in a forest have been shifted, you can then shift
the Functional Level of the forest itself to .NET.
In any Functional Level, the membership of Universal groups can be cached
by non-Global Catalog servers, eliminating the need for placing GC servers
at each site to support authentication in Native mode. The Universal group
cache is updated periodically by replicating changes from a GC server
at a designated site. Figure 3 shows the configuration setting in AD Sites
and Services.
 |
| Figure 3. The New Universal group caching option
eliminates the need for Global Catalog servers at each site in a Native
mode network. |
Speaking of groups, .NET eliminates a problem that has nagged Win2K administrators
in large enterprises. In Win2K, when a user is added to or removed from
a group, the entire Member attribute is replicated. Not only does this
put quite a bit more replication traffic on the wire, it opens the possibility
for losing data if two administrators add different users to the same
group during the same replication interval. This isn’t a farfetched scenario
when you consider that the default inter-site replication interval is
three hours. .NET resolves the problem by replicating addition or deletion
of individual group members discretely rather than as a unit. This feature
requires the forest to be at .NET Functional Level.
Another useful replication improvement, and one that also requires forest
.NET Functional Level, targets the Knowledge Consistency Checker (KCC),
the service responsible for calculating replication paths for a DC and
creating the required Connection objects. In Win2K, the algorithm used
by the KCC is very complex. For large enterprises with mutiple sites,
the calculation can take too long, leaving some DCs out of the replication
map. The only workaround is to create Connection objects between sites
manually and leave the KCC out of the picture. The topology calculation
algorithm has been streamlined considerably in .NET, reducing the need
to take manual control.
For hard-core command-line junkies, a revamped REPADMIN utility makes
managing AD replication a breeze. You can quickly initiate replication,
check the identity of a bridgehead, list the items in the replication
queue, and display the latency between sites. A new /experthelp switch
displays additional operations that previously required direct AD changes
to implement, including the ability to enable change notification between
sites, override schedules, disable compression on replication traffic
and add or delete Connection objects.
One of the most significant features exposed by shifting a forest to
.NET Functional Level is the ability to create two-way transitive trusts
between forests. This helps to resolve autonomy issues that can arise
when administrators and their managers who don’t trust the OU rights delegation
model within a single domain and don’t like the sweeping powers that forest
root domain administrators wield in a single forest. They then demand
the total autonomy that comes with having a separate forest.
Even administrators perfectly willing to participate in a single domain
or forest often want a more robust boundary when faced with the task of
quickly incorporating a new business unit into their organization or setting
up an extranet with an affiliate or vendor while assuring that security
in their own organization isn’t compromised.
Inter-forest resource sharing is possible in Win2K but uses classic one-way,
non-transitive NT trusts. Using these trusts, resource sharing between
several forests with multiple domains quickly results in a snarl of one-
and two-way trust relationships drawn on big sheets of butcher paper that
hang on the wall of the server room.
.NET helps to resolve this issue by introducing a new trust type called
a Forest Root trust. Using this trust type, you can build a Federation
of forests where the root domains share a two-way, transitive trust that
can be used by clients in a child domain of one forest to get access to
resources in the child domains of another forest. See Figure 4.
 |
| Figure 4. .NET Server introduces Forest Root
trusts, allowing transitive trusts among forests. |
A Forest Root trust can be configured to select specific domains from
each forest that can participate in the Federation. For example, in the
figure, users from the US.Company.com and Canada.Company.com domain could
be granted access to resources in the England.Subsidiary.com domain but
not the Frankfort.Subsidiary.com domain.
Federations aren’t intended to be the ultimate solution for resource
management within an organization. The domains in the separate forests
don’t share a common Configuration or Schema naming context, so applications
such as Exchange 2000 that rely on shared knowledge in a forest can’t
bridge the gap. Also, trusts between forests are not transitive, so that
if Forest A trusts Forest B, and Forest B trusts Forest C, then Forest
A does not trust Forest C.
There is no “prune and graft” utility for AD, so you can’t restructure
a forest by introducing outside domains or by splitting off existing domains.
That being said, as long as you retain a single forest, .NET does offer
the flexibility of renaming your domains and thereby restructuring the
forest. This is a complex operation that requires quite a bit of planning,
but it’s simpler than creating a new domain and migrating all the user,
group and computer accounts. If you do find yourself needing to do a migration
between domains, the updated version of the AD Migration Tool (ADMT) in
.NET includes the ability to retain user passwords during the migration.
It also simplifies changing the ACLs on a newly migrated server so you
can get rid of SID History as soon as possible.
.NET also resolves an issue for large organizations with decentralized
IT organizations that promote DCs in the field rather than building them
locally and shipping them to a location. If you have a relatively large
AD database and limited bandwidth to the remote site, it can take a considerable
amount of time to finish the initial replication for a new DC. An advanced
feature of Dcpromo in .NET allows you to do the initial load of the AD
database from backup media. You can use this feature to do a system state
backup in one location and burn the result to a CD or DVD that you can
then overnight to the remote location.
Server Administrators: Driver Protection—Finally
It’s happened to me. It’s happened to you. You schedule a short
maintenance interval for a production server to install a new piece of
hardware and just as your time window closes, the machine coughs up a
blue bugcheck screen and becomes a rather expensive and noisy paperweight.
.NET avoids many of these sorts of incidents by taking a lesson from
Barney Fife to “Nip…it...in...the...bud.” A feature called Windows Driver
Protection compares a new hardware driver to a “bad boy” list of drivers
to determine if it’s known to cause problems. The system will refuse to
load any driver on the list. The bad boy list is kept current via Windows
Update. If you update an existing driver and cause a system crash, you
can quickly remove the offending driver and get the system back to status
quo using the Driver Rollback feature.
As a further enhancement to system stability, Microsoft has made it simpler
to write printer drivers that work in user mode rather than kernel mode.
This reversal from the architectural changes made in NT 4.0 is possible
thanks to improvement in the core system architecture. This makes user-mode
printer drivers at least as fast as their kernel-mode counterparts. A
group policy can be used to block installation of kernel-mode printer
drivers on both XP desktops and .NET servers.
Do you want to defrag your servers’ hard drives regularly but not spend
the money on Executive Software’s commercial product? .NET includes a
command-line defragger that you can schedule via the Task Scheduler. The
defragger in .NET is still a subset of Executive Software’s Diskeeper,
but it runs much faster than in Win2K and is capable of defragging the
Master File Table on the fly.
Do you like using unattended scripts for installing servers but don’t
like manually setting up additional partitions after the operating system’s
installed? You’ll appreciate the new DISKPART utility, which can create
any kind of partition and assign it the next available drive letter. You
can even use DISKPART to extend the size of a Basic disk partition as
long as the partition was created using .NET. This is especially handy
for resizing partitions on a hardware RAID array. Just pop a new drive
into the array and extend the partition, and voila!—lots of additional
storage with the same logical drive letter.
A boatload of new commands helps simplify Web server management. There
is IISWEB, which adds and removes virtual Web folders; IISFTP, which adds
and removes virtual ftp folders; IISBACK, which backs up the new XML metabase;
and IISCNFG, which exports the contents of all or part of the metabase
for quick import to another Web server. Cloning Web sites has never been
simpler.
To get a quick view of the system configuration, use the new SYSTEMINFO
command. This uses the Windows Management Interface (WMI) to obtain details
about the condition of the system, its hardware and drivers. To see the
status of services, a new TASKLIST utility lists the running processes
along with their status, process ID, session number and name, the amount
of CPU time allotted since the last restart, the memory used by the process
and any DLLs loaded by the process. If you like this kind of information
and want more, try the WMIC console utility, which lists the entries for
any class of object stored in the WMI information repository.
If you manage enterprise-class application servers and have a few extra
dollars to spend, .NET Enterprise Server supports four-node active-active
clusters and Datacenter Server supports eight-node clusters. For suitably
equipped servers, these versions of .NET support hot-swappable PCI adapters
and memory. But for truly stupendous scalability, look to the latest generation
of servers based on Intel’s Itanium and Itanium 2 processor that run 64-bit
(IA64) versions of .NET Enterprise and Datacenter server. .NET Standard
Server and Web Server don’t have IA64 versions. (See my July 2002 “Windows
Insider” column for more information on Itanium 2.)
DNS Administrators: Evolutionary, not Revolutionary
The DNS improvements in .NET aren’t revolutionary, but they do
improve life considerably for DNS administrators in large organizations.
First, replication for AD-integrated zones has been improved with the
addition of a new naming context, called an Application naming context.
A naming context represents a partition in an LDAP namespace that forms
a separate replication unit. By placing zone records into their own naming
context, you can now target DNS replication solely to DCs that are also
DNS servers. Separate naming contexts are available for domain DNS resource
records and resource records for DCs that host services of forest-wide
interest, such as Global Catalog servers and the PDC Emulator in each
domain.
The Application naming contexts aren’t exposed in the standard AD management
consoles, but you can see them in Replmon and Ntdsutil. If you attempt
to demote a DC that hosts an Application naming context, you’re prompted
to ensure that at least one other replica exists. If one doesn’t, Dcpromo
will refuse to let you demote the DC.
 |
| Figure 5. Conditional forwarding, shown here,
defines a DNS server as a forwarder for a specific DNS domain. |
Another DNS improvement resolves an issue that can arise if you build
a Federation or if you have extranet connections to subsidiaries or business
partners. For example, let’s say there’s a Forest Root trust between the
Company.com forest and the Widgets.com forest. The DNS servers in Company.com
need to resolve names for DCs in Widgets.com and vice versa. Those records
aren’t likely to be exposed on the Internet DNS servers, so some method
is required to resolve the names using internal DNS servers. This can
be done by defining a DNS server in the opposite domain as a forwarder,
but this is difficult to configure if you already use forwarding to resolve
Internet addresses.
.NET resolves this problem by implementing a feature called conditional
forwarding. Using this feature, you can define one or more DNS servers
as forwarders for a specific DNS domain. When the DNS server gets a request
for a resource record in that target domain, it forwards the request to
the defined name servers for that domain. Figure 5 shows how this is configured
in the DNS management console. (Also see "User
Administrators: More Efficient Management.")
Should You Upgrade?
As with many IT expenditures, the final decision whether or not
to upgrade to .NET boils down to a trust that exists between the administrators
and architects who want to do the upgrade and the executives who sign
the checks. You don’t earn that trust easily and don’t want to jeopardize
it unless you’re sure of the benefits. Here’s a quick summary of the reasons
why you may want to include .NET in your budget for next year:
Web servers. Unless you have a critical application that
simply refuses to run under IIS 6.0, you should certainly consider upgrading
your Web servers to .NET as quickly as possible. This not only moves you
to a more stable, scalable, and easily secured Web environment, it also
prepares your Web infrastructure for the introduction of .NET Framework
products such as ASP.NET and the .NET versions of Perl, Python and Java.
The pricing of .NET Web Server might make it an attractive addition to
your 2003 budget, especially considering that each IIS 6.0 server is capable
of hosting many more sites than its IIS 5.0 counterpart.
Security. The .NET Server products were the first to undergo
the extreme scrutiny of Microsoft’s new Trustworthy Computing Initiative.
If operating system security is a top concern, you should evaluate the
ways you currently use Microsoft-based services and ask yourself if each
operation could be done more securely when hosted on a .NET server. I
would especially call your attention to the improved features supporting
802.1x wireless security, Public Key Infrastructure (PKI), and the changes
to the use of anonymous connections.
| Wireless
Security: A Step Up |
|
Another significant improvement in .NET is the native
support for 802.1x wireless security using both PEAP
(Protected Extensible Authentication Protocol) and EAP-TLS
(Extensible Authentication Protocol-Transport Layer
Security). 802.1x security protects a wireless connection
by forcing the computer (in the case of EAS-TLS) or
the user (in the case of PEAP) to perform a secure authenticate
transaction with a RADIUS server before the wireless
connection is made operative. This protects the initial
authentication and key exchange as well as subsequent
key exchanges, eliminating the vulnerabilities that
plague the current implementation of Wired Equivalent
Privacy (WEP). In other words, goodbye Airsnort and
Airpeek.
Security administration is becoming increasingly synonymous
with certificate administration as many vendors incorporate
public-private key cryptography and digital signatures
into their products. .NET incorporates the Advanced
Encryption Standard (Rijndael) and the Advanced Hashing
Standard (SHA-256, 384, and 512) along with a much more
flexible Certification Authority that can store and
reissue private keys used for file encryption and autoenroll
users along with computers. This greatly simplifies
the deployment of cryptography-based technologies such
as the Encrypting File System (EFS) and 802.1x Wireless
security.
|
|
|
Active Directory. If you have a large enterprise with tens
of thousands of users scattered among dozens or hundreds of sites, then
the upgrade to .NET should be a top priority for 2003. The new replication
features alone make it a compelling upgrade. For smaller organizations
that have recently upgraded to Win2K and AD, look at the specific new
features and improvements to see if they address issues in your operations.
For example, the ability to create Federations of trusted forests is a
highly attractive option for organizations such as universities, secondary
schools and government agencies. If you plan to deploy Exchange 2000,
avoid Federations.
Terminal servers. If you run Citrix MetaFrame, you’ll want
to wait for .NET-compatible versions to appear. However, if you want to
deploy a terminal server solution without add-ons, take a long look at
the RDP improvements in .NET and see if they fulfill your needs. Also,
you may want to include the .NET-compatible version of Canaveral iQ from
New Moon Systems in your evaluation to get the advantages of application
publishing with the new RDP features.
File servers. One of the most significant new features
in .NET is the Volume Shadow Copy service and its support for individual
file restores performed by users rather than by backup admins. This feature
alone might be sufficient to prompt to you to upgrade your file servers
to .NET, but remember that you can only take advantage of it if you have
XP clients. As of this writing, there are no clients for NT or Win2K.
If you’re planning to purchase SAN or NAS equipment, you should also evaluate
the improved support in .NET for alternative storage solutions.
Application servers. If you support large database servers
or have applications that require fault-tolerant solutions, you should
begin evaluating the features in .NET Enterprise and Datacenter Server.
If an IA64 version of your application exists, you should definitely make
it a point to evaluate your application running on an Itanium 2 server.