Split DNS setup for Exchange Server Internal Web Interface mail.domain.com and External DNS Resolution for domain.com
This is the simplest fix for a head scratching problem with posts all over the internet with different methods of trying to “fix” it.
Here is the issue: you have an internal server such as your mail server with on an Active Directory domain, but you also have an external Web server somewhere out there in internet land (in the cloud, what a bogus term).
For example: you have an internal Exchange mail server (or any mail server for that matter) on your Active Directory domain at the IP 10.100.32.10 and you have an SSL Certificate for mail.yourdomain.com installed on your exchange server. Your web server however is hosted in a server farm by shared or dedicated web host at www.yourdomain.com at xxx.xxx.xxx.xxx IP address. If your DNS is configured correctly, when you try to access mail.yourdomain.com internally, it will fail, because DNS has tried to resolve mail.yourdomain.com to the IP of your web server that hosts www.yourdomain.com at xxx.xxx.xxx.xxx. Easy fix there, you create (should have already created an A Record on the web server that directs traffic the WAN IP of your company firewall that is NATed back to the internal IP of your server. In trying again you will notice that mail.yourdomain.com resolves now to your WAN IP of your router. This is fine with some cheaper routers, as you can NAT this IP on 443 to your Exchange server and it will answer these requests. However, most firewalls will not allow this type of traffic referred to as hairpinning, where the source network IP matches the destination IP but it is sent to the WAN IP of the router. Cisco for sure will drop this type of traffic (there are many articles describing hairpinning as being possible on ASA devices, but none of them including Cisco’s documentation actually work on my ASA 5505s).
How do you solve this? Many articles say it’s simple (and it is). You just create a dns zone for yourdomain.com and create an A record for mail.yourdomain.com. This is great, and after a flush of dns caches this will work just fine. Ping mail.yourdomain.com and the IP of your exchange server will reply 10.100.32.10 in our case. Now ping www.yourdomain.com and you will get host can not be found. What happened???? This new authoritative zone you just created for yourdomain.com does not contain a www record for yourdomain.com. I scratched my head over this for a bit and did some searching around the net looking for possible alternate methods. CNAMES, delegation, forwarders, none of these work for this situation.
The fix is so simple it makes me cry. Create a zone in your DNS server for mail.yourdomain.com. Create an A record with a blank host name and set the IP, which in this example is 10.100.32.10, and flush dns and reregister it. Problem solved. The mail.yourdomain.com now properly resolves internally to 10.100.32.10 and the yourdomain.com requests will properly forward to an external DNS for resolution.
Many thanks to gingerlime.com for the information he provided in his blog.
RansomWare-This type of virus is one that is typically distributed through a fake email claiming to have a greeting, card, invoice, check, PO, or something of the sort attached. It can also be published as a fake adobe or java update. In case you aren’t familiar with the utter destruction, you should read here http://www.bleepingcomputer.com/news/security/the-locky-ransomware-encrypts-local-files-and-unmapped-network-shares/
Basically if you don’t have backup, you have likely lost all of your files. In some iterations it is even smart enough to remove previous versions saved by Windows using VSS so that you can’t simply restore them to yesterday. In 95% of cases, you better have a good backup, I prefer Crashplan, I feel like it is the best backup solution on the market and is very very inexpensive. I have it on every device I own.