MicrosoftLearning / AZ-120-Planning-and-Administering-Microsoft-Azure-for-SAP-Workloads

Labs for AZ-120 Planning and administering Microsoft Azure for SAP workloads
MIT License
64 stars 87 forks source link

AZ-120_Lab03b-SQL_HA_Infrastructure_Deployment.md - workaround to deploy failure #56

Closed TesterTesterson1004 closed 10 months ago

TesterTesterson1004 commented 1 year ago

In this lab, Exercise 1, Task 1, Step 6, I have run multiple tests last week and the week previous where the deploy would fail every time, and the process documented to workaround the issue (removing extensions on the DCs) didn't succeed in getting me past the failure.

Unlike earlier labs with a similar failure, in this lab the failure occurred once for the PDC (and the workaround of removing the extension allowed an attempt at a redeploy) however this time I always received a second failure - this time on the BDC. This time, the recovery process could not be implemented because the redeploy insisted on the '_artifacts location Sas token' field be populated before proceeding, and I found no place to identify a value for that field.

image

I believe it was mentioned that this course may be getting some deploy instructions updates at some point in the future using bicep (at which point this issue may become moot) but at least for now - literally the only way I was able to proceed past this issue in this lab was to implement the following workaround:

-In place of the stock Quickstart template referenced in Exer 1/Task 1, I instead used the https://aka.ms/az120-1bdeployzone link referenced in earlier labs.

-Using that template, I also used the given values for Exer 1/Task 1/Step 6 as-written, with the exception of '_artifacts location', in which I used: https://raw.githubusercontent.com/polichtm/azure-quickstart-templates/master/application-workloads/active-directory/active-directory-new-domain-ha-2-dc-zones/

While this deploy still had a consistent single deploy failure, the currently-noted recovery process of uninstalling the extension and then redeploying succeeded - consistently - without the dual-failure.

May be worth investigating this workaround and potentially validating/adding to the current Instructions (unless a more reliable bicep-based install process is going to be incorporated in the very near future) as otherwise I found no way to proceed past this first task in repeated testing attempts, thus making the balance of the lab untestable/unusable.

polichtm commented 1 year ago

Really appreciate the input. There is actually a pending PR that we should be merging into the main branch shortly - others are to follow... rgds Marcin

Kiyani1 commented 1 year ago

Really appreciate the input. There is actually a pending PR that we should be merging into the main branch shortly - others are to follow... rgds Marcin

Hi @polichtm any update regarding this issue?

polichtm commented 10 months ago

this has been addressed - you can either ignore the current error (the resulting deployment is fully functional) or remediate it by following the updated instructions. rgds Marcin