[WADS] Error 400 when deploying from a secondary repository

[MaximeJ]

Good morning,

Following the activation and deployment of a secondary repository to accelerate our deployments, they are not working. The client boots correctly via the WinPE key, it correctly retrieves the rule instructing it to locate its secondary repository, but when it tries to download the wads.exe file, the following message appears in the client console:

Code: Select all

"Error getting wads executable from server: THttpClientSocket.WGet: serversecondaire.domaine.local:443/api/v3/get_wads_exe/192.168.1.10/wads64.exe failed as HTTP Error 400 - Bad Request"

And I see the same thing in the nginx logs of the secondary repository server. Yet my repository is properly synchronized, and I can see the files in the shared directory. Clients are successfully downloading their packages from this secondary repository. I only see this error, and I don't know where else to look besides the client logs and /var/log/ for the nginx and wapt files, but I can't find anything else.

Does anyone have any idea what could be causing this 400 error and how to fix it?


Furthermore, another question on the subject: we have Windows 11 Enterprise licenses, but regardless of the options we add to the .xml response file (based on the index number or the version label in the corresponding tag) once deployed, the workstations are in Professional edition.
Do you know what could explain this behavior and where to find the logs to understand it?


WAPT Agents and Server version: 2.4.0.14.080
Secondary servers and repositories running Debian 12.5

Thank you in advance for your help or ideas to move forward!
Maxim

[sfonteneau]

Hello

, do you have HTTPS certificate verification enabled on WinPE?

Is your secondary repository rule set to use HTTPS?

Simon

[dcardon]

Hello Maxime,

Also, another question on this topic: we have Windows 11 Enterprise licenses, but regardless of the options we add to the response .xml file (based on the index number or the version label in the corresponding tag), the workstations, once deployed, end up in the Professional edition.
Do you know what could explain this behavior and where to find the logs to understand it?

To make it easier to follow the discussion on the forum, it's best to ask one question per topic; otherwise, it's difficult to keep track. Could you please ask the question again in a new topic?

WAPT Agents and server version: 2.4.0.14.080.
Secondary servers and repositories running on Debian 12.5.

Version 2.5.5 has been released with a whole host of small fixes; I encourage you to upgrade

Sincerely,

Denis

[MaximeJ]

Yes, I checked the box to enable HTTPS on WinPE, and the secondary repository rule correctly points to an HTTPS URL on that server. When I look at the logs of clients already deployed and using this secondary repository, they correctly validate the server's certificate.

These are certificates issued by our internal CA; I added the certificate chain and validated the Nginx configuration without errors.

Are there any logs I can retrieve from the client or server that would give me more information? Perhaps the Nginx configuration?


Okay, good point about version 2.5.5; we'll plan an upgrade then! And the second question makes sense; I'll create another thread. Thanks!

[dcardon]

Hi Maxime,

there was a bug with HTTPS redirect. Before version 2.5.5, the wgetwads.exe pre-installer connected to the server, which then sent it an HTTP redirect to connect to the secondary repository. However, there was a misinterpretation of the return codes and the TLS context reset, hence the 400 error.
We've changed the behavior so that the wgetwads.exe pre-installer retrieves the secondary repository rules and connects directly without going through the HTTP redirect [1].

So upgrading to 2.5.5 should solve your problem.

Best regards,

Denis

[1] https://www.wapt.fr/en/doc/wapt-changel ... 2024-05-22

[MaximeJ]

That's very clear, thank you very much! I'll be able to put pressure on my colleagues who manage the server to launch the upgrade to 2.5.5 and we'll restart our deployments then.

Best regards