ArtiSan Restubbing

What is Restubbing?

Restubbing is a single step that occurs when you upgrade to version 1.44 or later. Prior to version 1.44 the restore url in the stubbed body only contained the EntryID (EID) and StoreID (SID) of the message at the time the content was stubbed. This created a problem when users subsequently moved the stubbed content to different folders in their mailbox or if the user’s mailbox was moved from one exchange to another (but both exchanges supported by the same ArtiSan store). The act of moving a message changes the EID and SID for the message; moving messages between folders changes the EID only, whilst moving between exchanges changes both the EID and SID. When messages are moved in this manner and the user subsequently clicks on the restore url in the stubbed body, the original EID and SID are forwarded to the ArtiSan server along with the alias for the mailbox. The ArtiSan server then attempts to open the user’s mailbox and open the message with the supplied EID and SID. If it finds the item (because it was never moved), it reads the ArtiSan ID from the MAPI properties and then retrieves the original mail content from the store and restores it into the mail. If the item has been moved (between folders or between exchanges), then the ArtiSan server will never find the item using the supplied EID and SID and the restore would fail.

From version 1.44 onwards, when items are stubbed, the ArtiSan ID is also encoded in the restore url within stubbed message’s body. Subsequently, when the restore link is clicked, the EID, SID and ArtiSan ID are forwarded to the ArtiSan server. The ArtiSan server then attempts to open the message with the given EID and SID. If the message was successfully opened (because it was never relocated) then the restore operation will proceed as normal. However, if the item was relocated after stubbing, then the retrieve with the EID and SID will fail. The ArtiSan server now detects this and searches the entire user mailbox and the public stores for all messages that have a matching ArtiSan ID and restores the content of all of them. The search is reasonably quick since it uses MAPI restriction clauses to narrow the search, but may be slow if the mailbox or the public folders have many subfolders.

Restubbing occurs automatically when the scheduler restarts after upgrading the server to 1.0.0.44 or later. This should fix all broken links caused by moving stubbed items from folder to folder. If the install is a new install from 1.0.0.45 onwards then restubbing does not need to be performed as the initial stubbing inserts the ArtiSan ID.

Okay, when should we manually perform restubbing?

You may consider restubbing when moving mailboxes from one exchange to another where the exchanges are supported by separate ArtiSan servers (but with the same underlying store). You would only consider this if each of the ArtiSan servers used a separate location within the url (e.g. http://ArtiSanServer1/ArtiSan versus http://ArtiSanServer2/ArtiSan). If you didn’t restub the items after moving the user from one exchange to another, the stubbed content would still link to the original webserver. This shouldn’t be a problem where the original ArtiSan server can still access the new exchange. However, running a restub operation will repair the link to point to the ArtiSan server that supports the exchange where the item is currently located.

You may also want to restub if you decide to change the branding or text in the stubbed urls (i.e. for cosmetic reasons or due to change of company name, logo etc.).

Restubbing also fixes the EID and SID within the stubbed body to reflect the current EID and SID for the message. When the ArtiSan server uses the ArtiSan ID to search for the lost message within the user mailbox and the public folders store, this has some overhead compared with using the EID and SID directly. So if clients run a restubbing operation periodically, this will fix all the broken links and will speed up restores on these items.

How do we start a restubbing operation?

There is an option on the maintenance page of the management UI to force a restub either on a per mailbox basis or across an entire organisation.

Is there a limitation with the restore using the ArtiSan ID when the EID and SID don’t match?

Yes. If you copy a stubbed item into another folder, this will result in two messages with stubbed content referencing the same SID and EID. If you click the restore link on the duplicate message (which won’t have the original EID and SID), the EID and SID of the original message will be sent to the ArtiSan server. The ArtiSan server will attempt to open the EID and SID and will succeed because the original message still exists in its original folder. Hence, the original will be restored (i.e. the fallback search on the ArtiSan ID is not performed). The net result is that the user will never see the duplicate item being restored when he clicks the url. There is currently no fix for this but we hope to have one in release 2.1 when we add some extra permissioning information that will also allow us to detect this condition. However, if the client performs periodic restubbing, then this will fix this condition, since all stubbed messages are recoded with their current EID and SID.

Does the COM AddIn do anything different?

Yes. When you select an item in a folder and click the restore button, the AddIn always uses the current EID and SID of the message to restore the item. i.e. the EID and SID in the stubbed body are never used and the ArtiSan server should never fail to find the item. Thus, if the restore in the stubbed body fails but the restore from the AddIn succeeds then this may be an indication that restubbing is required.

If I move a user’s mailbox from one Exchange to another and want to refresh his links, do I have to restub everybody on that ArtiSan server?

Currently Yes. In release 2.0, we will have interfaces that allow you to refresh individual users (even down to specific folders). However, the UI to do this won’t be available until 2.x. Until then this will have to be done by scripting on an ad hoc basis.

If I move a mailbox to an Exchange that is supported by a completely different ArtiSan Store what happens?

Suppose the customer has two exchanges each with their own separate ArtiSan servers with separate stores. They want to move some users from one exchange to the other and for them still to have access to all their mail.

You cannot do this for now. If an item is archived on one store, there is no guarantee that the message content (represented by the ArtiSan ID) exists on the other store. Therefore the View & Restore could fail. Simply restubbing won’t fix this if the underlying content is not present in the new store. This doesn’t only affect stubbed items. Items that are archived but not stubbed will also have a problem if they are subsequently stubbed on the new exchange. Old ArtiSan code performed a shortcut by assuming that the ArtiSan ID was present in the store and simply stubbed the content. Release 2.0 performs additional checks on archived items before stubbing them to ensure that the message exists in the archive. However, if the item was stubbed before moving between different ArtiSanStores then we have no guarantee that the ArtiSan ID is in the new store and no access to the old store in order to copy the content over.

In order to support this in 2.x, release 2.0 has code that allows individual mailboxes to be completely restored (known as a mailbox reset). This is different from a standard restore operation in that all the ArtiSan tags are completely removed from the message. In a standard restore the tags are retained so that the scheduler will automatically restub the messages (usually 5 days after the restore). With a mailbox reset, the messages are treated as never having been archived; this results in the archiving rules been reapplied to the messages. This was originally designed to allow clients to reapply new rules to mailboxes if they originally applied the wrong rules.

This reset functionality also allows us to move users between separate ArtiSan systems as follows:

As for the individual restubbing operations, the UI for performing resets won’t be available until 2.x, but can be done via scripting.

© Saxonite Limited, 2003-2006.