D365FFO On-Prem: Suggestions Based On A Few Installs

After running through a few installs, I have come up with a simple list of suggestions to help streamline the process and eliminate a little of the headache. For reference, these are the official steps to follow from MS for PU12 can be found here.

Install Azure Powershell Extentions On Template (also, use a template)

You should build a template in your VM environment then duplicate and prep it for use. While building your template you should install the Azure Powershell extensions which can be found here.

In short, run these two commands as an admin:

Install-Module PowerShellGet -Force

Install-Module -Name AzureRM -AllowClobber

This isn't required but it will let any node in your cluster interact with Azure as needed during the install so each node is interchangable from that perspective. Once you start specializing a node, you have to start remembering / documentating that specialization so let's make everything the same as much as we can.

Disable UAC Manually On Template

Again, more preperation. The powershell scripts as part of the install will attmpt to do this but can sometimes report false positives. I have had instances where UAC was reported as disabled by the Powershell scripts but it was still enabled and some cert installs failed as a result. So, let's just keep things simple and manually disable it on the template.

Install Prereqs Using Scripts, Reboot, Re-run Scripts, Reboot, Continue Cycle Until Scripts Don't Install Anything

The steps from MS for preparing the individuals nodes for their duties are somewhat laissez-faire about how to run the prereq scripts. For reference, the step I am referring to can be found here. When you run the following:

.\Configure-PreReqs.ps1 -MSIFilePath <path of the MSIs>

You should run it, reboot, run it again, reboot, run it again then do a final reboot. More than likely overkill but I have not initiated reboots and later got false positives that something wasn't installed or configured correctly. Depending on the node type, this script may not do much. For instance, the AOS node type will require at least 3 reboots for this but the Orchestrator will only require one. If this script installs anything, no matter how small, reboot and re-run. There seems to be some issues with the powershell scripts giving false negatives and positives depending on what it is checking so this is being more proactive in management of that.

Use A Single Domain Admin Account For All Of The Install

We initially tried to run most of the install under a local admin account on a few occasions. A local admin account will work for most, but not all, steps of the install. So rather than manage when a local admin or domain admin account is required, create a domain admin account to run the entire install and protect all certs to that users. This should be a user different than the service account that will run the AOS. In MS's example, the domain account is Contoso\AXServiceUser so create Contoso\AXAdminUser to run it from that.

ProtectTo Certs To Domain Admin Account Running Install Plus Shared Account (LIke Administrator)

In the ConfigTemplate.xml file, you have the option to ProtectTo your self-signed certs. Specify the user account that will be running the entire install plus a shared admin account that IT management has available to it. This may be domain\administrator or some other account but you'll want at least 2 ProtectTo accounts specified.

Add The AOS Service User As A Local Admin on AOSs 

This is a specific issue related to false negatives. When you run 

.\Test-D365FOConfiguration.ps1

On the AOS Nodes, you will get an error that your specified service user isn't a local admin even if it is already a domain admin. Domain admin infers local admin but that scripts don't seem to pick up on that so once you have your VMs build and node types specified, you'll need to add your service user as a local admin specifically to not get a false positive on this test script. In the example from MS this account is called Contoso\AXServiceUser.

Add The AOS gMSA Account As A Local Admin on AOSs

Similar to the last entry, you'll get the same error when running the test script for the node so also add your gMSA account as a local admin. In the example from MS, this account is called Contoso\svc-AXSF$.

Copy Client Cert From Trusted Zone To Personal Store 

This appears to be a bug of some sort but I haven't fully run it down. After you successfully create a service fabrix cluster, if you try to navigate to it by going to the DNS addresss for it, sf.d365ffo.onprem.contoso.com in the example from MS, you get a 403 error. If you open the local cert store for the current users can copy/paste the client cert, to the current users personal store, close and reopen IE then try again, you can get to the service fabric cluster. I'm not sure if this is because I have been using self signed certs. When you attempt to login for the first time, you should be asked which cert you want to use. If you get this prompt, select the client cert.