VMs showing they are in the UK when looking up ip and we cant sign into office on the VM bc we have usa access only.

Question

VMs showing they are in the UK when looking up ip and we cant sign into office on the VM bc we have usa access only.

Dylan Baker 0

this just started recently happening. has anyone else experienced this

Dylan Baker 0 Reputation points

2025-05-01T14:28:20.0766667+00:00

we have reset the NIC, redeployed and nothing worked.
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-02T02:51:36.92+00:00
Hi Dylan Baker,
It sounds like you're experiencing a frustrating issue with your Azure VMs showing them as being in the UK when you need them to reflect US access for Office. Here’s what you can do to troubleshoot this problem:

Region Check: Double-check the configuration of your VMs. If they are indeed deployed in the UK region instead of a US region, you may need to redeploy them in a US data center. This is critical for compliance with access restrictions tied to geographic locations.

Network Settings: Since you've already reset the NIC and redeployed, ensure there are no outbound rules in your network security groups or firewall settings blocking access to vital services. Especially double-check that your firewall allows traffic to the Key Management Service (KMS) for licensing.

KMS Server IP Addresses: Update your firewall to whitelist the new KMS IP addresses: 20.118.99.224 and 40.83.235.53 on port 1688. This is essential since access to KMS servers is crucial for Windows activation and Office sign-in.

Azure Serial Console: If you're still having trouble signing in, you can use the Azure Serial Console for troubleshooting. It allows you to access the VM and verify configurations if Remote Desktop isn’t working.

License Checking: Remember that Office 365 licensing might be tied to the region of the VM. You may need to revalidate your licenses or contact your Microsoft support representative for further assistance if there are regional restrictions impacting access.

I hope these suggestions help you resolve the issue! If the problem persists, could you provide a bit more detail on the following?

What specific versions of Windows and Office are installed on your VMs?

Are there any error messages you receive when trying to sign into Office?

Can you confirm if other users in your organization are facing similar issues?

Have you checked the VM’s NSG and firewall settings for any misconfigurations?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Dylan Baker 0 Reputation points

2025-05-02T12:07:45.2266667+00:00
every user that gets on these ertain boxes in the host pool 6/20 affected

error code is 53003 and our conditional access policy only allows usa login. microsoft thinks these boxes are physically sitting in GB causing them to flag our logins and not being able to login.

yes no misconfigurations, nothing has changed
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-05T09:14:55.6166667+00:00

Hi Dylan Baker,
Based on your latest comment the issue is happening on only 6 out of 20 virtual machines in the host pool. Everything else is working fine, and the Conditional Access policy is doing exactly what it should—allowing logins only from the U.S. The problem is that when users try to log in from these specific VMs, Microsoft's system incorrectly identifies them as being located in Great Britain instead of the U.S. Because of this, Microsoft flags the login attempts as coming from outside the allowed region and blocks access, even though the users are physically in the U.S.

The policy itself isn’t broken the real issue is that Microsoft's location data for those VM IPs is wrong is this correct what I understand if that is the case,

please try below troubleshooting steps If the affected VM’s public IP is set to dynamic, restarting it will prompt Azure to assign a new one. You just need to stop the VM from the Azure portal, then start it again. Once it's running, you can check the new public IP in the Networking or Overview tab. If the issue persists and the IP still shows a UK location, then switching to a manually assigned static IP might be necessary.

To replace a static IP, first, create a new public IP in the Azure portal, making sure to set its region to the U.S. and its assignment to static. Once created, you detach the old IP from the VM and associate the new one. After saving the changes, restart the VM and check if the new IP reflects a U.S. location correctly
Associate a public IP address to a virtual machine
Dylan Baker 0 Reputation points

2025-05-05T12:05:58.5833333+00:00

we dont have public IPs on these for security reasons.
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-06T09:17:54.7966667+00:00

Hi Dylan Baker,
Thanks for reply.
Can you confirm few things mentioned below
1.How are users accessing the session hosts, since public IPs aren't in use, are users connecting via VPN, ExpressRoute, Bastion, or another private networking method?

2.What is the current network configuration? Are the AVD session hosts running in a dedicated VNet with specific routing or NAT settings Do you have a VPN Gateway or a private connection configured for inbound access?

3.Are Conditional Access policies blocking login? Since access is restricted to US-based IPs, have you checked whether Conditional Access is misidentifying the session host’s IP location? Have any location-based access policies changed recently?

