MailStoreFileGroup.fdb file using the RecreateRecoveryRecords command.
Recovery Records do not need to be rebuilt in most cases unless there is underlying damage to the database and the Check Integrity feature reports problems with the recovery records.
You must resolve all underlying issues with the database before rebuilding recovery records. Any issues relating to the FDB file, missing messages, or Content DAT files must be resolved before rebuilding recovery records.
Go to Administrative Tools > API > Command Line and use the RecreateRecoveryRecords command to rebuild the Storage Location ID as noted in the previous step.
RecreateRecoveryRecords --id=1
See the Recreate Recovery Records command in the Instance Management documentation.
MailStoreHome.exe /recreaterecoveryrecords.MailStoreFileGroup.fdb can be rebuilt in-place from the recovery records.
Please ensure you have a backup of the Storage Location before proceeding.
The MailStoreFileGroup.FDB file should not need to be repaired or recreated unless there is a problem with the file itself. As the FDB file is open at all times while MailStore is running, it is possible that the file can be missed by third-party backup software, or otherwise become damaged.
Do not place MailStore’s database files in a directory monitored by a real-time synchronization product such as Dropbox, OneDrive, or Google Drive. These products are not designed to handle the constant changes to the database files and will result in an inconsistent database.
Disable the damaged Storage Location:
--id=1 parameter in the following steps.Enter the following command:
SetStoreRequestedState --id=1 -requestedState=disabled
Rebuild the FDB file:
Enter the following command:
RecoverStore --id=1Re-enable and verify the Storage Location:
Please contact support for assistance.
Please post in the MailStore Home Community for assistance.
]]>This process will work both for messages in a journal format, and when messages for multiple users have been mixed into one archive.
Navigate to Administrative Tools > Compliance > Compliance General.
Unblock admin access to the archive.
Access the Export E-mail panel.
Go to Archive E-mail panel.
In Progress View, click Details.
MailStore Gateway does not offer any high availability capabilities, but there are a few options to provide redundancy depending on your requirements and technical abilities.
These are unsupported, please do not contact MailStore Support with problems related to these configurations.
Consider if you need redundancy at all. A short term outage of a gateway is not an emergency and will not cause message loss. Journal reports are e-mails like any other and the sending server will queue them for re-delivery for period of time.
These are the currently available options:
This article assumes a basic understanding of how to use MailStore Gateway, networking, DNS, and Microsoft 365 (or your e-mail platform)
DNS
Assuming you have two MailStore Gateway servers, 192.0.2.1 and 192.0.2.55, create these DNS records:
| Name | Type | Record Data |
|---|---|---|
msgw1.mailarchiveco.example. |
A | 192.0.2.1 |
msgw2.mailarchiveco.example. |
A | 192.0.2.55 |
msgw.mailarchiveco.example. |
MX | 10 msgw1.mailarchiveco.example. |
msgw.mailarchiveco.example. |
MX | 20 msgw2.mailarchiveco.example. |
To be clear, this configuration has two A records, one pointing to each server, and then an MX record pointing to both servers.
In this configuration Exchange journal reports will preferentially sent to msgw1.mailarchiveco.example over msgw2.mailarchiveco.example, but you could change the MX records to have the same priority to (roughly) deliver messages equally.
MX records and their ordering are not absolute. Even if you prioritize the servers as described above, you will occasionally see messages delivered to msgw2.mailarchiveco.example. This is normal and expected behaviour. Similarly if you configure the MX records to have the same priority the servers will not receive an even 50/50 split of messages. MX records are best effort.
Configure MailStore Gateway using a single hostname for all clients
To be clear, both servers will be configured to have the same name in the MailStore Gateway configuration, e.g. msgw.mailarchiveco.example.
This is not the same as the DNS records above. In DNS the servers are called msgw1.mailarchiveco.example and msgw2.mailarchiveco.example, but in MailStore Gateway both are configured to respond to msgw.mailarchiveco.example.
Backup the configuration
Once the primary server is configured, take a backup of your MailStore Gateway configuration as described in the Backup and Restore article from the documentation.
Keep the configuration backup up to date
Be sure to update the configuration backup whenever you make any configuration changes to the gateway. This applies to new mailboxes as well as password changes.
Warning: MailStore Gateway stores all messages encrypted at rest, relying on the mailbox password to decrypt messages. If you change a mailbox password on one server and fail to update the configuration, you will likely lose all messages that are delivered to the second server.
Go to the first server, configure Let’s Encrypt to msgw1.mailarchiveco.example
Go to the second server, configure Let’s Encrypt to msgw2.mailarchiveco.example
When configuring a MailStore instance to archive messages, create two archiving profiles, one for each server.
The first profile should be configured to archive server name msgw1.mailarchiveco.example, and the second profile should be configured to archive server name msgw2.mailarchiveco.example.
Both will use the same credentials. Both will use mbx-123@msgw.mailarchiveco.example`, and use the same password.
There isn’t one. Microsoft 365 / Exchange will use the MX records to deliver messages to both servers, and MailStore Gateway will accept messages from both servers. Both servers will receive messages with a RCPT TO the same address. All MailStore instances pull mail from both gateways at all times.
Stop the service on either server, and messages will be delivered to the other server and then archived by MailStore normally. The only thing that you’ll notice is that archiving profiles accessing the stopped server will fail and any messages on the stopped server will be held in the queue until you resume operations.
This process is more complex and less forgiving of errors. You must create a mailbox, replicate the configuration, and only then enable journal rules.
You must take care to create mailboxes on one server, then replicate the configuration to the other server.
It is not possible to use the web interface to create the same mailbox on more than one server as you cannot assign the mailbox name, nor the password, nor the generated encryption name, you must copy the configuration files manually to reflect changes.
Because both servers use identical usernames and passwords, it is possible to move messages between the identically named mailboxes on the respective servers. You should not attempt to do this regularly, but in the case of a server failing catastrophically you could recover the messages from disk.
The Gateway servers can be located in different locations, allowing for network or geographic redundancy.
MailStore Gateway does not offer any high availability capabilities, but there are a few options to provide redundancy depending on your requirements and technical abilities.
These are unsupported, please do not contact MailStore Support with problems related to these configurations.
Consider if you need redundancy at all. A short term outage of a gateway is not an emergency and will not cause message loss. Journal reports are e-mails like any other and the sending server will queue them for re-delivery for period of time.
These are the currently available options:
This article assumes a basic understanding of how to use MailStore Gateway, networking, DNS, and Microsoft 365 (or your e-mail platform)
DNS
Assuming you have two MailStore Gateway servers, 192.0.2.1 and 192.0.2.55, create these DNS records:
| Name | Type | Record Data |
|---|---|---|
msgw1.mailarchiveco.example. |
A | 192.0.2.1 |
msgw2.mailarchiveco.example. |
A | 192.0.2.55 |
msgw.mailarchiveco.example. |
CNAME | msgw1.mailarchiveco.example. |
To be clear, this configuration has two A records, one pointing to each server. It has a CNAME record pointing to the primary server.
All configuration in MailStore, and on mail servers must only use msgw.mailarchiveco.example, do not reference msgw1.mailarchiveco.example or msgw2.mailarchiveco.example anywhere except these DNS records.
Configure MailStore Gateway using a single hostname for all clients
If your company’s domain is mailarchiveco.example then your gateway’s domain could be msgw.mailarchiveco.example.
If you have multiple MailStore instances then each would have a separate mailbox, e.g. .mbx-123...@msgw.mailarchiveco.example and mbx-456...@msg.mailarchiveco.example
Backup the configuration
Once the primary server is configured, take a backup of your MailStore Gateway configuration as described in the Backup and Restore article from the documentation.
Keep the configuration backup up to date
Be sure to update the configuration backup whenever you make any configuration changes to the gateway. This applies to new mailboxes as well as password changes.
Warning: MailStore Gateway stores all messages encrypted at rest, relying on the mailbox password to decrypt messages. If either server has messages in the mailbox when you do a password change you’ll likely lose messages. I would recommend not ever changing the password of the gateway mailbox.
You can optionally even have the gateway installed and ready on the other server, just be sure to upgrade both servers together.
I would recommend not keeping the service running on the second server, failovers should be done intentionally.
Technically you can failover automatically (for example, with a monitoring system updating a DNS record or NAT rule) but a human must review the mailbox status on both servers to ensure that no messages were left behind.
Let’s Encrypt will only work on one server at a time and will fail on the other server.
In the event you have a failure that you cannot resolve within 24-hours:
Switch the CNAME record for msgw.mailarchiveco.example from msgw1.mailarchiveco.example to msgw2.mailarchiveco.example.
This will cause both inbound messages and the archiving profile to use the secondary server.
Start the MailStore Gateway on the secondary server.
Verify the certificate is valid and properly configured.
If you use Let’s Encrypt then the certificate may be out of date as the secondary server will not be able to renew the certificate. You can manually renew the certificate on the secondary server, but the gateway should update the certificate on start-up.
In failover mode your DNS records will look like this:
| Name | Type | Record Data |
|---|---|---|
msgw1.mailarchiveco.example. |
A | 192.0.2.1 |
msgw2.mailarchiveco.example. |
A | 192.0.2.55 |
msgw.mailarchiveco.example. |
CNAME | msgw2.mailarchiveco.example. |
Once the primary server is back up and running and you are ready to switch back, there is a new intermediary step involved which is called “recovery mode”.
Create a new MX record for msgw2.mailarchiveco.example pointing to msgw1.mailarchiveco.example.
Your DNS records will now look like this:
| Name | Type | Record Data |
|---|---|---|
msgw1.mailarchiveco.example. |
A | 192.0.2.1 |
msgw2.mailarchiveco.example. |
A | 192.0.2.55 |
msgw2.mailarchiveco.example. |
MX | 0 msgw1.mailarchiveco.example. |
msgw.mailarchiveco.example. |
CNAME | msgw2.mailarchiveco.example. |
In this state, inbound messages will be delivered to msgw1.mailarchiveco.example due to the MX record, while MailStore instances will use the CNAME record to connect to msgw2.mailarchiveco.example.
Remember to consider DNS TTLs, if you have a 24-hour TTL then you will have to wait 24-hours before the change takes effect globally.
Wait for mailboxes on the secondary server to be empty.
You can check the status of the mailboxes on the secondary server by logging into the MailStore Gateway web interface and checking the status of each mailbox. You can also check the mailbox directories on the secondary server to see if they are empty.
Stop the service on the secondary MailStore Gateway.
It is important to stop the service to prevent the secondary MailStore Gateway from receiving messages, otherwise you may have to repeat the process.
Revert your DNS to the original configuration.
Change the CNAME record back to msgw1.mailarchiveco.example, and remove the MX record completely.
You can test a failover any time, or switch permanently to the secondary server if desired, just be sure to not leave any messages behind on the non-active server.
This process is more complex and potentially less intuitive, and you must have a solid understanding of what is happening. The goal is that in “recovery mode” both server are running, inbound messages are being routed to the primary server, but MailStore is still pulling messages from the secondary server.
Ideally all MailStore instances will check for messages from the gateway frequently, so it should only take a few minutes for the secondary server to be empty. During this time inbound messages are being queued on msgw1.mailarchiveco.example and will be archived once you return to normal mode.
Remember that messages can sit in the gateway queued for delivery without fear of being lost, so you can take your time with this process.
]]>MailStore Gateway does not offer any high availability capabilities, but there are a few options to provide redundancy depending on your requirements and technical abilities.
These are unsupported, please do not contact MailStore Support with problems related to these configurations.
Consider if you need redundancy at all. A short term outage of a gateway is not an emergency and will not cause message loss. Journal reports are e-mails like any other and the sending server will queue them for re-delivery for period of time.
These are the currently available options:
This article assumes a basic understanding of how to use MailStore Gateway, networking, DNS, and Microsoft 365 (or your e-mail platform)
Configure MailStore Gateway using a single hostname for all clients
If your company’s domain is mailarchiveco.example then your gateway could be msgw.mailarchiveco.example, if you have multiple MailStore instances then each would have a separate mailbox, e.g. mbx-123...@mailarchiveco.example and mbx-456...@mailarchiveco.example.
Backup the configuration
Once the primary server is configured, take a backup of your MailStore Gateway configuration as described in the Backup and Restore article from the documentation.
Keep the configuration backup up to date
Be sure to update the configuration backup whenever you make any configuration changes to the gateway. This applies to new mailboxes as well as password changes.
Warning: MailStore Gateway stores all messages encrypted at rest, relying on the mailbox password to decrypt messages. If either server has messages in the mailbox when you do a password change you’ll likely lose messages. I would recommend not ever changing the password of the gateway mailbox.
You can optionally even have the gateway installed and ready, just be sure to upgrade both servers to matching versions of MailStore Gateway.
I would recommend not keeping the service running on the second server, failovers should be done intentionally.
Technically you can failover automatically (for example, with a monitoring system updating a DNS record or NAT rule) but a human must review the mailbox status on both servers to ensure that no messages were left behind.
Let’s Encrypt will only work on one server at a time and will fail on the other server.
In the event you have a failure that you cannot resolve within 24-hours:
Either switch the DNS A record or update your NAT firewall rules to redirect traffic to the secondary server.
Start MailStore Gateway on the secondary server.
Verify the certificate is valid and properly configured.
If you use Let’s Encrypt then the certificate may be out of date as the secondary server will not be able to renew the certificate. You can manually renew the certificate on the secondary server, but the gateway should update the certificate on start-up.
Once the primary server is back up and running, you can switch back to it by reversing the DNS A record or NAT firewall rules, then review the mailbox status on both servers.
Switch the DNS A record or NAT firewall rule back to the primary server.
Remember to consider DNS TTLs, if you have a 24-hour TTL then you will have to wait 24-hours before the change takes effect globally.
Stop the service on the secondary MailStore Gateway.
It is important to stop the service to prevent the secondary MailStore Gateway from receiving messages, otherwise you may have to repeat the process.
Move the mailbox directories containing the messages from the secondary server to the primary server. The mailbox directories will already exist, you are just adding the files from one into the other.
You can test a failover any time, or switch permanently to the secondary server if desired, just be sure to not leave any messages behind on the non-active server.
]]>You will need the mailbox’s name and password. As the password is part of the message decryption process, it is not possible to access the mailbox or messages contained within without the password. Additionally, be aware that a password reset is not possible while the mailbox contains messages.
In order to access a message, you first need to get the message number from the message list, so we will start by connecting to the POP3 server and requesting the message list.
Use the following curl command:
curl --ssl-reqd --insecure pop3://msgw.example.com/ -u "mbx-2a20342e96294505a35eb5c8364eb67c"
The response will look like this:
1 91471
Now try doing a UIDL request as well:
curl --ssl-reqd --insecure --request UIDL pop3://msgw.example.com/ -u "mbx-2a20342e96294505a35eb5c8364eb67c"
The response will look like this:
1 f558587b-b6d6-490d-b21e-eaf02172131a
In both cases above, there is a single message in the mailbox, the size is 91471 bytes and UIDL is f558587b-b6d6-490d-b21e-eaf02172131a.
In the POP3 protocol messages are always numbered starting at 1, and message numbers may change between sessions. While the POP3 protocol does not specify how to generate UIDLs it does require that the UIDL is consistent. MailStore Gateway uses the filename on disk as the UIDL making it possible to identify the message in the filesystem.
Once you have the message number, you can download it by adding the message number to the URI:
curl --ssl-reqd --insecure pop3://msgw.example.com/1 -u "mbx-2a20342e96294505a35eb5c8364eb67c"
Technically the message numbers can change from session to session, so if there are new messages coming in and/or messages being deleted you might need to try a few times, and you should verify using the Date header or Received headers of the message to make sure it matches.
Normally in POP3 you would pull the list of messages and then retrieve the message in the same session (numbers are consistent within a session but are allowed to change between sessions) but curl doesn’t support this, so you will need to do it in two steps.
Modern versions of Windows have curl built in, as well as nearly any Linux environment (including WSL) so it is quick and easy to get going, and by default it leaves messages on the server whereas most other POP3 clients default to deleting messages after they’re accessed.
MailStore Gateway’s passwords are generated randomly and include punctuation, so it is easiest to paste it into curl each time. As an example, a password may include punctuation such as qn5x(/.B9M~PsZA92f]VYbIG\q{!1^[8 which would require an understanding of shell escape sequences to enter safely.
Archive of dwarren\Exchange dwarren\Inbox
Archive of dwarren\Journal Incoming
Archive of dwarren\dwarren@example.com\Inbox
I will skip typing “Archive of dwarren” going forward as it applies identically in all cases below.
In this context, MailStore’s archiving profiles can be broken down into two types that I’ll discuss individually, Individual User and Multiple User.
Individual User profiles are where there is a 1:1 relationship between the source mailbox and the owner of the messages in MailStore does not parse the headers to determine the owner. These start by knowing the target archive (user), then connect to a mailbox to find messages. This includes Multiple Mailbox profiles such as Exchange Multiple Mailbox, as this type of profile is really just a series of Single Mailbox profiles, with a 1:1 relationship between each source mailbox and target archive.
For Individual User profiles, each message is archived into only a single user (if you send a message, a separate copy will be retrieved from your Sent folder, but a copy is not placed in the recipient’s archive, instead a copy must be found in their mailbox for it to appear in their archive in MailStore For these profiles the folder structure is preserved so you’ll get folder structures that look something like this:
Exchange mailboxes (Single and Multiple mailbox, but not Gateway or Journal):
Exchange $MAILBOXNAME$\Inbox
Exchange $MAILBOXNAME$\Sent Items
Exchange $MAILBOXNAME$\And more!
IMAP mailboxes:
$EMAILADDRESS$\INBOX
$EMAILADDRESS$\Sent
$EMAILADDRESS$\And more!
Local files and mail prepend the source (Outlook is both Outlook itself and PST files) and then mirror the folder structure.
Outlook $PSTTITLE\Inbox
Outlook $PSTTITLE\Sent Items
Outlook $PSTTITLE\And more!
By “And More!” I mean all folders the user has created or otherwise exist in the mailbox.
One quirk, Google doesn’t have folders in the classic sense, and their Labels implementation is not compatible with the way MailStore organizes and deduplicates messages, so instead messages are sorted into only the Inbox and Send folder:
$EMAILADDRESS$\Inbox
$EMAILADDRESS$\Sent
“Multiple User” type profiles have a “1:many” relationship, MailStore parses the headers of each message to determine the sender and recipients. These are Gateway/Journal/Multi-drop (mail belonging to multiple individuals is located in a single mailbox and MailStore must therefore parse the headers to determine the owner). MailStore starts with a message, then determines the target archive by parsing the sender and recipient(s), looking for matching e-mail addresses in MailStore’s user list and placing a copy in each. Messages can have 0 or more target archives (for example, if you send a message to two co-workers, the single message can be archived into all three archives from one instance).
For Gateway/Journal/Multi-drop profiles the folder structure is simpler:
Exchange mailboxes target the “Journal” folders:
Journal Incoming
Journal Outgoing
IMAP and local files use the e-mail address plus a \ as the root.
$EMAILADDRESS$\INBOX
$EMAILADDRESS$\Sent Items
In these cases there is no further folder structure possible, MailStore is sorting messages internally (in most cases all the messages came from the source’s inbox folder).
The one quirk here, you can have messages in the source that have no matching user in MailStore, in this case the message can either be targeted to the “@catchall\Unknown E-mail Addresses” or skipped and left in the source mailbox.
A couple other things to be aware of, within a target scope (The “Archive of” plus one more layer, so “Archive of dwarren\Exchange” and everything below, only one instance of a single message is allowed and subsequent copies will be skipped – So if you copy a message from your Inbox to your “Important Stuff” folder on the server, in MailStore it is just in Inbox. When you delete it from your mailboxes’ Inbox MailStore will now find the copy in your mailbox’s “Important Stuff” folder and move the message in MailStore to match.
Lastly, this all applies to how MailStore presents message in the interface. There is a single-instance-storage system that deduplicates on disk for storage savings as well. The single instance storage system is totally disconnected from where/how messages are stored in the interface, MailStore splits messages at the MIME part level and stores each MIME block once.
]]>MailStore does not have any formal deduplication feature.
While archiving MailStore checks each message in the source mailbox to see if it is in the archive in the correct location, skipping messages already in the archive, so in normal operation you should not see duplicated messages.
However, if a user or a mailbox is renamed, you might end up with two different sets of folders for the same user, and although you can merge these together, if the two folders contain the same messages you’ll end up with duplicates.
Because MailStore’s archiving process skips messages already in the archive we can export, delete and re-archive the messages, skipping the duplicated messages in most cases.
You must first finish merging and organizing messages in MailStore before proceeding.
You can perform these tasks as the admin, but you need to unblock access to the archive under Administrative Tools -> Compliance -> Compliance General.
Alternatively an individual user can perform most of these steps. The user account must have Archive E-mail, Export E-mail, Delete permissions on their account and also Full Access to their archive. The admin will still need to be involved with certain steps, so it is best to perform the following steps as an administrator.
Login to MailStore using whatever account you like, all of the steps will be performed in MailStore Client using the same account other than any Administrative Tools steps must be performed by an admin.
This step is optional, but in some cases you’ll be able to narrow down the range of messages using the search filter. If this is not possible, you can perform the following steps on individual folders, entire user archives, or across the entire MailStore archive as you prefer.
Start by finding a few examples of duplicate messages, they should already be in the same folder and will have the same Date, but they may be archived on different dates, if so the goal is to determine the date that the duplication occurred. You can select a wider date range if you like.
You can review the search if you want, hopefully it will contain one instance of each duplicated message but it may contain both copies of the duplicated messages and/or it may contain messages that are not duplicated. This is fine. The goal is to make sure that at least one instance of every duplicated message is found.
It is highly recommend to stop all archiving tasks for the next steps. This can be done in more than one way:
This will stop all background tasks, and only allow admin users to login
-OR-
Whatever step you take, be sure to keep track of what you changed so you can revert the change later.
C:\EML. The directory will be created as needed.A note about the folder you select:
While most operations in MailStore Server use folders relative to the server, in this case we’re using a folder relative to the client. So for example, if MailStore Client is installed on your personal workstation and you export to C:\EML the files will be written to your workstation instead of the server.
It is possible to use a mapped network drive, UNC path, or external drive, but I would recommend finding a machine with sufficient local internal storage instead as this process is dependent on your disk performance.
Once the export finishes, return to MailStore Client and delete the messages.
Now we’ll re-archive the EML files that we exported.
C:\EML in my case).This will re-archive all of the exported messages, skipping messages already in the archive. If you were able to use a Search E-mail folder to select just a subset of messages then most messages will be skipped but there may be a few messages that were in the selected date ranges that did not get duplicated and we want to make sure we get these messages re-archived.
It is possible that you won’t have any messages get archived here at all.
When the profile finishes click the Details link, all messages should either be archived, or skipped because they were already in the archive.
You can now return MailStore to normal operation by undoing whatever steps you took in the Stop MailStore Archive E-mail profiles from running step.
Depending on how you deleted the messages, you might be able to get some disk space back.
If you deleted all of your Storage Locations, you can now delete the files associated with these old Storage Locations. Be sure to not delete the new Storage Location.
If you use MailStore’s internal backup feature go to the backup directory and delete all of the Filegroup### directories as MailStore’s backup will not do this automatically. The next time MailStore’s backup runs it will copy all files that are not in the backup directory.
If you deleted messages or folders (but not all Storage Locations) then you might consider running a Compact operation on your Storage Location(s).
You won’t get a lot of space back as much of the content would have been handled by the single-instance-storage system within the Storage Location but there will be some space recovered.
]]>If you have any questions or have not used rclone before, take great care. In particular, understand that some commands (sync) not only copy but also delete files in the target.
First use rclone config to create a remote called source and destination, you can then perform the tasks from either machine, or a third machine entirely if desired.
One of the perks of rclone is that you can use it to copy and synchronize files across a variety of different protocols, the configuration and details are out of scope for this article.
You can use --transfers to the end of any of these commands to make them run multi-threaded, increasing the disk I/O and giving you delayed output.
I would also recommend --progress to monitor the progress in real time, and -v (verbose) to keep a record of the files copied.
You can also add --dry-run to see what will happen before you start.
We’ll start off by copying the content .DAT files, this will be a substantial portion of the database and most of these are not being modified (the most recent handful may be modified, and new ones are created, but that’s ok).
rclone copy source:mailarchive destination:mailarchive --filter "- index*" --filter "+ *.dat" --filter "- **" --min-age 1d
You’ll possibly have a few errors, that’s fine and they can be ignored at this stage. Run it again if you want it to get caught up on any remaining files, but don’t worry about getting every last file.
Now we’ll run it again copying even more files, excluding the .fdb files as these will be modified. Additionally we’ll skip anything modified in the last day as these are likely to be modified again.
rclone copy source:mailarchive destination:mailarchive --filter "- *.fdb" --min-age 1d
Now we’re ready to stop archiving, so login to the existing server with MailStore Client, go to the Storage Locations panel, find the Storage Location marked as Archive Here and switch it to Normal, and copy everything except the .fdb files:
rclone copy source:mailarchive destination:mailarchive --filter "- *.fdb"
This will copy the remaining index files and recovery records even if they’ve been modified recently, but still skipping the .fdb files as they will be modified by MailStore again. You can run it again to retry any errors, but it isn’t critical.
Finally, stop the service on the old server (and if you already installed the service on the new machine, make sure it is stopped there too).
This time we’ll use the sync command instead of copy, to ensure the destination matches completely.
rclone sync source:mailarchive destination:mailarchive
In this case there should be no errors, if you see any errors at all then make sure the service is stopped (on both sides) and run it again as needed until successful.
At this point you can bring up MailStore on the existing server again and leave it serving users (but not archiving) by leaving the Storage Location in normal status. All archiving will remain paused.
If you haven’t already, install MailStore Server on the new server, launch the Configure the MailStore Server Service tool on the new server, go to the security tab and initialize encryption, you’ll be prompted for the old encryption recovery key (by default, the product key although you may have a custom one configured). This does not transfer the license.
You can now start the service on the new server, run any pending database upgrades, compact, perform Storage Location consolidations, re-indexing, or whatever else is needed.
Once you’re ready for the new server to start archiving, just switch the Storage Location that was formally set to Archive Here back to that status.
You’re now ready to uninstall the old MailStore Server installation, transfer the license and switch users over.
From a licensing standpoint, only a single server can use the license at once, but you could acquire another license, or use a 30-day trial license on the new machine.
MailStore Server’s 30-day trials have one limitation that you won’t encounter when doing a normal 30-day trial: You cannot view messages that have been in the archive more than 30 days ago. You can still see the messages in the list, search, and access all administrative functions but the message bodies themselves have a trial overlay blocking access to the message body, which is fine for our purposes.
Hopefully everything here is clear, but if not, please don’t start the process until you really understand what it is going to do.
]]>