Exchange

You are currently browsing articles tagged Exchange.

VMware, Zimbra, and Why I’m Not an Analyst

Tuesday, January 5, 2010 in Collaboration, Messaging, Virtualization by slowe | 9 comments

The rumors are swirling that VMware is going to buy Zimbra, an open source e-mail platform currently owned by Yahoo. You’ve probably all read the various news articles about the rumors and the events leading up to the rumored acquisition, so I won’t bother you with them again.

Yesterday on Twitter, I mentioned that the Zimbra acquisition didn’t quite make sense to me. I wasn’t the only one; several others mentioned it, too. That sparked a great discussion with Chris Wolf of the Burton Group (really sharp guy, by the way). His comments caused me to look at the purported acquisition in a different light where it starts to make a bit more sense. The discussion reminded me why I’m not an analyst: sometimes I don’t take a broad enough view. (It’s something I’ll work on improving.)

Most people look at the Zimbra acquisition (assuming that the rumor is accurate and it really does happen) and immediately recognize the intent to compete against Microsoft Exchange. However, if you look at the Zimbra acquisition strictly from the perspective of competing against Microsoft Exchange in the market as it currently exists, you’ll quickly come to the same conclusion that I did: it doesn’t make sense. Get real: lots of companies have tried before and failed. I believe that If VMware were to use Zimbra to compete against Exchange in the traditional corporate messaging market, where Exchange mopped up very worthy competitors like Lotus Notes, VMware would end up a failure like so many others before them. As Chris Wolf pointed out on Twitter, the integration between Exchange and the Microsoft applications is just too great to take them head-on.

However, what if you consider that the market is shifting? There is a greater move toward private clouds running scalable, web-based applications. There is an inclination toward workloads that can run outside of an organization’s data center. There is a shift toward virtual desktops. There is desire and interest in embracing the idea of cloud computing—however you choose to define that—across organizations of many different shapes and sizes. In the light of these market factors, now the Zimbra acquisition starts to make more sense. Yes, VMware will compete against Microsoft with Zimbra, but not using today’s architectures and today’s paradigms. As Chris put it in a Twitter post yesterday (emphasis mine):

@TonyWilburn @scott_lowe – IMO vmware has to redefine the traditional app stack for long term survival; email has to be part of it

In the light of this line of thinking, the acquisition begins to make a bit more sense (again, assuming that it’s actually going to happen). Although VMware has different leadership, and it’s a different market, I do feel that VMware would not be successful taking on Microsoft Exchange without redefining how e-mail platforms—as a key part of the overall application stack—can be provisioned, deployed, and managed in conjunction with VMware’s broader private cloud/public cloud strategy.

So what do you think?

Tags: , , , , ,

Growl Notifications with Snow Leopard Mail and Exchange

Thursday, December 10, 2009 in Macintosh, Messaging by slowe | 2 comments

Like many Mac users, I use Growl to provide customizable, centralized notifications for events occurring on my system. Rather than use the Growl team’s GrowlMail plug-in, I use a custom AppleScript that I wrote that provide new message notifications via Growl. It’s not a terribly advanced script; it just provides per-message notifications for each message received, unless I receive more than 5 messages at a time in which case the script just provides a summary notification. It’s worked very well for me for quite some time.

Now, following my upgrade to a new MacBook Pro running Snow Leopard, I’m finding that the script has an interesting flaw: when new messages are received via my Exchange account at work, the script notifies me using information from the previous message received on that account rather than the information from the newly-received message. I know that it’s not the script because notifications for all other accounts work just fine. Only the Exchange account—which uses Snow Leopard’s new Exchange support for connectivity—is affected.

Has anyone else seen this? If so, does anyone have a fix?

UPDATE: I wasn’t able to make Growl notifications invoked from an AppleScript work properly with my Exchange account, so I tried switching to GrowlMail. Unfortunately, GrowlMail has problems with Snow Leopard 10.6.2 that can only be fixed using the Terminal commands in this article. After getting GrowlMail recognized by Mail.app, notifications started appearing correctly for all accounts including my Exchange account.

Tags: , ,

Any iPhone App Recommendations?

Monday, September 1, 2008 in Macintosh by slowe | 14 comments

Yesterday I bought my iPhone 3G. When the original iPhone was released, I didn’t buy one because it lacked 3G network connectivity, and the Samsung BlackJack 2 I was using was already 3G capable. In addition, the BlackJack supported ActiveSync for connectivity to my corporate Exchange infrastructure, and the iPhone didn’t. After the iPhone 3G was released, my two primary complaints had now been removed, and I said that I would get one—but not right away. I wanted some time to let early adopters get the phone, figure out the limitations, and find workarounds for those limitations (where possible).

