Import-SPMetadataWebServicePartitionData error in multi server deployment
Before reading this post I would request you to first read my following posts for moving TermStore from one environment to another and support available in Windows PowerShell commands.
When I posted that blog post, I did all my tests on a single server deployment. Recently my colleague was trying to run the same commands on a multi-server deployment. He was using following command to import TermStore:
Import-SPMetadataWebServicePartitionData -Identity $mms2.Id -ServiceProxy $mms2proxy -path "C:\ mmsdev.bak" -OverwriteExisting;
He got following error message on running the command:
Import-SPMetadataWebServicePartitionData : Cannot bulk load because the file "C:\99f6833d2bac4c53af26b816afca1d55\ECMGroup.dat" could not be opened. Operating system error code 3(failed to retrieve text for this error. Reason: 15105).At line:1 char:41+ Import-SPMetadataWebServicePartitionData <<<< -Identity $mms2.Id -ServiceProxy $mms2proxy -path "C:\Veda\mmsdev.bak" -OverwriteExisting;+ CategoryInfo : InvalidData: (Microsoft.Share...cePartitionData: SPCmdletImportM...cePartitionData) [Import-SPMetadataWebServicePartitionData], FaultException'1 ``+ FullyQualifiedErrorId : Microsoft.SharePoint.Taxonomy.Cmdlet.SPCmdletImp ortMetadataWebServicePartitionData
Operating system error code 3 means system is not able to locate the file at path mentioned in command. This command uses BULK UPLOAD functionality and it's not able to find the file at specified path when using BULK Upload from SQL Server database. I reached this conclusion as it was working fine on single box deployment. Thereafter I specified network path to the TermStore backup file instead of local path. I started getting a new error (Operating system error code 5). This is an error code for access denied which meant that code is not allowed to access the file location. Since BULK Upload command is run by SQL Server Service account, I tried to give access to that account. I kept getting the same error message even if I gave Everyone group access to the share. I'm still not able to find the reason why it's giving access denied.
To work around, instead of keeping file on Application Server, I kept it on SQL Server box and used the network path to the file in command. You have to give read write access to this share as PowerShell creates temporary files while importing TermStore. After this the command worked as expected and we were able to import TermStore succesfully. I hope this post will help you save some time.
Comments
Anonymous
March 24, 2011
fantastic, exactly the problem we had .. would have been good to know exactly why it behaved this way, but a workaround is the next best thing, thanks!Anonymous
December 19, 2011
I Love youAnonymous
February 02, 2012
The comment has been removedAnonymous
March 31, 2014
yes it works in 2013 as well. awesome post. thanks !!!