Hi David
The 'orphaned' mailbox scenario is at present unavoidable. To put this in context though, these mailboxes are not orphaned from their archives, but are now on an Exchange server which is archived by another vault server. In this scenario, the new vault server is responsible for archive/retrieval operations for the moved mailbox, but the old vault server is responsible for its storage/indexes. In practice this is not a problem if the vault servers have good bandwidth between them, but if they are geographically dispersed (i.e. across a WAN link) then it would be better to disable the mailbox from archiving, export the corresponding archive to intermediary PSTs (with the export config file intact), delete the archive on the source vault server, create a new one using the enable mailbox wizard on the new vault server and then import the PSTs (the config file will re-knit all of the shortcuts in the mailbox so that they point to the new archive.) This is a pain in the posterior, I know, but at present it is the only option because of the architectural limitations I mentioned in my previous post.
As for the Directory service, I wouldn't necessarily call it a SPF. It would be more appropriate to define the SQL EnterpriseVaultDirectory database as the SPF since you can (and should) create a directory service on all of your EV servers in the site that point to the same database. Therefore an external HA mechanism for the SQL server (such as a cluster) would be the best recommendation. The bigger problem with the directory service is that it must point to a single SQL instance, which means that if you have a geographically remote EV server, it must traverse the WAN link for directory access. In such cases I would recommend creating a seperate EV Directory for these servers with a SQL server that is closer by.
:)