I’ve written an article on doing this in 2010
but seemed to have skipped 2007, so here goes…
The first step in exporting mailboxes is to make sure that the account you’re using to export mailboxes has permissions to do so. In this case, we’ll give the exportadmin account Import and Export options using the New-ManagementRoleAssignment cmdlet in Exchange 2010:
New-ManagementRoleAssignment –Role “Mailbox Import Export” –User exportadmin
Next, you’ll need a system with Outlook 2010 and the Exchange Management Tools installed. From here, you can export mailboxes into PST files. To do so, run the Export-Mailbox cmdlet with the -Identity option to include the account name of a user and the -PSTFolderPath option to include a file location for the pst file. For example, to export user cedge to a folder called N:\exmerges:
Export-Mailbox -Identity cedge -PSTFolderPath N:\exmerges\cedge.pst
I’ve written plenty about exporting mailboxes from Exchange. But what if you need to perform a selective import into Outlook? This is helpful for importing mail in date ranges, using an import to search for terms (common with litigation holds) and importing contacts and calendars.
To get started, click Open from the File ribbon.
When prompted, click on Import/Export.
At the Import and Export Wizard screen, click on “Import from another program or file”
At the “Import a File” screen, click on “Outlook Data File (pst)”
At the Import Outlook Data File screen, choose the mailbox to import into and then click on the Filter button. Using the filtering options, you can choose to import based on date ranges, using search terms, selecting specific folders or a combination of all of these.
Outlook Web Access (OWA) allows administrators to setup themes. I’ve noticed a lot of people configuring custom OWA themes these days. And when they do, they are always annoyed when users change the theme back to the default. So, let’s disable theme selection using the set-owavirtualdirectory cmdlet.
Here, we’ll do so on a server called krypted, on the default web site, for the default owa virtual directory using the -identity option. The option we’ll use is -themeselection enabled and we’ll set it to $false:
set-owavirtualdirectory -identity "krypted\owa (default web site)" -themeselectionenabled $false
To set it back, just swap $false for $true:
set-owavirtualdirectory -identity "krypted\owa (default web site)" -themeselectionenabled $true
By default, when you require an SSL certificate in IIS on an Exchange server, if users hit the page without providing an https:// in front they will get an error. Rather than require certificates, it’s better in most cases to redirect unsecured traffic to a secured login page. In order to do so, first configure the redirect. To do so, open IIS Manager and click on the Default Web Site.
At the bottom of the pane for the Default Web Site, click Features View if not already selected.
Then open HTTP Redirect. Here, check the box for “Redirect requests to this destination” and provide the path to the owa virtual directory (e.g. https://krypted.com/owa).
In the Redirect Behavior section, select the “Only redirect requests to content in this directory (not subdirectories)” check box and set the Status code to “Found (302)”.
In the Actions pane to the right of the screen, click Apply. Then click on Default Web Site again and open the SSL Settings pane. Here, uncheck the box for Require SSL.
Once done, restart IIS by right-clicking on the service and choosing Restart or by running iisreset:
Next, edit the offline address book web.config file on the CAS, stored by default at (assuming Exchange is installed on the C drive) C:\Program Files\Microsoft\Exchange Server\\ClientAccess\oab. To edit, right-click web.config and click Properties. Then click Security and then Edit. Under Group, click on Authenticated Users. Then click Read & execute for Authenticated Users in Permissions. Then click OK to save your changes.
Finally, if you have any issues with any messages not working, start the IIS Manager. Then browse to the virtual directories and open HTTP Redirect. Then uncheck “Redirect requests to this destination” and click Apply. When you’re done, restart IIS again and test the ability to send and receive emails to make sure that mail flow functions without error from within the web interface.
I’ve seen a number of cases where Exchange Information Stores are located on SANs. If you don’t have enough throughput you’re likely to see RPC request timeouts for the database, mailboxes or even a server. This typically correlates to Event IDs of 10025, 10026 and 10027. If a mailbox is having such problems then it will be quarantined. If you have this happen once or twice then it’s likely not that big of a deal. However, if it happens repeatedly then you’ve likely got a problem. These can be cumbersome to fix. So while you’re working on things, rather than have mailboxes go offline all the time, you can edit the registry to turn off the time-out detection that causes quarantining of assets. To do so, open regedit and backup your registry. Once done, locate the following key (assuming the server name is KRYPTEDEX2010:
Right-click the name of the server, click on New, and create a “DWORD (32-bit) Value” with a name of DisableTimeoutDetection. Set the value to 1 and save. All done. Good luck fixing your I/O (and don’t treat the symptom without curing the disease or you’ll end up having to isinteg your database eventually).
When running mailbox exports, move requests, etc in Exchange 201x you might get an error. This is because the Management Role Assignments have changed ever so slightly. In order to provide an account the ability to do certain tasks, you can use the New-ManagementRoleAssignment powershell cmdlet to process a request. To do so, pick a user (in this case the username is kryptedadmin) using the -User option and choose roles to assign (in this case, mailbox, export and import) using the -Role option. The command then looks as follows:
New-ManagementRoleAssignment -Role "Mailbox Import Export" -User kryptedadmin
To see if your roles were properly applied:
Get-ManagementRoleAssignment -Role "Mailbox Import Export" | ft Identity
One of the things that hasn’t changed in all these years with Exchange is Non-Delivery Reports. An NDR is an email that is sent when a message you send fails to go out. Exchange has had a consistent set of NDR status codes since version 5, just adding some here or there with changing technology (e.g. routing connectors, smarthosts, etc).
Exchange has a lot of NDR codes at this point. I keep a little list running in my collection of files I spotlight to find the answer to recurring questions (which happens to always be 42). When an email bounces in Exchange, these codes explain why without having to be overly verbose (usually the text is actually in the NDR but not in the error logs in Exchange). Anyway, my list:
- 2.0.x: Codes that start with 2 are success codes. The message got to where it was supposed to go.
- 4.0.x: Persistent failure codes, including the following:
- 4.2.2: The percent receiving the message is over their quota.
- 4.3.1: The server is out of memory or hard drive space in the queue or Information Store directories (or out of file IIS handlers).
- 4.3.2: Message was deleted by an administrator.
- 4.4.1: Target server isn’t responding or there’s no network connectivity.
- 4.4.2: Connection dropped. Often due to switching or intermittent routing failures if there are a lot of these.
- 4.4.6: Hop count exceeded. Check for loops, check your virtual server, DNS, etc.
- 4.4.7: Message sat in a queue too long.
- 4.4.9: DNS failure.
- 4.6.5: Language problems. Might need to install additional language packs.
- 5.x: Permanent error codes (usually) including the following:
- 5.0.0: This is usually the most annoying as it’s the generic, catch all error for when Exchange can’t decide on another error to give. Check your routing groups, check the email address, check that an SMTP communication can flow between your server and the target, etc. Prepare to get no satisfaction from your testing.
- 5.1.0: Destination address might be wonky; otherwise rebuild the Recipient Update Service.
- 5.1.1: Server can’t resolve the recipient. See this a lot when I delete accounts.
- 5.1.2: Results from a host unknown (550) SMTP code.
- 5.1.3: Malformed email address (e.g. charles@email@example.com). The previoius is usually a bad domain, this is usually something bad in front of the @.
- 5.1.4: Hash tables detect duplicate SMTP addresses.
- 5.1.5: Invalid mailbox. This happens when the SMTP address exists but the mailbox doesn’t.
- 5.1.6: I’ve found this means there’s a message store problem. If more than one person is impacted, check mdb integrity.
- 5.1.7: Senders mail attribute is bad. Check the sender’s mailbox info.
- 5.1.8: Senders mailbox is bad. Every time I’ve seen this I’ve had to delete/readd the sender from Exchange or their mailbox.
- 5.2.x: Size matters. Includes the following:
- 5.2.1: Message is too large. Often a policy issue on the sender’s end.
- 5.2.2: Recipient is over their quota.
- 5.2.3: Message is too large. Often a policy issue on the receiver’s end.
- 5.2.4: Distribution group is trying to send a message and can’t.
- 5.3.x: MTA Errors, including:
- 5.3.1: Mail system is full. Check free space for mdb directory.
- 5.3.2: System not accepting mail. Usually something like a port or relay not working. Especially if you have smarthosts.
- 5.3.3: The server the message is being sent to is out of space but SMTP is still running. I usually see this if the boot volume on the target/recipient server is not full but the queue directory is.
- 5.3.4: Message is too large but can decide if policy issue is on sender’s or receiver’s end.
- 5.3.5: The message is looping back (e.g. the server has an alias pointing back to your server, which tries to send again).
- 5.4.0: DNS problem (can’t find MX or there are too many MX records listed). I’ve also seen this when users try to send to email addresses but forget the tld. I’ve never forgotten a tld. At least not sober…
- 5.4.1: Receiving server isn’t responding.
- 5.4.2: Bad connection to the other server in the SMTP communication.
- 5.4.3: Routing error.
- 5.4.4: Routing group error.
- 5.4.6: The address is usually yourself with a weird reply-to situation (e.g. you’re sending to an alias of yourself and the message can’t deliver).
- 5.4.7: Exceeded time limit to transfer message.
- 5.4.8: You’re loopy. By default, SMTP should have a maximum of 20 hops for mail delivery. If Exchange detects a loop like this it’s usually been with an SMTP connector or a smarthost config. It’s usually my fault so I’ve seen this one many times.
- 5.5.0: Generic. I usually find that if I get this error, I probably need to restart the SMTP service on both hosts. One of the two will fix the issue.
- 5.5.1: Invalid smtp command. One of the servers is speaking some wonky kinda something. Shouldn’t be possible, but happens every now and then. Especially when there are people out there running weird mail servers.
- 5.5.2: The target mail server sucks. An SMTP error due to a broken sequence of SMTP commands is all kinds of 1980s. But it happens sometimes. If you can send to others then check the amount of memory and space as a communication stream can die if either of the two hosts craps out due to hardware and comes back online.
- 5.5.3: You have too many friends. Yes, there is a maximum number of people that can be in the sender field. Remove some and your message should go through.
- 5.5.4: Invalid character in a domain name (e.g. &).
- 5.5.5: Wrong protocol. This happens when you call a fax machine from an iPhone too. But in the computer world, http, even when encapsulated and running on port 25 simply can’t speak smtp.
- 5.5.6: Your message content sucks. Yes, I get plenty of these. Regrettably my server doesn’t discern between intelligent emails and unintelligible emails, but it does notice when there’s invalid strings in the content/body of a message!
- 5.6.0: Corrupt message content. Similar to above, but with attachments/MIME.
- 5.6.1: Unsupported attachment (e.g. happened when the .ipa standard was first released by Apple).
- 5.6.3: Anyone who tries to put more than 250 attachments in an email should be beaten. That’s the only way you’ll see this. Yes, I’ve seen it. No, I did not beat him. Yes, I regret that.
- 5.7.1: Sender sucks (aka, doesn’t have permissions to send to recipient) or client was not properly authenticated.
- 5.7.2: The array that comprises a distribution list can’t expand and so the server can’t send to the members in that list.
- 5.7.3: Security problem. Check auth types on servers and proxy settings. Alternative recipient can cause this as well.
- 5.7.4: Target server security problem. Check delivery settings.
- 5.7.5: Try again with plaintext as this usually means there isn’t a handshake between cryptographic algorithms/hashes.
- 5.7.6: Bad certificate.
- 5.7.7: Message integrity issues, likely due to encrypted email.
If you’ve seen one that isn’t in my list, let me know and I’ll add it!
Finally, keep in mind: friends don’t let friends run their own mail servers.
Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, Mail.app in Mac OS X, iPhone, iPad and ActiveSync enabled phones. Autodiscover is often made out to be complicated. There’s an Autodiscover service that gets installed when a Client Access Server (CAS) role is setup for Exchange 2010 in the form of a default virtual directory named Autodiscover for the default Web site in Internet Information Services (IIS). You then forward an autodiscover service locater record in DNS in the form of _autodiscover._tcp.
The virtual directory handles Autodiscover requests. But what about other vendors, and even for Exchange, how do you verify that it’s working correctly? If clients automatically configure then it’s working, obviously. But when it isn’t, what do you need to do? The most obvious step is to check that the DNS record responds appropriately. To do so, we can use nslookup. To use nslookup, run it from the command line, followed by the DNS name. For me.com, this might be:
But note that there’s not a response. This is because me.com doesn’t use _autodiscover (why would it, it’s not EWS/ActiveSync after all. But other domains that are configured for autodiscover would respond. For example, look at the output for 318.com:
Which looks like this:
Provided that the answer section is the address of the CAS Exchange server that sits in front of your organization (the one that runs the Autodiscover virtual directory in IIS) then you are more than likely off to a great start using autodiscover. If not, then that’s the first thing that likely needs to get fixed if you actually want clients to use autodiscvoer. Also keep in mind that you’ll want to check internally and externally, as you will likely have different domain names setup for these. I often find that people will configure the _autodiscover records in their public DNS but not in their private views. Also keep this in mind when acquiring SSL certificates for Exchange’s CAS instance.
Note: Autodiscover, as its implemented in Office Exchange clients, also has the ability to change configurations in Office on the fly as network settings change on internal networks (e.g. users get moved to different information stores, IPs of servers change, etc). This does not seem to work with Apple’s Mail. One could write a script to check for a change in the records nightly (or more frequently of course) if this is needed.
Sometimes the mail clients can interpret things differently than we do manually from the command line, including autodiscover. When the Apple Mail client is attempting to connect to Exchange, you can also get more information about the EWS autodiscovery process by capturing logs about it, not done by default, but invoked by firing up mail using the –LogEWSAutodiscoveryActivity option followed by a YES, as follows:
By reading these logs, you can learn way more than you ever wanted to know (or thought was possible) about Autodiscover. Given that Autodiscover is similar in iOS, most of this rings true in the Mail app there as well. However, given that you can’t view the activity in as granular a detail by invoking Mail through the command line, you can watch it in the logs in iPhone Configuration Utility while you’re setting up Mail, Contacts & Calendars in the Settings app, which should provide information about any connection failures.
While Autodiscover is awesome, you should still be able to connect without it. The only time I really both to troubleshoot Autodiscover itself is when I can install an account but I cannot get Autodiscover to eliminate the need for the second setup screen in Mail on iOS and OS X (possibly with the exception of Lion). If you can setup mail, but it requires two screens then the problem is basically always Autodiscover. If you can’t setup mail at all then the problem is basically never Autodiscover. Good luck, and hope someone finds this useful!
Today, Krypted.com turns 7. 9 books and almost 2,000 posts later, I seem to have slowed down a bit if you look at the last couple of months of postings. But I’ve been busy, just trying to get a few other projects finished, so I can get back to my normal writing-too-much self. These projects I’ve been wrapping up include:
- Writing Using Mac OS X Lion Server for O’Reilly (the final artwork for this one was turned in today)
- Converting krypted.com into a publishing company and putting out Time Machine in Mac OS X Lion, which should also be on the iBookstore soon
- Speaking at 4 or 5 conferences (MacWorld is coming up, where I’ll be doing 3 talks)
- My day job as Director of Technology at 318 seems to take up more and more time every year as we continue to grow and do cool stuff
- Working on the Exchange 2010 Server exam for brainbench.com
There’s other projects too, but this is what I’ve been working on during my days off over the holidays. Hopefully I’ll wrap all these up soon and get back to writing here. I’ve also been working on a re-design for the site and with the amount of traffic it’s getting, it seems the site needs to get moved as well. Included in this is bringing on the first paid sponsorships. I’ve got the first lined up at this point, but if you or someone you know has a product to put in front of the krypted.com audience, let me know. I’m also now accepting articles, tips, tricks or whatever, from others. So feel free to submit any content you’d like to get out there!