Could you please provide a bit more detail so we can assist you better
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-07T09:50:45.4733333+00:00

Hi Dylan Baker,
if you get chance, please look into my previous comment & review it once and let me know
Dylan Baker 0 Reputation points

2025-05-07T11:59:46.0366667+00:00

im not 100% sure on these. backend engineers at microsoft are on it though.
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-08T12:02:46.37+00:00
Hi Dylan Baker,
Thanks for reply back to us.
I understand you're not entirely sure on these points, and it's great to know Microsoft's backend engineers are working on it. In case you run into any issues related to this scenario, here are a few key areas you might want to check:

Accessing the session hosts – Since public IPs aren't in use, users typically connect through VPN Gateway, ExpressRoute, Azure Bastion, or a Jumpbox VM within the Virtual Network (VNet). If connectivity issues arise, ensuring these methods are properly configured is a good starting point. - Deploy private-only Bastion

Network configuration – AVD session hosts generally operate within a dedicated VNet with specific routing and NAT settings. It's worth checking if a VPN Gateway or private connection is in place for inbound access, and whether forced tunneling or firewall rules are affecting connectivity. - AVD network topology and connectivity

Conditional Access policies – If login is restricted to US-based IPs, it’s possible that Conditional Access is misidentifying the session host’s IP location. Checking Named Locations and recent policy changes can help determine if access is being blocked unintentionally. - Conditional Access policies for location-based restrictions

If any of these matches the issues you're experiencing, or if you get more details later, feel free to revisit these areas!

Please let me know if you need any other information, I'm happy to help as you needed.!

If my input is informative and useful, could you please consider an Upvote 👍
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-09T09:55:24.5266667+00:00

Hi Dylan Baker,
Just wanted check on my latest comment, review it once might help you resolve the issue if you're facing something similar. If you receive any updates or need further assistance, feel free to tag me—I'm here to help!
If my inputs are useful, on previous comment, could you please consider an Upvote 👍 on that comment.!
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-12T10:03:12.06+00:00

Hi Dylan Baker,
If you have any further query and need any other information just tag me in comment will help as you needed.!
Dylan Baker 0 Reputation points

2025-05-16T20:17:55.3866667+00:00

microsoft backend engineers have fixed the issue. now we are running into another issue that has just started, no changes in our environment. The screen goes grey says there is a interruption please wait, and comes back after a few seconds. i have a continuous ping to our boxes and no dropped packets or anything. @Akshay kumar Mandha
Arko 2,855 Reputation points Microsoft External Staff Moderator

2025-05-19T08:08:18.1233333+00:00

Hi Dylan Baker,

It's good to hear that the original geolocation issue appears to have been resolved after Microsoft’s backend engineering team stepped in. I am just putting it here for anyone on the MS QnA forum having similar query can try running the following quick check from any of the affected VMs and confirm by running curl https://ipinfo.io

This command will return the VM’s outbound IP address and its geolocation (e.g., country: US). If it shows GB or United Kingdom, then the geolocation issue may still be active on that box. If it shows US, then it's safe to assume the backend fix is fully in effect.

You mentioned the session occasionally goes grey and displays “interruption please wait” before resuming. Given that pings remain stable and there’s no packet loss, here are a few areas to investigate

First of all, check the affected session hosts for CPU/memory spikes or I/O latency at the time of the issue using Azure Monitor or Log Analytics. Even short bursts of high utilization can trigger session delays or rendering glitches.

Please share your findings. Thanks
Mallikarjuna Vardham 160 Reputation points Microsoft External Staff

2025-05-21T11:41:39.88+00:00

Hello @Dylan Baker, just checking if the issue is resolved or not. Please let us know how it goes according to Arko's suggestions.
Dylan Baker 0 Reputation points

2025-05-21T11:59:04.6133333+00:00

nope did not,. we think its the windows app. once we switch users over to the web we got no connectuion paused error
Mallikarjuna Vardham 160 Reputation points Microsoft External Staff

2025-05-21T12:58:33.13+00:00

Hello @Dylan Baker ,This error may be happening due to the following causes:

Can you check if the Windows Desktop Client is up to date? To check for updates, go to the app, select Settings, and open About, then check for updates.

Also, try clearing saved credentials and reconnecting, because stale saved credentials or session tokens can sometimes cause random disconnections.

And also turn off hardware acceleration. In the client settings, disable hardware-accelerated graphics, as this can reduce GPU-related issues that cause session stalling.

