As the year closes, I continue to hear that Windows XP has failed Microsoft and the PC market. XP was supposed to drive buyers to the nearest store to buy a new XP-equipped PC, but vendors say that's not happening. Let's examine why XP hasn't lived up to its promise and what Microsoft can do to create a big success with its next Windows release (or the one after it).
Microsoft's main idea behind XP Home is to convince users that the Windows Me and Windows 9x platform is unstable and persuade them to cleave to an OS based on the Windows NT kernel. But the sad truth is that reliability doesn't sell. Furthermore, XP Home and XP Professional don't offer many new features. XP Pro is nothing more than a 1.1 version of Windows 2000 Professional. Other than Remote Desktop Connection, I can't see any major improvements. In fact, XP's new "Playskool" interface with the bright colors and pretty icons makes a support person's job harder; getting to the Network Control Panel, for example, takes more mouse clicks than it did under Win2K. I haven't found one administrative tool that's quicker to access under XP Pro than it was under Win2K Pro. You can't even run the Win2K Administrative Tools under XP Pro; you have to get the tools from Windows .NET Server Beta 3 or download a beta version of the tools from Microsoft's Web site. Was Microsoft trying to imply that you shouldn't use XP if you have to administer Active Directory (AD)?
I suspect that Microsoft is simply running out of new things to add to a desktop OS. Until we can communicate with computers in colloquial human language, what other functionality can you add to a desktop OS? An OS lets you install, uninstall, and start programs; manage a file system; and add new hardware via drivers—and Win2K Pro already does those things well.
Microsoft's dilemma is similar to the problem the automotive industry has selling cars: There's not many more features that manufacturers can add to cars and, therefore, few reasons for people to upgrade. (Maybe that's why XP's main feature seems to be the new UI—just more chrome and fins on the old vehicle.)
So what features will help sell a new version of Windows? Well, the desktop might be out of opportunities for improvement, but the server isn't. If Microsoft wants to create excitement for Windows, the best thing the company can do is enhance its AD services, and it needs to give users a timetable for those AD enhancements.
AD is a great first effort. The version of AD that shipped with Win2K was a 1.0 version of a very large piece of software that aims to create a superstructure that all businesses can hang their hats on. AD 1.1, which will ship with Windows .NET Server, is a great improvement, letting you rename domains and build trust relationships among forests. AD 1.1 also fixes several annoying limitations, such as handling group memberships and partitioning AD replication.
But the improvements don't go far enough. AD is too inflexible for most enterprise environments. You'd better build your AD structure right the first time because AD is a pencil without an eraser. That inflexibility isn't reasonable in the real world; every company's organizational chart changes occasionally and someone has to rearrange the network to reflect those changes. If you designed your forest as just one domain with organizational units (OUs), you're lucky—rearranging OUs is a piece of cake. But if you want to rearrange domains in a forest, you're out of luck. Microsoft's best answer is that you need to use a migration tool, which is an expensive proposition unless your company is small enough to be able to use the free Active Directory Migration Tool (ADMT). That answer is just not acceptable: Microsoft needs to solve AD's limitations, not offer a workaround. The following list describes some of the functionality Microsoft needs to add in future AD versions:
- Different schema in different domains: Right now, a change to a schema in one domain changes the entire forest's schema. So loosely confederated organizations, such as educational and research organizations, might find that one department's installation of an AD-aware application causes schema changes that step on other schema changes made by another department's applications.
- Schema rollback: Currently, you can't delete an item from the schema. Other databases can handle this task; AD should be able to, as well.
- Reorganizing forests: If two companies merge and they both already have AD forests in place, there's currently no way to unify their forests into one forest. Yes, Windows .NET Server will let the companies create a forest-to-forest trust, but they'll still have two Global Catalogs (GCs), so applications such as Microsoft Exchange Server still see them as two different organizations. Yes, a migration tool could help, but they cost money, and it's ludicrous to suggest that AD out-of-the-box is only for organizations that never change.
- Simple delegation rollback and reports: If you're a new administrator in an existing AD, you can't easily determine what delegations the previous administrator made. If your predecessor didn't document delegations, then you're in for a painstaking process of searching through every container object in the forest to determine which administrative powers the last administrator granted to users and groups. AD should let you simply and quickly generate a report that says, "The variations from the out-of-the-box domain delegations are as follows: Joe Smith can reset passwords for the Engineering OU . . ."
I'm not saying that Microsoft must fix these limitations immediately, but users won't see AD as a mature product until the company addresses them. If Microsoft would give us a timetable of when we'll see these improvements (e.g., forest reorganizations by 2004, separate schemas by 2005), we'd have greater confidence that sometime soon, AD will move into its adolescence. Otherwise, we have to wonder whether Microsoft ever intends to address these problems. And if not, many firms won't migrate to AD—or the next Windows OS. Maybe Novell stock isn't such a bad idea, after all . . . .
