Virtual Machine: Connectivity Issue After Adding M365 Work Account — Ports No Longer Responding

Question

Virtual Machine: Connectivity Issue After Adding M365 Work Account — Ports No Longer Responding

Eric-5173 0

Problem description

I am experiencing an issue where my Azure virtual machine is no longer accepting incoming requests after I added a work account in Windows Settings. Specifically, both RDP (port 3389) and a custom SFTP service port (53281) stopped responding from multiple client computers. Prior to this change, inbound rules allowed traffic on these ports, and the services were listening inside the guest OS. The problem began around October 7, 2026, after making this account addition, but no error messages or logs indicate a boot failure.

Environment

Azure Virtual Machine running Windows, located in Central US, Availability Zone 1. The VM is not joined to Azure or Workplace, and I am using a non-built-in administrator account to access it.

What I've already tried

I verified that the services listening on ports 3389 and 53281 are active and that Windows Firewall is disabled. I confirmed inbound security rules in Azure allow traffic on these ports, and I attempted to connect from multiple client computers, including from other Azure VMs. I checked that the VM is in a running state with no apparent issues in Boot diagnostics. I also ran scripts to verify that ports are listening and that firewall rules are open, and I excluded the VM and M365 user from the firewall policies. Despite these efforts, inbound connections still fail after the account change.

Current status

Currently, both ports are listening, and firewall rules are open, but the inbound traffic is not reaching the services. I suspect that adding the work account caused the VM to become workplace-joined or device-managed, potentially applying policies that block inbound traffic. I am seeking guidance on how to verify the VM's join and management state, how to check effective security rules and network path configurations, and how to determine if policies or device management are causing the connectivity issues.

0 comments

1 answer

Your answer

Answer 1

Hello @Eric-5173

Adding a work account does not by itself confirm that the VM became Microsoft Entra joined or MDM-managed. The first step is to establish whether the timing is causal or coincidental.

Sign in with the account that was added and run:

dsregcmd /status

Check:

AzureAdJoined - whether the device is Microsoft Entra joined.
WorkplaceJoined - whether a work account is registered in the current user context.

Open Settings > Accounts > Access work or school. If the account has an Info option, open it and select Create report > Export to collect the MDM diagnostic report. Also check this Event Viewer location for enrollment or policy activity at the time the account was added:

Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin

In Azure Network Watcher, run IP flow verify separately for inbound TCP ports 3389 and 53281, using the VM’s private IP and the actual client source IP. IP flow verify reports whether the packet is allowed or denied by the applicable NSG or Azure Virtual Network Manager security-admin rule and identifies the matching rule.
If IP flow verify reports Allow, start an Azure Network Watcher packet capture filtered for these ports and reproduce the connection attempt. This determines whether the inbound TCP SYN reaches the VM and whether the VM sends a response.

Because both RDP and SFTP stopped simultaneously while both services remain listening, this should be investigated as a shared network-filtering path rather than as an RDP-only problem. If the SYN reaches the guest but no SYN-ACK leaves it, inspect Windows Filtering Platform, IPsec/connection-security rules, and any endpoint-security network filter. Disabling the Windows Firewall profiles does not necessarily remove filters installed by other WFP-based software. Windows Filtering Platform can filter or modify traffic at multiple networking layers.

I cannot find verified official documentation establishing that merely adding a Microsoft 365 work account blocks arbitrary inbound VM ports. The dsregcmd, MDM logs, IP flow result, and packet capture are therefore needed before attributing the outage to Entra registration or an MDM policy.

References:

Troubleshoot devices by using the dsregcmd command

Collect MDM logs

Diagnose MDM enrollment failures

IP flow verify overview

Azure Network Watcher packet capture overview

Windows Filtering Platform

Windows Filtering Platform auditing and logging

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.