TCP endpoints & Server Consolidation– where are you connected to?

I recently brought a new Wireless router/ADSL modem/switch, which lasted a grand total of four days, during which time I raised three support calls and didn’t get more than 4hours uptime from the device!  If that wasn’t bad enough the Firewall was also blocking Outlook Remote procedure Calls (RPC) within HTTP, which is my primary method of getting email at home.  I have since not surprisingly switched devices and have been running to date for 47 continuous days and with no email or other issues...anyway now to explain why this is relevant to Server consolidation.
When I initially got the problem I remembered some advice I’d given to a customer who was having issues tracing applications to remote IP addresses within his server farm.  This can be a common issue during server consolidation as often there is no documentation detailing where or what IP address an application points to.  The tools described below can also be used to check where you’re browsing to on the Internet, or as an aid to confirming that the useful (shareware?) utility you may use - isn’t misbehaving, or to check Firewall settings.  Here are two tools you could use:

Method 1
From a Windows Command prompt, you can use the NETSTAT utility (type “NETSTAT /?” For detailed help) with the parameters –AON
E.g. NETSTAT –aon

Method 2
Obtain https://www.sysinternals.com/Utilities/TcpView.html which gives a similar output to Netstat but with a few key differences (I will list some relevant to me) which are, name resolution of the Process ID (PID) and highlighted activity/real time monitoring.  Without the name resolution feature you will need to look for the PID in a tool such as Task Manager to obtain the process name.
The output enables you to capture where an application is connected to and the protocol, port used.  This can be invaluable to determine which applications you may have problems with if they are re-hosted or moved to another network segment.

So for my email example I was able to confirm that Outlook was connected to a specific (correct) IP address and that port 443 (HTTPS) was being used.  You can also see what protocol is being used, TCP in my case, local and remote addresses, connection State information and PID details from the output given.  By monitoring I was able to ascertain that sockets 1000-9999 were being used by Outlook (listed after the “:” in the Local Address column – to allow me to unblock the Firewall for port 443 sockets 1000-9999.  Note: this was a quick fix and the sockets range in reality may be different so please do your own monitoring.

So which tool would you use?  Netstat is on most Windows machines by default, the other would require an install – so I’d normally plumb for Netstat especially if I needed to script the data gathering process.  However from my home PC, I prefer the GUI version of TcpView (there is a command line version included in the download).