EXCHANGE相关有用信息

2010.11.24更新 exchange 2000 无法装载数据库，手动mount时提示 c1041737 错误。     单位的办公自动化系统 windows server 2000 sp4+oracle 8.17+exchange server 2000 sp2 安装360后，无法装载exchange 数据库，看不到exchange虚拟的 M盘，进入exchange system 管理工具手动mount 时报 c1041737 错误？ 费了很多时间，才发现是可恶的360主动防御干的坏事，禁用主动防御或在注册表删除 用Regedit 把下面的注册表键删除掉即可： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ZhuDongFangYu 经过上面的操作，还是不能mount 数据库，后来找到360安装文件夹，找到un打头的 反安装文件，卸载360安全卫士和360防火墙。重启电脑后，在进程里面没有发现 360的任何进程，才mount成功。   1.管理工具 OWAADMIN windows 2000管理工具 iis60rkt.exe selfssl(颁发证书) 2.设置更改密码 将物理目录位置设置为C:\WINNT\System32\Inetsrv\Iisadmpwd 3.关于公共文件夹的权限问题。 应该屏蔽M盘。方法  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS\Parameters  在“编辑”菜单上，指向“新建”，然后单击“字串值”。  键入DriveLetter，然后按Enter键。(屏蔽删除此字串即可) 4.一些常用管理命令 iisrest setup\i386\setup /? 验证数据库文件（.edb和.stm文件）一致且相互匹配。为此，请对每个文件运行以下命令： eseutil /mh database file | find /i "DB Signature" 注意：Exchange 2000 Service Pack 2及更高版本不是将数据库状态报告为“Consistent”或“Inconsistent”，而是报告为“Clean Shutdown”或“Dirty Shutdown”。“Clean Shutdown”的含义与“Consistent”相同，而“Dirty Shutdown”的含义与“Inconsistent”相同。对于Exchange 2000 Service Pack 2或更高版本，请运行下面的命令以确定每个数据库的状态： eseutil /mh database_name | find /i "Shutdown" 下面是前述命令的一个输出示例： D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature" DB Signature:Create time:04/02/2001 16:59:32Rand:2746771 Computer: D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature" DB Signature:Create time:04/02/2001 16:59:32Rand:2746771 Computer:        在上一示例中，DB签名都相同，从而证明.edb和.stm文件属于同一文件集。（两个签名行必须逐字符地完全匹配，才能认为这两个签名匹配。） 不仅DB签名必须匹配，而且文件也必须相互同步并一致。对每个文件运行下面的命令： eseutil /mh database file | find /i "consistent" 下面是前述命令的输出示例： D:\mdbdata>eseutil /mh priv.edb | find /i "consistent" State:Consistent Last Consistent:(0x2CC7,1F14,1F7)  04/04/2001 18:07:14 D:\mdbdata>eseutil /mh priv.stm | find /i "consistent" State:Consistent Last Consistent:(0x2CC7,1F14,1F7)  00/00/1900 00:00:00        在上一示例中，两个文件都报告“State:Consistent”。括号中相应于每个文件的十六进制编号(0x2CC7,1F14,1F7)也必须匹配。“Last Consistent”时间戳不必匹配。这两个文件既一致又相互匹配。 如果其中一个文件报告“State:Inconsistent”或者“Last Consistent”日志位置不同步，则表示数据库没有干净地卸除。装入该数据库，然后再次卸除它。如果这两个文件仍然没有正确地匹配或者不一致，请与Microsoft产品支持服务(PSS)联系以获得进一步的帮助。 要查看内部日志生成编号，请运行以下命令： eseutil /ml [log file] | find /i "lGeneration" 下面是前述命令的一个输出示例： E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration" lGeneration:11463 (0x2CC7) 5.关于脱机备份 (1、“时点”恢复。日志文件不会重放到数据库中。备份后所创建的所有数据都将丢失。 (2、“前滚”恢复。备份后所创建的日志文件将被播放到数据库中。如果所有日志文件都可用，则备份后所创建的全部数据都可保存下来。如果启用了循环记录，则必须对脱机备份执行2“时点”恢复，而不能选择“前滚”恢复。 (3、对于时点恢复，存储组中的所有已停止数据库必须一致，并且必须存在有效的检查点文件。不要删除当前的检查点文件或任何现有的日志文件。 (4、对于前滚恢复，存储组中的所有数据库必须停止且一致，并且生成备份后创建的所有日志文件都必须存在（包括当前的E0n.log）。必须删除检查点文件。 6.数据库故障处理 　　当无法mount上数据库时，按下列步骤操作 　　1.尝试启动信息存储，看错误提示和事件日志。 　　2.检查一致性 eseutil /mh  databasename 　　3.若state=dirty shutdown,则不要remove log 若state=clean shutdown,则把log移出，转到第11步。 　　4.不一致执行软恢复eseutil /r 成功再检查一致性，转到第9步。 　　5.若磁盘空间不足，执行碎片整理(eseutil /d) 　　6.数据库不一致并且软恢复不成功 删除mdbdata中的所有Log文件，还有chk文件，以及temp.edb文件。 　　7.执行eseutil /p,恢复到一致状态。 　　8.将数据库装入一次，并马上卸除。 　　9.使用Isinteg.exe修复Pub1.edb数据库和Priv1.edb数据库(isinteg -s (servername) -fix -test alltests) 　　10.如果能够启动信息存储服务，而且信息存储较为稳定，并且在多次运行Isinteg.exe后仍报告同样的错误和警告，请使用ExMerge实用工具，通过将数据导出为.pst格式，然后将其重新导入新的或干净的数据库结构中来重建信息存储。 　　11.重新启动信息存储,mount存储。 　　12.做一次全备份。   EXCHANGE之备份与恢复(Eseutil)

 

http://blog.sina.com.cn/s/blog_493cafbb0100cssu.html