If your organization is subject to U.S. Federal Information Processing Standards (FIPS) and runs in a FIPS-enabled environment, you can make Content Matrix compatible with that environment by changing the value of the key FIPSEnabled in the EnvironmentSettings.xml file to True.
Metalogix Content Matrix can manage its performance level through the Resource Utilization Setting. This type of management is also known as throttling, and is used for any migration action that is run with Metalogix Content Matrix.
To edit Resource Utilization Settings:
From the Contrent Matrix Console ribbon, choose Settings > Edit Resource Utilization Settings.
By default, the Efficiency value is set in the center or the slide bar. This is the recommended setting for best performance and resource utilization (use of RAM, CPU, Network and SharePoint load) during a migration.
If the slide bar is further to the left, the migration will run more slowly, but will have less chances of overloading the available resources and causing potential errors. If the slide bar is further to the right, it with use more system resources, and can speed the migration up, but could cause some potential errors if the system resources cannot handle the data being migrated. There is a chance that if the speed is too high, you would actually see a slowdown in the overall migration, because the migration is trying to run actions faster than the resources properly allow.
The actual values that are provided in the slide bar are determined by the systems resources (the system that has the Metalogix Content Matrix installed on it). A system with high resources will be able to run faster migrations, even if using the default setting, because over all available resources will be higher. This also means that the Efficiency and Speed values will have a larger spread between them. A system that has low resources will run more slowly, simply because it doesn't have the resources to run at faster levels. Again, this also affects the default values for Efficiency and Speed, since these numbers will be lower, and have a smaller spread between them.
NOTE: If the Efficiency is set to its maximum (all the way to the left), the migration will run more slowly, but the "slowest" speed will be the same between systems with high and low resources. The "slowest" value between systems will always be the same, however, the *"highest" value will be different based on the systems resources.
While this value can be set through the Contrent Matrix Console, you can also set it through the back end, if the UI setting does not seem to be working for you. Please contact Quest Support for more information on this back end setting.
You can use Distributed Migration to significantly improve the time it takes to complete large migration jobs by distributing the workload efficiently across the resource pool. The distributed model enables parallel processing of migration jobs that reduces migration time, and enables higher utilization, better workload throughput and higher productivity from deployed resources.
The feature consist of a central Distributed Database and one or more Distributed Migration agents.
Distributed Migration Components
Distributed Migration relys on the following components:
This is a SQL Server database that contains the repository or queue of migration job definitions which the agents can run. Distributed Migration agents share the same Distributed Database.
NOTE: The Distributed Database cannot be a SQL CE database.
Agents are physical or virtual machines on which you can run migrations remotely. Installed on each agent are the Content Matrix Console and the Metalogix Agent Service, which handles job queuing and processing. Any available agent can pull a migration job that has been set to Run Remotely directly from the Distributed Database.
Any logging information is then be sent to the Distributed Database.
When an agent is running a migration job, any interaction with the agent, such as changing a configuration setting, is not recommended.
If Distributed Migration was configured prior to version 9.2:
To provide more efficient resource utilization, the Distributed Migration model has been re-architected to eliminate the use of a Controller to push jobs to agents. Instead, Distributed Migration uses a Windows Service that allows any available agent to pull a migration job that has been set to Run Remotely directly from the Distributed Database.
If you configured Distributed Migration prior to version 9.2, you will need to reconfigure each agent in order to continue using Distributed Migration and to run any migration jobs remotely.
Refer to the Reconfiguring Distributed Migration After an Upgrade guide for more information.
NOTE: You will notice after an upgrade that the Configure Distributed Migration and Configure Self-Service options no longer display in the Content Matrix Console ribbon (Self-Service Migration has been removed as of version 9.2) and the Manage Agents dialog is empty.
Important Notes About Global Mappings
Currently, Distributed Migration does not support the following Global Mappings:
In the case of User Mappings, whenever a machine connects the Distributed Database, a pop-up displays with the option to copy local settings (which include User Mappings) from the local machine to the database.
User Mappings and settings can be copied from any machine that connects to the Distributed Database, even if it is not configured as an agent.
Requirements for the Distributed Database
·The Distributed Database must use a Microsoft-supported SQL server.
·The Distributed Database can reside on any machine in network, provided that all agents have access to that machine.
·The Distributed Database should be created from the Metalogix Content Matrix Console.
NOTE: It is recommended that SQL Server Authentication be used to connect to the Distributed Database, as it will allow for cross-domain connections.
Requirements for an Agent Machine
·An agent machine or workstation should have 16 GB of free RAM.
NOTE: An agent machine can be a physical or virtual machine.
·Microsoft .NET Framework 4.7.2 must be installed on the machine.
·The agent machine must meet all the prerequisites as specified in the Metalogix Content Matrix Console Advanced Installation Guide.
·The machine must allow remote connections to itself.
·All instances of Windows PowerShell must be closed.
·The following services must be started:
· If a migration job is using SP 2013 or 2016 DB as a source connection, then users can only run jobs remotely on an agent that meets the connection requirements for the same DB version as the machine from which the migration is configured. This means that the agent machines must either:
§Have the same version of SharePoint installed on or be a SharePoint WFE for a comptible version.
§Be a 64-bit machine that has no version of SharePoint installed on it.
·Local Object Model (OM) connections to SharePoint are not supported when using Remote Agents. - A Local OM connection to SharePoint can only be made when Metalogix Content Matrix is installed on a machine that is running SharePoint (a SharePoint server or WFE). Since this type of connection can be made on the Host machine, but cannot be guaranteed to also be available on an agent machine, it is not a supported connection adapter for running migrations using remote Agents. For making remote Object Model connections, make sure the Metalogix Extension Web Service (MEWS) is installed on each agent machine.