I remember when most firms' answer to the question “How's your shop doing with interoperability?” was “We're fine; we run on TCP/IP.” More interoperability tools exist today, but now we face a somewhat different and especially annoying problem: interoperability among Microsoft products.
For most people, achieving interoperability once meant that you could make some variation of UNIX, and possibly Novell NetWare, play nicely with some variation of Windows. “Play nicely” primarily meant that you could implement single sign-on (SSO) so that users could change their password in one place and have that place change it on their Sun Microsystems account, their NetWare account, their Lotus Notes account, and so on. That problem has since been solved to some extent, although many of the sites I visit have solved it by using some cobbled-together password-synchronization software.
One popular approach to reducing the number of accounts you have is to run mainly Microsoft OSs and server-based applications and to implement a domain or a set of domains that have trust relationships. Because the applications rely on one domain for authentication, you get a sort of SSO because your domain account is the point of authentication for most of your applications. Relying on one vendor for most of your software can be scary, but at least you get compatibility, don’t you?
Not always. Windows Server 2003, which Microsoft released in April, offers some reasons to upgrade. But although those reasons are good, they aren't compelling, and I predict that for the next few years we'll see some folks running Windows NT 4.0 while others run Windows 2003, Windows 2000 Server, or some combination of the two. Although Microsoft has placed a gun to our heads to try to convince us to get rid of NT 4.0 or suffer the consequences of living with an unsupported server OS, I estimate that about 30–40 percent of Windows shops are still running NT 4.0.
And that brings me to interoperability. With tongue only partially in cheek, I say that I’d love to see Microsoft open an "Office For Intra-Microsoft Interoperability." This group would clearly lay out exactly what does and doesn’t work when you combine different Microsoft OSs. For example, you’d think that an administrative tool such as the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in that shipped with Win2K would be compatible with Windows XP. But Microsoft required a year and a half to finally produce a set of Active Directory (AD) administrative tools that worked on XP. And even so, installing those tools often involves messing around in the registry.
Group Policy is another feature that doesn't work the same way in all Windows versions. An XP or Win2K workstation will look for and adhere to NT 4.0–style system policies, but only if you don't use AD. If the workstation detects the faintest whiff of AD, it ignores system policies and looks only for Group Policy Objects (GPOs). And do GPOs work on Windows 2003, XP, and Win2K systems? Some do, but some don't: Many work on Windows 2003 and XP but not on Win2K, while others run on Windows 2003 only. What happens if you apply a Windows 2003–only or XP-only GPO to a Win2K system? Usually nothing happens, but I've seen instances in which an XP GPO has apparently affected the Win2K system.
Server application interoperability is spotty, too. For example, I've been told that you can put Microsoft Exchange 5.5 on a Win2K AD-based network, and you should be able to run Exchange Server 5.5 on a Windows 2003–based AD system (although I haven't personally tried either of these configurations). But you can't put Exchange 2000 Server on an NT 4.0 domain. And although you can use Exchange 2000 on a Windows 2003-based AD, you can't do so easily—you need to read and follow all the relevant steps in the Microsoft article "How to Upgrade Windows 2000 Domain Controllers to Windows Server 2003." But be forewarned: I’ve written books that are shorter than that article.
Those are just a few examples of how even someone who’s been completely assimilated into the Redmond Collective could run up against compatibility and interoperability problems. And the situation is going to get worse as people continue to use OSs and other software for longer and longer periods without upgrading. As I’ve said in the past, a Windows Server expert must now know three OSs (Windows 2003, Win2K, and NT 4.0). But a Windows desktop expert realistically needs at least some experience with XP Professional Edition, Win2K Professional, NT Workstation 4.0, Windows Me, Windows 98 Second Edition (Win98SE), Win98, and Win95. That's seven OSs—and many more permutations. So I’m somewhat serious when I say that Microsoft (or someone) could perform a great service for the rest of us by compiling in one place all the “this goes with that unless some other thing happens” rules of assembling Microsoft-centric networks.
