in

Priasoft Community for Microsoft Exchange Server Professionals

This is not just for users of Priasoft’s Server products, but for all Exchange Server professionals. Feel free to share your knowledge and experiences, get the latest information on new features and enhancements to Priasoft’s portfolio, download the latest releases, get expert tips and techniques, be in touch with the product teams, participate in a beta programs, and much more. We want this community to be a channel of communication not just between you the user and the individuals here at Priasoft that bring you our Exchange Server offerings, but also with other users who employ Priasoft products.

Exchange Migration Support

  • Automating Exchange 2010 setup requirements for the Priasoft Migration Suite for Exchange

    We have recently developed a Powershell script to automate the requirements for Exchange 2010 target setup. You can see the manual steps here. This script will setup a remote PowerShell session with an Exchange 2010 server and then prompt you for a name that will be used to create a windows account for use by the Migration Suite for Exchange.

    The script has the following assumptions:

    1. The user name provided does not exist and needs to be created or the user name provided has been created already using this script and needs its setting refreshed.
    2. The User account provided to start the remote PowerShell session (script prompts for credentials) with the Exchange 2010 server has the necessary rights to execute the script. (NOTE: if this is a new installation you should you the user that was used to install Exchange 2010)
    3. Scripting is enabled in Windows PowerShell
    4. You are running this script from a host that has Windows PowerShell V2 and WinRM installed. (Note: Windows 7 already meets these requirements out of the box) 

     Below is the script and is also attached to this post as a downloadable attachment.

    # This source code is provided "AS IS" with no warranties, and confers no rights

    # Parts (c) 2010 by Priasoft, Inc

    function Read-HostMasked([string]$prompt="Please provide your password") {

    $password = Read-Host -AsSecureString $prompt;

    $BSTR = [System.Runtime.InteropServices.marshal]::SecureStringToBSTR($password);

    $password = [System.Runtime.InteropServices.marshal]::PtrToStringAuto($BSTR);

    [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($BSTR);

    return $password;

    }

    Function Write-hostG([string] $Value)

    {

    $fore = $Host.UI.RawUI.ForegroundColor

    $Host.UI.RawUI.ForegroundColor = "Green"

    write-host $value

    $Host.UI.RawUI.ForegroundColor = $fore

    }

     

    function New-SecureString([string] $plainText)

    {

    $secureString = new-object System.Security.SecureString

     

    foreach($char in $plainText.ToCharArray())

    {

    $secureString.AppendChar($char)

    }

     

    $secureString

    }

     

    function Pause ($Message="Press any key to continue...")

     

    {

     

    # The ReadKey functionality is only supported at the console (not is the ISE)

     

    if (!$psISE)

     

    {

     

    Write-Host -NoNewLine $Message

     

    $null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

     

    Write-Host ""

     

    }

     

    }

     

     

     

    write-host "Setup Exchange 2010 Power Shell Connection and create a new Migration User Account"

    write-host "(c) 2010 Priasoft, Inc - Experts in Exchange-to-Exchange Migration"

    write-host "Visit us on the web @ http://www.priasoft.com"

    write-host "______________________________________________________________"

    write-host ""

    write-host "This script will do the following:"

    write-host ""

    write-host "Create a new user account (you will be prompted for the name) with an Exchange 2010 mailbox, create a new Exchange Throttling Policy for use only by this user, assign the new user to the policy, "

    write-host "grant the new user rights to login to all mailboxes for existing databases, add the new user to the Builtin Administrators group on the domain,"

    write-host "Add user to the Exch Organization Container with full rights,"

    write-host "and add the new user to the Exchange 2010 Public Folder Management & Recipient Management role groups"

    write-host ""

    write-host ""

    pause

    write-host ""

    Write-hostG "Please provide the host name of an Exchange 2010 server to connect to.."

    write-host ""

    # Get the Exchange host name of a 2010 server - loop for value if none provided

    do {

    $Server = read-host "Exchange 2010 server hostname (i.e. psex10)"

    }

    while($Server.Length -le 0)

    write-host ""

    Write-hostG "Please provide the domain\username of an existing account that has remote power shell right on the Exchange 2010 server"

    Write-hostG "If this is a new install, you must provide the username that was used to install Exchange 2010"

    write-host ""

    # Get the Username - loop for value if none provided

    do {

    $userName = read-host "Enter username (i.e. Exch10\administrator)"

    }

    while($userName.Length -le 0)

    write-host ""

    $v = "Please enter password for " + $userName

    Write-hostG $v

    write-host ""

    $Pass = Read-HostMasked

    $Password = New-SecureString($Pass)

     

    $fqdn = "http://" + $server + "/PowerShell/?serializationLevel=Full"

     

    write-host ""

    $v = "Starting remote Exchange 2010 Power Shell session on " + $fqdn

    Write-hostG $v

    write-host ""

    Filter AssembleMessage ([String] $Path) { Add-Content -Path:"$Path" -Encoding:"Byte" -Value:$_.FileData }

    Get-PSSession | Remove-PSSession

    Get-Module | Remove-Module

    $secureString = $Password

    # by default connecting using kerberos auth

    $UserCredential = New-Object System.Management.Automation.PSCredential -ArgumentList $userName,$secureString

    $SkipCertificate = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $fqdn -Credential $UserCredential -Authentication kerberos -SessionOption $SkipCertificate

     

    if($Session -eq $null){

    throw write-host "Could not get Exchange 2010 session"

    }

    else {

    #do nothing

    }

     

     

     

    write-host ""

    Write-hostG "Please wait, importing session...."

    write-host ""

    Import-PSSession -Session $Session

    write-host ""

    Write-hostG "Please provide the name of the migration account you would like to create for use during the migration"

    write-host ""

    do {

    $MigrationUserName = read-host -Prompt "Migration Account User Name <MigrationAdmin>"

    }

    while($MigrationUserName.Length -le 0)

     

     

     

    # Note: You can change this if you like

    $UPN = $MigrationUserName + "@migrationServiceAccount.com"

    #

    write-host ""

    $v = "Looking for existing User " + $MigrationUserName + " with mailbox.."

    Write-hostG $v

    write-host ""

    $NewMailbox = Get-mailbox -Identity $MigrationUserName

     

    if($NewMailbox -eq $null){

    Write-hostG "No user with mailbox Found.."

    Write-Host ""

    Write-hostG "Creating new user with mailbox.."

    $NewMailbox = New-Mailbox -Alias $MigrationUserName -Name $MigrationUserName -Password $password -DisplayName $MigrationUserName -ResetPasswordOnNextLogon $False -RemotePowerShellEnabled $true -Force -UserPrincipalName $UPN

    }

     

    if($NewMailbox -eq $null){

    Write-Host "Could not get/create new mailbox object"

    quit

    }

     

    write-host ""

    $v = "Looking for existing ThrottlingPolicy 'MigrationPolicy_NoLimits'"

    Write-hostG $v

    write-host ""

    $pol = Get-ThrottlingPolicy -Identity 'MigrationPolicy_NoLimits'

     

    if($pol -eq $null){

    write-host ""

    Write-hostG "Creating a new throttling policy for use by the new user"

    write-host ""

    $Pol = New-ThrottlingPolicy 'MigrationPolicy_NoLimits'

    }

     

     

    if($pol -eq $null){

    Write-Host "Could not get/create new ThrottlingPolicy object"

    quit

    }

     

    write-host ""

    Write-hostG "Setting ThrottlingPolicy to RCAMaxConcurrency=0 and PowerShellMaxConcurrency=0"

    write-host ""

    Set-ThrottlingPolicy $pol -RCAMaxConcurrency $Null -PowerShellMaxConcurrency $Null

    write-host ""

    Write-hostG "Add new policy to user"

    Set-Mailbox $NewMailbox -ThrottlingPolicy $pol

    write-host ""

    Write-hostG "Getting domain local group Administrators..."

    write-host ""

    $Group = Get-Group "administrators"

    Write-hostG "Found domain local group Administrators"

    write-host ""

    write-host $group.grouptype

    $UserDN = $NewMailbox.distinguishedName

     

    $groupdn = $group.distinguishedName

    $GroupSvr = $group.OriginatingServer

    write-host ""

    Write-hostG "Binding to local administrators group via ADSI to add new user"

    write-host ""

    $g = New-Object -TypeName DirectoryServices.Directoryentry -ArgumentList("LDAP://$GroupSvr/$groupdn",$username, $Pass)

    Write-hostG "Bound to group via ADSI"

    write-host ""

    Write-hostG "Adding user " $UserDN

    write-host ""

    $g.member.add($userdn)

     

    Try {

    $g.psbase.CommitChanges()

    Write-hostG "User Added"

    write-host ""

    }

     

    Catch {

    if ($error -like "*The object already exists*"){

    write-hostg "User already a member"

    # Do nothing

    }

    else {

    write-host $error

    }

    }

    Finally {

    # Do nothing

    }

     

     

    Write-hostG "Locating exchange 2010 Org Object...."

    write-host ""

     

    $OClass = "msExchOrganizationContainer"

    [String]$StrFilter = "(objectClass=$OClass)"

    $objRootDSE = New-Object -TypeName DirectoryServices.Directoryentry -ArgumentList("LDAP://$GroupSvr/RootDSE",$username, $Pass)

    [String]$strContainer = $objRootDSE.configurationNamingContext

    [System.DirectoryServices.DirectorySearcher]$objSearcher = New-Object System.DirectoryServices.DirectorySearcher

    $objSearcher.SearchRoot = New-Object -TypeName DirectoryServices.Directoryentry -ArgumentList("LDAP://$GroupSvr/$strContainer",$username, $Pass)

    $objSearcher.PageSize = 1000

    $objSearcher.Filter = $strFilter

    $objSearcher.SearchScope = "Subtree"

    [System.DirectoryServices.SearchResult]$Result = $objSearcher.FindOne()

     

    [System.DirectoryServices.DirectoryEntry]$De = $result.GetDirectoryEntry()

    [string]$DnResult = $De.distinguishedName

     

     

     

    Write-hostG "Adding user to Org Object with Send-as and Receive-As"

    write-host ""

    Add-ADPermission -Identity $DNResult -User $UserDN -AccessRights ExtendedRight -ExtendedRights Send-As, Receive-As -InheritanceType All

    Write-hostG "Adding user to Org Object with Full Control"

    write-host ""

    Add-ADPermission -Identity $DNResult -User $UserDN -AccessRights GenericAll -InheritanceType All

     

     

     

     

    Write-hostG "Add new user with admin access to all mailbox databases"

    write-host ""

    Get-MailboxDatabase | Add-ADPermission -User $UserDN -AccessRights ExtendedRight -ExtendedRights Receive-As, ms-Exch-Store-Admin

     

    Write-hostG "Adding user to Recipient Management role group.."

    write-host ""

    Add-RoleGroupMember -Identity "Recipient Management" -Member $UserDN

    Write-hostG "Adding user to Public Folder Management role group.."

    write-host ""

    Add-RoleGroupMember -Identity "Public Folder Management" -Member $UserDN

    write-host ""

    Write-hostG "Done!"

    pause

  • Exchange 2010 Migration Setup Requirements

    The following outlines the requirments needed in order to migrate to Exchange 2010 using the Priasoft Migration Suite for Exchange, V6  

    Create a Windows account that has a Microsoft Exchange 2010 mailbox

    You must create a Windows® account with a Microsoft® Exchange 2010 mailbox so that the Windows account can authenticate with the Microsoft® Exchange Server.

    On the computer that hosts Microsoft Exchange 2010, log in using an administrator account that has the permission to create accounts (if this is a new installion this will be the account used to install Exchange 2010).

    On a computer that hosts the Microsoft® Exchange 2010 Management Shell, open the Microsoft Exchange Management Shell.

    Type the following command:

    New-Mailbox  -Alias 'MigrationAdmin' -Name 'MigrationAdmin' -Password 'password' -DisplayName 'MigrationAdmin' -ResetPasswordOnNextLogon $False -RemotePowerShellEnabled $true -Force -UserPrincipalName 'MigrationAdmin@YourDomain.com'

    • a) Verify that the Windows account is not a member of the Domain Administrators group and is a member of builtin Administrators in the Microsoft® Active Directory® domain.
    • b) To verify that you created the Windows account, log in to a computer using the new Windows account.

       

    Add the user to the Exchange 2010 Public Folder Management & Recipient Management role groups

    On a computer that hosts the Microsoft® Exchange 2010 Management Shell, open the Microsoft Exchange Management Shell.

    Type the following command:


    Add-RoleGroupMember -Identity "Recipient Management" -Member 'MigrationAdmin'

    Add-RoleGroupMember -Identity "Public Folder Management" -Member 'MigrationAdmin'

       

    Configure Microsoft Exchange 2010 permissions for the Windows account

    On a computer that hosts the Microsoft® Exchange 2010 Management Shell, open the Microsoft Exchange Management Shell.

    Type the following command:

    Get-MailboxDatabase | Add-ADPermission -User " MigrationAdmin " -AccessRights ExtendedRight -ExtendedRights Receive-As, ms-Exch-Store-Admin

    Add-ADPermission -Identity 'CN=(ORGNAME),CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=(DOMAIN),DC=(DOMAIN)' -User $UserDN -AccessRights ExtendedRight -ExtendedRights Send-As, Receive-As -InheritanceType All

    Add-ADPermission -Identity 'CN=(ORGNAME),CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=(DOMAIN),DC=(DOMAIN)' -User $UserDN -AccessRights GenericAll  -InheritanceType All

    Make sure to replace (ORGNAME) and (DOMAIN) with the correct values for your environment.
    (i.e. 'CN=Exch10,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Priasoft,DC=com)

    Turn off client throttling for Migration account in Microsoft Exchange 2010

    by default, Microsoft® Exchange 2010 uses client throttling policies to track the bandwidth that each Microsoft Exchange user consumes and enforce bandwidth limits. The policies affect the performance of the Priasoft® Migration Suite for Exchange negatively by limiting the number of mailboxes that can be migrated concurrently; therefore, you should turn off client throttling for the Windows® account being used by the migration.

    On a computer that hosts the Microsoft Exchange 2010 Management Shell, open the Microsoft Exchange Management Shell.

    Type the following commands:

    New-ThrottlingPolicy 'MigrationPolicy _NoLimits'

    Set-ThrottlingPolicy 'MigrationPolicy _NoLimits' -RCAMaxConcurrency $Null -PowerShellMaxConcurrency $Null

    Then type:

    Set-Mailbox " MigrationAdmin " -ThrottlingPolicy 'MigrationPolicy _NoLimits'

  • Priasoft's Mailbox Migration Manager

    Priasoft's Mailbox Migration Manager

    Recently I had a discussion with some of my fellow co-workers about some commonly asked questions, you know, the kind of questions that typically come up when considering using any third-party software. It gave us the idea for this blog, where we would be able to share some of our experiences and knowledge with you, the customer. This post shares some 'Frequently Asked Questions' and their answers of course, about Priasoft's Mailbox Migration Manager Version 5.4. The following dialogue is a conversation which took place between a customer and our Support team...


    Q. "During co-existence I would like to know whether the forwarding address is stamped to the migrated mailbox of the old SMTP name space."
    A. Priasoft ensures that all mail routing performs transparently to both migrated users and to users not yet migrated. We place X500 addresses from the Source mailbox on the contact we create, as well as on the new mailbox. We also place the X500 address of the contact we create on the Target mailbox. Furthermore, we take all secondary addresses from the Source mailbox and merge them with any address that may exist on the Target mailbox. By default the Target mailbox will have the same primary addresses as the Source had before migration. This behavior is controlled by a checkbox in the Mailbox Migration Manager Wizard.

    "Thanks for this, could you please let me know whether all the below features are supported parts of this migration,"

    Q. Calendar Synchronization from the Source and Target domain
    A. Priasoft does not provide a specific calendar sync tool. However, because we do bring all calendar items from Source to Target, each user’s calendar is actually repopulated. There is not a specific need for a calendar sync tool. As users update and/or create new calendar items, meeting notices are sent to the attendees. There is NO LIMITATION of the product by adding unnecessary replication/synching tools such as a calendar sync tool.

    Q. Public folder replication along with the permissions
    A. Priasoft provides the Public Folder Migration Manager (PFMM). This application can incrementally bring data from Source to Target as is seen fit by the admin. It is not an automatic sync tool but is a migration tool. PFMM provides the following features: Copy folders, data, permissions, email address, and rules from Source to Target Public Folder stores. It can export folder ‘event scripts’ if any exist, and can add new permissions to Source and/or Target folders. For more automatic replication of data, Priasoft recommends the Microsoft Public Folder InterOrg Replication Tool. This is a supported product from Microsoft.

    Q. Free / Busy schedule information from Source and Target domain
    A. As in reference to above, Priasoft does not provide an automatic replication tool for public folders. It is our recommendation to use the Microsoft Public Folder InterOrg Replication Tool for syncing information, including Free/Busy data. Realize too that the necessity to sync such information is often driven by the duration of the migration. If the migration is such that it can be completed within a few days, the burden and overhead of a replication engine is really unwarranted due to the fact that once all users are in the new organization, Outlook/Exchange will rebuild the Free/Busy data automatically. Free/Busy sync is only necessary when there will be organizers in both organizations that absolutely require the ability to lookup Free/Busy status of non-local attendees.

    Q. Unified Global Address list (GAL) of both the domain users
    A. Priasoft does not provide a ‘GAL sync’ tool at this time. Although one is in development, its timeline is still approximately 6 months away. However, note that no such synching tool is required for migration. This is often a requirement of business process when the migration will take considerable time (weeks instead of days). In most cases organizations already have directory sync tools in place and as such Priasoft will never require such to be replaced by a more proprietary version. Also realize that as users’ mailboxes are migrated into the new organization the GAL is automatically updated with that information.

    Q. Outlook client rules along with the new user profile update
    A. One of Priasoft’s strengths is the transparency it provides to the Outlook/Exchange end user. Rules are migrated and also translated, meaning that the rules are ‘re-created’ in the Target in order to ensure that rules will actually work in the new mailbox. Priasoft provides tools to update Outlook profiles. Updating existing profiles, versus creating new profiles, is important because all non-exchange related features of the profile will remain intact.

    Q. Co-existence Support
    A. Priasoft supports co-existence by creating ‘forwarding objects’ in the Source directory for migrated mailboxes. These objects (contacts in ActiveDirectory, custom recipients in Exchange 5.5) contain all the same attributes as the original Source mailbox (display attributes such as First and Last name as well as Exchange attributes such as Custom Attrributes). The specific implementation provides a situation where any inbound mail, either externally (e.g. SMTP from internet) or internally, are properly routed to the new mailbox. Furthermore, Priasoft will add the forwarding object to the same Distribution Lists that the original Source mailbox was a member of.

    Q. Mailbox Migration
    A. Of Course! This is one of the aspects we excel at.

    Q. Outlook profile updates
    A. The simple answer is ‘yes’.
All Material is Copyright 1998-2007, Priasoft.Inc. This website, including www.priasoft.com, and www.exchangemigrationexperts.com, and all of the information they contain are not to be reproduced in any form, electronic or otherwise without express written consent of Priasoft.