Home » Troubleshooting (Page 2)

Category Archives: Troubleshooting

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:

\D70\EE\98\19\DF\82B\BE\DF\3A\13\40\B8\B7\C0

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

And another one:

T\BA\A04l\B8\EEM\9F\D6\40m\258\CE\A0

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

Update:

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 Media Player and Other Libraries

I have been greatly enjoying Windows 7 recently. Microsoft has done a lot right with it. I enjoyed it so much that I actually migrated my primary workhorse from OpenSUSE to Windows 7. Being able to pin programs to the taskbar as well as programs like remote desktop having quick access to recently used links through the start menu are nice little touches. One of the great things about 7 though is Homegroups. They’re a much needed breath of fresh air for your average workgroup. I can see this benefiting small businesses a lot as you get some immediate access to easy file AND printer sharing. The printer sharing part was what I liked best. Just add yourself to the homegroup and ta da it is there. But what I am going to touch on today is something that gave me some grief for a few hours last night and this morning.

I decided to give this streaming media thing a go. The music I was wishing to listen to, which by the way is the fantastic Piano Concert #2 by Sergei Rachmaninov, was on another system. So I thought that this would be a great time to test out the streaming capabilities. I quickly switched it on in the homegroup for that system and started up Windows Media Player on my desktop to give it a go. Sorry! Access denied. WMP was complaining that it cannot access the file. This would happen for everything in the music library on that system. Interestingly enough though, was that videos and pictures would work just fine. I found it odd to be a permissions issue since that was working, and also if I browsed through via Explorer I could play the same music files with whatever media player I chose, including WMP. It didn’t quite seem like a permissions issue, especially since WMP’s error message was so generic that it could be anything, but I wasn’t quite ready to discount it yet. So I gave it a good night’s sleep and returned to the problem in the morning.

After a cup of mocha things became a little bit clearer. I decided to test playing music on the problem system from my desktop, thereby reversing the stream. This worked just dandy. So I gave the music folders a permissions inspection and found the problem. On the system that could stream music from the library there was an extra user with permissions, namely the WMPNetworkSvc who had Read permissions on the folder. The problem system did not have this permission. Unfortunately it wasn’t so simple a fix as just adding the user as the system would report that the user did not exist. Inspecting other folders such as the pictures and video folders did report the proper permissions. Thusly I fixed things with a bit of Powershell magic, and if you use this don’t forget to substitute your account name for MyAccount:

Get-Acl C:\Users\MyAccount\Videos | Set-Acl  C:\Users\MyAccount\Music

This turned a trick! I could stream music to my heart’s desire. Now as for speculation as to why this particular permission is missing, the only guess I have is due to this system being a system that was upgraded from XP, to Vista, to Windows 7. I could quite easily see something getting fouled up along the way, especially since this is over a number of years. It is a good test system though. The other system I have has gone from Vista to 7 and it did not exhibit the same issue.

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
Server: 192.168.1.1
Address: 192.168.1.1#53

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

Trying 64.24.111.68…
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 [203.32.9.6] pleased to meet you
250-8BITMIME
250-SIZE 10000000
250-DSN
250-ONEX
250-ETRN
250-XUSR
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:

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

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:

SMTPDiag.exe

Exchange Best Practices Analyzer

%d bloggers like this: