Home » Posts tagged 'exchange' (Page 2)

Tag Archives: exchange

Outlook pulling the wrong user’s mailbox?

Recent problem I ran into at a client’s site was that when they were attempting to setup an Outlook profile for a specific user it would keep on pulling a different user’s mailbox. Also same thing happened when they pulled the e-mail from the global address list, though oddly enough if done from a Blackberry it was just fine. Checking the two mailboxes involved in Exchange 2007 yielded no wrong information. All the names and aliases were correct. So to dig deeper I broke out adsiedit.msc. Pulling up the user’s properties and checking the mail property showed that both accounts had the exact same e-mail address. A swift change of that to the proper smtp address corrected the problem immediately on all accounts.

Manually Connecting Mailboxes by MailboxGUID or Hey! Where did my mailboxes go?!

On Monday I learned the hard lesson of always making sure that your Active Directory is replicating properly, especially in the middle of a migration. At least this is the best explanation that I can come up with for what happened. We were wrapping up my first Small Business Server 2003 to SBS 2008 migration, with an already less than stellar performance due to the Exchange System Manager refusing to show the new server, and to a few mailboxes that refused to move over. We had to export those monstrosities to pst before we could move them over. Which turned into a mixed blessing later on. Things had come to the point of being ready to remove Exchange 2003 from the SBS 2003 server, which went along fairly smoothly. We rebooted the server ready to breathe a sigh of relief that this portion of the migration was done. Not so lucky, the true nightmare began then. The calls from the users began coming in that they could no longer access their email, even after confirming that they really were pointing to the new server. I fired up the Exchange Management console to find out what was wrong to discover that no mail enabled users showed up, aside from the three we had to import from pst. I took a look for disconnected mailboxes and to my horror we did not have any. Restoring from backup wasn’t an option as we had not been able to take one yet. This began a mostly fruitless 6 hour call with Microsoft. It is very sad when your bluetooth dies and you also are able to recharge it and start using it again during the same call. Fortunately I did not stop doing research into the problem while on the call and eventually cobbled together the solution that I am going to present to you now. My warning is – do NOT do it this way unless you absolutely have to.

Before I had made the call I ran a Get-MailboxStatistics. Interestingly this reported everyone’s mailbox as existing and containing data. This meant that the users had lost their Exchange attributes. To verify this required digging into Active Directory with ADSI edit. Open up ADSI edit and connect to the default view. Drill down to the OU of your user and pull up their properties. You will see a list of attributes set there. Some specific attributes are required to mail enable a user. legacyExchangeDN, homeMTA, mailNickname,  msExchHomeServerName, and finally as well as perhaps the most import is msExchMailboxGuid. homeMDB is required as well but fortunately this was still populated. On the users that were missing mailboxes none of the msExch attributes were set. Fortunately there did remain some users, so looking at those I was able to glean a few of the attributes.

legacyExchangeDN –This attribute needs to be configured to point to the login for your mail enabled user. This drills down through the organization name and the default administrative group name ending down in your user’s login name. Example:  /o=first organization/ou=exchange administrative group (fydibohf23spdlt)/cn=recipients/cn=jland

You can pull this information from your mailboxes actually. Run Get-MailboxStatistics | ft Displayname, LegacyDN

homeMTA – This may not be required under Exchange 2007, but we decided to set it none-the-less. This drills down through Active Directory to where your Exchange server’s MTA resides. Example: CN=Microsoft MTA,CN=SERVER,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=linthicum,DC=local

mailNickname – This one is easy to miss yet is very important. If you user still doesn’t show up as mail enabled go back and make sure you entered in the mailNickname. This generally would be your user’s login name, though you should consult your organization’s naming scheme to be sure.

msExchHomeServerName – This one is fairly self-descriptive. This points to where your server is located in Active Directory, as based off the organization name. An example is: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=SERVER

msExchMailboxGuid – This one is the kicker. Exchange won’t know what mailbox to connect your user to without this info. But it isn’t exactly easy to get ahold of either. First run Get-MailboxStatistics | ft Displayname, MailboxGUID. You’ll see everyone’s msExchMailboxGuid listed right there. Easy? No. Now you have to be able to get that into Active Directory. Which is a royal pain. Go down through the properties of your user and open up msExchMailboxGuid to put in some new information. See how you only have the options of decimal, hex, octal and binary? You need to convert this GUID into something usable.

Go to joeware’s great site and download the adfind tool.  Open up a command line and go to where you extracted the tool and run adfind -gc -b “” -binenc -f ” msExchMailboxGUID={{GUID:98ee00d7-df19-4282-bedf-3a1340b8b7c0}}” –dn where of course you replace the GUID with the one you are searching for.  This will return you some interesting output which still isn’t quite usable, though it may look that way at first glance. Your response is mostly hex, but not fully. You need to translate it. I’ve included a utility at the bottom of this post that you can use to convert this output into full hex. Pull up the table at Ascii Table and use this for your translation. Start going through the characters and when you find one that doesn’t match like for instance a lower case j or the number 4 unpaired, look through the red characters in the table for your character and you’ll see the conversion to hex in the separate column. Go through the whole string this way and you’ll eventually get a fully hex string. Go back into your msExchMailboxGUID and put that in and after you click ok you’ll see that the attribute has been populated with the string that you began with. Look very closely at it to make sure it matches. If there’s some deviation go back and check your look-up tables again. This string should match completely, otherwise your user will end up with an empty mailbox created. Here’s an example of how to convert the returned string:


D7 00 EE 98 19 DF 82 42 BE DF 3A 13 40 B8 B7 C0

And another one:


54 BA A0 34 6C B8 EE 4D 9F D6 40 6D 25 08 CE A0

Your user has now been mail enabled as a refresh of your Exchange Management Console will show, but is still missing a number of Exchange attributes. Run Set-Mailbox “My User” –ApplyMandatoryProperties and all the rest will be filled out for you.

The last bit is to clean up Outlook for your users. Even the ones not using Cached Mode still showed as disconnected until we re-put the server back into their profile. For the ones using Cached Mode it was also a good idea to delete their .oab files from their directory to force them to download a newly rebuilt OAB. This may or may not be necessary in your case as that was most likely related to the timing in the migration. If you didn’t delete them it would populate the DN to the user they’re emailing rather than the email address, thusly bouncing back to them when they emailed.

Some extra reading:

Understanding Mailbox GUIDs

How to Re-Home Exchange Mailbox Accounts

Using ADFind Utility


I’ve finally gotten around to writing a simple little utility for converting the resulting GUID output from adfind into full hex for pasting back into adsiedit. Usage is guidconvert.exe <adfind guid output>.  Here’s the utility. C# source has been included as well.

Windows Server Backup and Exchange 2007 with iSCSI

Since service pack 2 has recently been released for Exchange 2007 this has enabled the long awaited integration of Exchange aware backups with Server 2008’s new Windows Server Backup. WSB is Microsoft’s replacement of the old ntbackup that we all know and love. This new backup is simpler to use than ntbackup and has a number of interesting new features, but it also lacks some of the more useful features of ntbackup as well. One of these missing features that is rather vexatious is that you have to backup whole volumes. You can’t just backup the mailbox stores, or even specific files and folders as well. Another missing feature is that you can’t just back up to a specific folder nor mapped drive. This can cause problems, especially at small businesses that don’t feel like shelling out for a more robust backup program. You will have to dedicate a whole volume to WSB, so this requires a bit more planning ahead. This is a problem that we had to get creative about solving last night on the spot though.

The client has an Exchange 2007 server running on Server 2008. No backup software had been acquired as they had been waiting for SP2 to enable Exchange aware backups. SP2 installed just fine, which was great considering all the other migration issues we had earlier, but then the hang-up we ran into was discovering that WSB wants its own volume for backing up, and doesn’t want to backup to a mapped drive on one of the other servers. This was a source of consternation for a bit as we did not have a spare volume available nor could we just grab an external drive for this either. Fortunately StarWind Software has this great, and free, iSCSI target software. Using StarWind we were able to turn a chunk of storage on the server into a virtual drive and set it up as an iSCSI target. All of this without having to reboot too, which is a huge plus. We connected this to the Exchange server using iSCSI and that meant we were finally able to backup the server and flush those transaction logs that had been building up. This made for a pretty quick and easy fix as StarWind is simple enough to set up.  If you are in need of a quick fix for your backups this is one way to do it.

