Chat now with support
Chat con el soporte

Metalogix Email Migrator 4.7.1 - Help

Introduction Getting started Migration User Interface Configuration Troubleshooting & Tips

Configuring Proxy Settings

In most cases Email Migrator can automatically authenticate license keys through an environment's proxy setting, however, in some cases the proxy may need to be configured within the Email Migrator. In these cases users can specify the proxy settings via the connecting dialog. This section will review how to set the proxy settings for these special cases.

1. Click the Set proxy link in the Activate License Key dialog, next to the Online Activation option. In the pop-up dialog check the Enable proxy check-box.

 

Image(409)

 

2. Enter the Server name and Port for the proxy. This text box allows users to specify the specific server name or IP for the proxy, and the specific port the proxy can be set in.

3. Next, specify the credentials to use. The credentials of the current user will be selected by default (the Window authentication credentials), and the Domain/username is displayed beside the first radio button option.

Alternatively, users can specify alternate credentials by clicking the Different user radio button, and entering an alternate username and password.

4. Once the proxy options are set (if there are any) select Set to return to the previous dialog.

The proxy configuration should be complete and users should be able to authenticate their license key through this proxy.

 

PowerShell Authentication

When configuring Exchange Server connection (see Connecting to Exchange (including Office 365)), administrator can select from various types of PowerShell authentication. Each of this types is suitable for different scenarios and offer some advantages. The following lines analyze PowerShell authentication options in respect to possible scenarios.

 

 

Image(410)

 

 

The PowerShell auth drop-box allows you to select the authentication that's right for you. The most commonly used authentication types are the following:

o Kerberos - recommended when Exchange Server is in the same domain as Email Migrator; for this type of authentication the Exchange Server must be specified by server name (not the IP address)

o Basic - recommended when Exchange Server is in different domain than Email Migrator; the basic authentication must be enabled for PowerShell Web Service on the target Exchange Server

o Default -  will try to use Kerberos or Negotiate authentication mechanism

o Negotiate - Windows authentication must be enabled for PowerShell Web Service on the Exchange Server

 

 

Possible scenarios

Email Migrator machine is within the Exchange Server domain

Default, Kerberos – these PowerShell authentication mechanisms should work by default

other authentication mechanisms – should work with specific configuration settings on the client and target machine:

 

I.On client machine (i.e. Email Migrator machine), the destination (i.e. Exchange Server) must be added to the trusted host using WinRM :

To do so, go to gpedit.msc / Administrative Templates /  Windows Compoments  / Windows Remote management (WinRT) /  WinRM Client.

a) Allow unencrypted traffic if needed (this enables http)

b) Trust the remote machine - Trusted Hosts - Enabled

Enable Trusted Hosts and add computer to TrustedHostsList (e.g.  "*.<DomainName>.local" will add all computers of the domain).

 

Image(212)

 

or execute commands:

winrm set winrm/config/client @{TrustedHosts="*"}

 

winrm set winrm/config/client @{AllowUnencrypted="true"}

 

To verify WinRM configuration:

winrm get winrm/config

 

 

or PowerShell commands:

Set-Item WSman:\localhost\client\TrustedHosts *

Set-Item WSman:\localhost\client\AllowUnencrypted true

To verify WinRM configuration:

Get-Item WSman:\localhost\Client\*

 

 

 

Important note: If you are still getting connection error

Connecting to remote server failed with the following error message:

"The WinRM client cannot process the request. Unencrypted traffic is currently disabled in the client configuration. Change the client configuration and try the request again. For more information, see the about_ Remote_Troubleshooting Help topic."

Check your settings using command winrm get winrm/config  and use winrm commands to configure these setting (gpedit.msc sometimes fails to set the properties).

 

To test connection, run the following command from the client computer:

 

winrm identify -r:http://winrm_server -auth:basic -u:userName -p:password -encoding:utf-8

 

or PowerShell command:

Test-WSMan serverName -Authentication basic –Credential Get-Credential

 

 

 

 

II.On target machine allow WinRM to accept remote connection by executing this command  

                                      winrm quickconfig          

                                      then select y (YES)

 

or PowerShell command

Set-WSManQuickConfig –force

then restart WinRm service

                  restart-Service winrm

 

Image(9)

NOTE:

If Kerberos authentication is used, Exchange Server should be specified by server name (not the IP address). If IP address is specified, Email Migrator tries to translate it to server name.

 

 

 

Email Migrator machine is outside the Exchange Server domain

Kerberos  - cannot be used

other authentication mechanisms  - must be configured on the client (Email Migrator) and target (Exchange Server) machine

 

Example - Basic authentication configuration

