For the Agent, Agent Server, and console to communicate properly across the network, they must be allowed in the firewall and antivirus software used in the environment. This is one of the most important stages of deployment, because even a correct module installation will not be enough if network traffic is blocked by system or network security.
Ewida Audit is a desktop application for Windows, and its modules work together directly within the company’s network environment. For that reason, it is worth configuring this properly from the start, before you begin synchronizing hosts and agents.
Information needed to allow communication
To allow inbound and outbound traffic, you need to add the correct executable files and TCP ports used by each module.
Agent
Files: PCAgent.exe, PCAgentUC.exe, PCAgentService.exe
TCP ports: 57771, 57777, 57779
Agent Server
File: PCAgentServer.exe
TCP port: 57773
Console
File: PCAudit.exe
TCP port: 57775
If the environment also uses additional network security controls, such as a hardware firewall, filtering between subnets, or centrally enforced rules managed by a domain administrator, these also need to be included during deployment.
Module log directories
If you run into communication, synchronization, or installation issues, the first step should be to check the module logs. They are the main source of diagnostic information.
Console
C:\ProgramData\Codenica\Audit\LOG
or C:\Program Files (x86)\Codenica\Audit\LOG
Agent
C:\Program Files (x86)\Codenica\Codenica Agent\LOG
Agent Server
C:\Program Files (x86)\Codenica\Codenica Server\LOG
or C:\ProgramData\Codenica\Codenica Server\LOG
The log location depends on how the module is run. If the application runs with administrator privileges, files are more often written to the Program Files (x86) directory. When running in standard user mode, logs may be saved to ProgramData, which is hidden by default in Windows.
Installing the Agent and Agent Server
The MSI installers are located in the program installation directory, by default:
C:\Program Files (x86)\Codenica\Audit
Two files are available:
- PCAgentInstaller.msi — the Agent installer,
- PCAgentServerInstaller.msi — the Agent Server installer.
A standard installation does not require any additional parameters. Optionally, you can use the TargetDir parameter if the module should be installed in a non-standard location. In most deployments, however, it is better to stay with the default directory because it makes diagnostics and later administration easier.
Installing the Agent Server
First, install the Agent Server from the PCAgentServerInstaller.msi file on a selected computer in the network. This should be a machine that is reliably available to workstations, ideally one that runs continuously and has a stable network configuration. After installation, the module must be allowed in the firewall and antivirus software, otherwise the console will not be able to establish a proper connection.
The next step is to synchronize the server with the console. After the first connection, the Agent Server becomes linked to that specific console installation. This is a security mechanism that prevents another Ewida Audit console from taking over the server.
If you plan to move the console to another computer in the future, you need to delete the NetHostConfig.xml file from the Agent Server computer. It may be located in one of the following paths:
- C:\Program Files (x86)\Codenica\Codenica Server\NET — when the server was run with administrator privileges,
- C:\ProgramData\Codenica\Codenica Server\NET — when it was running in standard mode.
Close the Agent Server before deleting the file.
Adding a host for the Agent Server
If the host representing the computer with Agent Server installed has not yet been added to the console, you need to do that before the first synchronization. You can use the new audit wizard or add the host manually through Host → New.
In the HOSTNAME field, it is usually best to enter the computer name visible on the network, provided DNS name resolution works correctly in that infrastructure. This is the most convenient option in a typical business network. However, if the server is in a subnet without proper DNS support, or in an environment where host names are not resolved reliably, it is safer to point to a computer with a fixed IP address and use that address during configuration.
In practice, the host name works best in a well-organized network environment. If the network is more complex or distributed, it is better to use a clear and consistent addressing method from the beginning.
Synchronizing the Agent Server
During the first synchronization, it is worth filling in the IP Address field with the current IPv4 address of the computer running the Agent Server. After a successful connection, the console can later retrieve this address dynamically, so manual entry is usually needed only when establishing the first connection.
If the network is simple and name resolution works correctly, the IP address field can be left empty. Entering an IP address in the HOSTNAME field only makes sense when the Agent Server computer uses a fixed IP address and that identification method is safer than using the host name.
After adding the host in the console, move on to synchronization. In Network Manager, select the computer with Agent Server and start the connection using the CONNECT (Server) button. If the connection fails, check the firewall configuration, antivirus software, and logs on both sides.
Only after the server connection works correctly should you move on to deploying Agents to workstations.
Installing Agents
The Agent is installed from the PCAgentInstaller.msi file and, like Agent Server, does not require special installation parameters in the standard scenario. After installation, you need to allow it in the firewall and antivirus software, because otherwise it will not be detected or synchronized correctly by the server.
To capture newly installed Agents, you must first add hosts in the console for the endpoint computers. The key part is correctly filling in the HOSTNAME field with the computer name exactly as it is visible on the network.
After the first synchronization, the Agent becomes linked to the Agent Server. This is also a security mechanism. If the Agent Server is going to be moved to another computer, you need to delete the NetHostConfig.xml file from the Agent computer in the following directory:
C:\Program Files (x86)\Codenica\Codenica Agent\NET
Before deleting the file, stop the PCAgentService service.
Once the hosts have been added, you can use the Search for Agents button in Network Manager. A successful synchronization is usually visible through a host icon change and a status update.
Alternatively, after synchronizing with the Agent Server earlier, you can copy the NetHostConfig.xml file from the working console directory, by default:
C:\ProgramData\Codenica\Audit\NET
to the Agent directory:
C:\Program Files (x86)\Codenica\Codenica Agent\NET
This method can be useful in environments where deployment needs to be done manually or in stages.
Script-based installation
In administrative environments where software is deployed automatically, you can use silent installation from your own scripts. This is a practical option when you need to deploy to a larger number of computers or when the company uses its own deployment procedures.
Installation
msiexec /i PCAgentInstaller.msi TARGETDIR="c:\Agent\" /qn /L*V "agent.log"
Uninstallation
msiexec /x PCAgentInstaller.msi TARGETDIR="c:\Agent\" /qn /L*V "agent.log"
Parameter meanings:
- C:\Agent — target installation directory,
- agent.log — log file created after the installation finishes.
It is worth remembering that a successful MSI installation alone does not replace the later network communication setup. You still need to configure firewall rules, make sure services are running, and properly synchronize the modules.
Remote installation
Agent Server and Agents can also be installed remotely using the wizard built into the program. This is a convenient approach when deploying to a larger number of workstations, but it requires a properly prepared environment. The target computer must have an active local administrator account, and all modules must be able to communicate through the firewall and antivirus software.
In this scenario, Ewida Audit uses the PSExec tool, so installation success also depends on system settings and administrative permissions on the target computer.
Enable the local Administrator account:
net user Administrator /active:yes
Disable the account after the work is complete:
net user Administrator /active:no
Check the account status:
net user Administrator
Depending on the network configuration, you can also specify additional installation options, including a temporary directory available on the remote computer. The TMP folder field defines the location where the installer must have read and write access. The default choice is usually enough, but in environments with stricter security settings, you may need to point to a different folder.
When reviewing remote installation logs, pay particular attention to the error code 0 message, which means the command completed successfully. Code 1605 often only means that the system did not find a previously installed version of the module that it tried to remove before installing the new one.
Problems with refreshing statuses
In some situations, Windows does not refresh interface controls immediately, so the host status shown in Network Manager may temporarily look outdated. This does not necessarily mean that synchronization failed. Sometimes manually refreshing the view is enough to force the statuses to be fetched and redrawn.
If the connection works but the interface does not show the changes right away, use the Refresh button. Only if the status still remains incorrect should you move on to analyzing the logs and network communication settings.
More information about how auditing and monitoring work is available on the Ewida Audit page.