Category Archives: exchange 2007

User Cannot Set an Out of Office in Exchange 2010/2013 or EventID 3004 Appears in your Event Log

exchange 2007, Exchange 2010, Exchange 2013

Recently had an issue where a user was setting an out of office in their Outlook client, but when a different user emailed them, no Out of Office was sent.  We did the traditional troubleshooting steps, check rules on the far side, check junk box, check OWA to ensure the Out of Office was set.  Everything looked good.  Strange enough, if an internal user went to email the person going on vacation, they would receive a MailTip to that effect:

image

But, went you sent the email to Paul Ponzeka, you would not get an Out of Office back.  So what gives?

One of the steps we took was to check if Microsoft Exchange Mailbox Assistants service was running.  It was, we restarted it, but still same effect.  One of the responsibilities of the Microsoft Exchange Mailbox Assistants service is to handle enabling the Out of Office.  In this case, it didn’t resolve anything.

The next step we took was to try disabling, and re-enabling the Out of Office message, and then checking the event log on the Mailbox server.  Low and behold, we found our answer:

Untitled

The above is EventID 3004 from the MsExchangeMailboxAssistants.  As you can see, there is an error stating the rules quota of the mailbox has been reached and the automatic reply rules can’t be enabled or updated.

Well, we found our issue, how do we fix it?  There are two ways.

The first the user can go through their Outlook rules and edit or delete existing rules.  Keep in mind that the length of both the rule actions, as well as the NAMES of the rules themselves will affect the size of the rule

The second is, the Exchange admin can increase the size of the rules quota.  By default, all mailboxes have a 64 KB quota, think of this as mailbox limits for Outlook rules.  We can increase this up to 256 KB on Exchange 2007 and later.  Exchange 2003 we cannot increase the rule size unfortunately, but that’s okay, because you should be off Exchange 2003 by now!

So, how do we increase the quota?  Easy.  Open Exchange Management Shell.  We can check the existing quota of the user pponzeka by running the command:

Get-Mailbox –Identity pponzeka | select RulesQuota

image

As we can see, its set to 64 KB.  To increase it, we run:

Set-Mailbox –Identity pponzeka –RulesQuota 256KB

image

And there we go, we can check by running the same Get-Mailbox as above to confirm:

image

Now, you cannot go past 256KB, this is the error you get, in this example I tried to set it to 512KB:

Untitled2

Users Are Unable to Use Activesync After Migration from Exchange 2007 to Exchange 2010

ActiveSync, exchange 2007, Exchange 2010, Threat Management Gateway

 

At a recent customer, we ran into an issue where a set of users were migrated from Exchange 2007 to Exchange 2010.  All of the users activesync worked without issue, but one user was unable to connect.  No matter what we tried, he would get”unable to connect to server” on his phone.  We checked the activesync logs, would see an initial connection but then nothing else.

Checking the event logs of one of the CAS servers, we found error event ID 1053: “Exchange Activesync doesn’t have sufficient permissions to create the container under Active Directory User”Untitled

So I opened Active Directory Users and Computers, selected View-Advanced Features:

image

Then I opened the user account, went to to the security tab->;Advanced:

23

Here, the “Include inheritable permissions from this objects parent” was UNCHECKED:

admin

I checked this box, hit apply, and boom active sync started working. Since this account was not a domain admin and just a standard user account, this was unexpected.

How to Import Users via CSV in Exchange 2010

exchange 2007, Exchange 2010

Create an csv file with the necessary information across the top row of the file as such:

image

The top row is going to coordinate with the S_.value that you are going to use in the following Exchange Shell command:

Import-CSV “C:Mailboxes.csv” | foreach {new-mailbox –Name $_.name –Alias $_.alias –UserPrincipalName $_.userprincipalname –Database $_.Database –OrganizationalUnit $_.organizationalunit –password (ConvertTo-SecureString $_.password –AsPlainText –force)}

image

And you should see the mailbox’s created below:

Untitled

That’s it.  You can see how the values map with their respective column names.  You can add as many users as you want, and change it so they go to different database’s.

You can even create an automated job to export from your production servers, and them import them to your DEV Exchange Servers for testing. 

