Resource Computer: Error 0x80041033 when VM joins AD domain

Details of the scenario you tried and the problem that is occurring

This problem happens only with the SharePoint public images of Azure:
When resource "Computer" joins the VM to the domain, this error systematically occurs just after resource completes:
"The WS-Management service cannot process the request. The WMI service or the WMI provider returned an unknown error: HRESULT 0x80041033"

Verbose logs showing the problem

Notice that the error is not in resource Computer, but just after:

VERBOSE: [2021-01-12 15:32:34Z] [VERBOSE] [SP1]: LCM:  [ Start  Set      ]  [[Computer]JoinDomain]
VERBOSE: [2021-01-12 15:32:34Z] [VERBOSE] [SP1]:                            [[Computer]JoinDomain] Setting computer state for 'SP1'.
VERBOSE: [2021-01-12 15:32:34Z] [VERBOSE] [SP1]:                            [[Computer]JoinDomain] Perform operation 'Enumerate CimInstances' with following parameters, ''namespaceName' = root\cimv2,'className' = Win32_ComputerSystem'.
VERBOSE: [2021-01-12 15:32:34Z] [VERBOSE] [SP1]:                            [[Computer]JoinDomain] Operation 'Enumerate CimInstances' complete.
VERBOSE: [2021-01-12 15:32:34Z] [WARNING] [SP1]:                            [[Computer]JoinDomain] The changes will take effect after you restart the computer SP1.
VERBOSE: [2021-01-12 15:32:35Z] [VERBOSE] [SP1]:                            [[Computer]JoinDomain] Added computer to domain 'contoso.local'.
VERBOSE: [2021-01-12 15:32:35Z] [VERBOSE] [SP1]: LCM:  [ End    Set      ]  [[Computer]JoinDomain]  in 1.7970 seconds.
VERBOSE: [2021-01-12 15:32:35Z] [VERBOSE] [SP1]: LCM:  [ End    Resource ]  [[Computer]JoinDomain]
VERBOSE: [2021-01-12 15:32:41Z] [ERROR] The WS-Management service cannot process the request. The WMI service or the 
WMI provider returned an unknown error: HRESULT 0x80041033 
VERBOSE: [2021-01-12 15:32:41Z] [VERBOSE] Operation 'Invoke CimMethod' complete.
VERBOSE: [2021-01-12 15:32:41Z] [VERBOSE] Time taken for configuration job to complete is 497.2 seconds
VERBOSE: [2021-01-12 15:32:42Z] Settings handler status to 'transitioning' 

Suggested solution to the issue

I found a dirty workaround that works 90% of the time:
I edited function Set-TargetResource in DSC_Computer.psm1 to add the following if this is a SharePoint VM:

• Add "Restart" to cmdlet Add-Computer
• Set the flag "$global:DSCMachineStatus = 1"

The DSC configuration that is used to reproduce the issue (as detailed as possible)

It repro every time, merely by joining an AD domain:

Computer JoinDomain
{
	Name       = $ComputerName
	DomainName = $DomainFQDN
	Credential = $DomainAdminCredsQualified
	DependsOn  = "[WaitForADDomain]WaitForDCReady"
}

I made an az cli script that creates a DC and a SP VM and fully repro from scratch:

# Create DC VM and SP VM
read -s -p "Type your password: " password
resourceGroupName="ydcli1"
adminUserName=yvand
dcip="10.0.0.4"
vmName=DC

az group create --name $resourceGroupName --location "west europe"
az vm create -g $resourceGroupName --name ${vmName} --os-disk-name "${vmName}-Disk-OS" --size Standard_D2_v3 \
  --image "MicrosoftWindowsServer:WindowsServer:2019-Datacenter:latest" --private-ip-address $dcip --public-ip-address "" \
  --admin-username $adminUserName --admin-password $password
az vm extension set -g $resourceGroupName --vm-name $vmName --name DSC --publisher Microsoft.Powershell --version 2.9  \
  --settings '{"ModulesURL": "https://github.com/Yvand/AzureRM-Templates/raw/bug-join-domain/Templates/DTL-SharePoint-AllVersions-light/dsc/ConfigureDCVM.zip", "configurationFunction": "ConfigureDCVM.ps1\\ConfigureDCVM", "Properties": {"domainFQDN": "contoso.local", "PrivateIP": "'${dcip}'", "ConfigureADFS": 0 } }' \
  --protected-settings '{"Properties": {"AdminCreds": {"UserName": "'${adminUserName}'", "Password": "'${password}'" }, "AdfsSvcCreds": {"UserName": "'${adminUserName}'", "Password": "'${password}'" }}}' --no-wait

vmName=SP1
az vm create -g $resourceGroupName --name ${vmName} --os-disk-name "${vmName}-Disk-OS" --size Standard_D2_v3 \
  --image "MicrosoftSharePoint:MicrosoftSharePointServer:sp2019:1.0.2" \
  --admin-username $adminUserName --admin-password $password
az vm extension set -g $resourceGroupName --vm-name $vmName --name DSC --publisher Microsoft.Powershell --version 2.9  \
  --settings '{"ModulesURL": "https://github.com/Yvand/AzureRM-Templates/raw/bug-join-domain/Templates/DTL-SharePoint-AllVersions-light/dsc/ConfigureSPVM.zip", "configurationFunction": "ConfigureSPVM.ps1\\ConfigureSPVM", "Properties": {"domainFQDN": "contoso.local", "DNSServer": "'${dcip}'" } }' \
  --protected-settings '{"Properties": {"DomainAdminCreds": {"UserName": "'${adminUserName}'", "Password": "'${password}'"}}}' --no-wait

The operating system the target node is running

It reproduces on SharePoint 2019/2016/2013 public images of Azure. Below is the output for the SharePoint 2019 VM:

OsName               : Microsoft Windows Server 2019 Datacenter
OsOperatingSystemSKU : DatacenterServerEdition
OsArchitecture       : 64-bit
WindowsVersion       : 1809
WindowsBuildLabEx    : 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Version and build of PowerShell the target node is running

Name                           Value
----                           -----
PSVersion                      5.1.17763.1007
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.1007
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version of the DSC module that was used ('dev' if using current dev branch)

ComputerManagementDsc 8.4.0

Start in DSC_Computer.psm1, specifically Set-TargetResource and the Computer JoinDomain operation, then reproduce the failure with the provided Azure CLI script and DSC configuration. Compare the existing Add-Computer behavior with the reported restart workaround; done means domain joining on the SharePoint Azure images completes without the WS-Management 0x80041033 error.