Closed melissa306HC closed 3 years ago
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @srinathvasireddy.
I involve Recovery Service team to look into this issue.
Hello melissa306HC, I encountered the same error, I managed to get around this by performing the following:
$AnotherInstanceWithFullConfig.OverwriteWLIfpresent = "Yes"
$AnotherInstanceWithFullConfig.RestoredDBName = "MSSQLSERVER/newtestdatabase_renamed"
$AnotherInstanceWithFullConfig.targetPhysicalPath[0].TargetPath = "F:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\NewDatabase.mdf" $AnotherInstanceWithFullConfig.targetPhysicalPath[1].TargetPath = "F:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\NewDatabase_log.ldf"
The Target Path seems to be indexed as part of an array. After checking the config after this using the: $AnotherInstanceWithFullConfig.targetPhysicalPath, this seems to have corrected it.
If you check this with the: $AnotherInstanceWithFullConfig.targetPhysicalPath
You can check the paths: for example mine where:
MappingType SourceLogicalName SourcePath TargetPath
Data NewDatabase F:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\NewDatabase.mdf F:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\NewDatabase.mdf
Log NewDatabase_log F:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\NewDatabase_log.ldf F:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\NewDatabase_log_1588595967.ldf
Not sure if this is of help.
Kind regards,
Ray
thank you for the reply Ray - i found out that it didn't like the restored database name i was passing in. I removed the "MSSQLSERVER/" from the name and the script worked.
@melissa306HC : Sorry for the delay in response. While it is good to know that things have worked for you, I agree that the response message can be more specific here. Will look into this and let you what we can do about this.
@melissa306HC : We are still working on how to provide the specific error message instead of generic one. Will update the thread with the date of fix soon.
We are still following up for an ETA to improve the error message.
We have identified the issue but the solution is taking more time than intended. We will add it to our backlog, but the ETA would not land within this calendar year. Closing this issue for now, will update this when we have more details
Description
Running Restore-AzRecoveryServicesBackupItem and passing in the config file returns an generic error: UserErrorOperationFailedInvalidParameters. The configuration parameter used to work just fine and suddenly stopped working last fall. The error does not specify what parameter(s) are invalid. A more specific error would be helpful.
Steps to reproduce
Use Get-AzRecoveryServicesBackupWorkloadRecoveryConfig to set the Config Parameter change values in configuration Run Restore-AzRecoveryServicesBackupItem -WLRecoveryConfig passing in updated config parameter
Environment data
Module versions
Debug output
Error output