Friday, September 07, 2012

Put your Exchange lab on the IPV6 Internet

I've been working on a project with a United States Federal Government customer that requires their e-mail system to operate on the public IPv6 Internet. I've spent a lot of time waiting for the customer's network to be configured for IPv6, but now that the deadline is near I realized that putting an Exchange system on the Internet is one of the few things that I've never done before and I didn't want to do it for the first time on a customer system and that I would want a way to reliably test the customer's configuration. Putting my Microsoft Exchange 2010 lab onto the IPv6 public Internet would solve both problems.

IPv6 Tunnel

My lab is on a small business connection from the local cable company. We have a small range of fixed IPv4 addresses, but no IPv6 support. I solved this problem by obtaining a free IPv6 tunnel from Hurricane Electric Internet Services They make it easy to configure, and even give you the netsh commands to configure your server to use the tunnel.

netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel
netsh interface ipv6 add address IP6Tunnel 2001:470:7:305::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:7:305::1

Since my server is NATted, I had to use the internal IPv4 address in the netsh command.

Exchange 2010

I would like to say that there was a lot of configuration involved, but it just worked. I had learned earlier that Exchange 2010 automatically looks for AAAA records when doing DNS delivery. This lab environment is a pretty basic install, a single multi-role Exchange 2010 on Windows Server 2008 R2. Of course, to receive e-mail, you will need to have an MX record. The tunnel provider assigns a quad A record to your IPv6 address, I simply changed the MX record to point to that FQDN. MX preference = 10, mail exchanger =

Address: 2001:470:7:305::2

Of course, you could configure your own AAAA record if you'd like (I did this too).

I did some additional experimenting with mixing IPv4 & IPv6 in the MX record. In doing so, I also created a separate receive connector for IPv6 to make it easy to figure out what was what. Testing Testing my lab was also pretty easy. First, gmail supports IPv6, so when I sent my first e-mail to gmail, the headers were all IPv6! Additionally, there are some test reflectors out there ( & that are only supposed to receive e-mail on IPv6 and will send a response with the headers, both use IPv6 for the reply by default, so looking at the headers of their replies will let you know if your IPv6 is working. In addition, I have configured protocol logging on my send and receive connectors to verbose, enabling me to verify in the logs that IPv6 was being used for message transfer (you can also see this in the message tracking log).


Putting my lab on the IPv6 public internet was easier than I thought. More and more customers are considering IPv6 functionality, and many US government agencies are under a mandate to support IPv6 on their public facing systems. Even though it is easy, there is no reason to do it in production for the first time, put your lab on IPv6 and experiment, gaining experience as you go.

Wednesday, September 05, 2012

IPV6 Newbie

Just taking some time to brush up on the IPV6 for a work project. IPv6 Certification Badge for JosephDurnal

Friday, August 24, 2012

Exchange Pickup Directory Transport Size Limit

I ran into a problem on a well established Microsoft Exchange 2010 installation that has implemented the edge server role and Microsoft Forefront Protection 2010 for Exchange Server.

The administrator was trying to release a message from the Froefront quarantine but it wasn't going trough.  A DSN was sent back to the forefront e-mail address with the status of 550 5.3.4 PICKUP.MessageSize; message size exceeds a fixed maximum size limit with the same information under a fail event in the message tracking log.

This system has been up and running for quite some time with a 25 megabyte limit regularly passing messages of that size, but this message was only a little over 10.  It seemed a little strange, I had configured it during implementation and everything seemed in order, but obviously, something wasn't quite right. 

The answer ended up being in the set-transportconfig cmdlet and the maxsendsize argument.  While on the internal exchange organization, that was set way back when, it wasn't done on the edge transport servers.  It didn't seem to be a problem when the server is doing its thing, transferring e-mail to and from the Internet. 

To resolve the problem on Microsoft Exchange 2010 Edge Transport server where pickup directory messages exceed the maximum message size, use set-transportconfig -maxsendsize 25MB (or whatever size you need). 

Saturday, July 28, 2012

New pictures of the kids

I updated the header of my blog with new pictures of the children :) finally.  The "new" pictures are about a year old now but that's OK, they are a lot more up to date than the pictures from 2008!

Here are the old ones

Quite the difference!

Monday, June 18, 2012

Tracking e-mails to invalid addresses

Customer request: Can you let me know what was e-mailed to an address that doesn't exist on our system? 

Consultant answer: Maybe, but any information on these e-mails will be limited to the source IP and from address. 

Most e-mail systems don't save much when an e-mail is received for a user that doesn't exist, since the recipient e-mail address is sent early in the establishment of the SMTP connection, most e-mails are dropped as soon as the server receives the invalid e-mail address.  On Microsoft Exchange Server 2010, the SMTP connection is logged through verbose protocol logging on the connectors, if this is enabled, you can get a little bit of information on e-mails sent to invalid addresses.

I whipped up the following command for doing just that.

for /f %a in ('dir /b') do for /f "delims=, tokens=3" %b in ('type %a ^| find /i ""') do for /f "delims=, tokens=1,8" %c in ('type %a ^| find "%b" ^| find "MAIL FROM"') do echo %c - %d >>; unknownuser.log
I'll break it down

for /f %a in ('dir /b')
This one should be easy, dir /b, a basic directory listing and store it in a variable, you'll see %a in the next line.  I ran the script from c:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive\

for /f "delims=, tokens=3" %b in ('type %a ^| find /i ""')
This one is a little more complex, using the %a from above, I type each file piping to find, the e-mail address I'm looking for.  I'm only looking for the connection's session identifier in the comma delineated file, hence the tokens=3, which I store in another variable.

for /f "delims=, tokens=1,8" %c in ('type %a ^| find "%b" ^| find "MAIL FROM"')
Using the file names in %a from above, plus the session ID I've stored in %b, I type the files again, limiting it to only the session ID I'm looking for, filtering it further to the MAIL FROM entry.  This will get me the e-mail address that tired to send the e-mail.  This time I want different fields, 2 this time, the date-time and the data, which will give me some useful data in my variables %c and %d.  Notice that I don't define %d, the for command does that for me.

echo %c - %d >> unknownuser.log
finally, take the %d and %d from above and write them to a file

I actually started doing this in powershell, but it was taking longer than I thought it should.  Since I've done a lot of log parsing with the for command, I decided to go to what I know and use the old DOS commands.  My colleague is working on a powershell version, if he posts it to his blog, I'll give him a link. 

Wednesday, April 11, 2012

The MCSE Returns

Just about everyone in the technology field knows about the MCSE or Microsoft Certified Systems Engineer, once one of the most respected certifications in the industry that lost its luster to brain dumps and rampant cheating. I earned my first MCSE back in the 90's, before they made it a little easier but near the end of it's era of respectability. The certificate is still displayed on my office wall.

The MCSE's decline was realized and replaced with a new certification system, the MCTS, Microsoft Certified Technology Specialist and the MCITP, Microsoft Certified Information Technology Professional. These certifications are an improvement on the old MCSE/MCP certs. I hold several MCTS and three MCITP certifications.

Enter the new MCSE, the Microsoft Certified Solutions Expert, part of the new Certification Version 3, CertV3 effort. This new certification system will be based on a core set of technologies with expert specializations in areas like Exchange, Lync, and SharePoint. These new MCSE exams are supposed to measure real 300 level knowledge and should be more challenging which should hopefully yield better qualified "experts". Only time will tell if cheating and brain dumps will dilute the value of this "expert" certification, or if the term MCSE, with its damaged reputation, will still be considered cheap.

One thing is for sure, the MCM, Microsoft Certified Master, will still be the certification that differentiates the experts from the masters.