For those of you who have had a chance to play with Microsoft’s Windows Vista there is a handy new feature called the “Network Map”. Vista uses the Link Layer Topology Discovery protocol (LLTP), a layer 2 protocol that gathers information about neighboring devices to create (among other things) a top-down map of your network segment.

However this feature is disabled by default on domain member machines, reason being that if you had it enabled in the enterprise on every machine it could pose a security risk (and lets just face it, this isn’t exactly something I want enabled across the enterprise). However for your IT department or in smaller domains you may want to enable this feature. To do so you’ll need to make some quick group policy changes.

If you haven’t already create a GPO and link it to the OU that computer account(s) reside in. Click on “start” and in the search box (or a run dialog) type “MMC”. Click on “File” and “Add/Remove Snap-in…” and add the “Group Policy Management” snap-in to your console. Drill-down and edit the policy you wish to change and browse to Computer Configuration>Administrative Templates>Network>Link-Layer Topology Discovery. Here you will notice 2 policies, “Turn on Mapper I/O (LLTDIO) driver” and “Turn on Responder (RSPNDR) driver”. If you enable the mapper driver it will allow the client(s) to connect out over the network and look for other devices, if you enable the responder it will allow other machines to locate these client(s).

We recently (finally) upgraded our Microsoft Exchange server to SP2, a nice feature that adds for us WM5 folks is the Exchange Server ActiveSync Push capabilities. Basically our device sends a long lived https query to the server which waits until something new shows up (or the timeout period expires) before sending a response.

However we quickly discovered that we were not getting “pushed” the mail, but we were getting a long string of Event 3033 Application Log errors on the Exchange server (The average of the most recent [200] heartbeat intervals used by clients is less than or equal to [540].)

Our firewall configuration is a little atypical in that we are basically using 2 firewalls. A Cisco PIX (515e) directly connected with an ISA server sitting on the DMZ. Yes I realize that it’s a bit redundant to have a firewall behind the firewall, it’s this way because when we originally deployed ISA we weren’t quite comfortable yet with sticking a Windows server directly on the internet (if we were to do it again I’d stick it on the outside). Needless to say things have yet to change and for lack of a compelling reason to do so they will probably remain the same for some time to come.

Now Cisco PIXes are pretty much a staple when it comes to corporate firewalls and the default timeout for TCP connections is 60 minutes, in addition we have plenty of customers running them with Exchange and were not having issues on their end so you can imagine our confusion. I scrubbed through the ISA configuration and made sure the HTTPS timeouts were at least 45 minutes (2700 seconds), the default maximum heartbeat interval for Exchange, but they were still failing.

Fortunately one of our other engineers who is good with PIXes came up with a better way of doing it using the Modular Policy Framework (MPF), keep in mind that this only works under 7.x:

Basically, we create a new class map for HTTPS traffic, then apply it to our policy map (“class HTTPS”) and set the timeout option to 45 minutes. Since we were unable to find a config out there (Google, etc.) relating to HTTPS timeouts with MPF I wanted to make sure to post for those of you running into similar issues.

As I mentioned we do have a lot of other clients with PIXes in front of their Exchange servers, however none with ISA on the DMZ so my hunch is that our issue may be related with this configuration. I’d love if someone else with a similar configuration could confirm/deny my theory.