Enter neodsconvert.exe . It was the surgical knife for directory transplants. The typical invocation looked something like this:
REM Step 1: Extract users from eDirectory container O=Acme\OU=Staff neodsconvert.exe -s edir01.acme.com:389 -B "cn=admin,o=acme" -p secret ^ -b "o=acme" -S "(&(objectClass=User)(!(loginDisabled=TRUE)))" ^ -m user.map -o staff_users.ldif -f ldif REM Step 2: Massage DN references (awkward manual step) REM Replace "o=acme" with "DC=acme,DC=com" in the LDIF REM Step 3: Import to AD ldifde -i -f staff_users.ldif -k neodsconvert.exe
If you ever find a dusty .map file on an old NetWare server, or a batch file that calls neodsconvert.exe at 2 AM, tip your hat to the systems administrator who wrote it. They were fighting the good fight—moving bits from one dying directory to another, ensuring that payroll ran on Monday morning. Enter neodsconvert
Think of it as a linguistic interpreter for directories. On one side, you have NDS (Novell Directory Services) or eDirectory—a robust, attribute-rich, X.500-inspired hierarchical database. On the other side, you have Active Directory, with its own schema rules, object classes, and security descriptors. neodsconvert.exe sits in the middle, translating attributes, mapping object types, and flattening Novell’s rich inheritance models into AD’s domain-centric view. To understand why neodsconvert.exe exists, you need to recall the late 1990s and early 2000s. Novell NetWare was the king of file and print services. eDirectory (then NDS) was technically superior to Microsoft’s Active Directory in several ways: truly distributed, masterless multi-master replication, and a more flexible schema. They were fighting the good fight—moving bits from