Please let us know if it was helpful, and feel free to reach out if you have any further queries.

Looking forward to your response, please try to reach out with the relevant details.
Mallikarjuna Vardham 160 Reputation points Microsoft External Staff

2025-05-22T11:19:20.6366667+00:00

Hello @Dylan Baker ,We haven’t heard from you on the last response, and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, please respond with more details and we will try to help.

1 answer

Your answer

Dylan Baker 0 Reputation points

2025-05-01T14:28:20.0766667+00:00

we have reset the NIC, redeployed and nothing worked.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Dylan Baker 0 Reputation points

2025-05-02T12:07:45.2266667+00:00

every user that gets on these ertain boxes in the host pool 6/20 affected

error code is 53003 and our conditional access policy only allows usa login. microsoft thinks these boxes are physically sitting in GB causing them to flag our logins and not being able to login.

yes no misconfigurations, nothing has changed
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-05T09:14:55.6166667+00:00

Hi Dylan Baker,
Based on your latest comment the issue is happening on only 6 out of 20 virtual machines in the host pool. Everything else is working fine, and the Conditional Access policy is doing exactly what it should—allowing logins only from the U.S. The problem is that when users try to log in from these specific VMs, Microsoft's system incorrectly identifies them as being located in Great Britain instead of the U.S. Because of this, Microsoft flags the login attempts as coming from outside the allowed region and blocks access, even though the users are physically in the U.S.

The policy itself isn’t broken the real issue is that Microsoft's location data for those VM IPs is wrong is this correct what I understand if that is the case,

please try below troubleshooting steps If the affected VM’s public IP is set to dynamic, restarting it will prompt Azure to assign a new one. You just need to stop the VM from the Azure portal, then start it again. Once it's running, you can check the new public IP in the Networking or Overview tab. If the issue persists and the IP still shows a UK location, then switching to a manually assigned static IP might be necessary.

To replace a static IP, first, create a new public IP in the Azure portal, making sure to set its region to the U.S. and its assignment to static. Once created, you detach the old IP from the VM and associate the new one. After saving the changes, restart the VM and check if the new IP reflects a U.S. location correctly
Associate a public IP address to a virtual machine
Dylan Baker 0 Reputation points

2025-05-05T12:05:58.5833333+00:00

we dont have public IPs on these for security reasons.
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-06T09:17:54.7966667+00:00

Hi Dylan Baker,
Thanks for reply.
Can you confirm few things mentioned below
1.How are users accessing the session hosts, since public IPs aren't in use, are users connecting via VPN, ExpressRoute, Bastion, or another private networking method?

2.What is the current network configuration? Are the AVD session hosts running in a dedicated VNet with specific routing or NAT settings Do you have a VPN Gateway or a private connection configured for inbound access?

3.Are Conditional Access policies blocking login? Since access is restricted to US-based IPs, have you checked whether Conditional Access is misidentifying the session host’s IP location? Have any location-based access policies changed recently?

Could you please provide a bit more detail so we can assist you better
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-07T09:50:45.4733333+00:00

Hi Dylan Baker,
if you get chance, please look into my previous comment & review it once and let me know
Dylan Baker 0 Reputation points

2025-05-07T11:59:46.0366667+00:00

im not 100% sure on these. backend engineers at microsoft are on it though.
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-08T12:02:46.37+00:00

Hi Dylan Baker,
Thanks for reply back to us.
I understand you're not entirely sure on these points, and it's great to know Microsoft's backend engineers are working on it. In case you run into any issues related to this scenario, here are a few key areas you might want to check:

Accessing the session hosts – Since public IPs aren't in use, users typically connect through VPN Gateway, ExpressRoute, Azure Bastion, or a Jumpbox VM within the Virtual Network (VNet). If connectivity issues arise, ensuring these methods are properly configured is a good starting point. - Deploy private-only Bastion

Network configuration – AVD session hosts generally operate within a dedicated VNet with specific routing and NAT settings. It's worth checking if a VPN Gateway or private connection is in place for inbound access, and whether forced tunneling or firewall rules are affecting connectivity. - AVD network topology and connectivity

Conditional Access policies – If login is restricted to US-based IPs, it’s possible that Conditional Access is misidentifying the session host’s IP location. Checking Named Locations and recent policy changes can help determine if access is being blocked unintentionally. - Conditional Access policies for location-based restrictions

