Fix Windows Sandbox network issues by setting a custom DNS server

Windows Sandbox is one of the easiest ways to test files, scripts, applications, and troubleshooting steps in a clean, temporary Windows environment. But sometimes Sandbox starts without working internet access. In many cases, the problem is not the Sandbox feature itself—it is DNS resolution.

If Windows Sandbox can reach the network but cannot resolve website names, setting a known DNS server manually can bring connectivity back quickly. This guide shows three practical ways to do it: with Command Prompt, through Control Panel, and by using a reusable Windows Sandbox configuration file.

Why DNS can break Windows Sandbox networking

Windows Sandbox launches as an isolated, disposable Windows environment. Networking is normally enabled by default, but name resolution can still fail depending on the host network, VPN configuration, DNS forwarding, or local network policies. When DNS is the issue, the Sandbox may appear offline even though the underlying network connection is available.

The quick fix is to configure the Sandbox network adapter to use a DNS server directly. In the examples below, the DNS server is set to 8.8.8.8, but you can replace it with your preferred public DNS server or an internal corporate DNS server if that is required in your environment.

Option 1: Set DNS quickly with Command Prompt

The fastest method is to open an elevated Command Prompt inside Windows Sandbox and use the netsh command to set a static DNS server on the Ethernet adapter.

1. Start Windows Sandbox.

2. Open Command Prompt as administrator.

3. Run the following command:

netsh interface ip set dns name="Ethernet" static 8.8.8.8

4. Wait a few seconds for the network status to update.

5. Test connectivity by opening a website or running a ping test.

If the interface name is different in your Sandbox instance, run ipconfig or check the adapter name in Network Connections, then replace "Ethernet" in the command with the correct interface name.

Option 2: Set DNS through Control Panel

If you prefer the graphical method, you can configure DNS through the classic Control Panel network settings.

1. Open Control Panel inside Windows Sandbox.

2. Go to Network and Internet.

3. Open Network and Sharing Center.

4. Select the Ethernet connection.

5. Choose Properties.

6. Select Internet Protocol Version 4 (TCP/IPv4), then choose Properties.

7. Select Use the following DNS server addresses.

8. Enter 8.8.8.8 as the preferred DNS server.

9. Choose OK to save the change.

10. Test internet access again.

This method is useful when demonstrating the fix visually or when you do not want to use command-line tools.

Option 3: Automate DNS setup with a .wsb configuration file

If you use Windows Sandbox often, the best approach is to automate the DNS setting with a .wsb file. A .wsb file is an XML-based Windows Sandbox configuration file. It can define settings such as networking, mapped folders, and a logon command that runs when Sandbox starts.

You can find an example at my github repo that sets the DNS and map a local folder from host to Sandbox 

https://github.com/OTvedt/Scripts-For-Sharing/blob/master/Sandbox/Custom-Dns/Custom-DNS(Netsh).wsb

Save the file with a descriptive name, such as Custom-DNS.wsb.

Double-click the .wsb file to start Windows Sandbox with the DNS command applied automatically.

This approach is especially useful if you regularly launch Sandbox for troubleshooting, testing downloads, running scripts, or working in a predictable lab environment. You can also extend the same .wsb file later with mapped folders, startup scripts, or application installation steps.

When should you use each method?

• Use Command Prompt when you need the fastest one-time fix.

• Use Control Panel when you want a visual, manual method that is easy to demonstrate.

• Use a .wsb file when you want a repeatable setup that applies automatically every time Sandbox starts.

Removing all "Unknown" object from permission/access list in Azure (IAM)

I do not like to have permission in Azure that gives access to "Unknown". I consider this a "visual" disturbance, a documentation issue, and a potential security risk. So I usually delete them when I find them.

You can find them by browsing around the entire portal manually or you can find them by using a script to document all access like my script explained in "Documenting Azure resources access (AIM)" 

To ease the cleanup process I created a script based on my findings from this blog. I basically extended it to go through all my subscriptions and document what it does during the process

So it will go through all subscriptions (with some exceptions). Documents all findings in a CSV file, remove the unknowns and then documents what has been removed in a text file at the end. I Was not able to test the text file part, since I already had cleaned up everything when I figured out that documentation of what actually got removed was something that should be included.

You will find the script in my GitHub repo here:

Scripts-For-Sharing/iam-removeunknown.ps1 at master · OTvedt/Scripts-For-Sharing (github.com)

Documenting Azure resources access (AIM)

There are many situations when you want to know the access structure for all your Azure resources. Examples could be:

• Documentation
• Cleaning out permission given to individuals instead of groups
• Safe screening (groups/individuals that should not have access)
• Deleted identities still visible in the AIM list
• Preparing for features like Privileged identity management (PIM)
• Comparing changes in access since the last audit
• Etc

 And the portal built in GUI works but is not particularly flexible or easy to use when you have multiple subscriptions

Change owner for App registration and Enterprise Apps in Azure

 I got a long list of Azure AD App Registration/Enterprise Apps that needed to get a new owner. This is a quite common task since the original owner might have quit or changed role. 

So knowing that this is a task that might appear every now and then I wrote two short and quick PowerShell script to fix this. One for App registration and one for Enterprise Apps, you can, of course, combine them and add lots of error checks and so on but I like KISS

PowerShell script to get some AzureAD logins stats

 The information you get in the Azure portal about logins are decent, but some time you need some statistic or insight fast and don't want to use the graphic interface or down load csv/json files.

I have created som script and favourite lines and uploaded it to my Github repo

Unused Azure AD Connect accounts "On-Premises Directory Synchronization Service Account"

Playing with #Azure Privileged Identity Management‎ made me aware of two active accounts from old or failed AAD connector installations from way back.

And we don't want to leave something with that potential for misusage laying available in our AAD. 

Requesting access with Azure AD Privileged Identity Management from PowerShell

Using Azure AD Privileged Identity Management (PIM for short) as a method to control access to Azure resource are nice security feature. It makes it more trackable and gives the granted roles for a defined time period. 

You can add approval as a necessary add-on security feature, use MFA or other adjustments. Read more about PIM here.

BUT! it can also feel like a pain in the... if you use it a lot. So I created a small and simple PowerShell script to request the access for me.