Exchange 2007 Single Server Migrations for Profit or Headache

I was originally writing up a guide for migrating, actually transitioning, Exchange 2003 to Exchange 2007. There are lots of guides out there that would have better screenshots and perhaps even better written steps. Basically I would not really be meeting a need as there are already plenty out there doing so. So instead I am scrapping all of my original work and concentrating on issues that I believe are not talked about as much out there. Mostly these issues affect those that are doing single server migrations, which is basically you have one Exchange 2007 server holding all of your roles. They have caused me a great deal of headache and drama which I am sure is true for others doing such migrations as well. I would imagine that this is mostly the SMB sector, which is where the majority of my work in this is being done. Let’s talk about the biggest issue now, client access.

The CAS role plays a big part in your Exchange organization as it is the broker for all requests to your mailboxes. You will have MAPI requests as well as HTTPS, POP3 and others coming into this server. By the way as a security side note the recommended set up is to have your CAS role on your internal network with a reverse proxy in your DMZ for proxying requests through to your CAS. The CAS when it receives a request for a mailbox that resides on a 2003 servers proxies that request through to your 2003 server. No issues at all there. The problem that comes up, though, with having a CAS on the same server as your MB is that web requests no longer get proxied to your 2003 servers, they get redirected. This is due to davex.dll handling the requests on a mailbox server, and it will grab the requests first. Exprox.dll is what handles proxying. This redirection is not configurable either. So that causes a problem when it is redirecting an external request to an internal FQDN. That doesn’t work out too well and you get lots of angry OWA users wondering why their logins take them to an invalid address. For a more in depth explanation take a look here. Let’s take a look at a few ideas for mitigating this issue.

First off an easy fix would be to make sure your Exchange 2003 FQDN has a matching public address. This is not a recommended set up though at all. It is against best practices to have your internal domain match your external domain. Not to mention you can get a number of funny DNS issues going on if this is the case unless you’ve planned things out well. Read this article for some more DNS information, and especially look at the split-brain section. All of this can turn your easy fix into a much more complicated fix. If the stars do just happen to be right on your migration though, then go for this. Set up a public record matching your internal Exchange 2003 name and you’ll be set. This will be transparent to your users.

Next up would be to use a reverse proxy such as ISA 2006. This would be great as it keeps the strict definitions of your DMZ as it keeps your Exchange servers from having to blur the lines. This doesn’t seem to be something that most SMBs care about in my experience though. They don’t seem to see the need for security and how having a properly defined DMZ fits into this. But that goes into an entirely separate article and could sound a bit ranty.

Other methods will require a bit more cooperation from your users. Remember, in Exchange 2007 the OWA access by default is /owa. So you will need to communicate this to your users as you migrate their mailboxes over. Then, remove the /exchange virtual directory through the Exchange Shell and recreate it in IIS. Finally, set up /exchange with a custom 403 redirect to a different port on your external address. Mind you that you’ll need to make sure that port does point to your legacy server. This either requires your firewall to be able to do port translation or changing the ports on your 2003 server.

Finally, and the most recommended method, is to set up a temporary virtual machine that will purely host a CAS role. Then everything will be proxied as it is supposed to be. The down side to this is that it would require a separate license in which case you might as well plan for as separate CAS to begin with.

Fortunately as long as everything is configured properly Outlook Anywhere and ActiveSync seem to work just fine. Some dangers with those is if you are having some DNS issues internally or improper communication with a global catalog. This can add to your headache so you will want to cozy up to rcpping which you can grab from Microsoft and get more info about how to work it from here. Another great site I have recently found out about is the Remote Connectivity Analyzer. This site will enable you to test Outlook Anywhere, ActiveSync, SMTP and Autodiscover with detailed error messages about where these break down. It will become your best friend very swiftly.

I guess the moral of all these suggestions is to make sure you have your migration well planned out. Run it through a test lab first if you are able. Definitely make sure you test it out, and definitely don’t spring it on your users unawares. You could be in for quite a “fun” surprise.

Troubleshooting 554 Relay Access Denied NDRs