I. You need to configure WinRM on the client. Go to gpedit.msc / Computer Configuration / Administrative Templates  / Windows Compoments  / Windows Remote management (WinRT)  / WinRM Client.

1.Allow Basic authentication

2.Enable "Allow unencrypted traffic" if needed (this enables http)

3.Enable "Trusted Host" for the remote machine

Enable Trusted Hosts and add computer to TrustedHostsList (e.g.  "*.<DomainName>.local" will add all computers of the domain).

 

Image(213)

 

or execute commands:

winrm set winrm/config/client @{TrustedHosts="*"}

 

winrm set winrm/config/client @{AllowUnencrypted="true"}

 

winrm set winrm/config/client/auth @{Basic="true"}

To verify WinRM configuration:

winrm get winrm/config

 

 

or PowerShell commands:

Set-Item WSman:\localhost\client\TrustedHosts *

Set-Item WSman:\localhost\client\AllowUnencrypted true

Set-Item WSman:\localhost\client\Auth\Basic true

To verify WinRM configuration:

Get-Item WSman:\localhost\Client\*

Get-Item WSman:\localhost\Client\Auth\*

 

 

Important note: If you are still getting connection error

Connecting to remote server failed with the following error message:

"The WinRM client cannot process the request. Unencrypted traffic is currently disabled in the client configuration. Change the client configuration and try the request again. For more information, see the about_ Remote_Troubleshooting Help topic."

Check your settings using command winrm get winrm/config and use winrm commands to configure these setting (gpedit.msc sometimes fails to set the properties).

 

To test connection, run following command from client computer:

winrm identify -r:http://winrm_server -auth:basic -u:userName -p:password -encoding:utf-8

 

or PowerShell command:

Test-WSMan serverName -Authentication basic –Credential Get-Credential

 

 

 

 

II. Configuration on the server:

1. Optional: If you want to allow unencrypted traffic , go to IIS Manager / <ServerName> / Sites / Default Web Site / PowerShell / SSL Settings and uncheck Require SSL option.

 

Image(191)

 

2. Under IIS Manager / <ServerName> / Sites / Default Web Site / PowerShell / Authentication enable Basic Authentication.

 

Image(192)

 

3. Allow WinRM to accept remote connection by executing this command: 

winrm quickconfig

then select y (YES)

 

or PowerShell command

Set-WSManQuickConfig –force

then restart WinRm service

restart-Service winrm

 

4. Restart IIS by using the command iisreset

 

Generating PowerShell Scripts

Email Migrator has the ability to generate PowerShell scripts, which can then be used to migrate your content through the PowerShell command window. Email Migrator can use a job list or batch file to create a PowerShell script, and this script can then be run from the PowerShell console. This means that anything users can do through the Email Migrator's User Interface (UI) can also be done though PowerShell, adding all of PowerShell's capabilities to a migration.

 

When Email Migrator is installed an Email Migrator Console is installed under the same Start menu folder location. When this PowerShell console is used it will already have the three snap-ins installed. It can be accessed from the Start menu at: Metalogix > Email Migrator > Email Migrator Console (as seen below).

 

Image(539)

 

 

 

Using PowerShell

In order to create a PowerShell script for the Email Migrator a job must first exist in the Job List section.

1. In the main UI, go down to the Job List section and select a job (or jobs) that you want to run in PowerShell.

2. Click the Generate PowerShell Script button in the Job List's tool bar, or right-click on one of the items and select Generate PowerShell Script from the context menu. This will open a drop down menu that allows users to select between two user based PowerShell script generation options. These option are:

For Current User and Machine - This option will generate a PowerShell script based on the currently logged in User account. Any PowerShell scripts that are generated from this option can only be run by the logged in user (on the machine they were generated on). This is the most likely scenario.

For Current Machine - This option will generate a PowerShell script that can be used by any User account on the machine they are created on.

For Certificate - This function is not implemented.

 

Image(588)

 

Once the PS script generation type is selected, Email Migrator will generate a PS script for the select Job, which will be written out to a Microsoft Notepad file. If multiple jobs are selected they will all be written out, into the same file.

3. A Notepad file will open containing the PowerShell script for any selected job(s). This file can now be saved as a PowerShell script file. To do this click File > Save As... and select any desired save location for the PowerShell script. Give the file any name you want, but change the file type to .PS1.

 

Image(566)

 

In the PowerShell (PS) script itself you may notice five sections (see the image above). They are:

Section 1 - This first section at the top (starting with an "if" statement) runs a check in the PowerShell console to make sure that the Metalogix snappins have been added. If they are not found then it will add them to that instance of the PS console.

Load Configuration settings - This section will find and load all of the Email Migrator client application configuration settings into the PowerShell script. These are the client application's environmental settings and not the migration settings.

