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.
 |
| 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.
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 [email protected]
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.