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
• November 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.

Also See: User Administrators: More Efficient Management The Shadow-Copy Knows Wireless Security: A Step Up

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.