OA 3.0 Tool: command-line and config file syntax
The OA 3.0 tool is a command-line tool that supports assembling, reporting, and returning a unique identifier for the computers on the factory floor. You can run the OA 3.0 tool in two ways:
By using audit mode on the fully assembled client computer. For more information about running the OA 3.0 tool in audit mode, see Audit Mode Overview in the Windows ADK.
By using OOBE mode on the fully assembled client computer. When the first prompt appears in the OOBE, press Shift + F10 to open an admin command prompt and run the OA3.0 tool, and then shutdown the machine. The end user OOBE experience must be consistent with running the OA tool in Audit Mode and not deviate from the standard.
|/Assemble||Retrieves a product key that has a state of Consumed from the factory floor database, and then assembles the OA3.bin file and the OA3.xml file for a specific computer. After assembly, the OEM-supplied firmware injection tool can inject the OA3.bin file into the firmware of the computer.
|/Report||Creates the hardware hash value for a specific computer, associates the value with the product key ID, and then sends the OA3.xml file to the reporting server on the factory floor. This command-line option is generally used on the factory floor after the product key is injected into the new computer.
ImportantWhen you use the /report command line option together with an internal wireless network adapter, you must run the full operating system. You cannot use Windows PE. In addition, if you run the /report option without a server connection, the resulting report is saved to the same location as the OA3.xml file that your configuration file specifies. The report file will be sent to the reporting server on the factory floor the next time that you run the /report option when the computer is connected.
If the machine has no product key in firmware, you can run /report /NoKeyCheck to generate a Hardware Hash for the offline validation. But CBR submission will fail if missing a product key in firmware. Example:
|/Return||Returns an existing product key for reconciliation. For example, you may use this option if you replace a previously injected hardware association with a new association for the same computer. This command-line option is generally used after the Computer Build Report is generated. It is not supported in MDOS.
|/LogTrace=<OA3_log_file>||Logs OA 3.0 hardware hash generation diagnostic tracing data into a file specified in <OA3_log_file>. The path must be valid for OA3Tool.exe to write to.
Optionally, this switch can be used with the /Report switch. We highly recommend partners use this switch when testing OA 3.0 CBR reporting and hardware hash tolerance.
|/CheckEdition||Performs a cross check between the injected product key and the target operating system for edition match. Two modes are possible:
|/Configfile=<configfile_location>||Specifies the location and name of the configuration file, which contains the location of the key provider server; file path locations for log files, error codes, and messages; and the location of the temporary directories that are required to assemble the product key into binary and XML formats.|
|/DecodeHwHash||Used to decode the hardware hash into an xml human readable format.
The /DecodeHwHash accepts either a string (e.g. if it is stored in a database or sent in email) or a file path to the full XML file generated at the /Report stage. Example:
|/Validate||Performs a validation pass to ensure that the MSDM table exists, that the MSDM table header includes all of the required fields, and that the MSDM table entries exist and conform to the correct formats. Example:
|/ValidateSMBIOS||The TotalPhysicalRAM and PrimaryDiskTypeCapacity values are obtained from the SMBIOS structures of the device. It is the responsibility of the OEMs to properly initialize these structures. To validate that these structures are properly initialized, OA3Tool RS3 or above version has a new option /ValidateSMBIOS which iterates over the SMBIOS tables and ensures that they are correctly initialized with respect to these two attributes. Two modes are possible:
|/ValidateHwHash||Used to validate the base64-encoded hardware hash element with the predefined quality criteria for critical and important fields. Critical fields are necessary for Autopilot feature to work, while important fields are used for calculating royalty license fee.
This function is only available in 18950 or above OA 3.0 tool version.
The /ValidateHwHash option accepts either a string (if it is stored in a database or sent in email, for example) or a file path to the full XML file generated at the /Report stage.
The /ValidateHwash option checks for any errors, blanks, or null values in any of the fields of the decoded Hardware Hash. Additional fields to check are in the following table.
|OS Type||Output should be “FullOS”. If the field is empty or represent “WinPE”, a full boot of the OS was not utilized when creating the Hardware Hash.|
|Total Physical RAM||Output should represent the RAM in the device. (i.e. 4, 8, 16, etc.). If the field is empty or “0”, 65535, RAM was not captured correctly.|
|Primary Disk Total Capacity||Output should represent the Primary Disc in the device. (i.e. 128, 256, 1024, etc.)|
|Display Resolution and Physical Display Size||Output should represent the internal display resolution and physical size. If the field is “0”, the device must have an external monitor, for example, as with a desktop.|
|SMBIOS Fields||The output should not contain no data, be blank, or contain a default string, like “To be filled by O.E.M”|
|MacAddress||The output should not represent no data, blank, 00:00:00:00:00:00 or FF:FF:FF:FF:FF:FF|
|ChassisTypes||The output should follow the rule in the SMBIOS Reference Specification .|