You should be able to check the Event Viewer and go through the Security section to see the Audit Successes and Failures for logins. If you are on the general tab, there is a box at the top (which you have to scroll through) that would say why it failed if it was a Failure and lower in that box it would say the source network address and the workstation name that was connecting.

Update:

To view the RDP logins:

Event Viewer > Applications and Services logs > Microsoft > Windows > TerminalServices-RemoteConnectionManager > Operational

Add the clean IP to the server.

Edit the firewall to NAT all connections FROM port 25 to use the new IP.

# iptables -t nat -A POSTROUTING -p tcp --dport 25 -j SNAT --to-source NEW.IPA.DDR.ESS
# service iptables save

Ensure that the IP is on eth1
or…

# iptables -t nat -A POSTROUTING -o eth1 -p tcp -j SNAP --dport 25 --to-source 123.45.6.7

What is the difference between SATA I, SATA II and SATA III?
SATA I (revision 1.x) interface, formally known as SATA 1.5Gb/s, is the first generation SATA interface running at 1.5 Gb/s. The bandwidth throughput, which is supported by the interface, is up to 150MB/s.

SATA II (revision 2.x) interface, formally known as SATA 3Gb/s, is a second generation SATA interface running at 3.0 Gb/s. The bandwidth throughput, which is supported by the interface, is up to 300MB/s.

SATA III (revision 3.x) interface, formally known as SATA 6Gb/s, is a third generation SATA interface running at 6.0Gb/s. The bandwidth throughput, which is supported by the interface, is up to 600MB/s. This interface is backwards compatible with SATA 3 Gb/s interface.

SATA II specifications provide backward compatibility to function on SATA I ports. SATA III specifications provide backward compatibility to function on SATA I and SATA II ports. However, the maximum speed of the drive will be slower due to the lower speed limitations of the port.

Example: SanDisk Extreme SSD, which supports SATA 6Gb/s interface and when connected to SATA 6Gb/s port, can reach up to 550/520MB/s sequential read and sequential write speed rates respectively. However, when the drive is connected to SATA 3 Gb/s port, it can reach up to 285/275MB/s sequential read and sequential write speed rates respectively.

To get the depth information of your network interfaces like IP Address, MAC Address information, use the following command as shown below.


# ip addr show


$ sudo ip addr show

]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:44:43:24 brd ff:ff:ff:ff:ff:ff
    inet 216.xx.xx.xx/24 brd 216.xx.xx.255 scope global eth0
    inet6 fe80::20c:29ff:fe44:4324/64 scope link
       valid_lft forever preferred_lft forever


# ip route show
216.xx.xxx.0/24 dev eth0  proto kernel  scope link  src 216.xx.xxx.xxx
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 216.xx.xxx.1 dev eth0

#  ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:44:43:24 brd ff:ff:ff:ff:ff:ff

If you have a hardware RAID controller, I’d find out if you can read its log (if 3Ware, use tw_cli). And, whether you have hardware or software RAID, you can look at the SMART parameters of the disks (if the disks are connected to a RAID controller, you may need special commands to access them. See the smartctl manpage).

If you do:

# smartctl -a /dev/sdX

I always primarily look at:

Reallocated sector count. Is especially bad when its increasing over time. And, I don’t fully trust a disk that has any reallocated sectors.
Look at the SMART error log. It’s tricky to read at first, but the primary thing is to see if there are events, and at what time (expressed in disk age in hours) they occurred.

You can see the current disk age as one of the SMART parameters. If it’s recent, it may be related.
Also, keep an eye on dmesg and syslog to see if you have get errors over time. For example, disk errors often show up long before it’s a fatal problem as ata exceptions. We have a central logging server (using rsyslog) that notifies me about ata exceptions. A quick example on how to set that up:

# /etc/rsyslog.d/60-smtp.conf:

$ModLoad ommail
$ActionMailSMTPServer localhost
$ActionMailFrom noreply@example.com
/etc/rsyslog.d/70-mail-ata-errors:
$ActionMailTo you@yexample.com
$template mailSubjectATA,"ATA error on %hostname%"
$template mailBodyATA,"You have ATA errors. Mostly it's the disk and you get these errors before a possible mdraid setup kicks the drive.\r\nBEWARE: ata1.00 is first ata, first disk. Ata1.01 is first ata, second disk. Use the ata-to-device-names.sh script to identify devices.\r\n msg='%msg%'"
$ActionMailSubject mailSubjectATA
$ActionExecOnlyOnceEveryInterval 3600
:msg, regex, "ata.*exception" :ommail:;mailBodyATA

Another thing you can do is a memtest. Ubuntu installation DVDs/CDs have those in the boot menu, and I believe any Ubuntu server has one in its regular boot menu as well. Let is make one pass at least, more if possible.

Do you have ECC RAM BTW? ECC RAM is important for long term stability and data integrity.

/var/log/syslog is a good place to start for Ubuntu systems. Find the first log messages after the reboot. They will say something about syslog starting and what kernel version you are running.

Then scroll up and find the last line, which was logged before the system crashed. Scroll up further to see if you can find any log messages from the kernel itself.

Go through other logs in /var/log to see if you can find any lines with a time stamp between the last log line from before the crash and the first from after.

It is highly probably that all of this effort can only narrow down the time of the crash, but not tell you anything about why the server crashed. In particular if it is a hardware fault, it can be difficult to get proper log messages.

First, you want to check /var/log/syslog. If you are not sure what to look for, you can start by looking for the words error, panic and warning.

grep -i error /var/log/syslog

Red Hat family distributions (including CentOS and Fedora) use /var/log/messages and /var/log/secure where Debian-family distributions use /var/log/syslog and /var/log/auth.log

If you have system graphs available (e.g. Munin). Check them and look for abnormal patterns. If you do not have munin installed, it might be an idea to install it (apt-get install munin munin-node)

You should also check root-mail for any interesting messages that might be related to your system crash.

Other logfiles you should check is application error-logs. E.g /var/log/apache2/error.log or similiar. They might contain information leading you to the problem.