cancel
Showing results for 
Search instead for 
Did you mean: 

Server migration wizard partition error

Laura
Level 3

Using the server migration wizard to migrate from Server 2008 11.0.1 to Server 2016 12.3.

Got to the part where it verifies partitions, and one of my 5 partitions is giving an error. The partition is not the current open partition. The error message in the log file doesn't really make sense to me:

Partition entry [105491E4A98C1D44EAA458F9B20A5F2EE1q10000evsite] does not match target partition entry [141BA74CE38981240A99B58BBF34A4ADE1q10000evsite]
7/14/2018 2:50:23 PM Partition Exchange Store 1 Ptn 4, location PartitionDataLocation, folder D:\Enterprise Vault Stores\Exchange Store 1 Ptn 4 is invalid

1. The location d:\Enterprise Vault Stores\Exchange Store 1 Ptn 4 ----- this is valid and is where the partition exists on both source and target.

2. Partition Entry [105491E4....] is the partitionentryID of another partition (Ptn 2, if it matters). The target partition entry [141BA...] is the one associated with Ptn 4. Why would Ptn 2 need to match target partition Ptn 4??

The only thing remotely different about the partition is that there's a space between "Ptn" and "4" while the others don't have that. The space does exists on both source and target. Any ideas?

EVpartitions.PNG

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

ChrisLangevin
Level 6
Employee

The mismatch it's complaining about is between the PartitionEntryId in SQL and the one recorded in the EnterpriseVaultPartitionRoot.xml, which resides in the partition root path (in your case, inside the "Exchange Store 1 Ptn 4" folder).

In your case, the value in the XML file is 105491E4A98C1D44EAA458F9B20A5F2EE1q10000evsite, which, as you said, actually corresponds to another partition.

I would double-check that you copied the data for Ptn 4 correctly, as the most likely cause would be if you copied the data from the Ptn2 folder on the source server into the Ptn 4 folder on the destination server (since the EnterpriseVaultPartitionRoot.xml is part of that data). If you are certain that the partition data was copied correctly, then either go manually copy the correct EnterpriseVaultPartitionRoot.xml from the source partition, or just edit the PartitionEntryId in the XML file to be the correct one for Ptn 4.

 

--Chris

View solution in original post

7 REPLIES 7

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

Hello Laura,

I assume you used the browse button on the target to reselect the folder on disk it is supposed to be in. Does that then also fail verification? If you select for ALL your partitions the location manually (even the correct ones), and then reverify, does that then work?

Thx. GJ

 

Regards. Gertjan

CConsult
Moderator
Moderator
Partner    VIP   

Hi,

could also be a permission problem. If the wizard cannot access the partition he will also show it as failed.

Have you changed anything after moving/copying the partitions?

Yes, I tried the browse button and that didn't work.

I just tried using the browse button to select the partitions that had been successfully verified and they remained successful even after using the browse button.

I had looked at permissions and that didn't seem to be an issue.

On the source server, the permissions for each partition folder were varied and not consistent. On the target server, the permissions were all the same between partition folders.

I didn't do anything other than select the root directory for the partitions and copy the whole thing over -- checked the copy and the file/folder count matched up. I also re-copied that particular partition after first encountering issues.

It's odd that the only one having the issue is named slightly differently (an extra space) though I don't understand how that could have any effect. And that the error message seems to equate the second partition with the fourth partition (the fourth being the one that's having issues). I'm tempted to rename the partition on the source (which is now reverted back to a working production installation) and see if that fixes it -- thinking that there's something gone awry in the database rather than it specifically having an issue with the extra space in the partition/folder name.

 

ChrisLangevin
Level 6
Employee

The mismatch it's complaining about is between the PartitionEntryId in SQL and the one recorded in the EnterpriseVaultPartitionRoot.xml, which resides in the partition root path (in your case, inside the "Exchange Store 1 Ptn 4" folder).

In your case, the value in the XML file is 105491E4A98C1D44EAA458F9B20A5F2EE1q10000evsite, which, as you said, actually corresponds to another partition.

I would double-check that you copied the data for Ptn 4 correctly, as the most likely cause would be if you copied the data from the Ptn2 folder on the source server into the Ptn 4 folder on the destination server (since the EnterpriseVaultPartitionRoot.xml is part of that data). If you are certain that the partition data was copied correctly, then either go manually copy the correct EnterpriseVaultPartitionRoot.xml from the source partition, or just edit the PartitionEntryId in the XML file to be the correct one for Ptn 4.

 

--Chris

Yes! The EnterpriseVaultPartitionRoot.xml file had been copied from the other partition for some reason. I edited the xml file with the correct PartitionID and everything's green.

Thank you so much!

Laura.

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

Simple like that :)

Laura, just to be sure (because I would be) are you certain the data in that partition IS indeed the data from the old corresponding partition?

Regards. Gertjan