blog.scottlowe.org

Interarchy is a well-respected FTP/SFTP client for Mac OS X, although the feature set now makes calling it an “FTP/SFTP client” a bit of a misnomer.  After, when you add in HTTP, WebDAV, and Amazon S3 support, it’s not exactly just an FTP/SFTP client any longer.  (For simplicity’s sake, we’ll continue calling it an FTP/SFTP client.)  For users of other FTP/SFTP clients, however, Interarchy’s interface is different enough to throw users off and prevent them from really being able to take advantage of the application’s full functionality.

Now that I’ve been using it for a couple of weeks, though, I’m starting to get the hang of the application, and beginning to understand (what I think) are the concepts behind the application.  In the event that other new users of Interarchy may find it useful, here are my thoughts.  I welcome additions, clarifications, or corrections from users more experienced than myself.

Multiple Windows

One difference that seems to throw new users of Interarchy is the use of multiple windows.  This didn’t really throw me at first, as I naturally use lots of windows anyway.  The idea here is that instead of using a two-paned “Midnight Commander”-type interface, Interarchy presents different windows for different remote locations, just like the Finder can present different windows for different file system locations.  In this respect, Interarchy is more Mac-like than most of the other similar applications out there.  (Side note: If you don’t like multiple windows, you can use multiple tabs in a single window instead.)  If you’ve ever used Linux with KDE or GNOME, then Interarchy’s windows with the URL address bar will look very familiar to you.

In addition, Interarchy has windows to report the status of mirror tasks, a transfers window, a transcript window, and of course the default Bookmarks window.

Bookmarks

Interarchy is built around the idea of bookmarks.  “Bookmark” isn’t the best name for this concept, but I can’t think of anything better either.  These bookmarks combine a set of basic building blocks (more on that in a moment) to create the desired result.  This makes Interarchy’s bookmarks much more than the bookmarks of a web browser; indeed, these bookmarks are more like Automator workflows.  (Hey, that’s a really good analogy.)

You’ll see this analogy carried throughout the application.  The “Connect to Server…” window, in which you can define “on-the-fly” bookmarks, is itself listed as a bookmark (although it’s a special bookmark that uses the “interarchy:” URL type).

Basic Building Blocks

Bookmarks in Interarchy combine three basic elements:  protocol, action, and parameters.

• Protocol:  Here you define the network protocol that should be used, such as FTP, SFTP, Amazon S3, HTTP, or WebDAV.  It’s kind of handy that the application and its bookmarks present a consistent interface regardless of the protocol(s) being used.
• Action:  Once the protocol is selected, you must then select the action. Actions include List (equivalent to a “traditional” connection that shows the contents of the selected server), Download, Upload, Mirror, New Net Disk, New Auto Upload, View, Edit, and others.  List is probably the one you’ll use the most.
• Parameters:  These will vary between actions.  For the List action, all you really need is the server name, path, username, and password.  For the Upload action, you’ll need those four parameters plus a source folder.

Mixing and matching these three building blocks allows you to build bookmarks (custom workflows) to do exactly what you want to do.

Here’s an example.  I maintain the web site for my church.  It’s not much (I’m not an HTML programmer by any stretch of the imagination), but God honors the effort anyway.  I have three bookmarks defined to help manage the church web site:

1. A List bookmark, which allows me to navigate the filesystem where the web site’s files are stored, edit files, etc.
2. A Mirror Download bookmark, which downloads an exact copy of the web site to my MacBook Pro.
3. A Mirror Upload bookmark, which uploads the local copy of the web site to the remote server.

Using these bookmarks, I can quickly and easily download a mirror copy of the web site, edit it locally, then publish it back up to the server with just a few clicks.  (Yes, I could probably do this easier with a straight-up Mirror task, but I’m not quite ready to go there yet.  I like control.)  Other applications have the same kind of synchronization functionality (Cyberduck does), but they require you to first establish a connection to the server, then initiate the synchronization.  Interarchy allows you to just do the task in one step.

Hopefully, you’ve found this information at least a little but useful.  I’m sure that as I continue to use Interarchy, I’ll continue to find new ways of streamlining these types of tasks.  Anyone have any tips they care to share?

Microsoft’s official response to the VMware complaints came in the form of an e-mail to Mary Jo Foley; you can read the full response here (see the addendum at the bottom of the blog posting).  In this response, Microsoft Virtualization Strategy General Manager Mike Neil claims:

Microsoft believes the claims made in VMware’s whitepaper contain several inaccuracies and misunderstandings of our current license and use policies, our support policy and our commitment to technology collaboration.

With regards to this response, I have to agree with Christian Mohn (of h0bbel.p0ggel.org):

While this seems to indicate that Microsoft will be looking to resolve the issues raised by VMware, I still see this email as nothing more than an attempt to further muddy the water as it really doesn’t address anything at all.

I suppose that Microsoft could be correct that there are some misunderstanding and misconceptions here, although it seems unlikely given the way VMware quoted specific portions of text from the applicable Microsoft EULAs in their “white paper”.  (Isn’t there a better term we can use?  This wasn’t a white paper.)  Even so, if VMware is incorrect in their understanding of the restrictions in place in the EULAs, why didn’t Microsoft respond sooner?  As pointed out by a blog posting on the Windows Server Division weblog, these complaints are very much like the complaints issued by VMware back in November of last year during VMworld 2006 (see this link).  If VMware was incorrect then and is still incorrect now, why wait until now to try to address those inaccuracies?

As I responded to a commenter on my previous article, the problem in my mind is not one of Microsoft being allowed to compete as fully and energetically as it can (an argument that the Windows Server Division weblog entry makes, quoting this article from TechWorld), but rather are these competitive actions in violation of anti-trust laws?  Are these the same kinds of actions that got Microsoft in trouble with the US Department of Justice and the European Union?  (I’m not a lawyer, so I won’t venture a guess.)

Furthermore, as again quoted by the Windows Server Divison themselves, a VMware deployment doesn’t mean fewer Windows Server licenses (the quote is from this Computerworld article):

Bruce McMillan, manager of emerging technologies at Solvay Pharmaceuticals Inc. in Marietta, Ga., is using Windows servers in a VMware virtualized environment. McMillan has read the white paper posted by VMware and said he thinks it “is there as a means to help educate people about what’s going on.”

But he said he hasn’t run into the issues outlined in the document. And just because Solvay is using virtualization technology, McMillan added, “it doesn’t mean we’re going to buy less [Windows] licenses.”

If that is indeed the case—and my experience bears it out completely—what are the motivations behind Microsoft’s licensing changes?  And how does this affect specifications, such as VHD, that are covered by the Microsoft Open Specification Promise?  On one hand, the OSP states:

Anyone is free to implement the specification(s), as they wish and do not need to make any mention of or reference to Microsoft. Anyone can use or implement these specification(s) with their technology, code, solution, etc.

Yet, according to VMware’s published complaints, Microsoft is restricting the use of some VHDs to use with their virtualization products only (this is taken from the VMware site, which in turn quotes from a Microsoft EULA):

You may install and use one copy of the software on your device of which you are running a validly licensed copy of Microsoft Virtual PC or Microsoft Virtual Server. You may not change or convert the virtual hard disk image from the VHD format.

Kind of seems like Microsoft is giving with one hand and taking with another, doesn’t it?  Developers are free to implement the VHD specification, but VHDs can only be used on Virtual PC or Virtual Server?  What, then, is the point?  (I will grant you that this complaint is a bit weak, since the text is taken from the EULA of a pre-configured VM available for download from Microsoft’s web site.  How much longer until this restriction isn’t quite so specific, though?)

The other recurring theme I see in a lot of the articles out there about this topic is that VMware has nothing to complain about as they are currently the market leader, holding about 80% of the market share for server virtualization.  Seems to me that Netscape held quite a commanding lead in the web browser share before Microsoft started bundling Internet Explorer with Windows.  Is there a pattern here?

Besides, VMware isn’t the only server virtualization vendor that’s affected here.  What about XenSource, SWSoft, or Virtual Iron?  These licensing restrictions affect them, too.  I think the only vendor that may be free of these restrictions might be Novell, but only because of the recent patent agreement between Novell and Microsoft.

I guess it’s the crazy stuff like this that drives people to use open source software—but that’s a different story for a different day.

Microsoft just can’t seem to shake off the perception in the industry that it will do whatever it takes to kill the competition, even if that includes unfairly leveraging a monopoly on the desktop OS market—an act which is criminal in nature and violates US anti-trust laws.  It was those laws that landed Microsoft in trouble for bundling Internet Explorer with Windows in an effort to kill Netscape.  (I’ll leave for another day the discussion of what is right and wrong for a company to do in a competitive marketplace.)

