Windows BranchCache OS requirements

I was asked at the Windows Intelligence event I presented at on Monday if there were specific requirements on what version of Windows 7 could be used with BranchCache. It turns out there are, you can only use Windows 7 Enterprise and Ultimate Editions to take advantage of BranchCache - even if you are doing a workgroup configuration and not a domain.

The step by step guide has the requirements for both the client and the server and can be found here.

It appears that Microsoft is assuming small and medium sized companies should be using Enterprise or Ultimate Editions to take advantage of newer technologies like BranchCache and DirectAccess. I will ask around to see if this will be changing at all in the future and post back up what I hear. I am a bit surprised to read that Windows 7 Professional didn't make the cut for BranchCache as a feature but licensing is a complicated thing that honestly I think very few folks truly understand, even within Microsoft.
- Ed

Windows Intelligence DirectAccess and BranchCache presentations

I had a fun time yesterday presenting on Microsoft DirectAccess and BranchCache at the Windows Intelligence NorCal event. Thank you to everyone who attended the event, I appreciate the discussion and feedback and as promised here are the slide decks for download.

DirectAccess

BranchCache

If you attended my sessions you might have missed sessions by Jennelle Crothers and Steve Evens who both gave excellent presentations from what I heard (I was giving mine so I couldn't be in two places at the same time!) and should be making their presentations available on their sites also. Doug Spindler also presented but I am not sure where his presentations are posted but I will find out and update here shortly.

It was also nice to see the West Coast Microsoft DPE IT Pro Evangelists at the event, Chris Henley, Chris Avis and Harold Wong. They are all wonderful presenters and totally passionate about what they do - a big shout out to them - you guys rock!
- Ed

Cisco IPSec VPN Client - 5.0.7 Released- Win7 64-bit support

Cisco has officially released a 64-bit version (non-beta) of the IPSec VPN Client, version 5.0.7 (vpnclient-winx64-msi-5.0.07.0290-k9.exe) available for download. Finally a Cisco supported 64-bit version of the IPSec client for Windows 7! It is available for download on CCO but requires a valid CCO login and current contract to get the code.

Do read the release notes, there are caveats for Windows Vista in the release notes so if you are planning on running it on 64-bit Vista make sure you review those. Also, it is important to note there is a specific section titled "Windows 7 and Vista Window Auto-tuning Feature Might Cause Network Timeout Problems" that states:
"Windows 7 and Vista support a feature called "Receive Window Auto-Tuning" that continually adjusts the receive Windows size, based upon the changing network conditions.

Some people reported that auto-tuning causes network timeout problems with some applications and routers. If you have experienced such problems, you can turn it off using the following procedure:

Step 1 Open an elevated command prompt.
Step 2 Enter the following command to disable auto-tuning:
netsh interface tcp set global autotuninglevel=disabled


If this solution does not fix the problem, you can turn it back on, as follows:
Step 1 Open up an elevated command prompt.
Step 2 Enter the following command to enable auto-tuning
netsh interface tcp set global autotuninglevel=normal

To view the states of the TCP global parameters, use the following command:
netsh interface tcp show global "

So for all of you that have to support Windows 7 64-bit and still have Cisco VPN Concentrators, PIX's and ASA's doing IPSec only you have a valid supported solution now! I don't know why it took so long but it is nice to know you don't have a pay the AnyConnect essentials license if you don't want to. I do like many of the features and advantages with AnyConnect, it just seemed wrong that to get VPN for a 64-bit OS you HAD to use AnyConnect only and pay the premium for the client.
- Ed

Cisco ASA - PAT performance and logging

It isn't a common issue for most small to medium businesses but occasionally you have to remember that when doing port address translation (PAT) or overloading a single IP address with multiple IP's behind it that there are actual limitation on how many session you can do simultaneously. Remember that for a single IP address can only do 65536 TCP sessions. If you remove the first 1024 you are down to 64512.

So why is this important? Turns out if you have enough hosts generating requests behind the ASA you can run out of ports and if you generate traffic quickly enough you will start getting the following error in the log files:

%ASA-3-305006: portmap translation creation failed for tcp src XXX dst XXX

The message description from Cisco is here and shows the format as:
%PIX|ASA-3-305006: {outbound static|identity|portmap|regular)
translation creation failed for protocol src interface_name:source_address/source_port
dst interface_name:dest_address/dest_port

I don't think this will be a common issue as it takes a lot of hosts to generate this sort of load doing thousands of requests a second. To exceed the threshold for instance you would need 250 hosts generating approximately 260 requests per second sustained per host and they would have to keep those sessions open for the ASA to start having this issue.

Luckily it is a rather fast and easy fix if you have more than one Public IP address available. You can simply add another global statement to the ASA with more public IP's to overload and the ASA will happily start spreading the load across the new IP addresses that you add. In terms of syslog, this is severity level 3 (error) so it should show up in most syslog data that is collected. Definitely recommend running Splunk, it makes finding these sort of errors so much easier!

Also, while it may be saying a portmap translation failed the ASA itself doesn't run out of resources from a CPU or memory standpoint. The ASA will continue to run along nicely it just won't be able to generate new TCP sessions as fast as your hosts may be requesting. This makes it really important to be looking at your log files to know what is happening. The problem is a function of how you are doing overloading, not a limitation of how the device performs that function.
- Ed

Cisco ASA - how to see your pre-shared-key

One of the annoying things about managing pre-shared keys for both site to site vpn tunnels and group pre-shared keys for client vpn tunnels is the fact that if you do a show run they are starred out (*) in the configuration file.

So you will see something like:
pre-shared-key *

If you need to recover back your keys because you have lots of folks running around with Cisco IPSec VPN clients with a standard PCF file and you can't remember what the group pre-shared-key is or don't have it documented you can do the following command.

more system:running-config

This will output your running-config file with the pre-shared-key variable in clear text.

Obviously this is useful for site to site keys also because you might have a tunnel set up with a third party vendor or a partner and you can't remember the key at all because you made it up on the fly with the other network engineer on the phone (That never happens... really.)

This will NOT show you the enable or passwd values because those are actually encrypted. You will have to use other tools to break those or do a standard password recovery process.
- Ed