Mike Raineri

Closing; debug files shown so far indicate the tool is behaving properly. OEM definitions in this case require refinement in the implementation.

That behavior looks correct then. When you define something as an EntityType in CSDL, the expectation is it's a resource with a durable URI (shown by an @odata.id propert). OEM...

Closing; issue with the OEM definition and not the tool

Closing; no additional info provided. It would be good to test with the Protocol Validator to see if there are protocol-related issues with the service (like if it's requiring credentials...

Can you please provide the debug output of the tool and sample resource responses? At least using the contents of the public-oem-example mockup, I see the tool parsing the OEM...

"Resource.OemObject" is used to enforce expected typing for the OEM extensions. The "Oem" object definition has a bit of hardening to ensure the only contents of `"Oem": { }` are...

Closing; no updates to debug the issue further.

You should be able to add the `--workaround` option to allow the tool to apply the override in non-conformant locations. It would be good to provide this feedback to your...

It's possible we need an update to the workaround logic. I'll take a look at the log file to see what can be done.

It seems like there's an additional requirement to specify the override mode (UEFI vs Legacy). A user shouldn't have to specify this; the service is expected to handle a default...