Now that the iPhone 3G has been available for a couple months, and since my birthday is coming up, my family decided that an iPhone 3G would be my (early) birthday present. While others had waited in lines for hours when the iPhone 3G was first released, I walked into my local AT&T store, picked up a 16GB black iPhone 3G, activated it with my existing number (I’m a current AT&T customer), and walked out—all in less than 20 minutes. The longest part of the process was selecting a new belt clip/case for the iPhone. There are definitely some benefits to waiting a while before buying!

So far, I’m pleased with the iPhone 3G. My only concern is battery life, but feedback from other iPhone 3G users in my office have recommended turning off Bluetooth and location-based services until they are needed. Some have even recommended turning off 3G, but I’ll leave that on for right now and see how it works.

I’ve also been browsing the App Store, looking for some useful iPhone applications. I’ll almost certainly buy OmniFocus for iPhone. Of course, then I’ll need to figure out how to get OmniFocus for iPhone synchronizing with OmniFocus for Mac, which I already use. Any other iPhone users have recommendations for useful iPhone applications? Suggestions for useful free applications would be particularly appreciated. Also, any other tips or pointers of which I should be aware? Thanks!

Tags: , , ,

Plain Text Messages with Mail.app

Saturday, August 16, 2008 in Macintosh, Messaging, Microsoft by slowe | 7 comments

I’m not really sure where or when it started, but over the last couple of years I started taking a strong preference to plain text communications. Perhaps it’s an increased amount of time spent on Usenet newsgroups (I’m still waiting for Panic to release a substantive update to Unison!), or perhaps its due to the annoyance of HTML e-mail that include more pictures than text; I don’t know. In any case, I set my e-mail client (Mac OS X’s Mail.app) to use plain text by default when composing messages, and I used the “hidden” preference to show the plain text alternative for messages when it’s available:

defaults write com.apple.mail PreferPlainText -bool TRUE

So that’s all well and good, but what I’ve noticed is that Mail.app seems to “ignore” some of the line endings in my message. It primarily only happens in signatures; I haven’t noticed it happening in the body of the message. At the same time that I adopted plain text messages, I also adopted the “standard” signature delimiter of two dashes and a space, so my signature will typically look something like this:

-- (hidden space at the end here)
Scott

What happens is that Mail.app turns it into this:

-- Scott

What in the world? Why is Mail.app playing with my signature? I’ve also noticed that in my longer signature—where I include my official title, phone numbers, company name, etc.—that Mail.app plays with the line endings there as well.

It also seems that this may be somehow related to Exchange Server 2007, as it only seems to happen to messages sent through my corporate Exchange infrastructure (I use IMAP and SMTP for connectivity to Exchange). I can’t find a single instance of an e-mail message where this has happened with any of my other non-Exchange e-mail accounts. But this doesn’t really make much sense, because the message I’m seeing is the local copy after it is submitted via SMTP. Perhaps the way in which Mail.app interacts with the SMTP server affects how the message in the Sent mailbox looks? I don’t know.

This is really irritating. If I type something, Mail.app (or Exchange Server) should NOT be going back and changing what I type. Anyone have any clue what could be going on here, or how I might fix it?

Tags: , , ,

ActiveSync on the iPhone

Thursday, March 6, 2008 in Macintosh by slowe | No comments

Apple has just given me one more reason to possibly switch to an iPhone…

iPhone opens to Exchange e-mail

I’m currently using a Samsung BlackJack II, a Windows Mobile 6-based device with 3G connectivity. The e-mail functionality is great, but not having an easy way to keep my Address Book contacts in sync with my phone is a major hassle. It looks like using an iPhone would help address that.

Now all we need is 3G (UMTS/HSDPA) functionality and a price drop…OK, at least the first is an actual possibility.

Tags: , , ,

Virtualization Short Take #3

Monday, March 3, 2008 in Microsoft, Virtualization by slowe | 3 comments

