Menu
Hi Exchange_Support,
I wouldn't remove users from a migration batch and create a new batch. If these users failed halfway on their migration, removing and adding them to a new batch could bring item duplication issues. Do that if these users have 0 items synced. Regardless of which, you really do not have to remove failed users and create a new migration batch. Simply starting the failed batch again would suffice. But, it is advised to check the reason why the mailboxes were failed in the first place and take corrective actions so that they won't fail again. You can use the Exchange Admin Center for this task, or use the PowerShell to do that.
If you're using the Exchange Admin Center, follow below steps to find out the reason users failed.
- Exchange Admin Center -> Recipients -> Migration - View Details
- From the Migration User pop-up, select each failed user and observe the error.
If you're using PowerShell, using below command you can export a CSV of the migration batch users. Investigate the errors in the file and take remediation actions.
$list = Get-MigrationUser -BatchId 'abcd' | select Identity,SyncedItems,Status,ErrorSummary | Format-Table
$list | Export-Csv C:MigrationReport.csv
$list | Export-Csv C:MigrationReport.csv
*Change 'abcd' and 'C:MigrationReport.csv' values as appropriately.
Let us know how it works.
Thank you.
Posted by1 year ago
Archived
Hey there,
I've recently taken over the process of performing Migration Batches for my company's migration to Exchange Online. We have Exchange 2010 on-prem and are in a hybrid configuration currently. We've done a few successful migrations with no issues.
This may be a silly question, but I saw in MS's documentation that the best practice is to delete the Migration Batches after they're complete to avoid errors if the same user gets migrated again (?). Just to be clear then, what is actually being deleted when you delete the migration batch? It says it could take several hours to complete. (I assume) this obviously wouldn't delete the successfully migrated mailboxes but I still am slightly nervous haha. Is it deleting an extra copy of the files that were synced over or something? Is there anything that could go wrong here?
Just trying to get a better understanding of what is going on behind the scenes.
Thank you!
2 comments
--> This cmdlet is available in on-premises Exchange and in the cloud-based service. Some parameters and settings may be exclusive to one environment or the other.
Use the Remove-MigrationUser cmdlet to remove a migration user from a batch.
For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax (https://technet.microsoft.com/library/bb123552.aspx).
Use the Remove-MigrationUser cmdlet to remove a migration user from a batch.
For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax (https://technet.microsoft.com/library/bb123552.aspx).
Syntax
Description
You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet (https://technet.microsoft.com/library/mt432940.aspx).
Examples
-------------------------- Example 1 --------------------------
This example removes the migration user Tony Smith from a migration batch.
Parameters
The Confirm switch specifies whether to show or hide the confirmation prompt. How this switch affects the cmdlet depends on if the cmdlet requires confirmation before proceeding.
- Destructive cmdlets (for example, Remove-* cmdlets) have a built-in pause that forces you to acknowledge the command before proceeding. For these cmdlets, you can skip the confirmation prompt by using this exact syntax: -Confirm:$false.
- Most other cmdlets (for example, New-* and Set-* cmdlets) don't have a built-in pause. For these cmdlets, specifying the Confirm switch without a value introduces a pause that forces you acknowledge the command before proceeding.
Type: | SwitchParameter |
Aliases: | cf |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online |
This parameter is available only in on-premises Exchange.
Exchange Migration Batch Stuck Syncing
The DomainController parameter specifies the domain controller that's used by this cmdlet to read data from or write data to Active Directory. You identify the domain controller by its fully qualified domain name (FQDN). For example, dc01.contoso.com.
Type: | Fqdn |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
This parameter is available only in on-premises Exchange.
The Force switch specifies that some specific checks and removal steps should be skipped and that the migration user should be forcibly removed. This parameter is used to work around issues where the migration user needs to be removed to fix issues when the user or data is corrupted, or to prevent such issues from occurring.
Type: | SwitchParameter |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
The Identity parameter specifies the user that you want to remove from the migration batch.
Type: | MigrationUserIdParameter |
Position: | 1 |
Default value: | None |
Accept pipeline input: | True |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online |
This parameter is available only in the cloud-based service.
This parameter is reserved for internal Microsoft use.
Type: | MailboxIdParameter |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Online |
The WhatIf switch simulates the actions of the command. You can use this switch to view the changes that would occur without actually applying those changes. You don't need to specify a value with this switch.
Type: | SwitchParameter |
Aliases: | wi |
Position: | Named |
Default value: | None |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online |
Inputs
To see the input types that this cmdlet accepts, see Cmdlet Input and Output Types (https://go.microsoft.com/fwlink/p/?linkId=616387). If the Input Type field for a cmdlet is blank, the cmdlet doesn't accept input data.
Outputs
To see the return types, which are also known as output types, that this cmdlet accepts, see Cmdlet Input and Output Types (https://go.microsoft.com/fwlink/p/?linkId=616387). If the Output Type field is blank, the cmdlet doesn't return data.
Related Links
I'm using EF 6.0 for my project in C# with manual migrations and updates. I have about 5 migrations on the database, but I realised that the last migration was bad and I don't want it. I know that I can rollback to a previous migration, but when I add a new (fixed) migration and run Update-Database, even the bad migration is applied.
I was trying to rollback to the previous migration and delete the file with bad migration. But then, when I try to add new migration, I get error when updating database, because the migration file is corrupted (more specifically, first line of code rename the table A to B and is next lines, EF is trying to update table with name A - maybe it is some EF bug).
Is there some query I can run, which would tell EF something like 'Forget last migration like it never existed, it was bad'? Something like Remove-Migration.
Edit1I found solution suited for me. Changing model to the good state and run
Add-Migration TheBadMigration -Force
. This will re-scaffold the last, not applied migration.Anyway, this still not answer the original question completely. If I UpdateDatabase to the bad migration, I did not found good way how to rollback and create new migration, excluding the bad one.
Thanks
Luke McGregor24.1k1313 gold badges101101 silver badges159159 bronze badges
Martin BrabecMartin Brabec1,45422 gold badges1818 silver badges2323 bronze badges
7 Answers
You have 2 options:
- You can take the Down from the bad migration and put it in a new migration (you will also need to make the subsequent changes to the model). This is effectively rolling up to a better version.I use this option on things that have gone to multiple environments.
- The other option is to actually run
Update-Database –TargetMigration: TheLastGoodMigration
against your deployed database and then delete the migration from your solution. This is kinda the hulk smash alternative and requires this to be performed against any database deployed with the bad version.Note: to rescaffold the migration you can useAdd-Migration [existingname] -Force
. This will however overwrite your existing migration, so be sure to do this only if you have removed the existing migration from the database. This does the same thing as deleting the existing migration file and runningadd-migration
I use this option while developing.
24.1k1313 gold badges101101 silver badges159159 bronze badges
As the question indicates this applies to a migration in a development type environment that has not yet been released.
This issue can be solved in these steps, the first step is to restore your database to the last good migration and then next delete the bad migration from your Entity Framework project, at this point, you will be able to generate a new migration and apply it to the database. Note: Judging from the comments these exact commands may no longer be applicable if you are using EF Core.
Step 1: Restore to a previous migration
To restore your database schema to a previous point use the:
Specifying the last good migration. If you haven't yet applied your migration you can skip this part.
Use the Get-Migrations command to get a list of the migration names that have been applied to your database.
This list shows the most recent applied migrations first. Pick the migration that occurs in the list after the one you want to downgrade to, ie the one applied before the one you want to downgrade.
All migrations applied after the one specified will be down-graded in order starting with the latest migration applied first.
Step 2: Delete your migration from the project
You now can delete the bad migration from your EF project 'Migrations' folder. At this point, you are free to create a new migration and apply it to the database.
Step 3: Add your new migration
Step 4: Apply your migration to the database
David SopkoDavid Sopko
For those using EF Core with ASP.NET Core v1.0.0 I had a similar problem and used the following commands to correct it (@DavidSopko's post pointed me in the right direction, but the details are slightly different for EF Core):
For example, in my current development the command became
The Remove-Migration will remove the last migration you applied. If you have a more complex scenario with multiple migrations to remove (I only had 2, the initial and the bad one), I suggest you test the steps in a dummy project.
There doesn't currently appear to be a Get-Migrations command in EF Core (v1.0.0) so you must look in your migrations folder and be familiar with what you have done. However, there is a nice help command:
Refreshing dastabase in VS2015 SQL Server Object Explorer, all of my data was preserved and the migration that I wanted to revert was gone :)
Initially I tried Remove-Migration by itself and found the error command confusing:
System.InvalidOperationException: The migration '..' has already been applied to the database. Unapply it and try again. If the migration has been applied to other databases, consider reverting its changes using a new migration.
There are already suggestions on improving this wording, but I'd like the error to say something like this:
Run Update-Database (last good migration name) to revert the database schema back to to that state. This command will unapply all migrations that occurred after the migration specified to Update-Database. You may then run Remove-Migration (migration name to remove)
Output from the EF Core help command follows:
Richard LogwoodRichard Logwood
First, Update your last perfect migration via this command :
Example:
And, then delete your unused migration manually.
Abdus Salam AzadAbdus Salam Azad
As of .NET Core 2.2,
TargetMigration
seems to be gone:So this works for me now:
As well as (no
-Migration
switch):On an added note, you can no longer cleanly delete migration folders without putting your Model Snapshot out of sync. So if you learn this the hard way and wind up with an empty migration where you know there should be changes, you can run (no switches needed for the last migration):
It will clean up the mess and put you back where you need to be, even though the last migration folder was deleted manually.
Sum NoneSum None51422 gold badges99 silver badges2121 bronze badges
For EF 6 here's a one-liner if you're re-scaffolding a lot in development. Just update the vars and then keep using the up arrow in package manager console to rinse and repeat.
Estnod 12.1.31 product key. Why is this necessary you ask? Not sure which versions of EF6 this applies but if your new migration target has already been applied then using '-Force' to re-scaffold in Add-Migration will not actually re-scaffold, but instead make a new file (this is a good thing though because you wouldn't want to lose your 'Down'). The above snippet does the 'Down' first if necessary then -Force works properly to re-scaffold.
madamissionmadamission
You can also use
This will revert and remove the last applied migration
Daniël TulpDaniël Tulp92922 gold badges1313 silver badges4545 bronze badges