Packer and Azure: what WinRM settings are actually set?

[Justin DynamicD]

TLDR: when using the "os_type" attribute in the Azure Builder, security settings are set that are incompatible with some company security settings set later in the provisioner section.  Does anyone know the required settings for Packer to successfully connect to Azure instances?

More Detailed Version:
We currently have a series of packer jsons for creating images in both AWs and VMware that follow the same basic pattern:

1. Call unique builder with unique method to inject common WinRM configurations
2. Use _common_ Ansible roles to configure system
3. Windows-restart
4. Use unique sysprep/shutown process.

This allows for a mostly consistent set of images across providers.  The Azure builder, however, introduces a wrinkle into that flow.  Unlike the other methods, if you include the attribute "os_type: Windows" in the builder, the Azure builder will automatically configure WinRM with a temporary SSL certificate and user account ("packer") to configure the server with.  It defaults to NTLM, but if you set "winrm_use_ntlm: false" it will enable basic instead.  So far this isn't too unlike VMware/AWS: all seem to have their own unique way to get things going as there's no cloud-init.  The big difference, however, is I'm not the one scripting WinRM setup:  Azure is.  I don't actually _know_ what's being set.

Sounds good so far?

The problem comes in that the Ansible roles include security configurations.  These all apply and finish completely (step #2) but as soon as step #3 starts (the server reboot, but I've also tried simple write-output commands), packer can no longer connect to the instance.  It gets:

2019/01/28 21:11:05 packer: 2019/01/28 21:11:05 Retryable error: Error uploading ps script containing env vars: Error uploading file to $env:TEMP\winrmcp-0634b90c-2098-42b7-7454-d6bb585c7bce.tmp: Couldn't create shell: http response error: 401 - invalid content type

Now to re-iterate: neither the AWS or VMware builders have this issue.  They both connect with basic+SSL (only difference is I wrote my own PS script to set that up during step #1) and have no problems completing the entire process.  This means that there is some non-default security setting being set by the Azure builder that is conflicting with the company security settings (VMware runs are built from ISO and I connect fine).  Because the ansible roles _finish_ deploying, it makes it very hard to know which setting is causing the error hence my question:

Does anyone know what settings are configured when you set "OS_Type" and allow Azure to configure WinRM?  If I know what's required, I can work around the limitation.  Otherwise, I'm disabling one role/task list/line at a time until I find it.

[Justin DynamicD]

One last time to bubble this up.  Anyone have any insight?