一,参照微软KB:
二,参照此篇BLOG
这几天的杀毒以及域服务器“目录服务无法启动”的经验总结
写在之前:之前好久没有写写工作中遇到问题的总结了,记述出来希望各位高手多提宝贵意见,多批评指正哈,谢谢了
有空了,写写这几天的杀毒以及域服务器“目录服务无法启动”的经验总结
原因:
至今为止也不太清楚是什么原因直接造成,那天情况大体是这样:
头一天服务器染了一种移动硬盘传播的病毒,诺顿没有报。症状为在映射盘里出现隐藏文件service.exe和autorun,后者可以删除,前者删除之后还会生成,而且前者显示的公司名是“番茄花园”!还好几乎所有PC都做过“关闭自动运行”的策略设置。service.exe没有被启动。只有一台机子,也就是病毒源的进程里发现非SYSTEM用户里有service.exe进程,用“恶意软件清理助手”可以查出来并清除。
奇怪的是第二天,又中了另一种U盘病毒,这次诺顿可以查出来,其命名为W32.sillyFDC.该病毒症状为在每一个硬盘分区中会出现图标和文件夹一样的名为new folder.exe的文件。诺顿的自动防护提示是已删除,但是还是不停的弹出威胁提示对话框,找到病毒源主机,拔掉网线,服务器停止弹出对话框。就在准备安心处理病毒源的时候。悲剧悄悄的上演了……
2台服务器几乎同时重启!之后主服务器正常启动,域服务器正常起不来了!显示错误信息为:lsass.exe - System Error : Security Accounts Manager initialization failed because of the following error: Directory Service cannot start. Error Status: 0xc00002e1. Please click OK to shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.
按提示点OK后进入Directory Services Restore Mode,正常。打开日至文件,没有查出异常,估计和从前出现的情况一样是电压不稳导致服务器保护性重启,不过奇怪的是稳压器和UPS电源为什么没有避免此类问题的发生。
木有办法,此前没有碰见过域控制器损坏的情况,server 2000也没有系统还原的功能,只能上网查查看看怎么恢复域控制器了。
网上很快查到了与上段Error Status一致的信息,是微软提供的解决方案,如下:
本文引导您完成一系列步骤,这些步骤或许可以帮助您诊断“目录服务无法启动”系统错误的原因。这些步骤可能包括:
"
验证 Active Directory 目录服务文件是否存在
"
验证文件系统权限是否正确
"
检查 Active Directory 数据库的完整性
"
执行语义数据库分析
"
修复 Active Directory 数据库
"
删除并重新创建 Active Directory 数据库
本文还介绍如何使用 Ntdsutil 或 Esentutl 对 Active Directory 数据库执行损失修复。由于损失修复会删除数据并且可能会带来新的问题,因此除非绝对必要,否则不要执行损失修复。
回到顶端
症状
当您启动域控制器时,屏幕可能会变黑,并且您可能会收到以下错误消息:
LSASS.EXE - 系统错误,由于下列错误,安全帐户管理器初始化失败:目录服务无法启动。错误状态 0xc00002e1。
请单击“确定”,关闭这个系统并重新启动到目录服务还原模式中。有关详细信息,请查阅事件日志
原因
发生此问题的原因是出现了下列一种或多种情况:
"
NTFS 文件系统对驱动器根目录的权限限制过于严格。
"
NTFS 文件系统对 NTDS 文件夹的权限限制过于严格。
"
包含 Active Directory 数据库的卷的驱动器号已更改。
"
Active Directory 数据库 (Ntds.dit) 已损坏。
"
NTDS 文件夹已被压缩。
回到顶端
解决方案
要解决此问题,请按照下列步骤操作:
1.
重新启动域控制器。
2.
当显示 BIOS 信息时,按 F8。
3.
选择“目录服务还原模式”,然后按 Enter。
4.
使用目录服务还原模式的密码登录。
注意:如果无法登录,请访问以下 Microsoft 知识库文章:
249321 ( http://support.microsoft.com/kb/249321/) 如果启动分区的驱动器号更改则无法登录
5.
单击“开始”,选择“运行”,在“打开”框中键入 cmd,然后单击“确定”。
6.
在命令提示符处,键入 ntdsutil files info。
即会显示与以下内容类似的输出:驱动器信息: C:\ NTFS (Fixed Drive ) free(533.3 Mb) total(4.1 Gb) DS 路径信息: Database :C:\WINDOWS\NTDS\ntds.dit - 10.1 MbBackup dir :C:\WINDOWS\NTDS\dsadata.bakWorking dir:C:\WINDOWS\NTDSLog dir :C:\WINDOWS\NTDS - 42.1 Mb totaltemp.edb - 2.1 Mbres2.log - 10.0 Mbres1.log - 10.0 Mbedb00001.log - 10.0 Mbedb.log - 10.0 Mb
注意:在下面的注册表子项中,也可以找到该输出中所包含的文件位置:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
该项中的下列条目包含这些文件位置
"
Database Backup path
"
Database Log files path
"
DSA Working Directory
7.
验证步骤 6 的输出中所列出的文件是否存在。如果这些文件不存在,请按照以下 Microsoft 知识库文章中的步骤操作:
240362 ( http://support.microsoft.com/kb/240362/) 目录服务在缺少 Ntds.dit 文件时无法启动
验证 Ntdsutil 输出中的文件夹是否具有正确的权限。下列表格中指定了正确的权限。
…………
由于篇幅有限,步骤十以下省略,读者可自行登陆 http://support.microsoft.com/kb/258062/zh-cn查询
(注:微软的中文翻译几乎是直译,很垃圾!)
仔细阅读此份解决方案,与自己遇到的情况似乎并不吻合,但是还是硬着头皮去做做试试,其实本人觉得前8步基本可以省略,确实很快做到了第12步,碎片整理,这一步微软提示会花很长时间大约得12个小时吧。看看表,距明天上班已经是来不及了,倒霉的是正巧上面来检查,要求必须在明天上班前解决!13步也基本不用想了,因为最早的备份也就是服务器刚建时做的,2年前的数据已经没有什么价值了,RESTORE这一步也可以PASS了。( 良好的备份习惯是多么的重要啊!55555~)木办法只能孤注一掷使用Ntdsutil 或 Esentutl修复了,但是微软后面给的提示确实很吓人:“这种修复通过从数据库删除数据来对损坏进行修复。如非绝对必要,请勿使用这种修复。”“虽然在修复后域控制器可以启动并且似乎可以正常运行,但由于从数据库中删除的数据可能会导致发生任意数量的问题(可能以后才会出现),因此该域控制器的状态是不受支持的。”TNND,管不了这么多了,修复!之前还是先要做点准备工作,先把数据都先备份一下,这会是记住了。又在网上查了一篇有关《灾难性的域控制器的恢复》文章,里面哥们写的用了Esentutl修复效果很好,曾强了我的信心!LET'S GO!
运行--cmd--esentutl /p c:\winnt\ntds\ntds.dit 深吸一口气回车
报错!——Operation terminated with error -1213 (JET_errPageSizeMismatch, The database page size does not match the engine) after 2.875 seconds.
靠!俺又不是微软认证系统工程师!这是什么乱七八糟的。
换Ntdsutil命令试试:
cmd——ntdsutil回车——files回车——repair回车
又报错!——Opening database[Current].***Error BInitializeJetDatabase failed with [cannot access file].
疯了! 啊~~
这时候开始抓狂了,难道真的要重新做域吗?55555~~`洼凉洼凉的
不行啊,一定得尽快解决啊,不然影响正常营业可就大头了。重来,继续在网上搜索解决方案!这次一定要对症,把上面两个报错在网上搜搜试试,点摆渡,没有!一条都没有!靠,不是吧,老天啊!GOOGLE!好久没用了,最后的希望,GOOGLE一回(事实证明——救世主啊)找到一篇求助的文章,症状和我几乎一样,只不是全是英文,无所,看看后面的解答,挺长的,不过基本步骤和微软提供的差不多一样。看看后面,给的命令: esentutl /p c:\winnt\ntds\ntds.dit /!10240 /8 /v /x /o 确实不一样,加了这么多参数。管他,老子现在不需要知道 /!10240 /8 /v /x /o 是什么东东,回 ~ 车 ~
唰唰唰唰,没有报错!一行行的开始显示:
Initiating REPAIR mode...
Database: c:\winnt\ntds\ntds.dit
Temp. Database: REPAIR.EDB
got 81621 buffers
checking database header
forcing database to consistent state
checking database integrity
Scanning Status ( % complete )
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
..........
乖乖,终于修了!
重启!正常进入,成功了!成功使用几天截至目前未发现异常
几点总结: 1、备份太重要了!
2、网络上搜索技术类尤其是英文的资料,还是GOOGLE更好些!
3、一定要对症再下药
4、微软中文直译太烂了!
有空了,写写这几天的杀毒以及域服务器“目录服务无法启动”的经验总结
原因:
至今为止也不太清楚是什么原因直接造成,那天情况大体是这样:
头一天服务器染了一种移动硬盘传播的病毒,诺顿没有报。症状为在映射盘里出现隐藏文件service.exe和autorun,后者可以删除,前者删除之后还会生成,而且前者显示的公司名是“番茄花园”!还好几乎所有PC都做过“关闭自动运行”的策略设置。service.exe没有被启动。只有一台机子,也就是病毒源的进程里发现非SYSTEM用户里有service.exe进程,用“恶意软件清理助手”可以查出来并清除。
奇怪的是第二天,又中了另一种U盘病毒,这次诺顿可以查出来,其命名为W32.sillyFDC.该病毒症状为在每一个硬盘分区中会出现图标和文件夹一样的名为new folder.exe的文件。诺顿的自动防护提示是已删除,但是还是不停的弹出威胁提示对话框,找到病毒源主机,拔掉网线,服务器停止弹出对话框。就在准备安心处理病毒源的时候。悲剧悄悄的上演了……
2台服务器几乎同时重启!之后主服务器正常启动,域服务器正常起不来了!显示错误信息为:lsass.exe - System Error : Security Accounts Manager initialization failed because of the following error: Directory Service cannot start. Error Status: 0xc00002e1. Please click OK to shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.
按提示点OK后进入Directory Services Restore Mode,正常。打开日至文件,没有查出异常,估计和从前出现的情况一样是电压不稳导致服务器保护性重启,不过奇怪的是稳压器和UPS电源为什么没有避免此类问题的发生。
木有办法,此前没有碰见过域控制器损坏的情况,server 2000也没有系统还原的功能,只能上网查查看看怎么恢复域控制器了。
网上很快查到了与上段Error Status一致的信息,是微软提供的解决方案,如下:
本文引导您完成一系列步骤,这些步骤或许可以帮助您诊断“目录服务无法启动”系统错误的原因。这些步骤可能包括:
"
验证 Active Directory 目录服务文件是否存在
"
验证文件系统权限是否正确
"
检查 Active Directory 数据库的完整性
"
执行语义数据库分析
"
修复 Active Directory 数据库
"
删除并重新创建 Active Directory 数据库
本文还介绍如何使用 Ntdsutil 或 Esentutl 对 Active Directory 数据库执行损失修复。由于损失修复会删除数据并且可能会带来新的问题,因此除非绝对必要,否则不要执行损失修复。
回到顶端
症状
当您启动域控制器时,屏幕可能会变黑,并且您可能会收到以下错误消息:
LSASS.EXE - 系统错误,由于下列错误,安全帐户管理器初始化失败:目录服务无法启动。错误状态 0xc00002e1。
请单击“确定”,关闭这个系统并重新启动到目录服务还原模式中。有关详细信息,请查阅事件日志
原因
发生此问题的原因是出现了下列一种或多种情况:
"
NTFS 文件系统对驱动器根目录的权限限制过于严格。
"
NTFS 文件系统对 NTDS 文件夹的权限限制过于严格。
"
包含 Active Directory 数据库的卷的驱动器号已更改。
"
Active Directory 数据库 (Ntds.dit) 已损坏。
"
NTDS 文件夹已被压缩。
回到顶端
解决方案
要解决此问题,请按照下列步骤操作:
1.
重新启动域控制器。
2.
当显示 BIOS 信息时,按 F8。
3.
选择“目录服务还原模式”,然后按 Enter。
4.
使用目录服务还原模式的密码登录。
注意:如果无法登录,请访问以下 Microsoft 知识库文章:
249321 ( http://support.microsoft.com/kb/249321/) 如果启动分区的驱动器号更改则无法登录
5.
单击“开始”,选择“运行”,在“打开”框中键入 cmd,然后单击“确定”。
6.
在命令提示符处,键入 ntdsutil files info。
即会显示与以下内容类似的输出:驱动器信息: C:\ NTFS (Fixed Drive ) free(533.3 Mb) total(4.1 Gb) DS 路径信息: Database :C:\WINDOWS\NTDS\ntds.dit - 10.1 MbBackup dir :C:\WINDOWS\NTDS\dsadata.bakWorking dir:C:\WINDOWS\NTDSLog dir :C:\WINDOWS\NTDS - 42.1 Mb totaltemp.edb - 2.1 Mbres2.log - 10.0 Mbres1.log - 10.0 Mbedb00001.log - 10.0 Mbedb.log - 10.0 Mb
注意:在下面的注册表子项中,也可以找到该输出中所包含的文件位置:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
该项中的下列条目包含这些文件位置
"
Database Backup path
"
Database Log files path
"
DSA Working Directory
7.
验证步骤 6 的输出中所列出的文件是否存在。如果这些文件不存在,请按照以下 Microsoft 知识库文章中的步骤操作:
240362 ( http://support.microsoft.com/kb/240362/) 目录服务在缺少 Ntds.dit 文件时无法启动
验证 Ntdsutil 输出中的文件夹是否具有正确的权限。下列表格中指定了正确的权限。
…………
由于篇幅有限,步骤十以下省略,读者可自行登陆 http://support.microsoft.com/kb/258062/zh-cn查询
(注:微软的中文翻译几乎是直译,很垃圾!)
仔细阅读此份解决方案,与自己遇到的情况似乎并不吻合,但是还是硬着头皮去做做试试,其实本人觉得前8步基本可以省略,确实很快做到了第12步,碎片整理,这一步微软提示会花很长时间大约得12个小时吧。看看表,距明天上班已经是来不及了,倒霉的是正巧上面来检查,要求必须在明天上班前解决!13步也基本不用想了,因为最早的备份也就是服务器刚建时做的,2年前的数据已经没有什么价值了,RESTORE这一步也可以PASS了。( 良好的备份习惯是多么的重要啊!55555~)木办法只能孤注一掷使用Ntdsutil 或 Esentutl修复了,但是微软后面给的提示确实很吓人:“这种修复通过从数据库删除数据来对损坏进行修复。如非绝对必要,请勿使用这种修复。”“虽然在修复后域控制器可以启动并且似乎可以正常运行,但由于从数据库中删除的数据可能会导致发生任意数量的问题(可能以后才会出现),因此该域控制器的状态是不受支持的。”TNND,管不了这么多了,修复!之前还是先要做点准备工作,先把数据都先备份一下,这会是记住了。又在网上查了一篇有关《灾难性的域控制器的恢复》文章,里面哥们写的用了Esentutl修复效果很好,曾强了我的信心!LET'S GO!
运行--cmd--esentutl /p c:\winnt\ntds\ntds.dit 深吸一口气回车
报错!——Operation terminated with error -1213 (JET_errPageSizeMismatch, The database page size does not match the engine) after 2.875 seconds.
靠!俺又不是微软认证系统工程师!这是什么乱七八糟的。
换Ntdsutil命令试试:
cmd——ntdsutil回车——files回车——repair回车
又报错!——Opening database[Current].***Error BInitializeJetDatabase failed with [cannot access file].
疯了! 啊~~
这时候开始抓狂了,难道真的要重新做域吗?55555~~`洼凉洼凉的
不行啊,一定得尽快解决啊,不然影响正常营业可就大头了。重来,继续在网上搜索解决方案!这次一定要对症,把上面两个报错在网上搜搜试试,点摆渡,没有!一条都没有!靠,不是吧,老天啊!GOOGLE!好久没用了,最后的希望,GOOGLE一回(事实证明——救世主啊)找到一篇求助的文章,症状和我几乎一样,只不是全是英文,无所,看看后面的解答,挺长的,不过基本步骤和微软提供的差不多一样。看看后面,给的命令: esentutl /p c:\winnt\ntds\ntds.dit /!10240 /8 /v /x /o 确实不一样,加了这么多参数。管他,老子现在不需要知道 /!10240 /8 /v /x /o 是什么东东,回 ~ 车 ~
唰唰唰唰,没有报错!一行行的开始显示:
Initiating REPAIR mode...
Database: c:\winnt\ntds\ntds.dit
Temp. Database: REPAIR.EDB
got 81621 buffers
checking database header
forcing database to consistent state
checking database integrity
Scanning Status ( % complete )
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
..........
乖乖,终于修了!
重启!正常进入,成功了!成功使用几天截至目前未发现异常
几点总结: 1、备份太重要了!
2、网络上搜索技术类尤其是英文的资料,还是GOOGLE更好些!
3、一定要对症再下药
4、微软中文直译太烂了!
相关热门文章
给主人留下些什么吧!~~
评论热议