u/grimson73

New Firewall exceptions needed after new version AudioHero

Hi, I enjoy the rapid development of this app and glad I'm passively noticing all updates and progress. Also kudo's to the developer for detailed changelogs and, now in search of it, the excellent documentation and debug logging. Really a solid development for this product in regard to support and documentation too :)

I noticed lately that starting AudioHero started with a long delay searching for devices and then asked for a Firewall Exception. Disregarding earlier occurrences it just happened again so i wanted to see why this is. Started to look into the excellent documentation and enabled debugging in the log files but also checked the firewall rules.

I think the explanation is that with every update a firewall exception has to be made for this new location of the app. I can't really tell if this was before as I might have turned off the firewall or the app was located in the same folder.

Config: Windows 11, default firewall enabled which pops up to ask for add exception.
I might enable an exclusion based on the appname solely but this is what I think, the default firewall behavior is.

I’m trying to validate an assumption about the inner workings of the Autopilot hardware hash, specifically regarding how it handles data from different collection contexts (like WinPE) and whether it ever updates.

I want to make WinPE possible to obtain the hash but became aware there are some TPM specifics you need in the hash. Although its purpose is not 'just' user-driven scenarios the future might be different and got me thinking am i stuck with an 'incomplete' hash when not imported 'fully'.

Here is my current understanding:

1. User-Driven vs. Self-Deploying Requirements: A device can be registered in Autopilot and successfully complete a User-Driven deployment as long as the basic hardware identity matches and user authentication succeeds. However, Self-Deploying / Pre-Provisioning modes have strict cryptographic requirements (TPM 2.0 attestation) that might not always be captured in the hash depending on the environment used to collect it.
2. Immutable Registrations: Device hashes registered in the Autopilot service are never dynamically updated or enriched post-enrollment. Therefore, a hash that works for User-Driven might remain permanently insufficient for Self-Deploying flows.

Question 1 (Scenario Validation): Is it true that a device can have a valid Autopilot registration that works perfectly for User-Driven Autopilot, but will consistently fail Self-Deploying / Pre-Provisioning because the originally captured hardware hash lacks the necessary markers required for TPM-based attestation flows?

Question 2 (will the hash be updated?): If this 'missing tpm in hash' exists, does the Autopilot backend ever re-evaluate, enrich, or update the device’s registered hardware identity after a successful enrollment (for example, via post-enrollment Intune/Entra/TPM signals), or is the originally imported identity completely static for the lifetime of that Autopilot object?

Question 3 (self deploying authentication?): To get into the weeds: Is the "TPM information" embedded within the hardware hash essentially acting as the device's "pre-shared password"? In other words, does the Autopilot/Entra backend use those specific embedded TPM markers to authenticate the physical machine during a headless deployment, serving the same functional purpose that user credentials do during a User-Driven deployment? And therefore it is needed? Just trying to understand what makes a self deploying authenticate itself.