OA 3.0 Tool: command-line and config file syntax

  • Article

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.

Option Description
/Assemble Retrieves a product key that has a state of Fulfilled 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.

Example:

OA3Tool.exe /Assemble /Configfile=C:\OA3\OA3.cfg
/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.

Important

When 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.

Example:

OA3Tool.exe /Report /Configfile=C:\OA30\OA3.cfg

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:

OA3Tool.exe /Report /Configfile=C:\OA30\OA3.cfg /NoKeyCheck
/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.

Example:

OA3Tool.exe /Return /Configfile=C:\OA30\OA3.cfg
/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. We highly recommend partners use this switch when testing OA 3.0 CBR reporting and hardware hash tolerance.

Example:

OA3Tool.exe /Report /Configfile=C:\OA30\OA3.cfg /LogTrace=C:\OA30\OA3.log
/CheckEdition Performs a cross check between the injected product key and the target operating system for edition match. Two modes are possible:
  1. Offline checking in Windows PE. You must use /ImageDrive=<image_drive_letter> to specify the drive letter where the image is applied.

    Before you use this switch in Windows PE, ensure that the latest version of DISM.exe and all the files from the entire DISM folder (approximately 7 to 9 MB) from the latest Windows ADK must be copied to the same folder where the Windows 10 OA3Tool.exe resides.
  2. Online checking in the full operating system. In this case the /online mode should be specified. No drive letter information is required. This switch is only available if the target operating system is Windows 10 client.
/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:

OA3Tool /decodeHwhash=<Hardware Hash string>
/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:

OA3Tool.exe /Validate
/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:
  1. Online checking in the full operating system. You must use /ValidateSMBIOS without the parameter.
  2. Offline checking in the SMBIOS table. The contents of this table can be collected using the /Logtrace output file from the /report command. There is an attribute (SMBIOSRawData) which contains the SMBIOS table contents. This value then needs to be passed to the /ValidateSMBIOS option to validate that the contents are indeed correct.

Example:
  1. OA3Tool.exe /Logtrace=trace.txt /Report /ConfigFile=<OA3 Config file>
  2. From trace.txt extract the SMBIOSRawData attribute value
  3. OA3Toool.exe /ValidateSMBIOS = <SMBIOSRawData value>
/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.

Example:

OA3Tool.exe /ValidateHwhash=<Hardware Hash string>|<report_file.xml>

The critical fields are:
DiskSerialNumber
TpmVersion
EkPubHash
MacAddress
ProductKeyId
SmbiosSystemFamily
SmbiosSystemManufacturer
SmbiosSystemProductName
SmbiosSystemSerialNumber
SmbiosUuid

The important fields are:
ChassisTypes
DigitizerSupportID
DiskType
DisplayResolution
DisplaySize
InternalDiskCount
OsBuild
OsCpuArchitecture
OSType
ProcessorCores
ProcessorModel
TotalDiskCapacity
TotalPhysicalRAM

Note

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.

Field Output
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 .