Here I wanted to emphasize some important facts about the new QMM MAgE (Migration Agent for Exchange) agents… what one should know about them when starting migration project.
1. Don’t underestimate Agent Host hardware requirements. MAgE is quite hungry for computer resources, especially CPU. Below is official requirement which I cannot agree more based on my experience, certainly go with the “recommended” section:
•Intel x86
•AMD 64
•Intel EM64T
RAM: Minimum: 0.8 GB per MAgE instances
Recommended: 1.6 GB per MAgE instance
CPU: 2 GHz or higher (before Turbo Boost if applicable)
Minimum: 1 CPU core per 2 MAgE instances
Recommended: 1 CPU core per each MAgE instance
LAN Bandwidth: Minimum: 100 Mbps
Recommended: 1 Gbps
2. As of this writing (Feb 2015, QMM 8.11) each MAgE agent (Calendar or Mail) runs 5 threads allowing to process 5 concurrent mailboxes. It is very rarely when you’d need to change the default thread count, but if you do – there is SQL query which I will not publish here. Please contact product Support team.
3. Agent reads all configuration directly from SQL database and for most of them it happens at the service start time. To see effect immediately, please restart MAgE agent from QMM console and watch log immediately after restart – a lot of interesting configuration information will be there. Also keep an eye on SQL instance, agents put lots of “stress” on SQL box and it really needs to be “top notch” in terms of CPU and memory. For example on the project with ~ 6,000 mailboxes it had to be 32 GB of RAM and Quad and more CPU no more or less cope with the amount of queries that come from all the multi-threaded agents.
4. Some other key agent settings that contain unique project guid linking agent to particular QMM project are stored in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Quest Software\Migration Agent for Exchange\<instance_name>
5. Target mailboxes are no longer deleted / re-created. This makes it very flexible when merging into the pre-existing mailboxes.
6. MAgE is relying on Primary X500 address for matching: Source (LegacyExchangeDN) = Target (X500)
7. MAgE keeps track of every synced message Source-Target pair of MAPI SOURCE KEYs (in other words unique message guids) storing them in QMM SQL project database. Every such entry takes 1024 byte. For large migrations it can grow quite high, for example my average size current migration involving ~ 6,000 mailboxes with the total of ~ 150 mln messages estimated to have ~150 GB SQL project size. Here is official guideline:
SQL database size = [Total number of mailboxes] x [Average number of messages in a mailbox] x 1024 bytes [Size of information for single message] x 1.05 [Additional 5% of size to store error messages]
For a sample migration that involves
•100 mailboxes
•Around 30,000 messages per each mailbox
The resulting database size is calculated as follows:
SQL database size = 100 mailboxes x 30,000 messages x 1024 x 1.05 = 3,225,600,000 bytes ≈ 3GB
8. Even if MAgE may be installed to the drive other than C:\, it still stores logs under ProgramData folder which is by default located under C:\ProgramData\Quest Software\Migration Agent for Exchange. Each MAgE stores its log in a separate folder.
9. Here are SQL queries to enable / disable extended logging (Don’t forget about Agent restart!). Please also note that extended logging is enabled out of the box and Support insists that it has to be left this way. So likely you wouldn’t have to do anything here.
TURNING ON:
UPDATE AGENTPROPERTY
SET VALUE=’1′
WHERE BINDINGID IN(SELECT ID FROM AGENTPROPERTYBINDING WHERE SCHEMAID=1003 AND AGENTTYPE=18)
TURNING OFF:
UPDATE AGENTPROPERTY
SET VALUE=’0′
WHERE BINDINGID IN(SELECT ID FROM AGENTPROPERTYBINDING WHERE SCHEMAID=1003 AND AGENTTYPE=18)
10. When reading MAgE logs since each instance is now multi-threaded, the Tx marker gives the thread unique identifier. In the example below Tx15 is that thread id, which is set by Windows on thread creation. During each new mailbox processing, agent instance creates the new thread to process this new mailbox, and then deletes the thread after its done and moving to the next mailbox. So Tx (TTL) = “Single Mailbox Processing Time” and if you look at single agent’s log file, you’ll see way more than just 5 of such unique TX identifiers. But it will never exceed (5+S) individual threads per agent running concurrently, where 5 is default per agent value of MaxConcurrentMigrations parameter (how many mailboxes are processed simultaneously by one agent = how many mailbox processing threads single agent can run) and S describes a few additional service threads running in parallel – main thread, watchdog thread etc. You can also see A# for example A26 – that is agent instance id which is set at agent’s setup and stored at SQL database.
2015-02-06 19:38:12.7364 Px14B4 Tx15 A128 C47 M1357 Info Create DisBase filter for collection: 47
2015-02-06 19:38:12.7364 Px14B4 Tx1a A128 C47 M1347 Info Filter body is empty
11. MAGE logs are using UTC time standard.
12. Every MAgE agent is by default configured to process mailbox for 23 hours or until it gets to 100% in sync, whatever comes first. Therefore when adding new mailboxes to a given collection, it may take considerable time (couple days) until some mailboxes change their status from “New” to “In Progress” or “Ready to Switch”.
13. Unlike legacy agents, Mail Sync MAgE agent will also sync Calendar folders. If mailbox is also a member of Calendar sync collection, both Mail and Calendar Sync MAgE agents will be syncing mailboxes’ calendar data.
14. Every MAgE based collection now has Statistics tab ( on the QMM console there are 3 tabs Members | Statistics | Agent Manager). It gives very good insight into how sync is doing: last time mailbox was processed by the agent, mailbox status (Ready To Switch, Syncing …) and any errors or issues.
15. (As of QMM 8.13) If MAgE fails to migrate any message, it will still retry it 3 times during subsequent sync cycles. As such, often failed messages counter on QMM Statistics screen may actually decrease over time until it settles on certain final number when mailbox is 100% in sync.
16. MAgE “Older Than X Days” message filtering logic works based on the “Last Modified” date. I have seen instances where such migrated mailboxes, even though they were “leaner” on the Target and it was obvious that many messages were filtered past certain date, some noticeable amount of old messages were still presented. More detailed investigation was revealing that all those messages were modified recently. Note that double clicking on the message / saving it as .msg file or some other activities will result in message modified property being updated on the Exchange server so it is not very rare event when end user is working with the message later and causing modified date to be updated.
