logo-header-e2010logo_office[2]

        微软知识库编号 KB2028193 提到了如何解决 0x80070057 故障,虽然 gOxiA 也遇到了该故障问题,但是却无法通过 KB2028193 完全解决,因为虽然能够通过手动配置的方法与 Exchange Server 连接,但是在下载脱机通讯簿时会遇到错误。所以才引出此篇日志与大家分享一下经验。

        gOxiA 使用 Outlook 2010 与 Exchange 2010 连接,早先在 gOxiA 的机器上安装有 Microsoft Online Services 客户端,并自动配置使用 Outlook 访问 Microsoft Online Services 的 Exchange Online 服务。由于公司内部的 SBS7 开始使用,所以 gOxiA 又连接到了公司的 Exchange 系统上,之后又卸载了 Microsoft Online Services 客户端,改为 Web 方式访问。前几天 gOxiA 在公司外部进行一些技术测试,无意发现 Outlook 下当前账户设置信息中,显示的“在网上访问此帐户”的信息为 Microsoft Online Services 的地址,而非本公司的 Exchange OWA 地址,并且无法修改该信息,于是删除了当前配置文件,并重新建立。之后便出现了 0x80070057 故障。

0x80070057

        随后向导提示手工进行配置,虽然能够连接到 Exchange Server,但是在下载脱机通讯簿时又出现了 0x8004010F 故障。

0x8004010F

        查询了网上的资料据称与 Exchange 有关,回忆之前 SBS7 确实遭遇停电意外关机过,随后根据提示进行了排错,重新生成并同步了脱机通讯簿。在内网的测试机上使用 gOxiA 自己的账户进行了连接测试,并成功的下载了脱机通讯簿,但是在 gOxiA 自己的笔记本上始终会出现 0x80070057 和 0x8004010F 错误,之后又在本机登录了其他的域帐户,并发现自动配置与脱机通讯簿都正常看来问题应该出在 gOxiA 在本机的用户配置文件上。

        首先需要解决的就是自动配置,根据 KB2028193 提到的相关注册表项,gOxiA 对当前配置文件的注册表进行了检查,发现了一些异样,PreferLocalXML 以及与自动配置有关的项均存在,对比内网的测试机发现虽然其注册表没有相关的项但是也能够进行 Outlook 的 Exchange 连接自动配置。看来因该是之前 Microsoft Online Services 遗留的配置信息与当前冲突了。随后在注册表 AutoDiscover 中删除了 PreferLocalXML 以及有关的其他信息。在办公网内重新配置 Outlook 去自动配置连接 Exchange,此时自动配置连接正常了,并成功与 Exchange 同步,而之前的 0x8004010F 故障也随之消失。

windowsmobile_banner

        gOxiA 目前所服务的公司部署了一套 Windows Small Business Server "7" Preview(SBS7),在此之前该公司一直使用 Microsoft Online Services 提供的基于云计算的 Exchange 等服务,而 gOxiA 的 Windows Mobile 手机也通过 Exchange ActiveSync 同步邮件等信息,在配置 Exchange ActiveSync 时并未遇到任何错误。

        在公司的 SBS7 部署完毕之后,gOxiA 全面将邮箱转向到了本地企业的 Exchange 2010 上,但是在手机上重新配置 Exchange ActiveSync 时却遇到了问题,同步中心显示因为证书问题导致同步失败,之后 gOxiA 将企业根证书拷贝到 WM 手机上点击证书文件发现证书安装失败,如下图所示:

import_rootca_failed

        利用 Certificate Distribution Package 中的 InstallCertificate.exe 工具安装证书依然在设备上提示如上图的错误信息,查阅相关信息有提到如果 ROM 版本非正式版,那么可能会出现导入证书失败的问题,根据网上的建议需要通过注册表来手工倒入。

        首先,我们要查看当前的企业根证书,并获取到证书的指纹代码,这样便于我们在注册表中查找该证书数据,如下图所示:

CARoot

        之后,打开注册表编辑器,找到该证书,可以利用指纹代码进行搜索,搜索时注意将指纹代码中的空格删去。导出企业根证书的注册表数据后,编辑该注册表文件,将其数据路径修改为如下格式:

[HKEY_LOCAL_MACHINE\Comm\Security\SystemCertificates\Root\Certificates\"指纹代码"]

        最后将该注册表文件拷贝到 WM 设备上进行导入即可,再次打开 WM 的证书查看器便能够看到企业根证书成功导入到设备。

WM_Cert_Viewer

        再次连接 Exchange ActiveSync 成功与公司的 Exchange Server 同步,至此问题解决!

        近期 gOxiA 重新搞起 Windows XP 的映像部署实践,虽然 Windows XP 正逐步被淘汰,但是面对一些老机器而言,有一个能够快速部署 Windows XP 的安装映像,能省掉不少时间和精力。此外,MDT 的新版本打包的 Windows XP 貌似能在不同的硬件上使用。所以 gOxiA 耗费了几天的时间制作了包含预装应用程序的 Windows XP Pro with SP3 Volume 和 Windows XP Pro with SP3 Dell OEM 的自定义映像,用于加速安装 Windows XP。

        加上早期制作的 Windows 7 HomePremium Custom Image,目前有三个自定义映像,下面便是三个自定义映像的相关信息截图。

WDS_Windows_Setup_Collection

W7HPCI

WXPProSP3DellOemCI

WXPProSP3VolCI

        大家已经留意到上面的第一张截图是 WDS 控制台的界面,是的!gOxiA 将 MDT 中捕获的 Windows XP 映像进行了修改,去除了与 MDT 相关的执行脚本,便于在 WDS 或通过 Windows Setup 来进行安装。

        但是在使用 WDS 部署 Windows XP Custom Image 时会出现如下图的蓝屏故障,即:STOP: 0x000000ED (0x823329E0, 0xC000014F, 0x00000000, 0x00000000)。系统在执行完毕 Mini Setup 阶段之后,重新启动便无法自举!

BOSD_0x000000ED

        随即启动 Windows PE 3.0,进入 Diskpart 环境,通过 Detail Disk 查看磁盘信息,发现了问题!虽然磁盘是联机状态,并且磁盘及分区都能够被识别,但是分区格式为 RAW。

detail_disk

        在命令行状态下进入 C: 失败,反馈信息为“此卷不包含可识别的文件系统。请确定所有请求的文件系统驱动程序已加载,且此卷未损坏。”查阅了微软知识库,找到了一篇 KB315403。KB 解释出现该故障的原因是由于 IDE 磁盘驱动器中的写模式优化导致的,为了将驱动器的写入速度保持在尽可能最快的水平上,缓存例程有时会根据数据在磁盘上的位置,打乱数据的写入顺序。一次写入没有完成时,将会在 NTFS 磁盘系统可能有关键表受损的位置开一个计时窗口……

        这么讲貌似应该与 WDS 没有关系,问题应该是出在映像系统本身上,但是实际的测试表明,当使用 Windows Setup 或 MDT 来部署 Windows XP Custom Image 时则不会发生这样的故障。之后,gOxiA 又在 WDS 上做了更深入的测试,在安装过程中,直接在现有分区上进行安装,而不再删除或格式化。之后发现 0x000000ED 故障不再出现,看来此故障应该与 WDS 中使用 Windows Setup 安装 Windows XP Custom Image 时建立的分区有关,而单独使用 Windows 7 安装源的架构和 Windows Setup 则不会出现故障,看来还是 WDS 在添加 Windows 7 的 Boot.wim 时,加入的某个 WDS 相关动态链接库文件(DLL)存在 Bug。

        目前在出现 0x000000ED 蓝屏故障后有效的解决办法就是参考 KB315403,在 Windows XP 故障恢复控制台或 Windows PE 中执行 chkdsk /r 执行扫描修复。之后再重新启动计算机 0x000000ED 故障消失!

chkdsk_rchkdsk_r_1

Tags: , , , , , , ,
分页: 180/469 第一页 上页 175 176 177 178 179 180 181 182 183 184 下页 最后页 [ 显示模式: 摘要 | 列表 ]