It’s that time again, folks…time for another Virtualization Short Take!

  • VMware’s performance team published some interesting information on running Exchange Server 2007 on VMware ESX Server 3.5. 16,000 mailboxes on 1 physical server, eh? Now all we need is for Microsoft to actually support running Exchange Server on top of ESX Server and we’ll be good to go.
  • Speaking of vendor support, Simon Gallagher at vinf.net has started an open discussion of vendor support for virtualization. This is truly a difficult sticking point for many organizations. Visionary vendors, like SAP, will fully support their solutions on virtualized platforms, but others—which I won’t mention by name but are based in the Pacific Northwest area of the United States—won’t. At least, they won’t until they need to build market share for their own virtualization solution, and then they’ll only support their own platform. There is no easy answer to the dilemma that Simon brings to light, but I am interested in the same question as Simon: what is everyone out there doing about vendor support?
  • vinternals.net has discovered that the 2.5 version of the VI Client finally supports passthrough authentication, including—if you are willing to edit the vpxd.cfg file—Kerberos support. Good information!
  • The team over at xtravirt.com has updated their information on vimsh, a woefully underdocumented but extremely useful command-line utility. This is must-have information for ESX Server engineers and architects.
  • Chris Hoff has responded with some thoughts on VMsafe, the new set of security APIs that VMware announced at VMworld Europe last week. Chris, along with others, has been trumpeting the need for a sea change in security to accommodate the changes wrought by virtualization. In his words, it looks like the security vendors have been given another chance at life. Let’s hope they don’t blow this one.
  • Many of you are probably aware that not all virtualization solutions support memory page sharing. The implications of supporting or not supporting memory page sharing may be greater than you think, though; have a look at this analysis.
  • OK, take a deep breath here and don’t faint, but I’m getting ready to do something I don’t normally do: I’m going to defend Microsoft. That’s right. Via VMblog, I was turned on to some apparent controversy about VM performance under Hyper-V during guest OS installation. As Ben Armstrong aka “Virtual PC Guy” explains at his site, this is due to the use of emulated drivers during the installation process. People, this is no different than VMware. Before you install VMware Tools, VMware uses emulated drivers as well. Perhaps VMware’s emulated drivers are a bit more efficient than Hyper-V’s at this point, but Hyper-V is still in beta. And which would you rather have—highly optimized “synthetic drivers” (equivalent to VMware’s paravirtualized drivers) or efficient emulated drivers? Personally, I’ll take the second. So give Microsoft and Hyper-V a break for once. Save your energy for after the product is released.
  • Information on booting VMs from an iSCSI LUN under Hyper-V is posted here. I don’t know that I would actually call that booting from an iSCSI LUN, since to the VM it’s a local drive, but I guess it all depends on your perspective.

That about wraps it up for now. As always, your thoughts, corrections, rants, and raves are welcome below.

Tags: , , ,

Lessons Learned About Exchange Server 2007

Wednesday, October 31, 2007 in Microsoft by slowe | 12 comments

I’m in the midst of a non-virtualization-related project right now, which is a bit odd; a great majority of my work these days is centered around virtualization.  Nevertheless, I try to view every project as one from which I can learn.  I have definitely learned some things with this project, that’s for sure.

Here are a few tidbits that I’ve learned so far this week, most of them centered around the installation of Microsoft Exchange Server 2007:

  • First, if you have even one Active Directory domain controller that isn’t running Windows Server 2003 SP1, you can’t use the GUI setup routine for installing Exchange Server 2007.  That’s right, no GUI setup for you.  Instead, you’ll have to install from the command line like this:

    setup.com /mode:install /roles:mb, ca, ht, mt /EnableLegacyOutlook /LegacyRoutingServer:oldserver.domain.com /dc:win2k3sp1.domain.com

    Nice, eh?  Supposedly this will be fixed in Exchange 2007 SP1.

  • Apparently, about 20% of the installations run from the command-line fail with an error about being unable to access the source files.  This is even when installing from local CD-ROM, as I was.  The Microsoft tech I spoke with recognized that this was a problem; the suggested solution was to copy the files from the CD to a local hard drive and run setup from there.
  • The use of the “/LegacyRoutingServer:” command-line switch, which is required for interoperability with “legacy” Exchange 2000/2003 servers, can only be used when installing the very first server with the Hub Transport role (the “ht” in the command line above).  If the installation of that first server dies for some reason—say, like due to some strange error about not being able to access the source files—then you won’t be able to use this command-line switch again.  This means you’ll need to create the appropriate connector yourself manually after installation.
  • If Exchange Server 2007 setup fails while installing the Client Access server role (the “ca” in the setup command line above) citing an error about not being able to find an object (see this URL), then you’ve got some damaged attributes in Active Directory.  In my case, while sitting on hold with Microsoft Support for an hour, I resolved it by doing a full dump of the domain and configuration naming contexts of Active Directory using LDIFDE:

    ldifde -f example.domain.ldf -d “dc=example,dc=com”
    ldifde -f example.config.ldf -d “cn=configuration,dc=example,dc=com”

    I was then able to find the specific object with which Exchange Server 2007 Setup was having a problem and fix it.  In my case, the Offline Address Book server had somehow gotten damaged and was causing setup to fail.  I was able to manually correct the problem using Exchange 2000 System Manager and then Exchange Server 2007 setup proceeded to completion.

  • Specifying a smart host on the SMTP virtual server properties on your “legacy” Exchange servers will cause a routing loop, and mail won’t flow between the new and old servers.  Apparently this is documented somewhere, although the Microsoft tech I spoke to could only point me to some articles about how to configure a smart host.  I haven’t seen any documentation yet that recommends checking and fixing this potential problem.  Furthermore, the troubleshooting tools in Exchange Server 2007 pick this up, but fail to tell you that it could be a problem.
  • Oh, yes, I almost forgot about one: ASP.NET is required for Exchange Server 2007, but what happens when you can’t install it via Add/Remove Programs > Add/Remove Windows Components?  That’s right, back to the command line again:

    %systemroot%\Microsoft.NET\Framework64\
    v2.0.50727\aspnet_regiis.exe -ir -enable

    This is assuming, of course, that you’ve already installed the .NET Framework 2.0 on your server in preparation for Exchange.