Migrating Exchange 2007 ActiveSync to Exchange 2010. And why your Android may work but your Apple iphone / ipad may not.

ActiveSync, Client Access, exchange 2007, Exchange 2010, Security

 

When doing a migration from Exchange 2007 to Exchange 2010, one of the biggest item’s you need to watch out for is the migration of the ActiveSync environment, and be aware of how it can affect your end users.  You should also be aware of potential issues depending on the TYPE of active sync device you are using, as some will work, and other’s will have issues.

First we’ll start with the migration.  Our current Exchange 2007 ActiveSync environment is as follows:

Exchange07as

Here, we have one internet facing site, the NY site.  There is a DNS record for the CAS server in NY, activesync.company.com that points to the IP of the CAS server on the internet.  We have set the –externalurl to activesync.company.com and the –internalurl to newyork2007.company.local.  Note that newyork2007 is the NETBIOS name of the CAS server in NY.  We set both of these values with the following command:

Set-ActiveSyncVirtualDirectory –Identity “newyork2007Microsoft-Server-ActiveSync” –InternalURL newyork2007.company.local –ExternalURL activesync.company.local

In London, we have set the InternalURL attribute to the local name of the server, but leave the ExternalURL attribute blank.  We do not populate the ExternalURL attribute because London is not accessible directly from the internet. 

Setting the –internalurl attribute updates the SCP in active directory, so that any system that query’s AD itself, will be able to return the internal URL the user should access.  For instance, in our above scenario, LON07 the user configures his active sync device from the internet.  He put’s in activesync.company.com as the server address, which is the external DNS name of the NY CAS server.  The NY CAS server, as part of the Active Sync process, query’s Active Directory for the home mailbox of LON07, and then determines which site LON07 is in.  Since LON07 is not in the same site as the NY CAS, the NY CAS then returns the value for ExternalURL.  If we had entered a value here, such as lonactivesync.company.com, the users device would be redirected to it (as long as the device supported auto discovery, more on that later), and the user would connect, as long as that was configured properly.  In our case, since there isn’t, the NY CAS uses the InternalURL entry to determine what address the NY CAS should use to proxy on behalf of the LON07 user.  Essentially the NY CAS connects to the London CAS, and returns the Active Sync info to the users device, all seamless to the LON07 user.

Now, we start to introduce Exchange 2010 to the equation.  Microsoft’s high level recommendation is to create a new namespace, called legacy.company.com and have this entry point to the 07 CAS, and slide the 2010 CAS into the existing activesync.company.com namespace.   See the below diagram:

Exchange2010as

So we would need to reconfigure the –ExternalURL and –InternalURL attributes of the NY 07 CAS servers, as well as the NY 2010 CAS servers.  They can all be done by changing the values of the command listed earlier in this article.  The logic here is the same as 07-07 proxy.  If the NYC07 user enters in activesync.company.com into his/hers server address on their ActiveSync device, the 2010 CAS server will query AD, and determine that he is a 2010 user, but in the same AD site.  It will then query to see if an ExternalURL setting is populated, in which case ours is.  That users device, if it supports activesync, will automatically be redirected to legacy.company.com and their profile loaded, all seamless to the end user.

If LON07 enters in activesync.company.com the NY 2010 CAS server query’s Active Directory, finds his mailbox is in another site, and checks to see if there is an ExternalURL entry.  Since their isn’t, like before, it proxies the connection to the London 07 CAS server, all seamless to the end user. 

Now, this is all great, but what happens if your device does not support auto discovery?  Some active sync devices don’t work properly with auto discovery, and in that case, Microsoft recommends that you manually change their profile to point to legacy.company.com.  Maybe not even that, but for security purposes you don’t allow external devices to use auto discover to determine the settings.  In this case, you again have to manually point those devices to legacy.company.com  If you have any significant number of users, this can be insanely time consuming. 

Let me show you an example.  I had configured everything as it was in the above diagram.  I was configuring his active sync on an Apple iPad, a device that supports activesync.  Problem was, his account wasn’t working.  The following log file was taken from the NY 2010 CAS server for the NYC07 user, they are located at c:inetpublogsLogFilesW3SVC1:

 

