Active Directory and eDirectory

Reading Time: 12 minutes

It's not easy to look objectively to the differences between Microsoft's Active Directory and Novell's eDirectory. It's even harder to choose between them for your identity and security infrastructure needs, when your customer wants you to look at them objectively, especially when most of the information is sales material. From a sales position it's good to rely on your own strength and sensible not to slander your competition.


Since the Active Directory and the eDirectory make up most of the market I'll compare these Directory Services in most detail. When other Directory Services provide more value for money, features or benefits I'll mention them briefly. In this post I will try to be as objective as possible to both directory services and not be as prejudice as you might expect me to be as a blogger on Dirteam.


The information in this post is based on personal findings, research and information available in 2006. Undoubtedly this information becomes obsolete when either Microsoft or Novell introduce a new version of their Directory product. I don't want this post to be the authorative post on the choice between the Active Directory and the eDirectory, but I will be thorough and I will try to give you as much real world information as possible.

Furthermore I don't intend to harm anyone's feelings. I feel Novell's eDirectory and Microsoft's Active Directory are both fantastic LDAP directory products that make the lives of so many systems administrators livable. I also feel that you can benefit from choosing the right directory for your situation or organization.


The Comparison

Fields of comparison

There are many ways to compare Directory Services. In their sales materials Novell and Microsoft compare their directory products in different ways. Let's compare the Active Directory and the eDirectory on the following:

  • Manageability; (capability of being managed or controlled)
  • Scalability; (ability of being scaled and the quality of being scalable)
  • Security; (freedom from risk or danger)
  • Compatibility;  (capability of existing or performing in harmonious or congenial combination)
  • Supportability; (capability to "be supported" in the field)
  • Reliability; (Probability of good working)
  • Interoperability; (ability of software from multiple vendors to communicate meaningfully)
  • Cost.

It's hard to compare both products without dragging the operating system and the environment in which you're using or going to use it into the equation.



