ECC memory requirementsfor Azure Stack HCI, version 23H2

Hello @Aaron Parker
Appreciate the feedback, I have passed it on to the concerned product team. Regarding the validation check, I am not completely sure when it was added. I did ask this to our product team. I will keep you posted once I hear from them

I also second Aarons comment's. I used to deploy 23H2 HCI on VMs in our demo lab but since last week, this new validation came into effect and is preventing the Cloud Deployment on virtual machines. Labs are a critical part of the learning process and also useful for our sales cycle and POCs. Please provide an alternative way to bypass this validation so we can continue to use 23H2 in our demo environments

Hendrick Lorentz

I had a quick discussion with the product team. Per them, the ECC check has been in for quite a while for all 23H2 deployments.  The suggestions is that customers can deploy it virtually on that hardware where we do not enforce the requirements as virtual deployments are not supported for production.

 Deploy a virtual Azure Local, version 23H2 system - Azure Local | Microsoft Learn

Azure MVP here who loves to play around with Stack HCI in his home lab as well.

Please relax the ECC requirement, or give us an option to bypass it. This was previously not required, so why make it required now?

Hi Nathan

Thanks for the feedback. I am discussing this product team. I will keep this thread posted with the details.

@Prrudram-MSFT Thank you for you attention to this, it's definitely appreciated. I'd also like to point out that the suggestion to deploy virtually also appears to be broken. I've not personally tried this yet, but according to @Hendrick Lorentz post above, this is also failing on VMs as well.

But VMs aside, I'd also argue that deploying virtually kind of misses a lot of the point of an Azure HCI deployment in a lab. The hardware is a large part of the equation, especially in a hyperconverged setup. You are missing much of the real-world applications when doing this solely via VM.

Hi Aaron Parker thanks for your feedback. I work for an OEM HW vendor and we do lots of ASHCI deployment on physical servers but we use VMs for our training labs. Since all our kit has ECC modules this new requirement is not an issue on physical servers with ECC memory but only appears on VM as the memory gets reported as non-ECC even though is running on kit that has ECC memory modules. Having the ability to bypass this ECC requirement for our virtual labs would really be helpful especially because that was the way it worked before the recent changes.

Hi guys, quick follow up! @Prrudram-MSFT Has there been any updates on this request? Any idea of timeline (if any) to have the ability to bypass ECC checks?

Hi all,

Thanks for your cooperation and understanding. I am in discussion with the product team, we would need some time to address this question here. Please standby while I get back.

Hi, Microsoft has removed bugged version ( 1.2100.2845.573 ) of AzStackHci.EnvironmentChecker module from PS Gallery.

I forced install the previous stable version ( 1.2100.2790.560 ) whit command

Install-Module -Name AzStackHci.EnvironmentChecker -Force

and now works fine!

Thanks for that info. I will try it in our lab

Echoing comments on ECC above. Want to spin this up in my home lab and ECC kills it.

I've been able to successfully get past the environment checker by either reverting the AzStackHci.EnvironmentChecker module on the installer node, or editing the check in the installed version of the PowerShell module itself.

Hi, unfortunatly my workarount not working. The module used by checker is related to LCM controller that download the latest (bugged) version. We wait the official Microsoft FIX

Same issue here. please keep us posted!

Hello! I want to add my voice to the choir for relaxing the ECC requirement.

It is extremely valuable to install Windows Server and Azure Stack HCI on normal PC hardware in a home lab environment.

I think its important to encourage home lab scenarios for building a community around the product. Proxmox currently gains a lot of attention much because of how easy it is to use in home labs and then enthusiasts tries to bring that to the real datacenter even despite it not being enterprise-ready.

I have found a workaround for now to get around de ECC memory check.

It's a bit dirty but it works.
Please see https://www.linkedin.com/pulse/azure-local-vmware-esxi-workaround-ecc-memory-check-marcel-braak-8wede/

Hello Everyone,

I have taken this with product team, they are working on finding a way. As of now there is no ETA on this, I would recommend looking at some of the workarounds shared on this thread.

Marcel,

The workaround you linked is not necessary. Make sure that when you install the older version of the powershell module, you're uninstalling the .573 version, and installing the .560 with a -scope AllUsers. I also deleted the nuget package from the C:\nugetstore folder to confirm that when re-running it wasn't downloading again.

If even that isn't working for you, like I mentioned, it'd be better to edit the specific ECC check, rather than removing the hardware checker as a whole. I don't recall which file it was in, but if you search the main environmentchecker powershell file for "ECC", you can edit the check from "-gt" to "-eq" to make it report non-ecc memory as ECC memory.

David,

Thanks for your reply.

I tried your method however this doesn't seem to work. Installing the old version for allusers and deinstalling the new one does work when running the hardware validation manually (Invoke-AzStackHciHardwareValidation) but not for the deployment. Also deleting the package from the C:\nugetstore directory will result in an error the package can not be found in this directory by the deployment process.

The reason i chose to change the xml file and remove the check is that i can't edit the powershell scripts themselves because they are signed.

Also i have to mention the network validation step (which comes after the hardware valiadation) will also fail because it checks if all network interfaces are physical interfaces (which will fail in a virtual machine)

So it seems Microsoft did a lot of work to prevent homelab test environments running virtual it seems. ;(

Marcel,

I did notice that they were signed, but none of the executions are actually checking the signatures, so it doesn't really matter. I just worry that recommending disabling the entire hardware validator will lead to some people being able to run the install on actually unsupported hardware.