Tranquil IT Forum

Hello,

I've been happily using WAPT Community 1.8.2.

However, I wanted to share my unfortunate experience installing a new Windows 10 workstation equipped with the WAPT agent.
I installed the agent and then deployed my software.
Everything was fine... until I joined my new machine to my Active Directory domain (Server 2012 R2).
Then, from my WAPT console, the workstation suddenly appeared as "DISCONNECTED"...

So, I scratched my head and thought, "Maybe it's the Windows firewall when I joined my new machine to the domain." I disabled the firewall and stopped Kaspersky...
Same problem...
I restarted my WAPT Windows service on the new workstation, and while I was at it, I restarted my WAPT server on CentOS 7.
Same problem...

Darn, I'm completely lost.

It turns out the problem is with the machine name registered in the WAPT server.
Before joining my new computer to the Active Directory domain, my computer was simply named "computername".
After joining the domain, the name became "computername.mydomain.something"...

I thought WAPT worked by IP address... Especially since I have the "Community" version and not the Enterprise version (so no Active Directory support and no ability to create machine groups).

So, I:
- Removed my new computer from the WAPT Server registry,
- Uninstalled and reinstalled the WAPT agent on my new computer,
- Re-registered the new computer during the agent installation on the server (this time with the name "computername.mydomain.something"),
- Re-launched my software, which reinstalled itself over the initial installations.

While I was at it, I searched the forum for a solution to my problem.
The post viewtopic.php?f=10&t=1091 is interesting, but it wasn't my antivirus that was blocking my connection, nor the issue with the out-of-sync clocks (viewtopic.php?t=1635)

. Therefore, it's important to remember when managing an Active Directory domain:
- Install the WAPT agent only after joining a new machine to the domain

.

Hello,
very interesting feedback.
We disable the agent via GPO, so it happens when adding to the domain.
I think this could resolve the issue for your system.

Normally, by default, workstations register with a unique identifier (UUID) from the BIOS, independent of the workstation's naming convention.
This is unless you chose to identify it with its FQDN in the agent configuration.

The agent's authentication on the server uses this UUID, so adding the workstation to the domain or changing its name should not cause the disconnection you mentioned.

Did you use the "use_fqdn_as_uuid" setting (Use the FQDN as the unique identifier)?