This week I was called up by a former employer to come in and check out their Exchange 2003 server. They had been having problems with a few domains rejecting their e-mails for the past few weeks and what made it a big problem was that one of the domains was their largest customer. Not a good scene there. They were receiving several NDRs of which the most prominent was something like <mail.domain.com #5.7.1 smtp;554 5.7.1 foo@otherdomain.com: Relay access denied> as well as some from another domain referencing authentication. I don’t have it in front of me so unfortunately I can not quote it. Doing some research I found that there was not much information on troubleshooting this and related problems even though there were lots of people asking. So I am putting together a quick little guide based off how I came to a resolution. Your results may vary.

E-mail problems generally break down to two types. Either you are having DNS problems, or you have a misconfigured server. First thing to do of course is to narrow down whether the problem is on your end or if it is on their end. Generally one would suspect the problem to be on their end when it is only a couple of domains giving you a problem, but that isn’t always the case. Easiest way to narrow it down is to break out the command line utilities. First verify that you are using the same DNS as your Exchange server. This is very important otherwise it may skew the results of your test. Next off you need to find your problem domain’s mail server. You have several options for this. The lazy way is to go to MX Lookup Tool and put in the domain. It should return the mail servers for that domain. You’d be best off going with the first one. The site also has some interesting diagnostic utilities that you could run against your mail server as well as their own. The non-lazy method, and one you should learn anyhow, is using nslookup. Pop open your command line and run nslookup. Here’s the steps to go through to get the MX records for their domain.

> set type=mx
> problemdomain.com

Non-authoritative answer:
problemdomain.com mail exchanger = 10 mail.problemdomain.com.

Authoritative answers can be found from:

There’s the mail server that you are working with. Sometimes there are more than one so start from the top and work your way down. Next up is we’re going to send an e-mail the archaic way, through telnet. Note that not all SMTP servers respond with the exact same banners and responses, though the codes should generally line-up. Open up a telnet prompt.

telnet>  open mail.problemdomain.com 25

Connected to mail.problemdomain.com.
Escape character is ‘^]’.
220 mail.yourdomain.com ESMTP Sendmail 8.9.3/8.9.3; Tue, 27 Aug 2002 16:20:32 -0500

At this point you need to identify yourself as your mail server.

ehlo mail.mydomain.com

250-mail.problemdomain.com mail.mydomain.com [] pleased to meet you
250-SIZE 10000000
250 HELP

Now it is time to identify who you are.

mail from:yourself@mydomain.com

250 Ok

Next is who you are e-mailing.

rcpt to:testaccount@problemdomain.com notify=success,failure

250 Ok

If you get a 250 Ok at this point then telnet will most likely complete successfully. Also if you get a  510 Bad user that is ok as well, since you are not getting a relay access denied which is what your Exchange server is getting when it communicates with this server. This means their server has passed the telnet test so you need to start digging into your server to fix the problem. If you get a 550 Relaying denied error though that is different. Time to modify the test. Change your DNS server to a known good external DNS server that resolves both forward AND reverse look-ups correctly. If it does not resolve reverse look-ups it is no good to you. Switch your machine over to that DNS server and run through the test against. If it is successful then you’ve tracked the problem down. Time to look at what DNS servers your Exchange is using. Or it may also be time to check on your own internal DNS servers, as they may not be resolving addresses correctly. If, though, you receive a failure from your telnet test with a known good set of DNS servers then things may be a bit more complex. Do a look up on whether your domain is in any Realtime Blackhole Lists (RBL). If it is then definitely check to see if you are running an open relay and get yourself off those lists fast. If not then you had best get on the phone with the admin over at problemdomain.com to find out if your domain has been blacklisted. Finally another thing to verify is your SPF record on your external facing DNS. Here is a site to help craft an SPF record.

For completeness here are the rest of the directions to finish sending your e-mail through telnet:

354 End data with <CR><LF>.<CR><LF>
Test e-mail
250 Ok
221 Bye
Connection closed by foreign host.

In case you were wondering at the client’s site it turned out the Exchange server was set up to use an external DNS server that was not resolving reverse look-ups. This was causing a few sites to return the 554 relay access denied NDRs.

Some other tools that may be helpful in diagnosing your problem:


Exchange Best Practices Analyzer

%d bloggers like this: