Vista的OOBESYSTEM阶段，FirstLogonCommands命令字段与Audit Mode的冲突问题

这是一个PC OEM厂家方面在处理我们公司一款软件预装时遇到的问题，网上没有相关类似问题参考，我自己也摸索了半天无果。后来经过多方协调，微软上海方面的技术支持工程师给出了一种解决方案，拿出来问题经验共享下： 

 

问题现象：

     开发了一个备份软件作为PC出厂预装，希望用户拿到新PC后第一次登陆桌面时，该备份软件能够被安装并完成初始化操作。为此，将该软件的安装批处理命令加入unattend文件中OOBE阶段的FirstLogonCommands中。但问题是，在厂家PC出厂抽检测试时发现，如果在启动中（启动至OOBE用户解封装的界面），按下Ctrl+Alt+F3跳入审核模式(Audit mode)，则本属于OOBE解封装阶段的FirstLogonCommands中命令依然会被执行。由此导致，抽检PC第一次登陆桌面时，备份软件已经安装并初始化。这样备份软件未到用户手里就初始化了备份信息，这不是我们想要的。即使按正常流程再次进行OOBE封装，回到PC出厂状态，但备份软件的使用就有异常了。 最终，这批抽检PC得完全重灌才能出厂。

 

   有意思的是，出现了这样的情况： 类似的命令字段，XP系统表现与Vista表现不同，在Audit Model下不执行该命令。但在Vista的AIK相应文档《比较 Windows XP 和 Windows Vista 部署技术》中是这样说明的“[GUIRunOnce] 部分由 Microsoft-Windows-Shell-Setup 组件中的 FirstLogonCommands 设置替换”

 

在Vista的OOBESYSTEM阶段之前，在相应的应答文件unattend.xml中添加用户第一次登录是运行程序的命令FirstLogonCommands字段，指定运行安装批处理文件。（字段说明参考http://technet.microsoft.com/en-us/library/cc722150.aspx）

在XP的OOBESYSTEM阶段之前，在相应的应答文件sysprep.inf中添加用户第一次登录是运行程序的命令GuiRunOnce字段，指定运行安装批处理文件。（字段说明参考http://technet.microsoft.com/en-us/library/cc780201.aspx ）

 

但从问题的结果分析来看，使用的这两个命令字段的作用和调用过程在XP和Vsita的调用过程中实际是有差异的。

 

厂家急要求解决，一方面问题反馈到微软OEM支持的相关部门，而等待中的我被逼无奈，也要的解决尝试：

 

解决方案有两种思路：①在Vista的解封应答文件中，可以控制在审核模式下不执行预装软件的静安装，而正常OOBEsystem阶段可以执行。但根据微软技术文档没有发现有合适地流程接口可达到此目的。②执行软件预安装命令时，判断当前是否运行在Audit Mode，是则不执行静安装。但我们目前没有找到相关判断方法或接口工具等。

 

自力更生，寻找解决方案：可行性最大的是判断当前是否是审核模式的方案。关键是判断是否in audit mode的依据。没有函数接口，靠猜估计Windows在启动过程中至少会置一个标记指示当前状态，估计可能在注册表中。

=================================================

在审核模式下，运行注册表，查找audit关键字寻找可疑键值。最后找到一处：

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Setup/State]
"ImageState"="IMAGE_STATE_SPECIALIZE_RESEAL_TO_AUDIT"

这是审核模式的值。同理查看正常Vista系统的值。

[HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Setup/State]
"ImageState"="IMAGE_STATE_COMPLETE"

这是正常系统的值。 

通过关键字Google反查，找到相关文档解释内容如下：

 

Windows Setup Installation Process

Windows Setup States

There are several "states" assigned to a Windows image during installation. This state information can be used to automatically detect the different states and stages of Windows Setup.

The Windows image state is stored in two places, in the registry and in a file.

• In the registry:
  KEY: HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Setup/State
  TYPE: REG_SZ
  VALUE: StateName
• In a file:
  FILE: %WINDIR%/Setup/State/State.ini
  SECTION: [State]
  VALUE: StateName

The following table describes the different values that exist for StateName.

 