Load source - This section will load all of the data for the source environment connection.

Load target - Similar to the previous section, this will load target environment's connection information.

Run the action - Last is the "Run the action" section. This last section will contain all of the other data for the migration, such as the type of migration and all of the settings and configurations for the migration that is being run. This includes things like settings for versions, content types, permissions, etc.

4. Open the Email Migrator Console shortcut (Start > Metalogix > Email Migrator > Email Migrator Console), for the PowerShell window with the Metalogix snap-ins already installed.

 

Image(542)

 

5. In the PowerShell window you can set yourself to act from any desired directory. In some cases users will set themselves to the same directory that contains their PowerShell scripts. Now enter the name and extension of the PowerShell Script (at its specified location), and the script will run.

In the case that you are running a script from the same directory you would use the format: .\[ScriptName].ps1. So if your PowerShell script was named "ResourceScript.ps1" then you would enter: .\ResourceScript.ps1 into the window, and the script would run.

In the case that the script is in a different directory, you would enter the location of that directory relative to your current location, followed by the script name. For example, if your prompt is at the "C:\" drive and your PowerShell script, named "ResourceScript.ps1" is on the desktop you would enter: C:\Users\[User]\Desktop\ResourceScript.ps1, and the script would run.

 

Image(9)

NOTE:

In some cases the Execution Policy may prevent you from executing a PowerShell script. In this case you will likely see the message: [Script].ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details. In this case, running the command: set-executionpolicy RemoteSigned should change the existing script policy to allow you to run these scripts for your location. It is advised that you check with your System Administrators before doing this to ensure that no Company Policies are being broken by this action. If this is an action you need to take, you should only need to run this command once.

 

6. The migration will begin, and any warnings and/or errors that are encountered in running the script will be displayed in the PowerShell window. Once the migration has run, migration summary is displayed in the PowerShell window. You can also refresh the Job list to see the given job updated.

For more information on Email Migrator's PowerShell cmdlets please see the PowerShell Command-Let List page for details.

 

PowerShell Command-let List

Email Migrator has the ability to generate PowerShell script for you, for any migration action that is available through it (see the Generating PowerShell Scripts section). The below cmdlets are used in the generated PowerShell script, but they can also be used to write your own script, should you desire to do so. For more information on each cmdlet, simply type "get-help [cmdlet]."

For example, if you want more information on Copy-ArchiveServer cmdlet you would enter "get-help Copy-ArchiveServer, followed by the Enter (return) key.

Below is a list of the available cmdlets (and their parameters), broken up into the available commands for each snap-in:

 

Archive to archive commands

Copy-ArchiveServer

o Target - the target node.

o ReplaceShortcutActionOptions - Defines for which items to create shortcuts. Possible values:

§CreateShortcutsForAllMigratedEmails - shortcut will be created for every single migrated item in the user mailbox

§RecreateShortcutsOnlyIfTheOriginalShortcutsExist - shortcuts will be created only for items that have shortcuts also in the source system

§DoNotCreateShortcuts - no shortcuts are created during migration

o DeleteOriginalShortcuts - Defines whether to delete original shortcuts from source Exchange Server.

o CopyFolders - Defines whether to copy folders.

o FilterOptions - Defines which items to migrate.

o CopyItems  - Defines whether to copy items.

o RetentionOptions - Defines the retention time on the target. Possible values:

§Migrate - migrated items will have the same retention in the target system as in the source system

§OverwriteAll - original retention of the migrated items will be overwritten; the value defined in the RetentionInMonths will be used

§SetIfNotDefined - retention will be overwritten only for items that have no retention set in the source system, the value defined in the RetentionInMonths will be used for such items

 

o Transformers - not used.

o Quiet - If set, the operation will not report progress to the PowerShell console.

o JobFile - The name of a job file to use for logging.

o JobDatabase - The connection string of a jobs database to use for logging.

 

Copy-ArchiveMailboxToServer

o Target - The target node

o ReplaceShortcutActionOptions - Defines for which items to create shortcuts. Possible values:

§CreateShortcutsForAllMigratedEmails - shortcut will be created for every single migrated item in the user mailbox

§RecreateShortcutsOnlyIfTheOriginalShortcutsExist - shortcuts will be created only for items that have shortcuts also in the source system

§DoNotCreateShortcuts - no shortcuts are created during migration

o DeleteOriginalShortcuts - Defines whether to delete original shortcuts from source Exchange Server.

o CopyFolders - Defines whether to copy folders.

o FilterOptions - Defines which items to migrate

o CopyItems  - Defines whether to copy items.

o RetentionOptions - Defines the retention time on the target. Possible values:

§Migrate - migrated items will have the same retention in the target system as in the source system

§OverwriteAll - original retention of the migrated items will be overwritten; the value defined in the RetentionInMonths will be used

§SetIfNotDefined - retention will be overwritten only for items that have no retention set in the source system, the value defined in the RetentionInMonths will be used for such items

o Transformers - not used.

o Quiet - If set, the operation will not report progress to the PowerShell console.

o JobFile - The name of a job file to use for logging.

o JobDatabase - The connection string of a jobs database to use for logging.

 

Copy-ArchiveMailboxToMailbox

o Target - The target node

o ReplaceShortcutActionOptions - Defines for which items to create shortcuts. Possible values:

§CreateShortcutsForAllMigratedEmails - shortcut will be created for every single migrated item in the user mailbox

§RecreateShortcutsOnlyIfTheOriginalShortcutsExist - shortcuts will be created only for items that have shortcuts also in the source system

§DoNotCreateShortcuts - no shortcuts are created during migration

o DeleteOriginalShortcuts - Defines whether to delete original shortcuts from source Exchange Server

o CopyFolders - Defines whether to copy folders.

o CopyFolders - Defines whether to copy folders

o CopyItems  - Defines whether to copy items.

o RetentionOptions - Defines the retention time on the target. Possible values:

§Migrate - migrated items will have the same retention in the target system as in the source system

§OverwriteAll - original retention of the migrated items will be overwritten; the value defined in the RetentionInMonths will be used

§SetIfNotDefined - retention will be overwritten only for items that have no retention set in the source system, the value defined in the RetentionInMonths will be used for such items

o Transformers - not used

o Quiet - If set, the operation will not report progress to the PowerShell console.

o JobFile - The name of a job file to use for logging.

o JobDatabase - The connection string of a jobs database to use for logging.

 

 

Email to archive commands

Copy-EmailMailboxToArchiveServer

o Target - The target node

o ReplaceShortcutActionOptions - Defines for which items to create shortcuts. Possible values:

§CreateShortcutsForAllMigratedEmails - shortcut will be created for every single migrated item in the user mailbox

§DoNotCreateShortcuts - no shortcuts are created during migration

o CopyFolders - Defines whether to copy folders.

o CopyItems  - Defines whether to copy items.

oCopyPrimaryMailbox - Defines whether to copy primary mailbox.

oCopyArchiveMailbox - Defines whether to copy archive mailbox.

o FilterOptions - Defines filter rules: item creation date, item size, message class.

o RetentionOptions - Defines the retention time on the target. Possible values:

§Migrate - migrated items will have the same retention in the target system as in the source system

§OverwriteAll - original retention of the migrated items will be overwritten; the value defined in the RetentionInMonths will be used

§SetIfNotDefined - retention will be overwritten only for items that have no retention set in the source system, the value defined in the RetentionInMonths will be used for such items

o Transformers - not used.

o Quiet - If set, the operation will not report progress to the PowerShell console.

o JobFile - The name of a job file to use for logging.

o JobDatabase - The connection string of a jobs database to use for logging.

 

Copy-EmailToArchiveMailbox

o Target - The target node

o ReplaceShortcutActionOption - Defines for which items to create shortcuts. Possible values:

§CreateShortcutsForAllMigratedEmails - shortcut will be created for every single migrated item in the user mailbox

§DoNotCreateShortcuts - no shortcuts are created during migration

o CopyFolders  - Defines whether to copy folders.

oCopyItems - Defines whether to copy items.

oCopyPrimaryMailbox - Defines whether to copy primary mailbox.

oCopyArchiveMailbox - Defines whether to copy archive mailbox.

oRetentionOptions - Defines the retention time on the target. Possible values:

§Migrate - migrated items will have the same retention in the target system as in the source system

§OverwriteAll - original retention of the migrated items will be overwritten; the value defined in the RetentionInMonths will be used

§SetIfNotDefined - retention will be overwritten only for items that have no retention set in the source system, the value defined in the RetentionInMonths will be used for such items

oFilterOptions - Defines filter rules: item creation date, item size, message class.

o Transformers - not used.

o Quiet - If set, the operation will not report progress to the PowerShell console.

o JobFile - The name of a job file to use for logging.

o JobDatabase - The connection string of a jobs database to use for logging.

 

 

Remove commands

Remove-Shortcuts

o Target - The target node

o ShortcutMessageClasses - Defines shortcut message classes.

o Transformers - not used.

o Quiet - If set, the operation will not report progress to the PowerShell console.

o JobFile - The name of a job file to use for logging.

o JobDatabase - The connection string of a jobs database to use for logging.

 

 

Documentos relacionados