Difference between revisions of "MailStore Server to MailStore SPE Migration"

[unchecked revision][pending revision]
(Created page with "This guide shows, how to migrate a MailStore Server installation into the MailStore SPE. This can be useful, if the customer has used MailStore Server before, but now he want...")
 
 
(37 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This guide shows, how to migrate a MailStore Server installation into the MailStore SPE.
+
__NOTOC__
 +
This guide explains how to turn a MailStore Server installation into a MailStore SPE Instance.
  
This can be useful, if the customer has used MailStore Server before, but now he wants the archive to be stored in a service provider's datacenter.
+
As the two products use a slightly different format of the master database (''MailStoreMaster.fdb''), which contains the configuration, it is not possible to move the entire ''MailArchive'' directory of MailStore Server onto a MailStore SPE Instance Host. However, it is possible to transfer all archive stores, which contain the actual messages, by following these simple steps:
  
Also, when an on-premise mailserver or on-premise e-mail files, like PSTs, should be archive by an SPE instance, it might be a good decision to do the [http://en.help.mailstore.com/Archiving_Email intial archiving with MailStore Server] in the customer's infrastructure, and then migrating the resulting MailStore databases into the SPE.
+
<p class="msnote">'''Important Notice:''' The MailStore Server archive stores must be on Firebird 4 or higher. If this is not the case, the entire archive (MasterDatabase and Archive Stores) must be loaded once into a MailStore Server 24.4 before it can be migrated to the SPE. All archive stores must be manually upgraded to the latest version, because then some necessary database upgrades will be performed. The MailStore SPE version must be equal or higher than the MailStore Server version where the archive stores were attached to last. <br/><br/>If the customer does not want to share the product key to decrypt the archive store with the service provider, the recovery key can be set to a generated value before migrating.</p>
 +
* First [[Creating_Instances| create a new MailStore SPE Instance]]. The instance must not be started yet.
 +
* Stop all archiving profiles in MailStore Server, either by setting the execution mode to ''manual'', by disabling all ''Jobs'' or by disabling all scheduled tasks.
 +
* [http://en.help.mailstore.com/MailStore_Server_Service_Configuration Stop the MailStore Server] service.
 +
* Copy all archive store directories from MailStore Server into the instance's ''Data'' directory. Do not transfer the ''MailStoreMaster.fdb'', the ''MailStoreMaster.key'' and ''MailStore.xml'' files. Make sure, there is no remaining ''.lock'' file in any  of the archive store directories. If there is, the MailStore Server service has not been stopped completely yet. When there are identical folder names, do not merge them, but give them unique names instead.
 +
<p class="msnote">'''Important Notice:''' After this step, do not run any of the archiving profiles in MailStore Server again, otherwise you might risk that  emails are not getting archived by the MailStore SPE Instance (i.e. when a profile contains automatic deletion rules).</p>
 +
* Start the MailStore SPE Instance.
 +
* [[Instance_Management#Attach_Existing_Archive_Store|Attach the archive stores]] that were previously transferred to the newly created instance. In case the archive store is migrated from MailStore Server 10 or newer the recovery key (product key or generated value) of the source MailStore Server installation is required. You have to use the ''UnlockStore'' command in the ''DEVELOPER'' > ''Management API'' window of the Management Console as described [[Instance_Management#Unlock_Archive_Stores|here]].
 +
* Set the state of one archive store to ''Current''.
  
Since the MailStore databases usually are considerable smaller then the uncrompressed e-mail volume, the amount of data to be transferred initially is significantly less.
+
== Additional Steps ==
 +
Depending on the previous configuration of MailStore Server, the following tasks are to be done to configure the MailStore SPE Instance accordingly:
  
The two product use a slightly different format of the ''MasterDatabase'', which holds the configuration items, therefore it is not possible just to move the entire ''MailArchive'' directory of MailStore Server into the SPE.
+
* Create users, either manually or by synchronizing with a directory service.
 
+
* Configure compliance settings.
However, it is possible to move all the ''archive stores''.
+
* Create archiving profiles.
 
+
* Verify the rest of the configuration, such as search index configuration, export profiles, permissions, etc.
* First you have to [[Instance_Management_-_General_Administration#Creating_Instances| create an instance]].
 
* Click on ''General'' > ''Instances''.
 
* Select the instance to move.
 
* Stop the instance.
 
* Open the ''Instance Configuration''.
 
[[File:Ms_spe_move_instance_01.png|center]]
 
* Move the ''Base Directory'' of the Instance with your preferred file explorer to the new location. It is not sufficient just to change the ''Base Directory'' in the ''Instance Configuration''. This will not move the instance automatically. You are able to move the ''Base Directory'' to a different ''Instance Host'' or to a storage, that is accessible from a different ''Instance Host'' if you want that instance being run on a different ''Instance Host''.
 
*: '''Hint:''' If you need a minimal downtime of the instance, you could stop all archiving processes, create a backup of the instance with VSS, and store the backup in the new location. Then you just have to change the path instead of waiting for the transfer process.
 
* Change the ''Base Directory'' in the ''Instance Configuration'' if you just have changed the location on the same ''Instance Host''.
 
[[File:Ms_spe_move_instance_02.png|center]]
 
* If you want the instance being run on a different ''Instance Host'', change the ''Instance Host'' and the ''Base Directory'', if it has changed.
 
[[File:Ms_spe_move_instance_03.png|center]]
 
* Close the ''Instance Configuration''.
 
* Start the instance.
 
* Doubleclick on the instance and navigate to the ''Archive Stores'' tab.
 
* Verify that all stores are loaded correctly.
 
[[File:Ms_spe_move_instance_04.png|600px|center]]
 
* If an archive store is in an error state, because the path could not be found, follow these steps:
 
** Remember the current ''Requested State'' of the archive store.
 
** Set the ''Requested State'' to ''disabled''.
 
** Select the ''Set Path'' command of the archive store.
 
** Change the path to the new path. You either can enter the full absolute path, or you can enter a relative path from the instance's ''Data'' directory, by appending a ''~'' in front of the archive store directory.
 
** Set the ''Requested State'' of the store back to the previous state.
 
[[File:Ms_spe_move_instance_05.png|600px|center]]
 
* Restart your archiving profiles if you have paused them.
 

Latest revision as of 13:35, 3 December 2024

This guide explains how to turn a MailStore Server installation into a MailStore SPE Instance.

As the two products use a slightly different format of the master database (MailStoreMaster.fdb), which contains the configuration, it is not possible to move the entire MailArchive directory of MailStore Server onto a MailStore SPE Instance Host. However, it is possible to transfer all archive stores, which contain the actual messages, by following these simple steps:

Important Notice: The MailStore Server archive stores must be on Firebird 4 or higher. If this is not the case, the entire archive (MasterDatabase and Archive Stores) must be loaded once into a MailStore Server 24.4 before it can be migrated to the SPE. All archive stores must be manually upgraded to the latest version, because then some necessary database upgrades will be performed. The MailStore SPE version must be equal or higher than the MailStore Server version where the archive stores were attached to last.

If the customer does not want to share the product key to decrypt the archive store with the service provider, the recovery key can be set to a generated value before migrating.

  • First create a new MailStore SPE Instance. The instance must not be started yet.
  • Stop all archiving profiles in MailStore Server, either by setting the execution mode to manual, by disabling all Jobs or by disabling all scheduled tasks.
  • Stop the MailStore Server service.
  • Copy all archive store directories from MailStore Server into the instance's Data directory. Do not transfer the MailStoreMaster.fdb, the MailStoreMaster.key and MailStore.xml files. Make sure, there is no remaining .lock file in any of the archive store directories. If there is, the MailStore Server service has not been stopped completely yet. When there are identical folder names, do not merge them, but give them unique names instead.

Important Notice: After this step, do not run any of the archiving profiles in MailStore Server again, otherwise you might risk that emails are not getting archived by the MailStore SPE Instance (i.e. when a profile contains automatic deletion rules).

  • Start the MailStore SPE Instance.
  • Attach the archive stores that were previously transferred to the newly created instance. In case the archive store is migrated from MailStore Server 10 or newer the recovery key (product key or generated value) of the source MailStore Server installation is required. You have to use the UnlockStore command in the DEVELOPER > Management API window of the Management Console as described here.
  • Set the state of one archive store to Current.

Additional Steps

Depending on the previous configuration of MailStore Server, the following tasks are to be done to configure the MailStore SPE Instance accordingly:

  • Create users, either manually or by synchronizing with a directory service.
  • Configure compliance settings.
  • Create archiving profiles.
  • Verify the rest of the configuration, such as search index configuration, export profiles, permissions, etc.