Remote WEF and Remote PowerShell Connectors

As of version 5.0 of ConsoleWorks TDI began offering an alternative to installing the WEF on multiple machines. We listened to our customers and prospects and heard them tell us that not only did they not want to install a program on many Windows Servers in their environment, but in some cases they they weren’t allowed to. TDi Engineering provided a solution called the Remote WEF, and Remote PowerShell Connectors. What this means is you now only need to install the WEF once. For your other Windows Servers you simply run a command or two to ‘turn on’ RPC remoting features already built into Windows. This in turn allows the one installed WEF to become a ‘WEF Server’. If you have multiple sub-nets, you can if you like set up a WEF for each subnet so that only the machines in that Subnet need talk to their WEF Server via several ports while the WEF itself communicates with ConsoleWorks on the standard ports. As a matter of fact, this would be a TDi Technologies Best practice.

A quick discussion about network topographies

Sample Network Diagram

In the diagram on the left, for Subnet1, all machines are on the same network, so no real issue with ports exists. For Subnet2 however, the Windows Machine communicates with the WEF via ports 135, 1024-65,535, and 5985, BUT the WEF communicates with the ConsoleWorks server through the Firewall(s) via ports 5176 and 5178, thus reducing the number of ports that need to be opened in the firewall. Both ports 5176 and 5178 are configurable ConsoleWorks ports. (Note that the Reference Table displays the ports ConsoleWorks can use in a given environment, but not all of them will necessarily be used in your installation). On each of the Windows machines displayed in the diagram not running the WEF, you run the following command to enable Remote PowerShell.

What this does is:

• Runs the Set-WSManQuickConfig, which performs the following:
• Starts the WinRM service
• Sets the startup type on the WinRM service to Automatic
• Creates a listener to accept requests on any IP address
• Enables a firewall exception for WS-Management communications
• Enables all registered Windows PowerShell session configurations to receive instructions from a remote computer.
• Registers the "Microsoft.PowerShell" session configuration
• Registers the "Microsoft.PowerShell32" session configuration on 64-bit computers

Of course the user will want to explore any security ramifications associated with enabling PSRemoting and make the appropriate Firewall changes.
Remote management may be administered as a Group Policy Object in Active Directory. See the following links for more information
https://msdn.microsoft.com/en-us/library/aa384372(v=vs.85).aspx
https://www.briantist.com/how-to/PowerShell-remoting-group-policy/
As shown above, the WinRM service is used and you may see it’s configuration by using this command:
WinRM Get WinRM/Config.

Adding Remote Windows Event Forwarder and Remote PowerShell Consoles

Standard WEF Console

To add one or both of the Remote WEF and Remote PowerShell Consoles to ConsoleWorks you would do the following:
Install the WEF on the Windows machine of your choice. As you may already know, the WEF also enables the use of our PowerShell Connector on the WEF Host.
You may use the WEF on this machine as you would have in the past. That is to say you may configure it as a Console in ConsoleWorks using the Windows Event Forwarder and have it forward the Windows logs of your choice from itself. You can also have it forward any files you choose.

Standard PowerShell Console

As well you may add a PowerShell Console for this machine for command line activities. The difference is in the NEXT Windows machine of interest. You don’t install the WEF on the next one, you point to this machines WEF for the Host IP and use it for log and file forwarding. You do a similar thing for the Standard and Remote PowerShell Connectors.

Remote WEF Console

Notice how the Host IP: uses the same Host IP as the Standard WEF and the Remote Host: is where you are defining the next Windows Machine. (Make sure the account on the remote target machine that you use in the Remote Username: has enough privileges to do what you will need). This way you are leveraging the installation of the original WEF for the second, and third or more Windows Servers. You can also use the same Standard WEF for your Remote PowerShell Consoles.

Remote PowerShell Console

Again the Host IP: uses the same Host IP as the Standard WEF and the Remote Host: is where you are defining the next Windows Machine. (Make sure the account on the remote target machine that you use in the Remote Username: has enough privileges to do what you will need). This way you are leveraging the installation of the original WEF for the second or more Windows Servers.

Troubleshooting Tips

A good source for troubleshooting information can be found by running the following command from PowerShell: (You may find you first need to run “update-help”)

You may need to Create a rule in the remote machine Firewall to allow Remote PowerShell
(Run from a PowerShel prompt with Run-As-Administrator)

If the local computer is on a different domain or not on a domain
On the local computer make sure the FQDN of the remote computer is in the TrustedHost.
Example commands for getting and setting the TrustedHosts are given below:
(Run from PowerShell prompt with Run-As-Administrator for the Set-Item command to work.)