Sep. 2801 15.56 Here, we can see that the NY 2010 CAS server is telling the device that it has the wrong URL, and is redirecting it to legacy.company.com.  This is because the device has advertised that it can do auto discover.  In our example, since auto discover is disabled, or because the device doesn’t handle auto discover properly, the user was getting a connection to server error on the iPad.

Now, with NO changes, let’s try configuring the same user, but not using the iPAD, but using Touchdown for the Android.  Now, all work’s without issue, here is the log files:

 

Sep. 2802 15.56

In this case, the configuration worked without issue.  Notice how it also says PrxTo:newyork07.company.local.  This is because since Touchdown did not advertise to Exchange that it could do auto discovery, Exchange knew it would have to proxy the connection back to the NY 07 CAS server to allow this to complete successfully.

The funny thing is, if we were to configure LON07 on the iPAD it would work fine.  Why?  Because since the London 07 CAS server does NOT have a value for ExternalURL, Exchange knows it HAS to proxy to London 07 CAS for all London users.

So, we want the same behavior for the NY users on 07.  To do so, we simply need to clear the ExternalURLvalue on the NY 07 CAS server.  We would do so with the following command:

Set-ActiveSyncVirtualDirectory –Identity “newyork2007Microsoft-Server-ActiveSync” –InternalURL newyork2007.company.local –ExternalURL $null

This would wipe out the ExternalURL value.  The downside to this, is that auto discover for this URL would not be included, so if you used Outlook Anywhere, or other devices to connect using Auto discover, it would cause issues.  If you didn’t though, for instance you disable auto discover, this fixes all your issues.  Now when you try to connect NYC07’s mailbox to the iPad, since there is no ExternalURL entry for the NY 07 CAS server, the NY 2010 CAS server is forced to proxy:

 

Sep. 2803 15.56

Now, all existing 07 users will continue to have access to their mailbox’s via active sync and will not need any changes when their mailbox’s are moved to 2010.

How to Lock Down Activesync Users to Specific Device in Exchange 2010 or Exchange 2007

ActiveSync, Client Access, exchange 2007, Exchange 2010

 

With the recent release of the Apple iPad, the new iPhone, not to mention the numerous Google Android phones available, there has been a dramatic increase in interest in using Exchange ActiveSync along with Exchange Server 2010 or Exchange Server 2007. 

Along with using these devices, comes certain questions regarding security.  One of those topics, covered by this post, is how to restrict end users to a specific ActiveSync device.  Some ActiveSync devices do not support certain features, that Exchange Admins may want to ensure don’t connect to their systems.

For this example, we’ll run the Get-ActiveSyncDeviceStatistics –Mailbox pponzeka command to determine the DeviceID of the users current ActiveSync device:

 

Jun. 2310 08.55

Note the DeviceID listed, 413030303030313542354533744.  This is akin to a serial number for this particular active sync device, its unique per device.  We can lock down this use, so that he can only use THIS device to connect to his mailbox via activesync.

To do so, we simple run the command Set-CasMailbox pponzeka –ActiveSyncAllowedDeviceIDs number1,number2

Jun. 2314 09.16

If we had multiple devices, you would just list both numbers separated by a comma.

If you ever want to remove the restriction, simply enter the null value:

Set-CasMailbox pponzeka –ActiveSyncAllowedDeviceIDs:$null

image

This will set this users mailbox back to the default of allowing all activesync device’s to connect!

How to Publish Outlook Web Access with RSA SecureID on Exchange 2007 or Exchange 2010

exchange 2007, Exchange 2010, Security, Threat Management Gateway

With many companies putting an emphasis on security, especially given the recent events involving Google and China, one of the things many companies turn to is two form authentication. The most popular brand out there is RSA, a subdivision of EMC.

Those who work with RSA know the deal. You get an appliance that you install on your internal LAN, and give your users a key fob.  This key fob has a display that changes a number sequence every sixty seconds. Users then use this key code, along with their user name and password, to log onto company resources. It’s regularly seen with network resources such as Citrix XenApp and web resources. Another solution where you can leverage it is by securing Outlook Web Access from Exchange 2007 or Exchange 2010 with RSA two form authentication. This means that users would need to use an RSA token along with their user name and password to log onto OWA.