You are welcome to tell me that I’m an idiot for not knowing this stuff, on one condition: you provide a URL where information about the problem is posted and a workaround provided.  That way, when someone else runs into the issue, we’ll at least know where to point them for help.

Tags: , , ,

Preserving Nickname Cache in Exchange Migrations

Thursday, February 15, 2007 in Microsoft by slowe | 22 comments

Migrating from one Microsoft Exchange organization to another Exchange organization is always a troublesome task.  There’s free/busy time, public folders, the Global Address List (GAL), permissions, mailbox data, etc., to be worried out during the migration.  With recent versions of the Outlook client, there’s also the nickname cache to worry about, too.

The nickname cache is that functionality in Outlook that lets you start typing a recipient’s name (one that you’ve used before) and Outlook will “auto-complete” the name for you.  It’s a pretty handy feature, to be honest, and I’m sure that quite a few users out there rely on this functionality.  In fact, I’ve had people tell me that their nickname cache is more important than their contacts folder!

In a straight STMP-only situation, the nickname cache can be quite harmless during the migration.  In an Exchange migration, however (such as when migrating from one organization to a new organization, perhaps due to acquisition, rebranding, whatever), the nickname cache can be quite a pain in the rear.  Why?  Because the nickname cache doesn’t store the SMTP address of the Exchange recipients to which you’ve been sending e-mail; instead, it stores the X.500 address.

For example, when you mailbox-enable (i.e., create a mailbox for) a user object, Active Directory and Exchange will stamp the legacyExchangeDN attribute with an address that looks something like this:

/o=VMware Test Lab/ou=Raleigh/cn=Recipients/cn=scott.lowe

This is an X.500 address, and if an Outlook user sends an e-mail to this mailbox-enabled user object, this X.500 address will get added to the nickname cache.  For an Outlook user creates a contact for an Exchange recipient from the GAL, this X.500 address will be the address that is saved with the contact.  If this mailbox is moved to a new organization, this X.500 address—by default—won’t go with it, and that is the root cause of the most of nickname cache problems in a migration.

So how do we fix it?  Easy, actually.  Let’s say that you want to represent John Doe, who has a mailbox in Organization B, in the GAL for Organization A.  You create distinct SMTP namespaces for the two organizations, create SMTP connectors with the appropriate namespaces, and you test mail flow between the two.  Everything works fine, and so you create contacts in the GAL for Organization A to be able to send e-mail messages to those recipients in Organization B.

Thinking you’re pretty clever (which you likely are, since you’re visiting this site), you create contacts in Organization A to represent users in Organization B and vice versa.  Since these contacts are all SMTP based, routing messages based on the SMTP namespace, all should be well, right?  Nope.

Unfortunately, because these contacts were created on the server (we’re talking Active Directory Contact objects here, not Outlook contacts), users sending e-mail messages to them will be adding the X.500 address of the contact to their nickname cache, not the SMTP address.  When these users migrate from Org A to Org B and send mail to these recipients again, the system will generate an NDR (non-delivery report).  Why? Because the nickname cache has the X.500 address for the Contact object in the source AD tree.

