Stop draggin’ my port around

Problem: Remote user reports he is unable to connect to shared network drive over PPTP VPN.

Troubleshooting:

• Tried connecting to VPN from my computer. Could not connect. Conclusion: remote user is neither stupid nor crazy.
• Tried to telnet to server over port 1723. Could not connect.
• Checked firewall logs for dropped connections on port 1723. None there.
• Disabled VPN access at firewall. Tried to connect again. Failed again. Checked logs again. Showed dropped connection. Conclusion: firewall is not the problem; when the rule is enabled, it is successfully letting PPTP traffic through.
• Checked status of Routing and Remote Access Service. Looked fine. Restarted service anyway. Still can’t connect to VPN.
• Ran netstat -a on server to see if server was listening for connections on port 1723. It was, but it was in CLOSE_WAIT status. A-ha! Now we’re on to something.
• Ran netstat -b -v -o to see what exactly is using port 1723. Surprise! The executable involved is store.exe, i.e., Microsoft Exchange. What the hell is Exchange doing using port 1723?
• Restarted Exchange Information Store. (Not easy — had to try several times before it successfully stopped.) Ran netstat again after services restarted. Now server not listening on port 1723 at all. Progress, I suppose, but not good enough.
• Restarted RRAS. Still not listening on 1723. Started swearing. Didn’t help.
• Started Blackberry Enterprise Server Dispatcher, Policy, and Synchronization services, which had to be stopped in order to stop Exchange store. Tried VPN again. It works!

Conclusion: I have no idea why Exchange hijacked the VPN port. But I will remember that netstat is my friend.