Last night's (6/14/12) Microsoft automatic security update install broke the VPN remote access on our Windows SBS 2003 server.

While a client can establish the VPN connection to the server, outlook is unable to connect to exchange (error 0x80040115 - connection to Microsoft Exchange is unavailable) and network shared drives on the server cannot be mapped.
Also, the IVv4 network connectivity status of the VPN as seen from the client is "Limited" rather than what is usually is - "Local.

This is a very simple configuration - one server that does everything - exchange and RAS. Two NIC's - LAN and WAN. No firewalls on the server. This tiny server has been working fine for months (actually years) until this
update.
Inbound SMTP to the server working fine. As does outlook web access. All updates and service packs are current. So far as I can tell, all services are running normally.
Any thoughts on what's causing this problem would be appreciated. Thank you.

There is an amazing pack of free network admin tools. click here to download it

I have seen problems like this, but it was actually a problem on the XP machines trying to connect. The binding order in the registry got hosed, and \ndiswanip entry got placed at the bottom of the list.
One one of the afflicted machines, loot at this key inn the registry: "SYSTEM\CurrentControlSet\Services\Tcpip\Linkage" and see if NDISWanIP isn't last in the list. It needs to be first, if you have a Split DNS, or the clients aren't using your
domain DNS servers. If I'm correct, you can get more info, and a VBS script at the link below. The script can be incorporated into the CMAK profile as a Pre-Init task.

http://www.isaserver.org/tutorials/work-around-vpn-clients-split-dns.html


Need to support users over the internet? click here try our remote control online beta

LonesomeDove - Thanks for the suggestion. I looked into it. I can replicate the same VPN remote client problem with Windows XP, Vista and Windows 7 clients..all of which worked fine yesterday. The problem started immediately after the automatic
security update install and reboot of the server last night, so I'm fairly confident that's the cause.
I did check the binding order as you suggested...on the XP machine...NDISWanIP was bound last. I moved it to first position, but no difference...same problem. Definitely seems like the VPN adapters aren't seeing the LAN....which would
explain the exchange connection failure and shared drive mapping problem. However, there's nothing obviously wrong in the settings I checked so far a I can tell. I may rerun the RRAS wizard and hope that that will reset some parameter somewhere
that the security update messed with.

Thanks again - David E.

Need to support users over the internet? click here try our remote control online beta

If you have the clients do nslookup, with no parameters, it will show you what DNS server it is talking to by default. If it is not one of your domain DNS servers, that's the problem. I hadn't heard of Win7 seeing the problem I mentioned,
and I banned Vista long ago. You may be on the right track restarting the RRAS setup.

There is an amazing pack of free network admin tools. click here to download it

Good news. Problem resolved. Tried uninstalling all the Microsoft security updates that were auto-installed last night - June 14, 2012. That didn't resolve the problem. So, I reapplied all the security updates. Same.
Then I re-ran the RRAS wizard...and the problem cleared up. VPN and remote access are working fine now. This isn't a very satisfying resolution, because it's unclear what the wizard fixed that got corrupted by the updates...but at least
it's back to normal. Hope that is helpful to someone with the same problem.
Note: The telltale symptom was that when VPN remote access was broken, the server VPN ports were mapped onto a different subnet (192.168.2.*) than the server LAN (192.168.3.*). I have no explanation why. This is why the exchange
server wouldn't connect nor would drive shares work. When things are working correctly...the VPN is mapped, as you'd expect, into the same range as the LAN and are assigned by DHCP on the server. At least it works now.

Need to support users over the internet? click here try our remote control online beta