Now we see Microsoft doing it again:  limiting ways in which users can utilize functionality provided by competitor’s products and restricting customers to utilizing only Microsoft virtualization technologies.  VMware’s white paper on the subject lays out clearly the ways in which Microsoft is actively attempting to block competitor’s functionality and lock customers into Microsoft’s products only.  Sadly, I have to say I’m not too terribly surprised.  Neither is Alex Weeks of Virtual Infrastructure 411:

I hate to say I told you so, but I told you so. I said that Microsoft would find a way to unfairly restrict or cripple VMware.

John Troyer of the VMTN Blog really points out what an obvious ploy these recents moves are:

Do you think that when Viridian, Microsoft’s hypervisor, eventually comes out and has “live migration” that they’ll find a way to decouple licenses from physical hardware? That when Viridian can do the equivalent of DRS and HA, they’ll suddenly become advocates of putting your enterprise software in virtual resource pools for manageability and reliability? Funny how that works. It’s all bad for the consumer right now in 2007.

C’mon, Microsoft!  Have you learned nothing?  Compete on the basis of your products’ quality, not your marketshare!  Make the Windows Hypervisor the best virtualization platform out there and people will use it.  Why are VirtualPC and Virtual Server losing to VMware?  Because VMware’s products are better.  All you need to do to win is make the best product, and doing anything else—especially stuff like this—only makes your customers mistrust you.  That trust, once lost, is unbelievably hard to regain.

I know I said I’d leave the topic of right vs. wrong in a competitive situation for another day, but I do have to speak to one phrase I saw while reading the NY Times article on this issue:

“This seems to be a far more subtle, informed and polished form of competitive aggression than we’ve seen from Microsoft in the past,” said Andrew I. Gavil, a law professor at Howard University. “And Microsoft has no obligation to facilitate a competitor.”

Facilitate a competitor?  I don’t think VMware is asking Microsoft to facilitate them.  What VMware is asking is that Microsoft stop changing license policies in a way that specifically prohibits actions that were once allowed.  VMware wants Microsoft to stop saying that customers can only use Microsoft software with other Microsoft software, which is essentially what these EULA changes are doing.  That closed attitude, in my humble opinion, is what has helped drive Linux and the open source realm to its current level of adoption.

Personally, I hope that VMware does launch an anti-trust lawsuit (like Mary Jo Foley seems to think they might).  It’s wrong for Microsoft to use a monopoly in one market (desktop operating systems) to extend marketshare in a different market segment (virtualization).  I’d say the same for VMware or Apple or IBM if they tried to do the same thing.

What about you?  What do you think?

Approximately 11 minutes ago I started my first 30 Hour Famine, an event sponsored by World Vision.  Our youth group is participating in the 30 Hour Famine this year to raise money and awareness of hunger around the world; all our proceeds go to World Vision to fund their efforts.

A lot of people think that they can’t make any difference against a problem like world hunger or starvation; the reality is that $1 can care and feed a child for a day.  That’s the message I’ve been trying to get across to the kids in my youth group:  everyone can make a difference.  We’ll spend the entire day today fasting from food and participating in service projects to help others in need.  The idea is that while helping those in need—homeless, orphans, etc.—we will ourselves be experiencing the effects of hunger.  We’re hoping that God will reveal Himself to us in a new way and open our eyes to His will and His purpose for us as individuals and us as a youth group.

Pray for us as we lead the youth group through the 30 Hour Famine, which runs from 7:00AM this morning to 1:00PM tomorrow afternoon (just after church), when we’ll “break the fast” and reflect upon what God has shown us during our time of service and fasting.

The “ticking storage time bomb,” as described in this article, is the fact that all virtual servers share the same WWN (World Wide Name) on the Fibre Channel HBA.

Quoting from the article:

In a virtual server mode, all of the server instances can see and access the same HBA - and all the same logical unit numbers (LUN) attached to it.

Fair enough, at first glance.  At first glance, you might say, “Wow!  He’s right—all those servers share the same HBA going out to my Fibre Channel SAN, and I’m doing all my zoning and LUN presentation based on HBA.  I’m in trouble!”

But look a little deeper and it appears that there is a fundamental flaw in this argument:  The virtual servers don’t have access to the HBA.  In fact, they don’t even know the HBA exists.  They don’t know the SAN exists.  Even if they knew the HBA and the SAN existed, they still don’t have direct access to that hardware—they have to go through the virtualization layer.