Besides the RSA appliance, you would need also a Microsoft Threat Management Gateway Server (formerly called ISA Server) installed and operational. In the remainder of this article, I’ll show you how to publish the OWA page utilizing RSA for two form authentication.

Our test network is as follows:

1. NYRSA1 (RSA Server) – 10.1.1.100

2. NYTMG1 (TMG Server) – Local LAN 10.1.1.87, Internet 192.168.1.87

3. NYCAS01 (Exchange 2007 Client Access Server) – 10.1.1.12

Remember, with TMG the server generally has 2 NICS, one is connected to the unprotected network, or internet, and one is connected to the protected LAN, or internal network.  With Threat Management Gateway, you can either have it external to the domain, joined to a workgroup, or joined to the internal domain.  In our example, we have the TMG server joined to the domain.

So, the first thing we need to do is make the RSA server and the RSA Agent (in this case the TMG server) aware of each other and allow the TMG server to authenticate users with RSA. Log into NYRSA1 and launch RSA Authentication Manager Host Mode:

From here select “Agent Host” and select Add Agent Host. Fill out the name of the TMG server. (Ensure the server name is resolvable from the host, you can tell if it automatically fills in the IP of the TMG server):

Ensure the Agent Type is set as NET OS Agent and check Open to All Locally Known Users.

Select OK to save the host. Next, we need to export a file that we will import on the TMG server to establish communications. Go to Agent Host, Generate Configuration File and select One Agent Host:

Select the TMG server, NYTMG1 and save the resulting sdconf.rec file to the RSA appliance desktop. Next, move that file to a location on the TMG server that you can access from that server. You may need to use a USB key or CD if your TMG server is set with the default settings, which doesn’t allow remote or network share access.

Next, log onto NYTMG1, and copy the sdconf.rec files to two locations:

1. C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig

2. C:WindowsSystem32

***If you do not copy the sdconf.rec file to C:Program Files location, you will receive an error later on that I will show you***

Next, we need to export a copy of the certificate that is installed on NYCAS01, so that we can install this same certificate on NYTMG1. This is because the TMG server does SSL bridging between the two servers, and needs this certificate in order to unwrap the SSL packets from the client.

On NYCAS01, open an Exchange Management Shell. First we need to figure out the thumbprint for our certificate. You can get this by running the command Get-ExchangeCertificate:

Next, you can export this certificate to a .pfx file with the command above. Note we are exporting the certificate whose thumbprint begins with 331BF.At the end of this command, a logon prompt will appear which will force you to enter logon credentials to password protect the certificate. The prompt forces you to enter a logon name with a domain, but rest assured, it’s the password that’s important.

Now, copy the file export.pfx to the TMG server so you can access it locally, we need to import this certificate. On NYTMG01, open a blank console by running the command mmc and pressing enter. Now, select Add/Remove Snap In and select the Certificates snap in:

Select Computer Account and Local Computer and finish:

Next, navigate to the Personal store and select Import:

Now, the Import Certificate Wizard starts:

Select Next, and browse to the .pfx file you copied over:

At the next screen, select Mark This Key as Exportable, enter the password you created earlier and select next and finish. Now this certificate is available for use in TMG.

Next, let’s start creating our rule to publish OWA. Open the Threat Management Gateway Console and Select Firewall Policy:

Click on Publish Exchange Web Client Access from the Tasks bar on the right, which will start a Wizard. Give the rule you are creating a name:

Click Next, and select the version of Exchange you are using, as you can see, it supports all versions from 2000 through 2010:

Click next, and it will ask you if you want to publish a single site, or multiple sites for load balancing. In this example, since we only have one CAS server, we’ll select Publish a single Web Site or Load Balancer:

Click Next. The next screen is how you want the TMG server to speak to the CAS server. Since security is paramount here, we want to select “Use SSL”.

