xExchDatabaseAvailabilityGroupMember: Remove Windows Failover-Clustering check while adding DAG member

[malauter]

Pull Request (PR) description

While adding a server as a new member to a DAG, Exchange automatically installs the necessary Windows Failover-Clustering role. So no need to install it before. If it is installed before, adding the server to the DAG sometimes fails because the cluster service is already running. Therefore I removed the check if the role is installed before running Add-DatabaseAvailabilityGroupServer.

This Pull Request (PR) fixes the following issues

None

Task list

• [ x] Added an entry under the Unreleased section of the change log in the CHANGELOG.md. Entry should say what was changed, and how that affects users (if applicable).
• [ ] Resource documentation added/updated in README.md.
• [ ] Resource parameter descriptions added/updated in README.md, schema.mof and comment-based help.
• [ ] Comment-based help added/updated.
• [ ] Localization strings added/updated in all localization files as appropriate.
• [ ] Examples appropriately added/updated.
• [ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
• [ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
• [ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

---

This change is 

[mhendric]

Hi @malauter , thanks for the submission! So, I "think" that Exchange only adds the Failover Cluster role during setup if you also specified the optional 'InstallWindowsComponents' switch (or checked the corresponding GUI setup box). I think that the code being removed in this PR would still be useful for situations where someone didn't choose that setup route. What do you think? Also, I'm having a hard time envisioning why removing this code helps if the cluster is installed and the service is already running. Can you elaborate on how you think this fixes the issue?

[malauter]

Hi @mhendric, AFAIK Exchange always adds the Failover Cluster role as soon as you add the server to a DAG (not during setup). This happens independently if InstallWindowsComponents switch was used during setup or not. Of course this change does not help if somebody has installed the Failover Cluster role manually before adding the server into a DAG. But without this change it is necessary to install it to make the DSC resource work. Neither in the Exchange prerequsites (list of Windows features/roles) (https://docs.microsoft.com/en-us/exchange/plan-and-deploy/prerequisites?view=exchserver-2016#windows-server-2016-prerequisites-for-exchange-2016) nor in the doc about creating a DAG and adding members (https://docs.microsoft.com/en-us/exchange/high-availability/manage-ha/create-dags?view=exchserver-2019) I can find something that it would be necessary to install the Failover Cluster role manually before adding a new member, so it will be installed automatically when you add a server.

[mhendric]

Hey @malauter , sorry for the really late response. I think you may be right that none of the Exchange documentation discusses pre-installing the cluster feature at any point before adding a DAG member. So this change probably makes sense. However, after the call to Add-DatabaseAvailabilityGroupMember in Set-TargetResource, we may want to re-check if the cluster is in a state of InstallPending, or if the server was actually successfully added as a DAG member, and possibly require a reboot or throw an exception. Would you be able to add that functionality too? The InstallPending check can probably be turned into a re-usable function. Thanks.

[mhendric]

@malauter , can you update the base branch of this to point to Master per step 'Remove branch dev from upstream repository' in https://dsccommunity.org/blog/convert-a-module-for-continuous-delivery?

[mhendric]

@malauter , please disregard my request to point this to Master. I was able to do it myself. Thanks.

[johlju]

I'm closing this issue as there has been no work to adress the comment for a long time. This can re-opened or another PR can be sent in to propose the appropriate changes.