If any of these matches the issues you're experiencing, or if you get more details later, feel free to revisit these areas!

Please let me know if you need any other information, I'm happy to help as you needed.!

If my input is informative and useful, could you please consider an Upvote 👍
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-09T09:55:24.5266667+00:00

Hi Dylan Baker,
Just wanted check on my latest comment, review it once might help you resolve the issue if you're facing something similar. If you receive any updates or need further assistance, feel free to tag me—I'm here to help!
If my inputs are useful, on previous comment, could you please consider an Upvote 👍 on that comment.!
Akshay kumar Mandha 3,315 Reputation points Microsoft External Staff Moderator

2025-05-12T10:03:12.06+00:00

Hi Dylan Baker,
If you have any further query and need any other information just tag me in comment will help as you needed.!
Dylan Baker 0 Reputation points

2025-05-16T20:17:55.3866667+00:00

microsoft backend engineers have fixed the issue. now we are running into another issue that has just started, no changes in our environment. The screen goes grey says there is a interruption please wait, and comes back after a few seconds. i have a continuous ping to our boxes and no dropped packets or anything. @Akshay kumar Mandha
Arko 2,855 Reputation points Microsoft External Staff Moderator

2025-05-19T08:08:18.1233333+00:00

Hi Dylan Baker,

It's good to hear that the original geolocation issue appears to have been resolved after Microsoft’s backend engineering team stepped in. I am just putting it here for anyone on the MS QnA forum having similar query can try running the following quick check from any of the affected VMs and confirm by running curl https://ipinfo.io

This command will return the VM’s outbound IP address and its geolocation (e.g., country: US). If it shows GB or United Kingdom, then the geolocation issue may still be active on that box. If it shows US, then it's safe to assume the backend fix is fully in effect.

You mentioned the session occasionally goes grey and displays “interruption please wait” before resuming. Given that pings remain stable and there’s no packet loss, here are a few areas to investigate

First of all, check the affected session hosts for CPU/memory spikes or I/O latency at the time of the issue using Azure Monitor or Log Analytics. Even short bursts of high utilization can trigger session delays or rendering glitches.

Please share your findings. Thanks
Mallikarjuna Vardham 160 Reputation points Microsoft External Staff

2025-05-21T11:41:39.88+00:00

Hello @Dylan Baker, just checking if the issue is resolved or not. Please let us know how it goes according to Arko's suggestions.
Dylan Baker 0 Reputation points

2025-05-21T11:59:04.6133333+00:00

nope did not,. we think its the windows app. once we switch users over to the web we got no connectuion paused error
Mallikarjuna Vardham 160 Reputation points Microsoft External Staff

2025-05-21T12:58:33.13+00:00

Hello @Dylan Baker ,This error may be happening due to the following causes:

Can you check if the Windows Desktop Client is up to date? To check for updates, go to the app, select Settings, and open About, then check for updates.

Also, try clearing saved credentials and reconnecting, because stale saved credentials or session tokens can sometimes cause random disconnections.

And also turn off hardware acceleration. In the client settings, disable hardware-accelerated graphics, as this can reduce GPU-related issues that cause session stalling.

Please let us know if it was helpful, and feel free to reach out if you have any further queries.

Looking forward to your response, please try to reach out with the relevant details.
Mallikarjuna Vardham 160 Reputation points Microsoft External Staff

2025-05-22T11:19:20.6366667+00:00

Hello @Dylan Baker ,We haven’t heard from you on the last response, and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, please respond with more details and we will try to help.

Answer 1

Alex Burlachenko 5,830

Hi Dylan,

Thanks for reaching out. This could be due to a recent configuration or network routing issue. To troubleshoot:

Verify the VM’s Azure region is set to a USA location (e.g., East US/West US).

Check if a proxy/VPN is routing traffic through the UK instead of the USA.

Run curl ipinfo.io in the VM’s CLI to confirm the outgoing IP location.

Your Office 365 tenant may block non-US IPs work with IT to adjust Conditional Access policies or enforce a USA-based VPN.

Best regards,
Alex
P.S. If my answer help to you, please Accept my answer
PPS That is my Answer and not a Comment

Dylan Baker 0 Reputation points

2025-05-16T20:18:32.09+00:00

this was a 100% microsoft issue. we are experiencing another issue. see comment above

Share via

VMs showing they are in the UK when looking up ip and we cant sign into office on the VM bc we have usa access only.

1 answer

Your answer