Node Expansion - Add-server

Question

Node Expansion - Add-server

Cem Iscen 20

Hi there,

While trying to add a new node, I encountered a “cannot resolve node name” error. DNS resolution from the existing clustered node works as expected, and Wsman tests also succeed—so basic connectivity appears to be fine at least locally/on-prem.

I used the hostname (not FQDN) in the Add-Server command, which might be contributing to the issue. However, once the process starts, there doesn’t seem to be a way to cancel or modify the existing ActionPlan ID. The only available option is -rerun, which doesn’t help in this case, and unfortunately, there’s no useful visibility into this through the Azure portal either.

In an earlier test, I got past the initial steps but ran into a version mismatch issue. That scenario wasn’t clearly documented—specifically, whether the onboarding process accounts for clusters deployed with vendor-provided SBE images. It’s unclear if the new node is expected to match automatically or if we need to domain-join it and install specific extensions manually before attempting to add it.

Appreciated for any insight!

Durga Reshma Malthi 11,400 Reputation points Microsoft External Staff Moderator

2025-08-04T10:50:53.67+00:00

Hi Cem Iscen

Is this Azure Stack HCI Environment and what DNS servers are assigned to the new node

Since you mentioned using the hostname instead of the FQDN, try using the FQDN in the Add-Server command. This can help avoid DNS resolution issues.

Also ensure that the DNS settings on the existing clustered node are correctly configured to resolve the new node's hostname. You can test this by running nslookup <hostname> from the existing node.
Durga Reshma Malthi 11,400 Reputation points Microsoft External Staff Moderator

2025-08-05T10:04:57.7366667+00:00

Hi Cem Iscen

Just checking in to see if you had a chance to review the response provided to your question.

Feel free to reach out if you have any further queries.
Cem Iscen 20 Reputation points

2025-08-05T14:03:59.9566667+00:00

Hi Durga,

As you suggested, I tried running the add-server command with the FQDN parameter. However, as shown below, the process seems to be using the previous actionid, so I’m not sure if it actually picked up the updated FQDN at this stage.

From what I can tell, the only way to restart the process is by using the rerun option/flag—but I assume that reuses the original parameters, not the updated ones!

Just to confirm—name resolution works correctly for the new node using hostname, FQDN, and IP (both forward and reverse lookups) on the local DNS servers.

I’d appreciate it if you could share any guidance on how to fully cancel or reset the current action.

VERBOSE: Setting credential completed

VERBOSE: Starting add node operation to add node tp-azl-01.tpoint.ca to current cluster

VERBOSE: Checking for the status of last run ScaleOutOperation operation

VERBOSE: Action ScaleOutOperation is currently not running, looking for last completed or failed instance

VERBOSE: Most recent action was 365e7259-08b9-4c13-b789-acf3a279f942 and it has a status of Failed

VERBOSE: Checking for any active update operation running on the environment

VERBOSE: Looking up shared vhd product drive letter.

VERBOSE: Suppressed Warning Unknown category for 'NuGet'::'GetDynamicOptions': 'Provider'

VERBOSE: Get-Package returned with Success:True

VERBOSE: Found package Microsoft.AzureStack.LcmUpdateService.PowerShell with version 2.2506.0.9 at C:\NugetStore\Microsoft.AzureStack.LcmUpdateService.PowerShell.2.2506.0.9\Microsoft.AzureStack.LcmUpdateService.PowerShell.nuspec.

WARNING: ScaleOutOperation was already started and is currently in Failed. Please resume ScaleOutOperation by using Rerun flag

WARNING: Please resume the last instance of ScaleOutOperation using Rerun flag
Ankit Yadav 410 Reputation points Microsoft External Staff Moderator

2025-08-07T18:13:41.12+00:00

Hello @Cem Iscen ,

thank you for sharing the updates along with the logs.

Yes, as suspected the reason behind the failure for the Add-Server command is the previous failed ScaleOutOperation and as an alternative it's asking to try Add-Server -Rerun.

If you have already tried with -Rerun and that also is failing, then next good step could be to try repairing the node. For more guidance around repairing the node, please refer: https://learn.microsoft.com/en-us/azure/azure-local/manage/repair-server?view=azloc-2507#prerequisites

Feel free to reach out to us if you have any queries.
Cem Iscen 20 Reputation points

2025-08-08T18:26:57.1966667+00:00

I’d appreciate it if you could provide more details about the process. Suggesting the repair-node command essentially bypasses other potential solutions without first addressing the root cause. After the repair—which appears to involve reinstalling the OS and running the initial preparation—the process might fail again. I also suspect that the documentation is missing key details on how to properly initiate the node addition process.
Ankit Yadav 410 Reputation points Microsoft External Staff Moderator

2025-08-19T12:04:55.82+00:00

Hi Cem Iscen

I’ve asked few details about the cluster in the private message, please review and answer them there.

Thank you!
Ankit Yadav 410 Reputation points Microsoft External Staff Moderator

2025-08-23T02:07:44.1166667+00:00