But enough of the background.  How do we fix the problem?  Check out these steps:

  1. Review the legacyExchangeDN attribute on the target mailbox.
  2. Add the value of legacyExchangeDN (on the target mailbox) to an X.500 address on the Contact object in the source domain.  To create an X.500 address, select the “Custom Address” and specify the address type as “X500” (no quotes).

That’s it!  When users send e-mail to the Contact objects, the X.500 address will be stored in the nickname cache.  The Contact object’s targetAddress attribute will, of course, point to an SMTP address assigned to the target mailbox; that’s what allows Exchange Server to route the e-mail messages appropriately.  After the users are migrated to the new Exchange organization, the X.500 address for the users to which they used to send mail will still be the same as the Contact objects they used to use.  Perfect!

Tags: , ,

Erroneous Mail Relay Error with Exchange

Thursday, August 24, 2006 in Microsoft by slowe | No comments

You’ve probably all run into the “Unable to relay” error message before.  The usual fixes to this problem are pretty straightforward:

  • Add the address space to a recipient policy in Exchange System Manager; this tell Exchange to accept the messages as inbound; or
  • Add IP addresses, subnets, or host names to the SMTP virtual server in Exchange System Manager as allowed to relay through this host;

Generally speaking, either one of these two options will generally fix the problem.  If the address space (say, example.com) should truly be accepted inbound, then adding it to an Exchange recipient policy will tell Exchange to accept it as inbound—thus eliminating the relay issue.  Likewise, if the messages should truly be relayed to their final destination, then adding the host(s) to the list of machines allowed to relay via the Exchange SMTP virtual server will indeed do that.  Pretty simple, right?

In this case, the e-mail address space should have been accepted inbound, so I first added the address space to an Exchange recipient policy (leaving the check box to apply that address space to recipients unchecked, since I didn’t really want addresses from this domain applied to users).  That didn’t work.  OK, maybe the check box to apply this domain needs to be checked, so I add it to a recipient policy that has no filter criteria (and therefore won’t be applied to any users).  It still doesn’t work.

Next, I add the appropriate servers to the list of hosts allowed to relay (by modifying the properties of the Exchange SMTP virtual server), restart the SMTP service, and try again.  It still doesn’t work, reporting a “5.7.1 Unable to relay for <username>” message.

My colleague searched the Microsoft Knowledge Base and turns up KB article 323669, titled “XFOR: 550 5.7.1 Unable to relay Error Message When E-Mail is Sent to Local Exchange Recipient”.  In the article, it mentions using MetaEdit to edit the IIS metabase and delete the LM/DS2MB key.

Good idea, but MetaEdit doesn’t support IIS 6.0, and this problem is occurring on Windows Server 2003 with Exchange Server 2003.  Fortunately, the IIS 6.0 Resource Kit comes with the Metabase Explorer, which allows me to delete the key as per the KB article and restart the services.  After restarting the services, the problem is fixed!  (Kudos go to Chauncey, who found both the article and the Metabase Explorer.)

Apparently, the DS2MB portion is involved in one-way replication of configuration data from Active Directory (the directory service, hence the “DS” in the name) to the metabase.  If the metabase (or even just the DS2MB portion of the metabase) gets damaged, then changes made in Exchange System Manager—which are written to Active Directory via the configuration domain controller—will never get synchronized to the IIS metabase.  Since the IIS metabase controls the SMTP service, then SMTP will continue to deny what it believes to be unallowed requests to relay.  Removing the DS2MB key and restarting the services rebuilds that portion of the metabase from scratch, thus pulling in the correct configuration from Active Directory and fixing the problem.

Tags: , ,

Best Practices Analyzers

Monday, July 31, 2006 in Microsoft by slowe

The Exchange Best Practices Analyzer (ExBPA) has been around for a while now, and is a very useful tool in making sure that your Exchange implementation is following recommended best practices from Microsoft for optimal performance, reliability, and scalability.  The ExBPA was recently updated to include the ability to check the overall Exchange topology for readiness to upgrade to Exchange Server 2007.  The Exchange team blog has full details on the new “Readiness Check” in this posting.

In addition, Microsoft has released the Internet Security and Acceleration (ISA) Server Best Practices Analyzer (IsaBPA), which is designed to do the same thing for ISA implementations.  Supporting both ISA 2004 and ISA 2006, IsaBPA helps make sure that the ISA deployment adheres to a set of best practices outlined by Microsoft, and identifies critical configuration errors or potential problems.  The IsaBPA can be downloaded from the Microsoft Download Center.

Also available for download are the SQL Server Best Practices Analyzer and the BizTalk Server Best Practices Analyzer.

Tags: , ,

« Older entries