In-Depth

The Guide to Windows 2000 Wisdom: My Whistler Whish List

Because Whistler is Microsoft's response to customer feedback on Windows 2000, here's my lists of wants.

People who know me know I love Windows 2000. I’m often guilty of espousing the many countless aspects where it triumphs over Windows NT (and its competitors): the ease of management, its IntelliMirror features and increased stability, to name just a few.

Currently in development, as we’ve reported in these pages, is the next iteration of Win2K, code-named Whistler. With the release of a new operating system comes the opportunity to enhance current features and add some new ones.

The purpose of this article is to voice comments from administrators and consultants who say that Win2K “has missed the mark” in certain areas. It’s not meant to attack Microsoft’s efforts to make Win2K the feature-rich and stable product it is. It’s my hope that these current Win2K issues will be addressed in the Whistler release to further satisfy the ever-hungry desires of Microsoft customers.

I’ve weighted each item on a scale of 1 to 10 to rank its severity in the current implementation. Additionally, I’ve included a “probability rank” to ponder whether Whistler will address a particular oversight. Mind you, I don’t have access to the code or to any top-secret information; so it’s simply conjecture on my part as to what the future may bring.

The Inconsistencies
These Win2K features work as advertised, but in a confusing manner. Customers are hesitant to implement them because it’s unclear how to make the most out of them.

No “Un-Delegate of Control Wizard”
Severity: 8, Probability: 5

The Delegation of Control Wizard is a great feature in Win2K. It allows domain administrators and Organizational Unit administrators the ability to easily grant common abilities, such as “Reset passwords on user accounts,” and uncommon abilities, such as “Write postalAddress” to lower-level administrators via the easy-to-handle wizard-style interface.

But there’s no equally easy way to un-delegate an ability once it’s been delegated away. Currently, the only way to do this is to use the View | Advanced Features option in the Active Directory Users and Computers MMC snap in, then find the permission by right-clicking over the delegated object (such as OU), clicking the Properties tab, then clicking the Security tab, digging around until you come across the permission you wish to remove, and deleting the corresponding Access Control Entry (ACE.)

Some power-administrators might not mind the steps required to revoke a delegated permission. But less-savvy OU administrators will cringe at the process. It should be just as easy to renege on tasks as it is to delegate them. Can your OU administrators perform the necessary steps to un-delegate? Whistler should have an un-delegation wizard.

No Ability To Set Quotas on Groups
Severity: 7, Probability: 8

Although the hooks have been around since NT Server 3.1 (see Q103657, “NTFS System Files”), the implementation of disk quotas is new for Win2K Server. Quotas are implemented on a per-user/per-volume basis. This means that the sizes of files a user owns on each volume is compared against a set number to trigger either a warning message or a ceasing of disk writing to that volume for that user.

Figure 1. The Delegation of Control wizard is a great feature, but what about a “Renege Delegation” wizard?

This works adequately for small customers where there’s one volume containing everyone’s home drive; but Win2K has no facility for specifying a security group (i.e. Engineering) to have a chunk of disk space on a volume.

Instead of specifying, “Engineers can only use 500MB of disk-space,” you can only specify that “Bob (an engineer) can use only 100MB, Sally (an engineer) can use only 100MB,” and so on — which really isn’t the same thing at all.

Interestingly, the Administrators group is immune from disk quotas — so the hooks to make disk quotas apply to groups must be buried in Win2K somewhere.

Quota Entries dialog
Figure 2. Win2K immunizes the Administrators group from quotas, but doesn’t allow so for other groups.(Click image to view larger version.)

Note that third-party disk quota solutions do currently exist to enable group membership. Even if Whistler includes the ability to define group-based quotas, there’s still plenty of room for those vendors to be creative, such as a per-domain- or per-forest-based quota system (hint, hint).

No SMTP Replication Within the Same Domain
Severity: 2, Probability: 9

Win2K does much of its replication chores via remote procedure calls. A new method of replication is via the Internet’s standard way of sending mail messages, Simple Mail Transfer Protocol (SMTP).

If you choose to implement this feature, you might find a bizarre quirk: The SMTP replication method can’t be used to transfer data within the same domain. In other words, the SMTP replication method only works between domains. It’s a small point of order (that’s why I’ve only ranked it a two), but it’s an inconsistency nonetheless.

Chances are slim that many enterprises will choose SMTP replication inter-domain or even care if this feature inconsistency is rectified for intra-domain. Surely, Whistler will clear up this inconsistency.

GPO Links Aren’t Checked When Deleted
Severity: 4, Probability: 3

Companies have many options in how they implement Group Policy Objects. Some organizations delegate an OU to an OU administrator and have that person simply create the GPOs he or she sees fit. Other organizations have upper-level administrators (such as the Domain Administrator) pre-create the GPOs and then force the OU administrator to pick from the pre-created ones. This is called “GPO linking.”

This is a swell idea in theory: Give the harder job to the more seasoned administrators and have the sub-OU administrators simply pick the GPOs they need. There’s only one problem. If the OU administrator has linked to a GPO, but then the upper-level administrator deletes it, there’s no indication to the upper-level administrator that OUs were linking to it. Moreover, there’s no messaging mechanism to the OU administrator to inform him or her that the GPO (and the link) were cut.

Most organizations won’t use GPO linking, but if they do, they’ll be disappointed with this behavior in Win2K. Whistler should add some mechanism to check for GPO linkage relationships. But since it’s unlikely this will be addressed in Whistler, I rank the probability of its getting fixed at a three.

No Schema Deletions
Severity: 8, Probability: 5

The schema is the underlying database for the Active Directory. It’s extensible, which means if you want to add the ability to capture voiceprint or shoe size, the ability is there. It’s roughly analogous to adding a column definition in a database.

But there’s one problem: Once you’ve extended the schema, you can’t go back and fix the definitions. There’s no undo, no delete.

The only workaround is that you can disable the additions, but that’s it. If you enter, “Social Sec Number,” but want to delete it and create, “Social Security Number,” you’re stuck with this vestigial “Social Sec Number” floating around in your schema.

I think the lack of the ability to delete schema modifications is holding back application vendors from fully embracing Active Directory for fear of making a mistake or wanting to change or revise something later in their products’ life cycles. Whistler should make it easy for programmers, application vendors and administrators to change their minds when modifying the schema. I rank this issue a severity level of eight. The probability it will be addressed is a five.

No Security Policy Differential between Domain and OUs
Severity: 10, Probability: 8.5

This inconsistency is a major headache for AD designers.

In NT 4.0, one reason you created additional domains was because you had a group of users with different security requirements than the rest of the organization (such as password length).

Figure 3. Win2K retains the legacy limitation on passwords. Because security settings are domain-wide, you need to set up separate domains for variances in those settings.

Win2K administration is greatly reduced by axing your NT 4.0 domains and bringing them into a single domain.

The only problem is that this requirement is identical for Win2K as it was for NT. If you can’t come to agreement within your enterprise for what the password length, password expiration age, password complexity requirements and Kerberos policy will be, you’re forced, by definition, to create additional domains.

The user interface (Active Directory Users and Computers) lets an OU administrator set the policies any way he or she likes, but they won’t take effect at an OU level.

I rank this item a 10 for two reasons: 1) this inconsistency is counterintuitive to the logic behind having fewer domains; and 2) this user-interface inconsistency seemingly allows an administrator to perform what he or she truly can’t (without any indication to this effect). A main design goal of Whistler should be to have this inconsistency rectified. Microsoft has received much negative feedback regarding this issue, so the likelihood is good that this will be addressed. I rank the probability at 8.5.

Enterprise Computing Enhancements
These features don’t exist today, and they’d take a goodly amount of additional coding by the product-development team to make a reality, but the benefits to the large-scale enterprise customer would be amazing.

No Domain Rename
Severity: 7, Probability: 7

Here’s the scenario: Your company name is LITTLEFISH and your Win2K domain name is littlefish.net. The board of directors has just changed the company name to MEDIUMFISH; hence, they’d like you to change the name of the domain to mediumfish.net. Notice that there’s no technical reason for the change — just consistency throughout the company.

There’s currently no way to do this. If forced to perform this change, an administrator has two options: Migrate all the users, computers and resources to another domain with the new name (using Microsoft’s Active Directory Migration Tool or a third-party tool) or add an UPN suffix name, such as mediumfish.net to the list of possible names in the entire forest. (See Q243629 for “How to Add UPN Suffixes to a Forest.”)

I think we’ll see this issue surface a lot, as businesses seek ways to change their non-dot-com names to dot-com names, and back again. I rank the severity of this issue a seven — people have been clamoring for it for years. Maybe it will appear with Whistler.

No Tree/Forest Merge/Prune/Graft
Severity: 7, Probability: 7

Here’s the scenario: You’ve just gone though the pains of changing your company name from LITTLEFISH to MEDIUMFISH and migrating your users from the domain name littlefish.net to mediumfish.net.

And the bomb drops: Your company is being bought out.

The board of directors informs you that as of tomorrow, the company will be a wholly owned subsidiary of HUGECO. They want you to make it easy for the HUGECO employees to use the MEDIUMFISH AD to look up resources, such as color laser printers, as well as to send Exchange 2000 e-mail.

There’s currently no way to do this. If forced to perform this change, an administrator has two options: Migrate all the users, computers and resources to HUGECO’s domain or add two-way NTLM-style trusts. When you add two-way NTLM-style trusts, the users in HUGECO and MEDIUMFISH will be able to have access to resources in the other’s domain — but true AD integration won’t be achieved. For instance, the HUGECO engineers wouldn’t be able to perform AD lookups for color laser printers, nor could they do Exchange 2000 directory lookups in MEDIUMFISH’s domain without some directory synchronization software.

With all the merger mania running around, I think this issue will come up frequently. I rank the severity a seven. Because this is a particularly sore point about which Microsoft is very aware, I rank the probability of its being addressed at seven.

Active Directory Single Operations Masters
Severity: 5, Probability: 2

In the NT world, if the PDC went down, you were unable to add users or change passwords until the PDC came back up or a BDC was promoted to fill the role. If this happened at 2 a.m., you got a call at home, then had to run to the office and manually promote a BDC to take the place of the PDC. The PDC is the only place you could write the changed account information. The changed information then got replicated to the NT 4.0 BDCs.

With Win2K things are different. All Win2K Domain Controllers (DCs) are equal and writable, which means data can be changed on any of them.

More Jeremy in this issue ...
Find out your options for failing Domain Controllers in “So You’ve Had an Operations Master Die…

On paper this sounds like, if any DC goes down, you can still make changes to the domain and life goes on normally. This is true for all regular Domain Controllers, except those that hold any of the five “Single-Operations” roles: Schema master, Domain naming master, RID master, PDC emulator or Infrastructure daemon. They’re called “Single-Operations,” because each is singularly held on one Domain Controller. One Domain Controller can house many single-operations roles, but no two Domain Controllers can house the same role.

The world doesn’t come to an end if a Domain Controller that houses a single operations master fails. But it isn’t a bed of roses, either. See “So You’ve Had an Operations Master Die…” for the gory details.

Domain Controllers with Operations Masters go down. When they go down in the wee hours, it still means a call to you, the administrator, to manually transfer or seize the role. It’d be nice if Whistler had a rules-based, self-maintaining mechanism for handling the Single-Operations roles. I rank the severity of this issue a five. Chances are this behavior won’t change with Whistler.

If you have suggestions...
...for improving any Microsoft product, you can make a difference. Send e-mail to mswish@microsoft.com and put the product name in the subject: line. Feel free to tell the folks at Microsoft, in explicit detail, what features you want to see in their products.

Take it from me: They usually listen.

Always Room for Improvement
The Win2K development team at Microsoft was under a huge amount of pressure to enhance the NT feature set and produce an amazing number of new features — and to make them all stable as well. At the time of this writing, Service Pack 1 has made its way out the door and Service Pack 2 is expected sometime in Q1 or Q2 of 2001. Yet most Win2K installations I’m aware of aren’t deploying it — not because they’re afraid of the service pack, but because Win2K is already so stable out of the box, why fix it if it ain’t broke?

The Win2K development team needed to walk a fine line between the new feature set and stability. In my opinion, it’s done a terrific job. With any piece of software, there’s always room for improvement. My hope is that the issues highlighted here (and in the accompanying chart, “An Additional Whish List”) will get the attention needed to further establish Microsoft as the leader of enterprise-ready software.

Featured

comments powered by Disqus

Subscribe on YouTube