What driver does a Windows guest running on VMware use to access its hard disk?  An LSI Logic or BusLogic SCSI controller. Not an Emulex HBA driver, or a Qlogic HBA driver, but a standard, ordinary SCSI controller.  So how exactly will this Windows guest gain access to LUNs on a SAN that it doesn’t know exists and for which it has no drivers?  Or am I just missing something here?

Unless I’m way off (which is certainly very possible), this article is completely misguided.  Yes, N-Port Virtualization is a good thing, but not necessarily for security.  Yes, zoning and LUN masking are important components of a Fibre Channel SAN, but those concepts don’t apply to virtual servers who don’t know the SAN exists, don’t have any drivers for SAN hardware, don’t have any SAN hardware, and couldn’t access the SAN directly if they wanted to.  You have to remember that VMware (and presumably Xen and others, although I don’t know that for certain) are hiding these details from the guest operating systems.

Am I missing some crucial detail?

UPDATE:  Some of you may have already considered this fact, but add this to the equation:  VMware Consolidated Backup uses a backup proxy server, running Windows Server 2003 or later, that must have access to the same SAN LUNs as the ESX Server hosts.  In this instance, I would consider this to be a potential security problem.  Make sure you properly secure and harden the backup proxy!

Over the last week or so, I’ve had the opportunity to use VMware Converter in two different settings to perform two different types of physical-to-virtual (P2V) conversions.  In one case, we booted from the Converter bootable CD image to perform an offline conversion; in the second instance, we used Converter to stream an image while the source machine was still online.  In addition, one of the conversions was to an ESX Server farm, while the other was to VMware Server for proof-of-concept and testing.  Here are some observations on each of these conversions.

Offline P2V to ESX Server

The first conversion I did was using VMware Converter’s boot CD to move a workload on a physical server over to an ESX Server managed by VirtualCenter (and a member of a DRS/HA cluster).  The overall process was very straightforward—boot the server on the CD, walk through the “Import Machine” wizard, etc.  The only odd thing we ran into was that Converter refused to log in to VirtualCenter.  We tried short hostname, fully qualified hostname, and IP address, and still had zero luck getting Converter to connect to VC.  Fortunately, connecting directly to one of the ESX servers using the root account worked without any problems whatsoever, and the overall conversion process took about 1 hour and 20 minutes to move the 12 to 13 gigabytes of data on the source server.  As fully expected, the new VM it created worked just fine.  (There were some DNS-related issues after starting the new virtual server, but I feel these were completely unrelated to Converter or the P2V process.)

I’m still not sure why Converter wouldn’t connect to VC; the only thing that may be a contributing factor was that the VC server was running on a non-standard port.  However, even when specifying the port number, Converter still wouldn’t connect. and the error message that was displayed after a failed attempt kept referencing TCP port 902.  I also found that the delays when attempting to connect were horrendous; three or four attempts to connect took up well over 35 or 40 minutes of time just waiting for Converter to come back and tell us it couldn’t connect.  I hope to be able to try another offline P2V in this same environment soon to see if we can isolate and address the issues we ran into this time around.  If anyone else has run into this issue and has a workaround, please share it in the comments.

What I Like:

• Able to import directly to VMFS on ESX Server farm, no need to use a helper VM or vmkfstools
• Installed VMware Tools automatically during the process
• Good network throughput (roughly 8-9GB per hour)

What I Don’t Like:

• Had a problem logging in to VirtualCenter, had to connect to back-end ESX server instead
• Seemed a bit slower to boot up than the older P2V Assistant (this is a very subjective assessment)

Online P2V to VMware Server

I also used VMware Converter to do an “online” P2V; that is, to make a virtual image of an existing physical machine while the physical machine was still up and running.  While this process requires some logistical coordination for the cut-over, it also eliminates the majority of the downtime typically involved in a P2V conversion.  The target ESX server wasn’t yet up and running in this particular case (another story for another day, trust me), so we used a Windows host running VMware Server as our target.

Once again, the process was very simple and straightforward.  Using the VMware Converter Manager on another host (the machine running VMware Server itself, actually), we selected a remote machine, installed the agent (which required a reboot, by the way), and then started the P2V process after the reboot.  At first, the process was very slow; it was estimating almost 6 hours to pull across the roughly 6GB of data on the remote PC.  After a while, though, the pace increased significantly and the overall time to pull across all the data was only about an hour and twenty minutes.  Still, when you compare this rate to the rate achieved in the offline conversion, you see that it is much slower.  Of course, there were differences in the environment (different network topologies, different source and target systems, etc.), so this isn’t necessarily an apples-to-apples comparison.  It does, however, give you a rough idea of what you to expect.

There were a few rough edges, though nothing major.  You apparently can’t install VMware Tools as part of the conversion; this adds an extra step to the configuration of the VM after it is created.  It also seemed to take a few minutes before Sysprep launched on the VM; in fact, I thought that Sysprep wasn’t even going to be invoked at all.  Neither of these issues are major issues, however.

What I Like:

• Minimal downtime required on source physical machine (just a reboot, and sometimes not even that—apparently depends upon version of Windows)

What I Don’t Like:

• Slower network throughput than offline conversion
• Can’t install VMware Tools during conversion

VMware Server to ESX Server

This last test surprised me, primarily because I was under the impression that VMware Converter Starter Edition wouldn’t support ESX Server as a target platform.  In this particular instance, we hadn’t bothered to get the Enterprise license installed because this was testing/proof of concept.  Although Converter wouldn’t let us go from physical machine to ESX Server, it would let us go from physical machine to VMware Server and then to ESX Server.

The downside, of course, is that this adds an extra step to the process.  The upside is that this extra step only took about 13 minutes to move the data from VMware Server to ESX Server (much less time than it took to get the data into VMware Server to start with).  After taking an hour and a half or so to get the data onto VMware Server, another 15 minutes to get it into ESX Server is not, in my opinion, a big deal.

This time around we were again able to install the VMware Tools during the conversion and ask for Sysprep to be run to customize the guest (although I had to reboot the VM once before the mini-Setup appeared).  After Sysprep ran and went through mini-Setup, I noticed that VMware Tools were being reported as “out of date”; a quick perusal showed that the VM was running the VMware Server build of VMware Tools, not the ESX Server build. Hence, the “out of date” indication.  Further, once you did launch an installation of VMware Tools from the ESX Server, the installer detected the previous installation and offered the typical “Remove/Repair/Modify” dialog box, rather than performing an upgrade of the tools.  Again, I’m not sure why that was the case.  It’s an issue that’s relatively easily resolved, but it would’ve been nice to know that the “Instal VMware Tools” checkbox wasn’t really going to help at all.

What I Like:

• Speed (didn’t take long to go from VMware Server to ESX Server)
• No need for a helper VM or vmkfstools
• Can install VMware Tools during migration (see below)

What I Don’t Like:

• Apparently doesn’t install ESX version of VMware Tools

All in all, VMware Converter is a very handy application.  I plan to continue to perform some testing with Converter in more environments and more scenarios over the next few weeks, and I will post additional information at that time.

As always, feel free to share any tips, tricks, thoughts, suggestions, or corrections in the comments below.

As expected, there are lots of comparisons between Mac OS X and Windows Vista.  This relatively recent article by Network Computing takes the two operating systems head-to-head; in most areas, Mac OS X takes the win.  These comparisons are fully to be expected, and I imagine there are as many pundits, experts, and analysts that claim Windows Vista is the best as there are that claim Mac OS X is the best.  It’s just another phase in the Windows vs. Mac vs. Linux holy wars.

What’s more interesting to me are the long-time Windows experts that are defecting the platform for the Macintosh, even as Microsoft is releasing the latest version of Windows—a version that is supposed to represent the next generation of usability and productivity.  Why is this happening?  Why, when Vista is now available, are Windows experts forsaking the platform?

The latest is Scot Finnie, who in this latest article states:

Bye-bye Windows! My three-month Macintosh trial has ended, but my permanent gig with the Mac is just getting started. Apple’s MacBook Pro and Mac OS X are now my computer and operating system of choice.

A while back, there were rumblings that a couple of high-profile defections from Mac OS X to Linux were “canaries in the Mac OS X and Red Hat coal mines” and that Apple should be worried.  When Mac OS X first started gaining ground, lots of “alpha geeks” adopted the platform; but, honestly, most of these were already UNIX-heads or Linux-heads to begin with, and I think they were really just looking for an alternative to Microsoft.  That is, people who were already inclined to a Unix-like platform were more likely to jump ship than those firmly entrenched in the Windows camp.

