As we’ve seen above, Windows 2000 has many new features that make it useful for system administrators. But it’s not perfect, and this section gives me a chance to voice a few complaints—and use my sense of humor a bit!
Groups in Windows NT were confusing: global groups were supposed to be used for organizing users together, whereas local groups were intended for managing the access users had to resources such as shared folders and printers. You could circumvent this however by assigning permissions directly to global groups or even individual users if you liked. Though local groups could contain global groups, they couldn’t contain other local groups, and global groups could contain neither local nor global groups.
Have groups been simplified in Windows 2000? Just the opposite. There are now three types of groups that can be used to manage domain users and control their access to resources:
With more groups come more rules for using them. The membership and nesting rules for groups in Windows 2000 are complex and differ depending on whether you are running in native mode (domain controllers are all running Windows 2000) or mixed mode (support for downlevel Windows NT domain controllers).
What’s really interesting in Windows 2000 are universal groups, which have the following attractive features:
- Scalability
The members of a universal group can be from any domain in the forest. (A forest is a collection of domains that trust each other.)
- Flexibility
The universal group’s members can be domain user accounts, global groups, or even other universal groups, and can be nested to any degree.
- Usability
Universal groups can be assigned permissions to grant users access to any resources in the forest.
Universal groups sound really terrific. It appears we can scrap the other types of groups (global and domain local) and instead use only universal groups. And since they can be nested to any degree and can be used to control access to resources in any domain for accounts in any domain, one has a great deal of flexibility in implementing them.
The downside is that universal groups can be used only when running in native mode, which means that you must first upgrade all your Windows NT domain controllers to Windows 2000 before implementing them. There is also a performance issue associated with universal groups: when you make a change to the membership of a universal group, not just the changes you made but the group itself plus its entire membership must be replicated to all global catalog servers throughout the enterprise (global catalog servers help find things in a Windows 2000 enterprise). The result is that if changes are made frequently to the membership of universal groups, the resulting replication traffic may eat up valuable network bandwidth, especially when slow WAN links are involved.
My gripe is that instead of making groups simpler, they’ve made them more complicated, and while universal groups look attractive on paper, they are limited to situations where group membership is relatively static.
Another basic area of network administration is using permissions to control access to shared resources. In Windows NT, permissions were fairly simple to understand: you secured a folder by assigning different NTFS permissions on the folder to different users and groups. (This was usually done by assigning each user or group one of the seven standard NTFS folder permissions, though occasionally some custom combination of the six special NTFS folder permissions was used instead for more granular control over the folder.) Then you shared the folder and left the shared-folder permissions set to Full Control for Everyone (that way you didn’t have to worry about figuring out the effective permissions resulting when different NTFS permissions and shared-folder permissions were combined).
In Windows 2000, permissions still work basically the same way, but with a wrinkle: the naming, complexity, and method of assignment of NTFS permissions have changed. Specifically:
The NTFS standard permission called Change in Windows NT is now called Modify in Windows 2000. Why change something when everyone is just getting used to it? And are they really the same?
In Windows NT there were seven standard folder permissions, but in Windows 2000 there are only six. It sounds like they tried to simplify permissions in Windows 2000, but see my next point.
In Windows NT you selected one of the standard permissions and assigned it to the user or group to control their access to the resource. In Windows 2000, however, you can specifically Allow or Deny any of the standard permissions. Even more confusing, when you do this, whole groups of checkmarks change in the Permissions list box on the Security tab. This can be really confusing! For example, if you Allow the Modify permission, then the four permissions below it (Read & Execute, List Folder Contents, Read, and Write) all automatically become Allowed as well. If you then Deny the Read & Execute permission, all the Allowed permissions become unchecked except Write permission, which remains allowed. Now I suppose this makes sense when you think about it, but the problem is that you have to think about it!
In the above example, when you Deny the Read & Execute permission, a message is displayed below the Permissions box saying “Additional permissions are present but not viewable here. Press Advanced to see them.” If you then select the Advanced button, you see a list of Allow and Deny items for different users and groups you have assigned permissions. Select one of these items and click View/Edit, and a list of 13 (!) raw NTFS folder permissions appears, each of which you can individually Allow or Deny.
Do we really need such complexity for such a simple and basic thing as controlling resource access through permissions? Of course, this gives administrators great flexibility and granularity in managing resource access, but isn’t it more likely to cause frustrating problems in tracking permissions problems if these advanced permissions are used? Perhaps they should take a lesson from Unix, whose permissions structure is much simpler to understand and implement.
The Windows 2000 administrative tools are for the most part implemented as MMC consoles, and these consoles typically display a hierarchical tree of resources in the left pane of their window (the hierarchy is referred to as the console tree). So Windows 2000 networks are therefore managed hierarchically, right? In some ways, yes, but the implementation could have been better in my opinion.
To illustrate my gripe, let’s say I have a domain tree with several domains, each containing a number of Windows 2000 Server computers, and I want to manage users and computers in different domains simultaneously. Here is how I might do it:
Open the Active Directory Domains and Trusts console from the Administrative Tools program group. This console hierarchically displays the various trees of domains in my forest.
Select a domain that contains users I want to manage.
Right-click on the domain node and select Manage from the shortcut menu. This opens the Active Directory Users and Computers console for the domain I selected, allowing me to manage users, groups, computers, and other published resources of the selected domain.
In the Active Directory Users and Computers window for the domain I selected, open the Computers container (or an organizational unit that contains computers I want to manage), right-click on a computer, and select Manage. This opens a Computer Management console for the selected computer, letting me manage various resources on the computer.
Repeat steps 2 through 5 until I can manage all the users and computers that I want to manage in the various domains.
What I have now are dozens and dozens of windows open all over my desktop. My gripe is that the Manage option is a good idea, but it’s more of an afterthought from poor planning when these tools were designed. In other words, Microsoft’s console-based management tools are simply not as integrated or hierarchical as they could have been. Instead of flipping between windows for Active Directory Domains and Trusts, Active Directory Users and Computers, Computer Management, and so on, why not have just one snap-in for all these functions that displays a single console tree? Managing a computer would then be as simple as:
Open the Active Directory Do Everything Dream Tool console (or whatever you want to call it).
Expand the console tree to select the node for the domain whose users and computers you want to manage.
Expand the node for the domain, and select the Users container to display the users and groups you want to manage, or select the Computers container to display the computers you want to manage.
Expand a node for a computer, and select the appropriate management tool in the System Tools, Storage, or Services and Applications container under the computer node. Select a specific tool to manage the computer.
Expand a node for a group to display the users that belong to the group in the console tree under it. Select a user to display further nodes under it, corresponding to the different tabs on the user’s property sheet. Select a node for a specific tab to display the settings for the tab in the right-hand pane of the console.
My dream tool would thus allow me to scroll down a single, hierarchical console tree for the entire enterprise and manage selected users and computers without opening any annoying property sheets (I hate property sheets!) or displaying any irritating messages like “Close all property sheets before closing this tool.”
Speaking of the MMC, I have another complaint that I’ll illustrate using the Active Directory Users and Computers console from the Administrative Tools program group. In this console you can organize your users, groups, computers, and other published resources (directory objects) by grouping them into containers you create called organizational units (OUs). Now this is very cool, since you can create a hierarchy of OUs to reflect the areas of administrative responsibility in your company and then delegate authority over different OUs to trusted users or apply Group Policy to OUs to control the configuration of objects in them. All this gives you a lot of flexibility in how you implement Active Directory, and I have no complaint about this.
But if you later change your mind and want to rearrange objects in your directory, you can do this by right-clicking on the object and selecting Move from the shortcut menu. What I don’t understand is why you can’t simply drag and drop objects from the right-hand console pane into any OU in the console tree at the left. This is annoying, and as you start to work with the Microsoft Management Console, you soon discover that drag and drop doesn’t work with any MMC consoles. As Ratbert says, “Now that’s an eye-opener!”
Still on this topic of administrative tools, it’s pretty cool that Windows 2000 lets me administer printers from any computer anywhere on the network, as long as it is running a simple web browser. This includes Macintosh and Unix machines. Browser-based administration of printers is a great idea and is superior in many ways to the traditional Printers folder (opened by Start → Settings → Printers), but why didn’t Microsoft extend this type of administration to all aspects of Active Directory?
If web-based network management is such a hot thing, then Windows 2000 should let me perform any administrative task involving Active Directory from any remote computer using only a simple web browser. I should be able to create users and groups, configure shares and permissions, set policies, view logs, run backups, and perform any other administrative tasks from any computer regardless of the operating system it is running, as long as it has a web browser installed.
So why did Microsoft not choose to proceed this way with Windows 2000 and instead create the Microsoft Management Console with its vast and confusing array of different snap-ins? I don’t know, but I expect third-party vendors to supply the need here in the near future. And if some vendor does this and does it well, we might soon be kissing MMC goodbye.
Speaking of changing things (recall my discussion of NTFS permissions earlier), it’s surprising that many aspects of Windows NT that we have grown comfortable with and did not really need improvement have been significantly changed in Windows 2000. For example:
Network Neighborhood is now called My Network Places. My guess is that this is part of the My paradigm that seems to be popular with the Me generation, of which I myself am naturally a member.
Right-clicking on Network Neighborhood used to display your network identification. Now you display your network identification by right-clicking on My Computer instead.
You used to configure your network protocols by right-clicking on Network Neighborhood and selecting the Protocols tab. Now you right-click on My Network Places to open the Network and Dial-up Connections folder and then right-click on Local Area Connection.
Windows NT Explorer used to be under Programs in the Start menu. Now it’s called Windows Explorer and is found in the Accessories program group.
Command Prompt used to be under Programs in the Start menu. Now it’s in Accessories as well.
The ODBC configuration utility used to be in the Control Panel. Now it’s in the Administrative Tools program group, and it’s called Data Sources (ODBC) instead.
Folder Options used to be available under Settings in the Start menu. Now it’s hidden away in the Control Panel.
I could go on and on. Have any of these changes made life simpler for the administrator?
Online help is fine and dandy, but I’ve always been willing to
shell out a few extra bucks for the hard-copy version of manuals for
Microsoft products so I could take them on the bus and read them. I
remember being annoyed when I was writing one of my earlier books
(Microsoft Exchange Server in a Nutshell from
O’Reilly) because when I phoned Microsoft to order the print
versions of the Exchange manuals, they said they could send them this
time but were planning on discontinuing printed manuals at the end of
the year. I thought that was pretty heavy-handed at the time.
I was wrong: Microsoft hasn’t discontinued product manuals at
all; they’ve simply renamed them Resource Kits. I’ve got
the Windows 2000 Server Resource
Kit
on my bookshelf, and believe me, this is the manual for the product,
not the Help file that comes with the product. Regardless of what
books on Windows 2000 you buy, you should shell out some bucks and
buy the 8,000-page-long Resource Kit as well, as at some point or
another you’re going to need it. No handy pocket-sized book can
possibly cover in depth all aspects of this behemoth, so the Resource
Kit is an essential reference when you need more information. But
don’t expect either to start reading it from the beginning and
learn how Windows 2000 works, as it is divided up into various
volumes with lots of interdependency between them in terms of
understanding. This is not your light bathroom reading!
In Event Viewer, which is under System Tools in Computer Management, you still have to double-click on an event to display the detailed information about the event. Sure, you can use the up and down arrow buttons on an event’s property sheet to scroll between events, but this is a pain (and the up and down arrow cursor keys won’t work here; you have to click the up and down arrow buttons instead). At least this is better than the Previous and Next buttons in Windows NT, where I could never remember if Previous meant the next item up in the list or the next item down. But it would have been nice if there were three panes in the Event Viewer console window instead of two, and if by using the up and down arrow keys, you could scroll the event list and immediately read the detailed description for each event.
In Shared Folders, which is also under System Tools in Computer Management, you can create and manage shares easily, but you cannot display the contents of a share. This is frustrating if you want to manage a share but you can’t quite remember which share it is you need to manage, and if you could just take a peek inside . . .
Device Manager (which is again under System Tools in Computer Management) is limited to managing hardware settings on the local computer—you can connect to a remote computer using Computer Management, but in this case Device Manager works in Read-only mode. It would be nice if Device Manager could be used to manage hardware settings on remote machines instead of just locally—but perhaps this is too much to ask, as it depends on not just the capabilities of the operating system but also on the design of the Intel architecture and PC hardware standards as well. Of course, if the remote machine is a Windows 2000 server, you could install Terminal Services on it and run Device Manager from a workstation running Terminal Services Client, but managing hardware settings on remote Windows 2000 workstations is what I am referring to here.
If you install Windows 2000 on a computer and configure it to use DHCP, but the DHCP server is not present on the network when your computer first boots up, you’re probably in trouble. This is because the Automatic Private IP Addressing (APIPA) kicks in and assigns the client a temporary IP address from the reserved Class B network 169.254.0.0. The trouble is that this all happens automatically with no warning, and since there were no error messages, you assume that your computer is now up and running on the network. Then you try to log on and browse network resources, but you can’t and wonder what’s gone wrong. The solution is to disable APIPA manually on Windows 2000 computers using the Registry Editor, but my complaint is why couldn’t it have been disabled by default?
Windows 2000 includes a Telnet server now, which is great since it allows you to perform remote administration from the command line. But the handy Telnet client that was included with previous versions has been replaced by a command-line version of the utility. I prefer the old client because you can log a telnet session simply by selecting Terminal → Start Logging from the menu.
Finally, I hate the new personalized Start menu, which only displays shortcuts you have used recently and hides the rest. You can turn this annoying feature off by selecting Start → Settings → Taskbar & Start menu → General → deselect Use Personalized Menus.
Get Windows 2000 Administration in a Nutshell now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