State Name	Description
IMAGE_STATE_COMPLETE	The image has successfully been installed. The specialize and oobeSystem passes are complete. This image is not deployable to alternate hardware because it is now hardware-dependent.
IMAGE_STATE _UNDEPLOYABLE	This is the default state for an image in a given phase of Windows Setup that is not yet complete. If a process queries the IMAGE_STATE value and IMG_UNDEPLOYABLE is returned, the image is in one of the following states: Setup is currently running and has not fully completed the phase. Once a given phase is complete, the IMAGE_STATE will be set to an appropriate completion value. If queried online while Setup is not running, there was a failure when completing a Setup phase. This image must be reinstalled. If queried offline, the image did not complete a phase and will never be deployable.
IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE	The image has successfully completed the generalize pass and will continue into OOBEsystem when Setup is initiated.
IMAGE_STATE_GENERALIZE_RESEAL_TO_AUDIT	The image has successfully completed the generalize pass and will continue into audit mode when Setup is initiated.
IMAGE_STATE_SPECIALIZE_RESEAL_TO_OOBE	The image has successfully completed the specialize pass and will continue into OOBEsystem when Setup is initiated.
IMAGE_STATE_SPECIALIZE_RESEAL_TO_AUDIT	The image has successfully completed the specialize pass and will continue into audit mode when Setup is initiated.

The following examples show how to access state information.

• To access state information from the registry:
  
  Copy Code

  C:/>reg query HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Setup/State /v Imag
  eState
  
  HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Setup/State
      ImageState    REG_SZ    IMAGE_STATE_SPECIALIZE_RESEAL_TO_OOBE

• To access state information from a file:
  
  Copy Code

  C:/>type %windir%/Setup/State/State.ini
  [State]
  ImageState="IMAGE_STATE_SPECIALIZE_RESEAL_TO_OOBE"

从而方案得到解，写一个控制台程序来访问并记录当前setup状态。

结果，不幸的是，在FirstLogonCommands执行批处理程序获取stateName时，得到值是IMAGE_STATE _UNDEPLOYABLE。也就是说，这一时刻，还是无法判断处于何种模式。。。。失败

=======================================================

没法，继续在注册表里搜索可疑键值。

[HKEY_LOCAL_MACHINE/SYSTEM/Setup/Status]
"AuditBoot"=dword:00000000

可疑，发现登陆进入审核模式桌面后，该值为1。尝试使用该值，结果不幸的时，似乎在在FirstLogonCommands执行批处理程序获取AuditBoot时，得到值是0。也就是说，这一时刻，还是无法判断处于何种模式。。。。失败

========================================================

 

至此，我无语了，只能等待微软方面的消息了。后来，跟微软方面的技术人员也沟通了我的尝试，对方告知要进一步反馈到技术开发组才能得到具体信息。继续等。。。

 

不幸的结果是，解决思路②被枪毙了，微软反馈说该流程设计方式是“By Design”，因为按下Ctrl+Alt+F3跳入审核模式(Audit mode)时，FirstLogonCommands已经被载入缓存生效，登录桌面时必定会被执行；如果是以参数方式直接启动到Audit Mode下则不会出现这种情况。我的尝试也是有效果的，呵呵，微软人最终也没有提供出能在这种情形下判断是否是Audit Mode的接口依据来。

 

还是微软人对自己的产品最了解，最终他们找到了解决方案：

解决方法
===========
1． 创建一个unattend文件(命名为Unattend.xml)，将该文件放到一个USB disk中。该unattend文件只包括Reseal项。其作用是将系统启动到Audit Mode。

Unattend.xml
**************
<?xml version="1.0" encoding="utf-8" ?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Deployment" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Reseal>
<Mode>Audit</Mode>
</Reseal>
</component>
</settings>
</unattend>
****************

2． 将原来的unattend文件放到%WINDIR%/System32/Sysprep，使该unattend文件的优先级比USB disk中的低。
3． 如果要将测试机器启动到审核模式，将USB disk插入被检测机器，然后从硬盘启动系统。系统将直接进入审核模式。

===========

 

最终厂家那边试验折腾了好一阵子，总算是通过了，具体过程我未参与，但原理就是以上部分，作为经验总结并记录下来，网上共享，呵呵。