Now, though, we are seeing the Windows die-hards switching platforms.  This isn’t simply moving from one UNIX-like platform to a different UNIX-like platform.  Mac OS X is nothing like Windows, and switching from one platform to another is a pretty significant effort.  Clearly, there must be a reason why these long-time Windows users are switching.  These aren’t your average Windows users—these are Windows power users, users who have championed the Windows platform for years.  Now they’re switching to the Mac.

I find this very interesting.  I don’t know; maybe I’m just reading more into it than is really there.  But I can’t help thinking that this may be the start of a much larger trend.  When the Mac is winning marketshare from Windows at a time when Windows is supposed to be at its strongest, and when those switchers are the former champions of the Windows platform, there’s something more at play here.

TSclientX is (according to the website) “an alternative RDP Client for Mac OS X”.  I’d describe it as more than that, but I suppose that will suffice.  I actually had the opportunity to meet Daniel Milisic, TSclientX’s maintainer, in Los Angeles at VMworld 2006.

Although I’d used TSclientX off and on for a while, it wasn’t until just recently that I started using TSclientX full-time as my primary RDP client.  Until that time, I’d been using the “official” RDP client from Microsoft, even though it is still PowerPC only (no Intel or Universal Binary available yet).  To get around the limitation of only one instance of the Microsoft RDP client running at a time (a serious limitation for me, since I often have multiple connections open at any given time), I was using RDC Menu.  It was a bit strange in that RDC Menu was a Universal Binary, although the RDP Client was not; it still worked fine, though.

So why did I switch?  Well, for a number of reasons:

1. TSclientX is faster.  As a Universal Binary, it’s both faster to launch (even including the time to launch X11, if it’s not already running) and faster during operation.  Not that the official client’s performance was awful, but the Rosetta overhead is there.  TSclientX doesn’t have that Rosetta overhead.
2. TSclientX didn’t interfere with Quicksilver.  Now that I’m a Quicksilver junkie, it irritated me that I couldn’t invoke Quicksilver when I was inside an RDP session.  I don’t run into that problem with TSclientX, thankfully.
3. Using Apple’s standard X11 environment, I can easily create a hotkey to launch TSclientX when X11 is active.  While this won’t replace Quicksilver, it can be handy at times nevertheless.  The path to use in creating a hotkey in X11 would be “/Applications/TSclientX.app/Contents/Resources/launcher.sh” (be sure to replace “/Applications” with the location of where you installed TSclientX, but I think that it doesn’t run properly anywhere else).

The one drawback I have found so far is that all instances of TSclientX share the X11 icon in the dock, so it makes it a tad more difficult to switch between multiple sessions using Cmd-Tab or the dock.  This isn’t a huge deal, since Expose works properly (I use F9 most of the time), but it does take a bit of adjustment to get used to that.

It would be great if someone wrote a native Aqua (not X11) version of this application, but until then TSClientX fits the bill quite nicely.  If you haven’t tried it, go give it a swing.

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!

I won’t go into all the details that led to my posting “Joy in the Morning?” other than to say it wasn’t (and isn’t) pleasant.  It was a very difficult and very trying time, and while things aren’t completely over now, God did give me a different perspective on times like this.

Later that same evening (after I posted that message), I had to drive down to a local supermarket to pick up a few items.  I had the radio turned to a local Christian radio station (as I almost always do), and this advertisement came on for Key Life Network, a Christian radio program.  Specifically, it was one of these “You think about that” little spots that come on between songs.  If you’ve listened to a Christian radio station, you’ve probably heard Steve Brown and Key Life and one of those little spots.

Anyway, I can’t remember exactly what he had to say that night (and I tried searching the Key Life web site but couldn’t find it), but the basic gist of the thought was that while going through the night is difficult, it is only at night that we can see the stars.

Wow…what a difference one phrase can make in your outlook.  He’s right, of course, and God used him to remind me that there is always a purpose in His plan—we may not know what that purpose is, but rest assured there is a purpose.  While I was in the darkness, waiting for the joy that comes in the morning, all I had to do was remember that some of God’s greatest blessings can only be seen at night.  Some of God’s most beautiful creations can’t be seen during the light of day; only during the darkness of night.  And while they don’t take away the darkness, the stars that God created remind us that we aren’t alone—even in the darkness.

For what it’s worth, try to keep that in mind next time you are in a time of spiritual darkness.  I know I will.