Cisco Etherchannel Configuration

I never seriously thought I would be blogging on how to configure Cisco devices, much less the advanced portions of the Cisco devices... but work has a funny way of making you learn things you never thought you would.

The site I am configuring has a HP blade enclosure with two Cisco Switches serving up the blades' primary and secondary ethernet connections. Right now, those switches have a single physical ethernet connection back to the core switch of the network (that way if one switch in the enclosure fails, the other takes over). We want to increase the bandwidth available between that blade center and the core switch because we are planning on filling up that blade center.

In addition, we have added a new core cisco switch as a fail over switch for total hardware redundancy up to the firewall. These two switches need to talk to eachother to pass traffic in the event that one goes down.

Enter Etherchannel, which aggregates single network connections on switches into a single logical connection with the combined bandwidth of both.

This is the site I used for configuring my switches: http://jklogic.net/cisco-ios-to-catos-etherchannel-configuration/

It gives a good understanding of what the tasks are at hand, but there are a few additional steps required to really get it going, and after confirming with a Cisco representative, this is what I ended up with for configuration:

Of the Cisco IOS flavor (cisco 3560G specifically, running 12.2):

...
!
interface port-channel1
switchport trunk encapsulation dot1q
switchport mode trunk
!
...
!
interface GigabitEthernet0/47
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
...

And of the CatOS variety (specifically the Cisco 2948G-GE-TX) we get:

...
!
#port channel
set port channel 2/47-48 20 (note that the 20 is an ID and is optional)
!
...
!
set trunk 2/47 nonegotiate dot1q (extra stuff about vlans)
set trunk 2/48 nonegotiate dot1q (extra stuff about vlans)
set port channel 2/47-48 mode on
end

At this point, you can connect the physical cables and you should have a working etherchannel. It looks deceptively easy written down... but this took like 6 hours to work out on the phone with Cisco.

For connecting IOS to IOS, just do the first IOS part on both devices... for CatOS to CatOS... you get the point.

When opening Microsoft Excel 2003 files in Microsoft Office Excel 2007 without having Excel 2007 already running you may find that files that a long time to open (20-60 seconds) while Excel 2007 or even Microsoft Office Word 2007, PowerPoint 2007 files take only a portion of that time to load.

The solution to this problem is easy and does not require any additional software other than the standard Microsoft Windows Explorer.

Open Windows Explorer (explorer.exe)
Select Tools | Folder Options from the menu
Go to the File Types tab
Select list item XLS (Microsoft Office Excel 97-2003 Worksheet) and click on Advanced.
If the "Appl ication used to perform action:" field the default value should be "C:\Program Files\Microsoft Office\Office12\EXCEL.EXE" /e" . Change this to "C:\Program Files\Microsoft Office\Office12\EXCEL.EXE" /e "%1" . Remember to enclose the full excel.exe path and %1 in parenthesis. Since Windows 95 this is a way to escape spaces in file names; %1 will return the file name of that file that is being opened by double-clicking.You can uncheck "U se DDE" but Microsoft Office Excel 2007 will bring it back to what you see above when you next open it.

Just confirm (hit "OK" ) on all the Microsoft Windows Explorer dialogs and next time you open a Excel 2003 file in Excel 2007 without having it already running you won’t have to wait! Problem solved

Ripped directly from m3rlin.org: http://www.m3rlin.org/wordpress/slow-opening-excel-2003-files-in-excel-2007/

NTLM Authentication using Outlook Anywhere on Exchange 2007

Here's a little gem I found in a response post to an article I was reading which worked for me immediately in getting NTLM authentication to work on Exchange 2007 / Outlook Anywhere / Outlook 2007 / Windows Server 2008:

1. In Exchange Management Console, go to Server Configuration > Client Access, double-click the server name, go to Outlook Anywhere (last tab), switch from Basic to NTLM.
2. in IIS, expand your server, go to Sites > Default Web Site > RPC, then in the “Features” page double-click Authentication, right-click Windows Authentication and choose Enable.

Exchange 2007 on Windows 2008 Bug With IPv6

Ok, whoever let this out of the door at Microsoft without resolving it is fired. Apparently, as described in this article: http://blog.aaronmarks.com/?p=65 there is a problem with running exchange and outlook anywhere on windows server 2008 such that if IPv6 is enabled in any form, you cannot connect. The nitty-gritty details come down to the server not listening on port 6004 for some reason when IPv6 is enabled... you can try it yourself by running "Telnet localhost 6004" in the command propmpt... no response.

Long story short, enabling the registry entry detailed in that article, unchecking ipv6 on the adapter, and removing the ::1 localhost entry from the hosts file then rebooting cleared the issue right up!

(For those wondering, the issue I was having was that outlook web access was working fine, and outlook was connecting just fine inside the network, but when i tried to use outlook anywhere with outlook 2007 outside the network I would persistently get an error indicating that outlook had to be online in order to connect.)

Configuring Exchange 2007 for external access to the Autodiscover service

You would like to think that going out and buying that expensive UCC Certificate then installing it properly into Exchange (as described in my previous post) would be enough, wouldn't you? Far from it. There are several follow-up steps required to properly configure Exchange 2007 (especially its Autodiscover service). Microsoft outlines a few of the commands here:

