Troubleshooting DSM issues managing remote services

If you're confident that all machines are in the same domain, it may be a firewall or network security issue that's blocking the necessary communication between your machines.

Please verify the following:

1. All machines can ping each other.
2. All machines are able to connect to each other on the ports 10101-10105, 3389, 8090, and 9090. You can use the Test-NetConnection cmdlet in PowerShell to test the connection to a remote machine on a specific port. Here is how you can do it for each of your ports:
   

   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 3389
   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 8090
   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 9090
   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 10101
   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 10102
   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 10103
   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 10104
   Test-NetConnection -ComputerName 'RemoteMachineNameOrIP' -Port 10105

3. Firewall settings are not blocking communication on these ports.
4. Group Policy Settings: In some cases, group policy settings could be preventing the management of services. Check with your IT department to ensure there are no group policies in place that might affect this.

If the above checks are all positive and the issue still persists, I suggest checking the Microsoft Windows event logs on each machine to see if there are any error messages related to the distributed services. The logs could provide us with more information about what's happening.

For the DSM to perform these operations, you'll need to have the necessary administrative permissions on the remote machine. Also, the Remote Registry service must be running on the remote machine for these commands to work, and you may need to configure the Windows Firewall to allow remote service management.

The following commands can test that the Venio Console machine is able to manage services properly on the remote servers hoisting the VenioDistributedService. If these commands fail, it indicates that some security settings, firewall, permissions, or group policy is preventing it.

net use \\RemoteComputerName /user:username password
sc \\RemoteComputerName stop VenioDistributedService
sc \\RemoteComputerName start VenioDistributedService
net use \\RemoteComputerName /delete

net use will leave a persistent connection to the remote machine that will need to be closed, which is what is done with the command: net use \\RemoteComputerName /delete

To allow remote service management, you need to ensure that AWS Security Groups, Azure firewall, Windows Firewall (or any other firewall software you may have installed) allows incoming connections for the necessary services and ports. Here are the main settings you need to check:

1. Remote Service Management (NP-In): This rule allows the Server service to receive inbound network process (NP) traffic.
2. Remote Service Management (RPC): This rule allows the Server service to receive inbound remote procedure call (RPC) traffic.
3. Remote Service Management (RPC-EPMAP): This rule allows the Server service to receive inbound RPC Endpoint Mapper traffic.
4. File and Printer Sharing: This group of rules allows inbound file and printer sharing traffic. The exact rules needed depend on the network profile (private, public, or domain).

You can enable these rules using the Windows Firewall with Advanced Security console (wf.msc).

Remember, these changes can potentially expose your machine to external threats, so only apply them if necessary and if you understand the implications. If possible, limit the scope of the rules to specific IP addresses or subnets to reduce the potential exposure.

If you're still facing issues, we can arrange a screenshare session to help you troubleshoot this further.