Hello Cem Iscen,

Just checking in if you are still blocked with the Scaling issue, do let us know if you are still blocked and need our assistance, we'll be happy to assist you further.

Thank you!

1 answer

Your answer

Durga Reshma Malthi 11,400 Reputation points Microsoft External Staff Moderator

2025-08-04T10:50:53.67+00:00

Hi Cem Iscen

Is this Azure Stack HCI Environment and what DNS servers are assigned to the new node

Since you mentioned using the hostname instead of the FQDN, try using the FQDN in the Add-Server command. This can help avoid DNS resolution issues.

Also ensure that the DNS settings on the existing clustered node are correctly configured to resolve the new node's hostname. You can test this by running nslookup <hostname> from the existing node.
Durga Reshma Malthi 11,400 Reputation points Microsoft External Staff Moderator

2025-08-05T10:04:57.7366667+00:00

Hi Cem Iscen

Just checking in to see if you had a chance to review the response provided to your question.

Feel free to reach out if you have any further queries.
Cem Iscen 20 Reputation points

2025-08-05T14:03:59.9566667+00:00

Hi Durga,

As you suggested, I tried running the add-server command with the FQDN parameter. However, as shown below, the process seems to be using the previous actionid, so I’m not sure if it actually picked up the updated FQDN at this stage.

From what I can tell, the only way to restart the process is by using the rerun option/flag—but I assume that reuses the original parameters, not the updated ones!

Just to confirm—name resolution works correctly for the new node using hostname, FQDN, and IP (both forward and reverse lookups) on the local DNS servers.

I’d appreciate it if you could share any guidance on how to fully cancel or reset the current action.

VERBOSE: Setting credential completed

VERBOSE: Starting add node operation to add node tp-azl-01.tpoint.ca to current cluster

VERBOSE: Checking for the status of last run ScaleOutOperation operation

VERBOSE: Action ScaleOutOperation is currently not running, looking for last completed or failed instance

VERBOSE: Most recent action was 365e7259-08b9-4c13-b789-acf3a279f942 and it has a status of Failed

VERBOSE: Checking for any active update operation running on the environment

VERBOSE: Looking up shared vhd product drive letter.

VERBOSE: Suppressed Warning Unknown category for 'NuGet'::'GetDynamicOptions': 'Provider'

VERBOSE: Get-Package returned with Success:True

VERBOSE: Found package Microsoft.AzureStack.LcmUpdateService.PowerShell with version 2.2506.0.9 at C:\NugetStore\Microsoft.AzureStack.LcmUpdateService.PowerShell.2.2506.0.9\Microsoft.AzureStack.LcmUpdateService.PowerShell.nuspec.

WARNING: ScaleOutOperation was already started and is currently in Failed. Please resume ScaleOutOperation by using Rerun flag

WARNING: Please resume the last instance of ScaleOutOperation using Rerun flag
Ankit Yadav 410 Reputation points Microsoft External Staff Moderator

2025-08-07T18:13:41.12+00:00

Hello @Cem Iscen ,

thank you for sharing the updates along with the logs.

Yes, as suspected the reason behind the failure for the Add-Server command is the previous failed ScaleOutOperation and as an alternative it's asking to try Add-Server -Rerun.

If you have already tried with -Rerun and that also is failing, then next good step could be to try repairing the node. For more guidance around repairing the node, please refer: https://learn.microsoft.com/en-us/azure/azure-local/manage/repair-server?view=azloc-2507#prerequisites

Feel free to reach out to us if you have any queries.
Cem Iscen 20 Reputation points

2025-08-08T18:26:57.1966667+00:00

I’d appreciate it if you could provide more details about the process. Suggesting the repair-node command essentially bypasses other potential solutions without first addressing the root cause. After the repair—which appears to involve reinstalling the OS and running the initial preparation—the process might fail again. I also suspect that the documentation is missing key details on how to properly initiate the node addition process.
Ankit Yadav 410 Reputation points Microsoft External Staff Moderator

2025-08-19T12:04:55.82+00:00

Hi Cem Iscen

I’ve asked few details about the cluster in the private message, please review and answer them there.

Thank you!
Ankit Yadav 410 Reputation points Microsoft External Staff Moderator

2025-08-23T02:07:44.1166667+00:00

Hello Cem Iscen,

Just checking in if you are still blocked with the Scaling issue, do let us know if you are still blocked and need our assistance, we'll be happy to assist you further.

Thank you!

Answer 1

At this point, we suspect that the root cause behind the scale out failure is due to DNS resolution while trying to add the node to the cluster due to DNS mis-configuration. However DNS resolution from existing node to new node worked fine and vice-versa and wsman test also was successful, this makes the use of hostname as the root cause behind failure.

If you are still stuck with the failed action plan, you could try to restart the cluster or refreshing the management console to reset it's state.

If this doesn't work, unfortunately you would be required to repair the node. This will help to ensure that the node is in clean state when attempting Add-Server again.

Share via

Node Expansion - Add-server

1 answer

Your answer