To configure the Outlook Anywhere service, run this in the EMS:

Enable-OutlookAnywhere -Server CAS01 -ExternalHostname "mail.contoso.com" -ExternalAuthenticationMethod "Basic" -SSLOffloading:$False

To configure the Offline Address Book service, run this in the EMS:

Set-OABVirtualDirectory -identity "CAS01\OAB (Default Web Site)" -externalurl https://mail.contoso.com/OAB -RequireSSL:$true

To configure the Exchange web services, run this in the EMS:

Set-WebServicesVirtualDirectory -identity "CAS01\EWS (Default Web Site)" -externalurl https://mail.contoso.com/EWS/Exchange.asmx -BasicAuthentication:$True

If using Unified Messaging, run this in the EMS:

Set-UMVirtualDirectory -identity "CAS01\UnifiedMessaging (Default Web Site)" -externalurl https://mail.contoso.com/UnifiedMessaging/Service.asmx -BasicAuthentication:$True

Of course, don't forget to change the contoso stuff to your own domain. Many of these can be configured in the EMC if you are scared of command line, except for EWS... that one can only be found in the EMS. Finally, add an A record for Autodiscover and point it to the external IP of your exchange server (the same IP that mail.domain.com is pointing to) and Autodiscover should be set.

Exchange 2007 and SSL

Installing a SSL certificate on an Exchange 2007 server is about the most unnessecarily complicated task I have come across to date. Unlike 2003, you have several names that this certificate needs to respond to, called SANs or 'Subject Alternative Names' such as autodiscover, mail (or your external fqdn), your internal dns name, and your internal netbios name. This certificate is so conveluted that most SSL certificate companies have a special process JUST for creating Exchange2007 certificates (and a REALLY special price to go with it...)

This site makes the process a little less painful by explaining in clear english step by step what needs to be done to generate the request from Exchange which you then submit to your CA (or external CA such as Entrust) so that you can get your .cer and move on.

http://exchangeninjas.com/cascert

Microsoft even links to that site, as well as other useful sources (such as vendors that provide these special Exchange certificates) in this site:

http://support.microsoft.com/?id=929395

-----------UPDATE---------------

Just another site that has proved useful to me in configuring an Exchange 2007 server with a UCC (multi SAN certificate):

http://www.sembee.co.uk/archive/2008/05/30/78.aspx

-----------UPDATE---------------

After doing some reasearch and consulting with some of my fellow techs, I found an article that describes how you can actually implement an Exchange 07 server (in a supported manner) that needs only a single name SSL certificate. The site is here:

http://www.amset.info/exchange/singlenamessl.asp

The major limitations of going this way are that you cannot use UC in Exchange 07 if you use this method, and your external DNS host MUST support SRV records (not a lot of them do...).

Backup Exec agents fail to start

It is unlikely that anyone will run into the same issue I have been facing over the past few days, but I figured I should post my eventual solution to this nightmare.

The starting symptoms of the issue I had were that the backup exec agent would not start... the service would sit at starting for a minute or two, then fail saying that the service did not respond in a timely fashion... or some generic message like that. Pushing out the remote agents again, trying different versions, manually cleaning the registry... none of it worked.

The problem started with the Mariofev virus that was discovered on almost all the workstations and servers at this site. The behavior of the virus is to copy itself to any network shares that it can access, then create an autorun.inf file in the directory such that every time a user opens that directory the virus autoruns and copies itself into the unknowing users registry. The virus then appends itself to any executables it can reach in a manner of ways, including attaching itself to outgoing emails. With some virus updates and installations of Spybot, the worst of the active virus was caught and stopped from further spread.

In addition, a Trojan W32.AgentMon found its way onto several systems, particularly the ones having problems with the backup agent. The action of this Trojan is unknown, but it modifies the tcp stack with some sort of hook. This was overlooked by all the antivirus and antispyware systems installed. It was discovered that a single file named vapor.dll exists in the C:\windows\system32 directory of infected computers with a date/time stamp of the moment the Trojan activated. This dll deeply entwines itself with the winsock/tcp functions of windows causing havoc due to being poorly written (I am not sure that it actually functions, but it messes stuff up).

While working with Symantec support on the backup agent installation issues, I decided to grab a copy of process monitor from sysinternals and track all calls etc from beremote.exe (the backup exec remote agent)… and low-and-behold when beremote.exe (and soon come to find any network application) tried to establish a port it was directed to call vapor.dll first… which promptly crashed. I renamed vapor.dll to vapor.dll.old and suddenly no dns worked. Returning the file to its original name re-enabled dns. It was clear at this point that the tcp stack had been hijacked. I began thinking that it may be a good idea to try and rebuild tcp/ip on the servers to see if that fixes the issue.

Following MS article 811259, I rebuilt Winsock and reinstalled tcp/ip on the network connection, rebooting after each. After rebooting, beremote.exe started up just fine and the system could get out to the internet while vapor.dll was still renamed. Examining process monitor, no calls are made to vapor.dll anymore.

I was then able to push out the backup exec 12 agent via the normal method and start the backups running. Backup of the two systems is being performed as I write this.