Click next, and now it will ask for the Internal Site Name. This is the DNS name of the internal CAS server. Since the TMG server is also on the local LAN, this would be the INTERNAL DNS NAME of the server, or in our example, NYCAS01.internal.local

Click next, and this screen is asking what EXTERNAL DNS NAMES your users will be typing into their browsers to connect to this page from an external computer. If you set the public name wrong, users won’t be able to connect. In our example, users will type in owa.company.com to access the OWA page from outside the organization.

Next, we have to select a Web Listener. Since we haven’t created on, there are none from the drop down:

Select “New” and we’ll be presented with the New Web Listener Wizard

After creating a name, select next, and you’ll be presented with should the listener require SSL. Since, again, security is paramount, we select require.

Next, it will ask what networks will be connecting to the server through this listener; here select External since this will be a web page that users will access from outside the company network.

Next, you’ll need to select the SSL certificate to use to secure this connection. Select the certificate we imported earlier:

Next, we are selecting particulars of how the user will log in through this listener. Here, we want to select HTML Form Authentication, and we need to select Collect Additional Delegation Credentials in the Form, and select RSA SecurID. This will add an extra field in the OWA logon page, requesting the SecureID token from the user’s key fob.

At the next screen, uncheck the option for Single Sign On:

At the next screen, you’ll get prompted with the following screen:

Select Yes. The TMG server has built in RSA dll’s, so you don’t need to install the RSA Agent software on the TMG server. You do need to select yes though here, to create the necessary firewall rules to enable communication between the TMG server and the RSA server.

Now, you’ll be returned to the Exchange Publishing Rule Wizard, and the Web Listener should be populated with the new Web Listener you just created:

At the next screen, you are presented with how the TMG server is going to authenticate to NYCAS01. Here, we are going to select Basic Authentication. Since it’s wrapped in an SSL wrapper, Basic Authentication in this case is secure:

The next screen will allow you to select which users can authenticate through this connection:

We’ll leave All Authenticated Users and select next. This will finish the creation of the rule. Ensure you hit apply at the top of the Firewall Page to apply the changes made:

So that takes care of the configuration on the TMG server side, but we need to ensure of some configuration on the Client Access Server side of NYCAS01.

On NYCAS01, open the Exchange Management Console, and Browse to Server Configuration->Client Access Server->NYCAS01 and right click the OWA virtual directory and select properties:

Remember, before we selected Basic Authentication as the method the TMG server would use to authenticate to NYCAS01, so ensure this is selected as an authentication option. After you apply these settings, you’ll need to run IISRESET /NOFORCE from a command line to recycle the IIS process and apply the changes.

So, now we should be all set, let’s test it out! If we point our browser to the external IP of the TMG server we should be presented with the correct logon page:

There we go! Notice the three boxes, one for user name, password and pass code.

One more thing. Remember before, how I warned you that if you didn’t copy the sdconfig.rec file to C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig you would receive an error? The error is actually received by the end user, as a web server busy message as below:

Just copy the file to correct location, no need to recycle services, and you should be all set!

Any questions just shoot me an email!

How to Apply Permissions to Public Folder and All Sub Folders in Exchange 2007/2010 Using Exchange Management Shell

exchange 2007, Exchange 2010, Public Folders

 

If you have a public folder that your working on, and you need to apply permissions to it using the Exchange Management Shell, its pretty easy.  The command is:

Add-PublicFolderClientPermission –Identity “Foldername” –user UserName –AccessRights PublishingEditor

For instance, to add the user pponzeka to the folder IT with the Publishing Editor permission, the command would be the following:

13-Nov01 11.12

This works great, but what if we have several subfolders under IT, and we want to apply the same user permissions to all of the subfolders as well?  A utility called PFDAVADMIN that was available from Microsoft used to allow you to do this, and it still works with Exchange 2007.  But, since the protocol it uses, WebDAV is no longer available in Exchange 2010, we no longer have this option.  Plus, the shell is easier to use anyway!

So, we have the IT public folder, and three subfolders:

13-Nov02 11.16

So, first, in the Exchange Management Shell, if we attempt to list the public folder IT, this is the result of what we’ll see.  The command used is Get-PublicFolder –Identity “IT”

