Member Avatar for jovypinoy

Hi,

Does upgrading from Windows NT Server 2000 to Windows Server 2008 will fix my problem on corrupted databases and active directory.

Our Windows NT Server 2000 is unusable because of lsass.exe - system error and I tried everything to fix it but no luck. I am wondering if I'll upgrade to newer version, will it fix the problem? Although I could access the file as another drive / slave. But I don't want to reconfigure everything (call me lazydog!).

But if no other option. Of course, I'll go with reconfiguring everything..

Any suggestions would be much appreciated.

Thanks in advanced,
Jovy

  • 2 Contributors
  • 1 Reply
  • 421 Views
  • 30 Minutes Discussion Span
  • Latest Post Latest Post by JorgeM

Dani AI

Generated

Short answer: no — an upgrade alone is not a reliable way to “fix” a corrupted Active Directory/NTDS database. If lsass.exe is failing and the directory service cannot start, an in-place upgrade will likely fail or simply carry the corruption into the new OS. For Windows 2000 domain controllers you cannot jump straight to Server 2008 with an in-place upgrade (there’s an intermediate 2003 path), so the safe, supported routes are repair (if possible) or a rebuild/migration. Deploying AD DS in a Windows 2000 Organization (learn.microsoft.com)

Immediate, practical steps (in order of safety):

  1. Stop. Take a full image of the failed server and a copy of the NTDS folder (NTDS.dit + log files + system state) before you touch anything.
  2. If you have a recent System State backup, perform a system-state restore (nonauthoritative first; authoritative only if you must) following Microsoft’s forest-recovery guidance. AD forest recovery / nonauthoritative restore. (learn.microsoft.com)
  3. If no good backup: boot into Directory Services Restore Mode and run semantic checks (ntdsutil → semantic database analysis) and file integrity checks before attempting any destructive fixes. (learn.microsoft.com)

If no backup and nothing else helps: esentutl/ntdsutil can do a lossy repair, but this is last-resort. Microsoft documents the LSASS/0xc00002e1 symptoms and explicitly warns that lossy repairs may remove data and leave the DC in an unsupported state — rebuilding the domain controller (or the forest) is usually the safer long-term fix. Before running any esentutl repair, work on copies and expect data loss. Example checks you can run on the copy:

esentutl /mh C:\Windows\NTDS\NTDS.dit
ntdsutil
  semantic database analysis
  go

See the esentutl/repair guidance and Microsoft note on emergency recovery. (learn.microsoft.com)

Preferred production route: add healthy, clean domain controllers on new hardware (or VMs), run the appropriate adprep from the Server 2008 media on the schema master, promote the new servers, transfer FSMO roles, then demote/remove the broken DC. That both avoids importing corruption and is the supported migration path. See the adprep/upgrade guidance for details. (learn.microsoft.com)

As suggested, don’t expect an OS upgrade to “magically” repair directory corruption. Follow the backup → diagnose (DSRM + ntdsutil) → repair (only as last resort) → migrate sequence. If unsure, preserve images and get a recovery specialist involved — mistakes here can force a full forest rebuild.

Member Avatar for JorgeM

Does upgrading from Windows NT Server 2000 to Windows Server 2008 will fix my problem on corrupted databases and active directory.

No, either the upgrade will fail, or you will just bring the corruption along to the new version. I generally do not recommend in-place upgrades for this reason.

It would be best if you try to resolve the issues before processing with introducing a 2008 domain controller.

In addition, prior to introducing new DCs, you have to prepare the domain/forest.

Guide & Video | Preparing Active Directory for 2008

commented: Good answer. +5
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.