How to manage your Directory Services?. When you use Microsoft Windows Server you can use the Microsoft Management Consoles (MMC's) to administer your Directory. When you use Novell's eDirectory you can administer it using ConsoleOne and iManager (Unfortunately iManager isn't the most robust or useful of management tools… yet).

Management tools

Novell claims there are more tools to administer eDirectory from a variety of platforms than there are tools to administer the Active Directory.  This is an advantage for the eDirectory, but only if you want to implement various platforms and want to administer your Active Directory from platforms other than Windows. Microsoft's MMC approach makes administering your server straightforward, expandable (to your workstations) and easy: just get used to one look-and-feel. You can only use it on one platform (Windows) but nonetheless you can administer (almost) anything you want with it; from the Active Directory schema to the .Net framework on the computer in that lab on the other side of the world.

Delegated Administration

Everyone that has been on the verge of a burn-out has delegation of administration on his or her wish list. Administering huge environments alone isn't always possible and regulatory compliance simply states tracking changes to persons and role-based authorization. In the world of eDirectory delegation of administration is longer around than in the Active Directory universe. Role Based Services however can only truly be used in iManager, which isn't the most intuitive management tool around (where I work we have a proverb on Novell's 'i' tools). Novell is working on a new version of iManager that outperforms and outweighs the current version (version 2.6). In Active Directory every object has an Access Control List (ACL) but you'll have to make taskpads to make lesser administrators use and understand it. The Delegation of Control (DoC) Wizard comes to your rescue and if you're confident enough to do it without a wizard you can! (and accomplish better results too…)


Monitoring is vital to the wellbeing of your directory. Novell adds functionality to basic protocols like SNMP by throwing iMonitor in the mix. Microsoft offers MOM. It's safe to say both directories are easily monitorable. The difference here is there are a lot of 3rd party monitoring tools that are specifically written for Microsoft Windows-based systems.



There are two ways of improving your current directory solution. You can add more nodes (which is known as Scaling out) or you can add more resources (which is known as Scaling up) Novell and Microsoft both decided to emphasize scaling out. Especially for Microsoft scaling out was necessary since the Extensible Storage Engine isn't the highest performance database solution in the world.

Scaling out

Both directories aren't suitable for clustering in the usual way systems get clustered. You might also say Active Directory and eDirectory are clustered by default. They both present you with some sort of multi-master model in which you can place multiple directory servers hosting the same directory. In this model all servers are responsible for the directory and in the event that one server fails the other server(s) still host the directory so it doesn't get lost. The multi-master models used have a few drawbacks. Novell found more elegant solutions to these problems, but Microsoft's solutions are adequate. Microsoft's solution with FSMO roles causes limited management functionality when one of the masters fail and can therefor not be looked upon as a 100% multi-master model. Novell on the other hand urges its certified people to perform schema updates and other major tasks on one single server.

Scaling up the database

Novell's solutions make the eDirectory more suitable for enterprise implementations than Microsoft's Active Directory. I haven't heard of an Active Directory (test) implementation with more than 60 million objects, except for the one recently to prove a single ADAM database can theoretically contain roughly 2 billion objects. Novell claims there is no maximum to the number of objects within the eDirectory and demonstrated it with 1,5 billion objects.

Why Microsoft is still holding on to it's Extensible Storage Engine (ESE) database for storing Active Directory (and for that matter: Microsoft Exchange Server) objects might have good reasons, but it's negatively affecting the size of the database. An eDirectory database is nearly two times smaller in size than an Active Directory database with the same amount of objects. Besides the relative inefficient database lay-out accounting for the difference there's also the different way of storing rights. Where eDirectory works with a system that combines inherited rights and Access Control Lists (ACL's), the Active Directory stores an Access Control List (ACL) for each object.

Crippling large implementations as well is the fact that in Microsoft's Active Directory Organizational Units (OU's) aren't security principals. In contrast with the eDirectory this means that in Active Directory uniqueness for your objects username is required on a domain level instead of the OU level.

In Microsoft's long term vision all products that are using the Extensible Storage Engine or any flavor of the Jet Blue database will be fitted with a Microsoft SQL Server database and to de-emphasize other products that use it. (like WINS) There is certainly light at the end of the tunnel, gentlemen!

Scaling up the server (32 bits vs. 64 bits)

Microsoft has a 64 bit solution in the form of Microsoft Windows Server 2003, which allows it Active Directory to work with more than 4 GigaByte (GB) of RAM. Novell's eDirectory doesn't have 64bit support on Novell's Netware, but SuSE comes to the rescue! Rumor has it Novell's Open Enterprise Server 2 (OES2) will be available in 32 and 64 bits, but will this give the eDirectory the ability to put more than 4GB of RAM to good use?

When you have a relatively small directory 64 bits won't do you much good, but as Microsoft clearly points out in this whitepaper having a database that is fully cacheable on the 64 bit version of Microsoft Windows only (bigger than 2.5GB) gives it a dramatic performance gain.



The Directory Service

I haven't heard of any viruses attacking a specific Directory Service. However no Directory Service can claim it's secure… unless it's not cased in lead, buried in concrete and stored 15 meters under the ground without any cables sticking in or out of it. But that won't make it very useful for your organization, now would it?

The operating system hosting the Directory Services

Microsoft's Active Directory can only be implemented on Microsoft Windows boxes, where Novell's eDirectory can be hosted on a variety of operating systems. Sure, Microsoft's operating systems are rumored to be the least secure Operating Systems in the world, but this is considered to be merely an echo from the Windows 9x era. Microsoft Windows Server 2003 with ServicePack 1 has a small surface of attack and when you only implement it as a Domain Controller there's little risk involved. Versatility is Microsoft Windows' biggest plus, but I have to agree with Paul: If you put your Domain Controller to other uses and install it (for instance) as a webserver you deserve your behind getting pwned. (rather free interpretation)

Furthermore I think it's reasonable to say that Microsoft Windows (Server) gets a lot more exposure due to it's wide spread use and therefor more attention from malicious people or people that desire to prove they can be malicious than Novell's Netware.

Security benefits from a directory service

An organization can benefit from a good directory implementation. Microsoft's Active Directory with its Group Policies and Security templates and Novell's eDirectory with its ZENWorks Suite allow you to lockdown the desktops in your organization. Where Group Policy Objects can only be applied to Windows desktops, Windows servers and (when using Microsoft Exchange features) Windows mobile (5) handhelds, Novell's ZENWorks 7 Suite allows you to manage all these and even manage Linux desktops, patch Windows, Linux, Macintosh, Solaris, AIX, HP-UX and even Citrix and Adobe patches. This is way more than just a few simple LDAP and Kerberos integration tricks Microsoft currently offers for these platforms.



Platform compatibility

You can only install Active Directory on a Microsoft Windows server. Choosing the version of your Windows Domain Controller (Microsoft Windows 2000 Server, Microsoft Windows Server 2003 or Microsoft Windows Server 2003 R2) means choosing the features you want to be able to use.

Novell's eDirectory comes in packages for Novell Netware, Microsoft Windows, Linux, Solaris, AIX and HP-UX. When you want to run eDirectory 8.8 on a Netware server however requires Novell Netware 6.5 which strictly allows it to run on the latest version of Netware only. Choosing the directory version means choosing the Novell Netware version.

Client compatibility

Microsoft offers an endpoint-to-endpoint solution: Whether you want to install an Operating System on your servers or workstations, want to deploy a firewall, a CRM or ERP application, website or want to use a handheld device… Microsoft offers you a product to do that. Novell nowadays offers an endpoint-to-endpoint solution too, but not many people are using it yet so they're typically still stuck with Windows workstations with Novell clients in their eDirectory environment. Novell's vision in the last years, provide platform independent services, has lead to this situation where you have desktops with add-on software by Novell enabling it to work with the eDirectory. … and sometimes stops working because of a patch or hotfix issued by the company behind your desktop's Operating System.

Manufacturer compatibility

It's hard to administer or implement an environment when one of your two main software suppliers deny the existence of a third manufacturer. In Novell environments you see a lot of Windows-based application servers. Some of the applications however don't mention Novell anywhere on their websites or in their support contracts. This might present a problem when it's a business critical application or process. Novell virtually denying the existence of Citrix is one of many fine examples.

Don't forget the additional products that interoperate with Novell's eDirectory as well: How many Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP)programs do you know that work well in conjunction with Novell GroupWise?