13-Nov03 11.21

That’s odd, we know there are three folders underneath, why doesn’t it list these?  We need to add the –Recurse option to our command, so that it looks in the root, and everything underneath.  So the command should be Get-PublicFolder –Identity “IT” –Recurse

13-Nov04 11.23

Notice the Parent Path?  IT has listed, which means its a Top Level Folder in Public Folders.  The other three have IT listed, which means they are sub folders of IT.

So, back to the top.  The permission to add permission on a public folder was:

Add-PublicFolderClientPermission –Identity “Foldername” –user UserName –AccessRights PublishingEditor

So in our case it was:

Add-PublicFolderClientPermission –Identity “IT” –User pponzeka –AccessRights PublishingEditor

So, now, how do we apply these permissions to the root folder, in this case IT, and all three subfolders, in this case Documents, Emails and Plans?  Well, we use the piping command to pipe the entire list of folders to the Add-PublicFolderClientPermission command.

Get-PublicFolder –Identity “IT” –Recurse | Add-PublicFolderClientPermission –User pponzeka –AccessRights PublishingEditor

13-Nov05 11.30

Note that we don’t need to specify the Identity  in the Add-PublicFolderClientPermission because we piped that to it with the | command.

And there you go.  The user account has been given these rights to the root folder, IT, and all its subfolders.  This works for any number of subfolders, and you can also use the same method to remove access rights. 

Issues with IPv6 and Transport Servers using DNS Delivery in Exchange 2007 and General Troubleshooting Steps

exchange 2007, hub transport

 

I recently ran into a little bit of an issue at a company I was working with regarding their Exchange 2007 installation.  At the company, we had installed 2 Edge Transport servers in their main site in NY, and 1 Edge Transport server at their secondary location in Boston. 

One of their user’s complained that when they sent email to a specific domain, say xzy.com, they were getting delivery delayed messages, and eventually full blown NDR messages:

12-Oct01 14.39

12-Oct02 14.41

As we can see by the NDR, the message expired.  This happens when Exchange cannot connect to a certain destination mail server (such as the receiving company’s server is down), or there is no path to the destination.  The 1st is usually the fault of the receiving organization, the second is usually a configuration problem on your end.  Needless to say, we set out to troubleshoot.

Some basic stuff out of the way first.  All three Edge Servers were configured identical, and all experienced the same exact behavior.  All use Send Connectors, configured to deliver email using DNS, and thus connect directly to the destination domain.

The first thing I did, was the old telnet to the email server trick, and see if I can send email manually through telnet.  First, you need to figure out the receiving email server for the domain in question.  You can do this using the nslookup command.  In a command prompt, enter the command nslookup and hit return.  This will cause the machine your working off of to connect to its default DNS server, in NSLOOKUP mode.

Now, how do we find the server or servers that are responsible for receiving email on behalf of the organization?  Why, by searching for MX records of course!  In NSLOOKUP, tell the DNS server that you only want to know the MX records for a domain.  You do this by setting the query to MX only with the set q=mx command:

12-Oct04 14.49

Next, enter the domain you are having trouble with, such as espn.com:

12-Oct05 14.50

All the entries listed, are servers that receive email on behalf of espn.com.  Next, we want to see if we can send email to those servers, using telnet.  Which server should we pick?  Honestly, since they are all the same priority, to be really thorough, you can do all.  If one had a lower priority, start with that one, and work your way back up through the highest one.

Open up another command prompt, and run the command telnet nameofserver.domain.com 25 and hit enter:

12-Oct06 14.54

This is your greeting from the remote server.  Now, to send email, you must issue several commands.  First, introduce yourself using the helo  yourserver.yourdomain.com command.  Replace yourserver.yourdomain.com with the external DNS name of the server your connecting from.  If you don’t, the remote server may tell you that you forged your name:, and it may reject your email:

Correct:

12-Oct07 14.58

Incorrect:

12-Oct08 14.59

The whole process will end up looking like this:

12-Oct10 15.05