Deployed software is subject to change, because people and organizations change. In this day and age your deployed directory will have to change accordingly. Although you might be able to implement a good solution chances are someone else will wreck it for you. Likely your task will be to fix it.

In an Active Directory environment there are relatively little possibilities to wreck the system when you just use the Active Directory Users and Computers MMC. Even though you might succeed using adsiedit, ntdsutil or other tools the AdminSDHolder process will save your behind most of the times.

In an eDirectory environment there are the same ways to completely annihilate your admin account and there are two ways to help you solve all your problems: dial Novell support or dial a Novell (Gold) Partner. When you let them dial-in (don't let the word fool you, they use VPN nowadays too) they will restore your admin account or whatever you managed to trash. You won't have easy access to their tools however. It does make me feel like a little kid that isn't trusted on his own in the candystore.



Novell eDirectory on a Novell Netware server has a tremendous reputation for it's reliability. We all know downtime is costly and Novell servers have been known to run for years without any downtime. Novell adepts will state that Microsoft Windows has a reputation in the other way, but that's not applicable in this comparison.

Uptime statistics

There are two good reasons why Microsoft Windows servers have smaller uptimestatistics:

  • ServicePacks, hotfixes and patches
  • Badly written (3rd party) applications
  • Badly written (3rd party) drivers

Besides, we're talking 'statistics' here! We're techies, not politicians! Statistics aren't of any use when you look at dedicated Directory servers. Put two or three dedicated Directory machines in your organization. Then pull one or two of these servers down for maintenance or install an application on one of these servers and look at the statistics on the uptime of your Directory: It's 100%.

the Truth

The point made by Novell that it's directory service is more mature is a true statement and Microsoft still has a huge job catching up. Note however that with Microsoft Windows Server 2003 and Microsoft Windows Server 2003 R2 a lot of the features of eDirectory got delivered. Embraced, not (yet) extended.

The 'catch' here is that you'll need Microsoft Windows Server 2003 (R2) Domain Controllers to gain these features. When older Domain Controllers are involved you can't use benefit from these features, because they get 'unlocked' when you raise your functional levels.



Both Microsoft and Novell made products that enable their customers to integrate technologies from other suppliers into their Directory Services and to interoperate with even more products. They both walked down a different path though.

The Novell path

Novell walks down the opensource path and has a great range of products to let it's eDirectory interoperate with opensource servers and clients. One of the most noticeable products is the Open Enterprise Server (OES) which is Novell Netware or a Linux kernel. Other noteworthy products are the Novell client and ZENWorks 7 suite. The opensource path is a good path, but Novell doesn't really have a choice to walk it. Since it had no endpoint to endpoint solutions you had to use a product like Microsoft Windows or SuSe Linux on your desktop. With Novell SuSe Linux and Novell OpenOffice it produces a product range that includes all of the standard components.

The Microsoft path

Microsoft walks down a path where it focuses on the allroundness of it's product, because their products are all around us. Many eDirectory based companies use Windows desktops. Microsoft encouraged every large software producer to make their products compatible with Microsoft products which enlarges it's allroundness. The downside to this typical marketleader approach is that Microsoft itself interoperates badly with technologies that don't want to interoperate with Microsoft products. Novell's marketleadership in Directory Synchronization products is the perfect example in this.

Single Sign-on

According to Gartner there is a big misconception about what a directory service will and will not provide. The most common misconception is that a directory service will somehow magically solve the single sign-on problem. Every application and operating system has its own authentication architecture, which prevents and allows certain interoperability with the directory service. The approach that Microsoft and Novell choose to solve this is to synchronize accountinformation. Microsoft Identity Integration Server and Microsoft Windows services for Netware are Microsoft's products for this use. Novell supplies you with Novell Identity Manager. If you don't want to choose between eDirectory and Active Directory you don't need to.



This is the real hard subject, especially if you're from the Netherlands and businesses look at cost first instead of the above fields of comparison. In order to really give you an estimate of the cost involved I'll lay down three scenario's in which you can choose between eDirectory and Active Directory. That way you can calculate your own costs involved:

Migrating from one to another

In this scenario your company for instance uses Novell Netware, Novell eDirectory and Novell GroupWise and you're evaluating the cost involved in switching to Microsoft Windows Server, Microsoft Exchange Server and the Active Directory. You will have to take the following costs into consideration:

  • Cost of licensing
  • Cost of training for your users and administrators
  • Cost of Maintenance Due to Higher Security Risk
  • Cost of support (both internal and external)

Gartner clearly states that the cost involved to migrate from one Directory to another isn't worth the investment. This might be true when your technical situation doesn't change. The situation is different when you want to introduce new technology that is more compatible with one directory than another.

Migrating from old to new

Let's look at a migration scenario where you'd be migrating from Microsoft Windows NT4 Server and Microsoft Exchange 5.5 Server to Microsoft Windows Server 2003 and Microsoft Exchange Server 2003. Your primary costs would involve:

  • Cost of licensing
  • Cost of training

The cost of licensing in a Microsoft scenario could be minimal when you purchase Software Assurance and use some of the licensing advantages Microsoft offers you for leaving your nowadays unsupported environment. Never underestimate the cost of training when a NT4 shop migrates to the Active Directory…

Your organization, your education partner, your support partner and your licensing partner can supply you with a more detailed overview of the cost involved.



It's better to choose eDirectory when you plan to:
(choose one)

  • Implement a really large Directory;
  • Supply your users with non-Windows desktops;
  • Implement and/or use a vast amount of non-Windows servers;
  • Consider opensource to be the best thing since sliced bread;
  • Use software that has specific eDirectory requirements.
    (think about: GroupWise, Bordermanager etc.)

It's better to choose Active Directory when you plan to:

  • Implement and/or use Microsoft Windows-only servers and desktops.
  • Use software that has specific Active Directory requirements.
    (think about: Citrix, Exchange Server, ISA Server, etc.)

If you want the directory with the best trackrecord choose the eDirectory. It is the most mature solution and is best designed. Active Directory is catching up though! If your goal is a flexible solution to address a specific (application) problem choose Active Directory Application Mode (ADAM).

If you can't choose between Novell eDirectory and Microsoft Active Directory choose (the best of) both (worlds) and synchronize.


Norbert Klasen's thesis on Directory Services for Linux (dated August 2001)
Novell's Directory Services Competitive Guide (dated November 2001)
Novell on eDirectory vs. Active Directory (PDF document, dated September 2004)
Novell Cool Solution regarding Active Directory and eDirectory (dated October 2004)
Yankee Group's report on migrating from NDS to active Directory (dated December 2004)
Microsoft's executive summary on eDirectory (Word document, dated November 2005)
Adi Oltean on his MSDN Blog: Supportability is not a feature
Large AD database? Probably not this large… (Eric Fleischmans WebLog)
Whitepaper on Active Directory Performance for 64-bit Versions of Windows Server 2003



For those of you interested in a comparative matrix so they can add their own weight to the fields that interest them most or apply most to their organization:

Field of comparison


Active Directory

















14 Responses to Active Directory and eDirectory


    Hi, I see that you linked to my blog. Unfortunately you misread both my statement on scale as well as the MS documentation.

    The numbers quoted (60M objects in MS documentation as well as 2^31 objects in my post) are about a *single server* scalability. It is not about the # of objects in a replica set (ADAM terms) or forest (AD terms).

    So, in my case where I used ADAM, I could have had 2^31 objects per server with hundreds or more servers in the replica set. Considering this is not the economical way to scale, I would never assume anyone will hit this. We tend to see people scale by putting a few million to 25M or so objects on each server and simply adding more servers.

    So, please reconsider your comments on scale. We scale to infinity and beyond as well….we just encourage scale out as this is more economical. I believe that eDirectory has the same story. Again, more economical.


    Next up….reliability.
    I honestly do not understand how you came to your conclusion.

    I don't understand your comment about AD and R2. We did not add a single core AD feature in R2 (we did in ADAM). So what does this have to do with anything? R2 has no AD forest functional level, and in fact ADAM has no functional level either.

    With that, can you please comment further on what made up your position? I don't understand how you came to your conclusion, it seems arbitrary to me.


    Next up, your security comments. Again, I don't see where your position comes from.
    At first you comment on OS security generally. This is confusing to me as so far you have only commented on the DS itself, so the vectors you comment on seemed moot to me.

    Then you went on to GP and other *desktop* related security technologies. Again, none of this seemed relevant to me considering this was a conversation around the directory itself and selecting a secure directory.

    So, can you please comment on this further? Again, I don't understand where your position came from, it seemed to be a decision based upon things you saw on the desktop, not on the servers themselves hosting the DS.


    Eric, thank you so much for your comments!

    On scalability you're right on the mark. I've rewritten pieces on scaling the database to reflect this.

    Allthough you're absolutely right that Microsoft Windows Server 2003 R2 doesn't come with new functional levels I maintain to believe Microsoft Windows Server 2003 R2 adds a couple of things to the Microsoft Windows Server 2003 family to put the Active Directory to better (or at least more effective) use. Two of the biggest features of R2 are about replication (DFS-R and RDC) and storage / print management. The first feature provides you with more effective replication and lower bandwidth requirements for your Active Directory deployment. The second feature adds File and Print management; a field where Novells solution are traditionally strong. The last sentence on Microsoft Windows Server 2003 (R2) was perhaps poorly choosen: You need to upgrade to a flavour of the Microsoft Windows Server 2003 family.

    I find security in a directory service comparison a difficult subject. In my opinion both directories are at least equally secure (or rather insecure) and in terms of choosing the right identity and security infrastructure solution I feel the difference is made on the desktoplevel.


    Certain features that were introduced with Microsoft Windows Server 2003 R2 require schema updates. In that way they are indeed very much like Microsoft Exchange, true.

    One might get the impression from my text that SYSVOL on a Microsoft Windows Server 2003 R2 Domain Controller benefits from DFS-R as well, but this is only indirectly. However, when designing an Active Directory environment with Distributed File system (DFS) for a customer with different geographic locations I'd make different designs in pre-R2 and R2 situations because of the changed bandwidth requirements. Possibly better aligning with the customer's business needs…

    I considered making a server platform security comparison between a product that you can only implement on Microsoft Windows and another product that you can implement on at least seven different flavors of operating systems would make this post long and inaccessible. Now it's just long [A]

    Therefore I choose to make a directory security comparison based on the overall security of the implementation. In the matrix I let eDirectory 'win' on the security matter. Although Active Directory isn't more or less (in)secure than eDirectory the latter lets you choose your platforms. (both client and server) The scope of security therefore can simply be bigger which would make a customer benefit more.


    Little comment for reliability part: You don't have to run Windows 2003 R2 to get multi-master replication. AD works in this way since Windows 2000.

    And regarding SYSVOL and DFS-R: LH will use DFS-R for this.


    Thanks for your response. A few things to add.

    First, both of the items you mention (DFSR and RDC) are unrelated to AD. They both leverage AD, but are not at all related. That is to say, they are related to AD in the same way Exchange is related to AD…they are AD clients, nothing more. In fact nothing even in the DS itself uses them on any level. Even things that are often considered tightly AD integrated (like policy) can use them as one can not replicate SYSVOL with them. So I honestly still do not understand the relevance. Can you please clarify?

    Next on security. I do not understand why we are having a desktop security conversations, but ok, we are. If that is the case, why is there no mention of desktop security in this post? I mean, if you're to really weigh them (which I do encourage you to do), why would you not look at the platform? I guess I don't understand your approach here. This post doesn't delve in to desktop security yet you are making a server security decision based upon a desktop analysis? Can you please clarify this?



    Tomek, I've changed this bit. It could be read in a variety of ways and didn't clear anything up. I guess when you're working a long time on a post you develop a blind spot for these kinds of things.

    It's good to see Windows Server Codename "Longhorn" will put DFS-R to use for replicating the SYSVOL.


    Having read this article before it was published (and vehemently commented on it), I can understand a lot of Sander's points, and have to agree with them.

    Personally, I think it's rather difficult to judge a Directory Service nowadays without being influenced by its effects on sides such as host OS, 3rd party compatibility, etc, and therefore it is very feasible to take these aspects into stride when examining at a Directory Service. However, if you were to do that, you'd be writing a lot more than just these 11 pages you sent me, boyo. 😉 Especially as different AD versions are related to the implemented Windows versions, things might enter the grey area at times.
    Still, as I told you before, a strong post with a lot of points worth considering when making such a choice. And, let's be honest, a lot of the reasons to choose between AD and ED aren't even related to the DS-specific features. It's things like Printer Management, DFS-R, domain restructuring (alright, so that one's a bit more DS-related than the others) that we care about, isn't it ? 😉

    Still, I'll save more of the discussion for Friday when I'm at HQ again, so we can discuss and disagree on security again. I'm sure you're right, but I'm more right than you are. 😛


    Hi Sander,

    In addition to what others said:

    Where eDirectory works with a system that combines inherited rights and Access Control Lists (ACL's), the Active Directory stores an Access Control List (ACL) for each object.

    W2K3 implements Single Instance Storage for the ACLs. If multiple objects have identical access control lists (ACLs), then Active Directory will only store one instance of the ACL. Compared to W2K the DB size is reduced after performing an offline defrag when on W2K3 DCs

    Where Group Policy Objects can only be applied to Windows desktops, Windows servers and (when using Microsoft Exchange features) Windows mobile (5) handhelds, Novell's ZENWorks 7 Suite allows you to manage all these and even manage Linux desktops, patch Windows, Linux, Macintosh, Solaris, AIX, HP-UX and even Citrix and Adobe patches.

    Vendors like Vintela/Centrify provide tools/software to integrate non-Windows host with AD.

    The 'catch' here is that you'll need Microsoft Windows Server 2003 (R2) Domain Controllers to gain these features. When older Domain Controllers are involved you can't use benefit from these features, because they get 'unlocked' when you raise your functional levels.

    No you don't. You can use R2 functionalities without having R2 DCs. All servers that need the R2 functionality must be W2K3R2. However, extending the AD schema to support some of those functionalties is a must (e.g. printer connections through GPOs, DFS-R, etc.)




    This thread is pretty old, so I almost hate to comment, but I can't resist.

    You gave the nod to Microsoft on Compatibility. I guess that's because of the number of 3rd parties that specifically require Active Directory or something – not because AD is actually designed to be more compatible with 3rd parties. That's just their monopoly kicking in again. eDirectory, like most of Novell's products, are designed based on open standards (that's different from open source). I have to disagree on the compatibility bullet.

    On supportability, I don't even know what you mean. That makes no sense.

    On interoperability – what? eDirectory has more OS support and they adhere to standards better. Microsoft mutates standards, such as LDAP, into their own version, forcing 3rd parties to support two versions of everything or to only support Microsoft because of their market share. It's not by accident, and they are certainly not the example of interoperability.

    Contrary to Fleischman's perspective on security, I think it's very appropriate to tether the security of the directory itself with the OS that it runs on when the directory only runs on that one operating system. Seriously, don't refer to Windows 2000 and 2003 as different operating systems. If you only run on Windows, and Windows is insecure, you're insecure by association.

    Jorge mentioned Single Instance Storage for ACLs. It's nice that it helps shrink the database size, but it doesn't address the real problem. AD can't offer truly dynamic inherited rights as eDirectory does. Maybe when Intel releases a 1024 bit, 100 core processor that supports 128 petabytes of RAM, Microsoft can make it perform well enough. And this is off topic, but for god's sake, fix NTFS. It's still doesn't offer what Netware TFS or NSS has had for years. And don't act like NTFS is good or something – Microsoft is trying to replace it; they're just not having much luck.

    It's also very kind – very kind indeed – to attribute Windows' security problems to it's install base. Netware has been around for a long time, and has a very wide install base. It's more secure because it was designed from the ground up to be secure. Windows is insecure because it was designed as a personal operating system that has been upgraded over and over again to become what it is today. If not for the explosive climb in hardware performance, Windows wouldn't be able to contend with well designed operating systems. It's years of legacy and backward compatibility. Microsoft would do well to take what they've learned over the years along with their virtually unlimited R&D budget and design a new server OS from scratch – design it from the ground up for performance and security – and use virtualization to host a compatibility layer for the transition. There's just too much bad code in there – or just too much code in general.

    Well, anyway, it's always interesting to hear the Microsoft professional's point of view and compare that to reality – not you Sander, I know you were trying to be objective.


    Appreciate you sharing, great post.Thanks Again. Keep writing.


    This is a very informative post and with all the constructive comments to it, makes it a great one. Since the original post is from 2006, it will be great to see a revised version of this in 2015. Keep up the great work.


    Wonderful web site you have here, i do agree on some factors,but not all.