Okay, we’ll this means email was successfully sent from my Edge Transport server, to their email servers.  So that means that their wasn’t any connectivity issue between the servers.  Hmmm.  Next, on to Connectivity Logging!

Connectivity logging is not turned on by default, but can be configured by right clicking on the server in the console, and going to properties->Log Settings:

12-Oct11 15.10

Check the box to “Enable Connectivity Logging” and then select browse for the location. 

When I checked the log, this is what I found for the domain in question:

12-Oct12 15.13

The 72.21….. IP address is actually my DNS server for this particular Edge Transport server, and as you can see, it’s returning a DNS failure for that domain.  Well, that’s odd, being with the NSLOOKUP we already determined that we could resolve names for that domain on this particular server.

As a test, I changed DNS servers to be ones from a completely different company and……same problem.

We’ll, now we now why the emails are expiring, they cannot figure out how to get to the domain in question, so they sit in the queue until they expire and the server generates an NDR.

So we know its a problem with name resolution, but have no idea why it would be failing.  The next step I took was to use a network analyzer like WireShark to see what was happening.  Here is a sample capture for the domain in question that was giving me problems:

12-Oct13 15.19

Well, well well, here we have a DNS failure of Standard Query AAAA.  So, what’s going on here?  We’ll it seems that the server is performing ONLY an IPv6 DNS lookup, and not doing a IPv4 lookup.  Since the domain doesn’t have an IPv6 record for their domain, the query is failing. 

I reached out to Microsoft and it seems that this is a fairly common issue with Exchange 2007 servers working on Windows Server 2008 machines, as they come installed with IPv4 and IPv6.  Microsoft does not have an official fix for it, but does have three potential solutions for the problem.

  1. Place a regular SMTP server ahead of the Edge Transport server, and have the Edge Server forward all outgoing mail to this server as a smart host. (this is in my opinion the worst solution)
  2. Create a new Send Connector for that particular domain as an address space.  Set all email to forward through this connector as a smart host and add all MX records as potential smart hosts for this connector (this works very well, with the only potential problem being if the problem is spread across a lot of domain’s, there is a lot of work for the administrator)
  3. On the Send Connector, check the “Use the External DNS Lookup on the transport server”

12-Oct11 15.10

Even if you do not configure specific External DNS servers on the Edge or Hub Transport servers, this will cause the server to only perform a standard IPv4 lookup, which will resolve the issue.

Hopefully this article can help you when troubleshooting email delivery issue’s, giving you some of the steps you can take to track down the specific issue your users are having.

The “Require That All Senders are Authenticated” Does Not Work As Expected in Exchange 2007

exchange 2007, hub transport

 

I recently ran across an issue where one company was setting the “Require that all senders are authenticated” checkbox on a particular mail distribution group in Exchange 2007.

01 Jul. 07 11.26

Most organizations will do this, to ensure that only users of the internal Exchange organization can email this group, effectively stopping external users from emailing it.  This is particularly useful if the group is an extremely broad group such as “ALLUSERS” or something similar.

The problem was that even with this checked, the group was still receiving emails from outside senders.  What gives?  Well, I started doing a little digging, and this is what I found.

The company had followed this article by Scott Landry of the Exchange Team.  The articles discusses two ways to allow application servers to relay through Exchange 2007, applications such as SharePoint. 

If you read Scott’s article, his tone indicates that these applications are really internal applications.  He also lists two method’s for doing so.  The first being to set the receive connector to externally secured, and the second with manually applying permissions using powershell.  The company who was having this issue, had used the first method, eternally secured, but was using it to allow a 3rd party SMTP server that was used for spam filtering on it’s DMZ, to relay into Exchange.  So what’s the problem?  Essentially the method they used, gave TOO much permission to the 3rd party server.  Let’s take a look.

Scott’s article states to create a new receive connector, and set this connector to allow the IP address of the 3rd party server.  So, assuming our third party server has an IP address of 192.168.1.5, the connector would look like the following:

02 Jul. 07 11.34

Next, the article states to edit the authentication and permissions tab’s, so that “Exchange Servers” are set on the Permission Groups tab:

04 Jul. 07 11.36

  and then “Externally Secured” is selected for authentication:

03 Jul. 07 11.35

After this, the 3rd party server would be allowed to relay.  So you ask, what’s the problem.  Well, by setting the above, most importantly the Exchange Servers on the Permission Groups, you are essentially telling Exchange 2007, that any email that comes in this connector, should be treated the exact same as if it originated from an Exchange 2007 server.  This means that the emails will bypass anti-spam settings, as well as appear as if they were sent from inside the organization.  Scott lays out exactly what permissions are set:

MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS ExchangeExternally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS ExchangeExternally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS ExchangeExternally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Submit}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS ExchangeExternally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Now, any email from this connector, will bypass the “Require That All Senders are Authenticated” check box, because according to Exchange 2007, they are authenticated!

So, how do you fix it?  It couldn’t be easier, Scott’s article already tells us how.  He lists Option 2, grant the relay permission to Anonymous Users on the connector.

If we change the permission group, so that only “Anonymous” is checked, and remove “Externally Secured” from the authentication tab:

05 Jul. 07 11.42

06 Jul. 07 11.42

And then run one little powershell command:

Get-ReceiveConnector “3rd Party Relay” | Add-ADPermission –User “NT AuthorityAnonymous Logon” –ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”:

07 Jul. 07 11.45

That’s it.  Now, the third party server can send emails into the organization, but they are treated as outside emails.  This means they will be subject to size limit’s, anti-spam, as well as being rejected if they are sent to a group that has the “Require That All Senders Are Authenticated” setting checked.

Changing SMTP Database Location in Exchange Server 2007

exchange 2007, hub transport

In Exchange 2007, the only two servers that understand the actual SMTP protocol are the Hub Transport and Edge Transport Servers. The Edge Transport are used as messaging hygiene servers located on your company’s DMZ, and Hub Transport servers are used internally to route email between sites, and to local Mailbox servers.

Exchange 2007 no longer uses the Windows Server SMTP service to handle SMTP traffic. As a matter of fact, you have to make sure this service is not installed before you install either the HT or ET roles! Exchange 2007 uses a new SMTP stack, and also uses a new SMTP database system. It now uses a Extensible Storage Engine (ESE, formally JET) database to store and track the SMTP database. For best performance, specifically on a busy Transport server, you want to move the default location of these files. Just like with a standard ESE database, you preferably want to move the DB to one array or disk, and the log files to another array or disk.

To change the location, you need to edit the edgetransport.exe.config file, located in C:Program FilesMicrosoftExchange ServerBin. The location is the same for both roles. This file holds the defaults for many of the various options of the Transport services, but for now we will focus on the SMTP database and logs option.

Find the following keys:

add key=”QueueDatabasePath” value = “C:Program FilesMicrosoftExchange ServerTransportRolesdataQueue”

add key=”QueueDatabaseLoggingPath” value = “C:Program FilesMicrosoftExchange ServerTransportRolesdataQueue”

As you can see the default location for both is C:Program FilesMicrosoftExchange ServerTransportRolesdataQueue. Let’s change this. We want our Database to go to D:SMTP DB and our logs to go to D:SMTP Logs. You should edit the keys so that now they look like this:

add key=”QueueDatabasePath” value = “D:SMTP DB”

add key=”QueueDatabaseLoggingPath” value = “D:SMTP Logs”

Save the file, and restart the Microsoft Exchange Transport Service for the changes to take effect. There will be a longer than normal delay as it moves the files to the new paths. Now check the D:SMTP DB location, you will see the following files:

  1. Mail.que – this is the ESE database
  2. trn.chk – this is the checkpoint file used by the database to determine its position in relations to the transaction log files

In D:SMTP Logs you will find the following:

  1. Tmp.edb – the temporary EDB file
  2. trn.log – the transaction log (always 5 MB)
  3. trnres00001.jrs and trnres00002.jrs – these are reservation files just like Exchange uses to ensure that the Transport service can write its transactions to disk in case the disk fills up. Note these are always 5 MB each
  4. trntmp.log – the temporary transaction log file

This allows us to move our Transport database and logs off of the system file, for better performance, specifically on a busy Transport server.