2025-07-10 - Active Directory 5.0 - Group Policy Foundations: Understanding Domain Admins and User Accounts / Setting up Remote Access

 Why You Use TESTLAB\Administrator Across Multiple Machines — And Why You Need Separate Domain Users

When you join a workstation to an Active Directory domain like testlab.local, you can log into that machine using domain credentials. One of the first accounts I am using is TESTLAB\Administrator — the default domain admin account I created when I promoted my Windows Server to a domain controller.

Here’s what that means:

• One Account, Many Machines: TESTLAB\Administrator is a single domain-wide admin account. I can use it to log into any machine joined to my domain, whether it’s the server or a workstation.

• Local Access with Domain Credentials: Logging into a workstation as TESTLAB\Administrator doesn’t magically give me access to the server from that workstation — it just means I have admin rights on that local machine using the domain account.

• Why Not Use This Account Daily? Because TESTLAB\Administrator has full domain admin powers, it’s risky to use it for everyday tasks. Mistakes or malware on one machine can affect my entire domain.

• Create Separate Domain User Accounts: Instead of using TESTLAB\Administrator for daily work, you create separate domain user accounts (for example TESTLAB\ChristianUser). These accounts have limited permissions tailored for each user.

• Manage Users with Group Policy: By managing domain user accounts, I can apply group policies that control user access, permissions, security settings, and more — keeping my network secure and organized.

• Users Aren’t Per Machine: I don’t create a new user for every workstation. One domain user can log into multiple domain-joined machines based on my permissions and policies.

Bottom line: Using TESTLAB\Administrator across all machines is normal at first. But for security and management, create individual domain user accounts for daily use and control them through Active Directory and Group Policy.

Setting Up Seamless Remote Access to Windows Server VMs on Proxmox Using AnyDesk

In this post, I’ll walk through how I configured remote desktop access to a Windows Server VM running on Proxmox, bypassing the clunky built-in Proxmox console using AnyDesk with unattended access and automatic login.

This setup lets me spin up a VM and connect just using AnyDesk with zero interaction needed on the VM side. It's ideal for test labs and managing multiple VMs for learning and experimentation. This removed a great deal of security because passwords are bypassed as much as possible to make  running this test lab as smooth and not tedious as possible. 

---

Why I Chose AnyDesk Over Other Options

Proxmox Console: Not Suitable for Daily Use

While Proxmox’s built-in console is fine for initial setup or emergencies, it’s:

• Laggy and unresponsive

• Doesn’t support copy-paste or file transfer

• Poor resolution scaling

• Not good for day-to-day usability

Why I Got Sick of Using the Proxmox Console

I’ve been working more and more on Active Directory over the past few weeks — it’s now my top priority every day. Because of that, I’ve been spending a lot more time inside the Proxmox console, and it’s gotten tedious.

The scaling issues are the first problem. I’ve had to just deal with the copy-paste limitations between the VMs and my laptop, which is where all my actual productivity happens.

To get the scaling just right, I developed this clunky routine:

Maximize the VM console window > In the console sidebar, go full screen > Escape out of full screen > Minimize the sidebar > Restore the window size > resize entire window to suit my needs. 

And I’d have to repeat this entire process for every single VM I am working on at that time. Then if there is a problem, I have to reboot, some error that causes a closure, whatever, I have to go through the process again. If I didn’t, the console would stay zoomed in — I couldn’t see the taskbar or some of the desktop icons, and I’d be stuck scrolling around the desktop, which just slows everything down.

Remote Desktop (RDP): Not an Option Here

RDP is only available on Windows Server with Remote Desktop enabled, or on Pro and Enterprise editions of Windows. My laptop is running Windows Home, which can initiate RDP sessions, but not with machines on a domain without being Pro or Enterprise, and some of my test VMs might not support it either.

RustDesk: Good, but Unnecessary

RustDesk is a great open-source alternative to the Proxmox Console and Remote Desktop — but:

• I'm already familiar with AnyDesk

• It’s already installed and working well on my laptop and other machines I run 

• There's no compelling reason to switch for this workflow

So AnyDesk was the perfect fit: familiar, fast, and cross-platform.

---

What I Set Up

1. Installed and Configured AnyDesk on the Windows Server VM

• Installed AnyDesk and Right-clicked the AnyDesk shortcut icon > in shortcut tab > Advanced > Chose Run as administrator. (I'm not sure if this was necessary). I spent some time trying to get unattended access to work and doing this was part of what I did to troubleshoot why it wasn't working. 

• Set AnyDesk to start with Windows via:

  • To set AnyDesk to start automatically with Windows, I:

    Opened Task Manager > Went to Startup > Confirmed AnyDesk was enabled

    It was already enabled, but I wasn't sure, since setting up Unattended Access was turned on but not working (I actually did these things in reverse order), I double-checked by:

    Opening the Run dialog (Win + R) > Typed services.msc > Hit Enter to open the Services window

    Searched and clicked on the AnyDesk service to check its' configuration which was set to automatic. 

    I rebooted since that was all that was left to do, and it worked.  

• Firewall Rules

  To make sure AnyDesk could connect without issues, I added inbound and outbound rules for both TCP and UDP on the following ports:

  80, 443, 7070, and 6568

  In hindsight I believe that only port 7070 was necessary but since I am only doing this to streamline using the VM's and this will have no bearing on AD itself and I actually really need to get going and finish this project as soon as possible, I will skip this for now. If I had the time, I would disable certain rles one by one to see which ones I can't be without. Instructions online led me to believe all of these were necessary despite my feeling this could potentially open me up to attacks. But I read that some of these ports like 80 for HTTP (which is not a secure protocol, frequently replaced by 443 for HTTPS) has to be opened anyway if you want to browse online. 

  Then I spent time figuring out how to add that file to Proxmox as a virtual CD ISO, so I could mount it inside my other Windows 11 VMs and import the rules directly — no need to recreate them by hand every time.

  • In Settings > Access > Unattended Access, I found no option to simply enable it. I noticed that on this Windows Server install, the Unlock button — normally visible on the Access page on all my other machines — was missing. I thought that might be why I couldn’t turn it on.

    Eventually, I found the workaround:

    Settings > Security > Permissions > Permission Profiles > Selected Unattended Access > Changed the password

    I didn’t want to use a password, but it didn't seem to enable Unattended Access until I added one. 

•   These rules were added manually in Windows Defender Firewall > Advanced Settings on the Windows Server VM — and it was tedious. 

• I didn’t want to manually recreate those rules for every new VM, so I decided to mount it as a virtual CD in other VMs, so I exported the finished firewall configuration as a .wfw file using:

• netsh advfirewall export "C:\AllRules.wfw"

• Adding the Firewall Rules ISO to Proxmox Storage and Attaching to a VM

  
  

  Uploaded it to my file server. 

   I didn’t want to manually recreate those rules for every new VM, so I decided to mount it as a virtual CD in other VMs — using the Proxmox web interface, thinking it would be easier. 

  In Proxmox web UI:
  Datacenter > Add > LVM

  In the window that popped up, I:

  • Named the storage anydeskfirewallrules

  • Set the directory path where I wanted to store the ISO (e.g., /var/lib/vz/template/iso/)

  • Selected Content type: ISO image

  After adding that storage, I clicked on anydeskfirewallrules in the Proxmox tree on the left.

  In the middle pane, I found the ISO Images tab under that storage, clicked it, then clicked the Upload button.

• Found out the hard way I needed to turn the .wfw file into an ISO, downloaded CDBurnerXP and converted it. 
• Opened CDBurnerxp > Selected Data Disc and pressed OK > Dragged and Dropped file in main window > File > Save Compilation as ISO File. Do not select Convert ISO Image!

          I uploaded the firewall rules ISO file I’d saved on my fileserver.

• Next, I went to the target VM:

  • Opened Hardware

  • Selected the CD/DVD drive

  • Changed the ISO to the new firewall rules ISO from anydeskfirewallrules storage

  Finally, I booted into the VM and verified the .wfw file was accessible from the mounted virtual CD-ROM drive.

• Set Unattended Access:

                    And usually where you add a password for Unattended Access is just Settings > Access >                        Unattended Access, and there is a button to set password right there. Maybe I am                                    misremembering, and you set a password right there and then things operate as normal. 

                    But to then deal with the password problem, when accessing the VM through                                        AnyDesk on another machine, simply select to Remember Password. 

2. Enabled Automatic Login to a Domain Admin Account

Used the registry method for forcing auto-login:

In regedit, navigated to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Created/edited the following string values:

Name	Value
AutoAdminLogon	1
DefaultUserName	DOMAIN_NAME\Administrator
DefaultPassword	yourpassword (plaintext)
DefaultDomainName	DOMAIN_NAME

        Password is stored in plaintext. Acceptable for lab use only.

3. Optional: Disabled the Lock Screen

To keep things as frictionless as possible:

Added in regedit:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Personalization

Created a new DWORD:
Name: NoLockScreen
Value: 1

---

Final Touches

• Confirmed clipboard and file transfer were enabled in AnyDesk permissions

• Saved and exported firewall rules to ISO so I can easily import them into future VMs

• Verified everything works by shutting down and restarting the VM via Proxmox

---

Outcome

Now I can:

• Boot the VM from Proxmox

• Wait a few minutes for Windows to auto-login, so I do still use the console to know when to open AnyDesk connection. 

• Connect instantly via AnyDesk using the ID + password (no prompts, no console)

This avoids all the limitations of the Proxmox console, gets around the lack of RDP support on my local machine, and lets me stick with tools I already use. It’s a fast, smooth remote access experience — perfect for lab environments or learning setups where convenience matters more than enterprise lockdowns.

2025-07-17 - Thursday

Yesterday the Windows 11 VMs stopped working because the ISO Images and Disk Image content types got unchecked in Proxmox storage after I imported the AnyDesk firewall rules as an ISO.

I kept getting this error:
TASK ERROR: storage 'local' does not support content-type 'iso'

I rebooted the Proxmox server twice to try to fix it, but it didn’t help.

I checked if I had backups — I didn’t — so I will be setting up backups going forward.

Finally, I went to Datacenter/storage/local/content dropdown menu in Proxmox and re-selected “ISO Images” and “Disk Image” as supported content types. Before this repair, only Container Template and VZDump Backup File were selected. 

After that, everything worked again, and none of my VMs or data were lost.

Replacing Proxmox Console with AnyDesk Using Group Policy

While working on setting up AnyDesk as a more convenient alternative to the built-in Proxmox console window for my two Windows 11 VMs, I realized it made sense to configure it through Active Directory using Group Policy Management. Since both VMs are already joined to the domain, I can push settings or even install AnyDesk centrally using a GPO, giving me tighter control and easier future maintenance. To do this, I:

• In ADCU, moved both Windows 11 VMs from the default Computers container into a custom Firewall OU under Workstations in Active Directory, preparing them for targeted GPO deployment using Group Policy Management.
• Created a new OU structure in Active Directory: Workstations > Firewall to organize target machines.

• Moved both Windows 11 VMs from the default Computers container into the new Firewall OU.

• In Group Policy Management Console (GPMC), created and linked a new GPO named anydeskFirewallWin11 to the Firewall OU.

• Began editing the GPO to configure firewall settings targeted at these specific machines, right clicking on anydeskFirewallWin11 > Selected Edit > new window appeared, clicked Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > In the left pane, click Windows Defender Firewall with Advanced Security – LDAP... > in the 'middle' pane which is actually just the right pane, click Windows Defender Firewall Properties. 

• Another new window appears, go Domain Profile > Set Firewall state to Off > Apply and OK > Close > 

AnyDesk Firewall Ports: Identifying and Narrowing  Down  Active Connections

• I had opened several ports on my server—including 443, 80, 6568, and 7070, both TCP and UDP, inbound and outbound. It felt potentially insecure, and Windows even asked me to confirm each inbound opening.

• Using the command

netstat -ano

in an elevated Command Prompt, I exported the active connections to a file and searched for relevant process IDs (PIDs) associated with AnyDesk, including 2464, 3336, and 6472.

• After sifting through the data, I found that PID 2092 was the one actively using TCP port 7070—the key port AnyDesk requires. This allowed me to narrow the firewall rules accordingly, focusing only on port 7070 to improve security.

Setting Up Win11Ent-2 for Remote Access via AnyDesk

• Renamed the computer to Win11Ent-2 via Windows Settings → System → About → Rename this PC.

• Ensured the machine is placed in the correct OU (Workstations > Firewall) in Active Directory Users and Computers.

• Ran gpupdate /force to apply Group Policy settings immediately, including firewall rules.

• Prepared for a reboot to finalize the name change and policy application.

• Verified AnyDesk is installed as a service, set to Automatic, with Unattended Access enabled and password set (WinServ2025).

AnyDesk Remote Access Setup Complete with Active Directory Integration

• AnyDesk is now fully installed and configured on all machines in my lab environment.

• I can access all Windows 11 VMs and the server remotely from my laptop using AnyDesk.

• Unattended access is enabled on all machines with a secure password.

• I successfully used Active Directory Group Policy to manage and restrict firewall ports, ensuring secure and streamlined remote connections.

• This marks my first practical experience managing devices through Active Directory, tying together networking, security, and remote access in a hands-on way.

This has been Truncat3d 00000000111100010100110______________end of line

2025-07-10 - BYU Wi‑Fi captive portal troubleshooting

 

BYU Wi‑Fi Captive Portal Troubleshooting

What happened

I had used BYU Wi‑Fi just fine before, but at some point, the captive portal started acting up.

Every time I opened Edge to trigger the portal, the page would just hang. I started getting warnings like “your connection to this site isn’t secure.” I allowed it anyway, but the page would only half-load—the “Connect” button would start to show, then everything froze. Eventually, it just timed out. No response.

I tried rebooting, updating, reversing settings—nothing changed.

---

What I tried

• Checked DNS settings and confirmed they were set to automatic.

• Cleared the DNS cache and reset Winsock using ipconfig and netsh. Rebooted and tried neverssl.com again—still hung.

• Verified VPN and proxy were off. I wasn’t running any WireGuard tunnels, and the proxy settings were disabled.

• Disabled all browser extensions in Edge, used InPrivate mode, and retried the portal. Same result.

• Tried direct portal URLs, like captive.apple.com. It either said unsupported or “Can’t reach this page.”

• Forgot the network, reconnected, and tried again—no difference.

• Double-checked proxy settings. Automatic detection was on, manual proxy was off.

• Updated the Wi‑Fi adapter driver in Device Manager—still nothing.

At that point, I started preparing for the nuclear option: a full Network Reset and deep stack flush.

---

Deep dive: what comes next

Before running the reset, I learned something important. Windows needs time to uninstall and reinstall the network stack completely—adapters, services, drivers, all of it. If I reboot too soon, things can break badly. Microsoft recommends waiting about five minutes for it to finish everything under the hood.

Interrupting that process mid-reset can result in missing drivers, failed reinstalls, and total loss of network functionality.

---

What Network Reset actually does

• Removes and reinstalls all network adapters (physical and virtual)

• Wipes out VPN adapters like WireGuard

• Resets DNS, TCP/IP, proxy settings, and the firewall

• Gives Windows time to rebuild the entire network stack

---

What happened to my WireGuard VPN setup

The reset wiped the virtual network adapter and all tunnel configurations. It also removed any routing rules or firewall exceptions that had been set up.

After the reset, I had to:

• Reopen the WireGuard app

• Re-import my tunnels

• Reactivate them

• Reapply any split-tunnel, kill-switch, or firewall settings I had customized

---

Captive portal test URL I used

After resetting everything, I used the URL http://captive.apple.com/hotspot-detect.html to trigger the BYU portal. If the network is live and DHCP is functioning, this page should return “Success” or redirect to BYU’s login portal.

---

What actually fixed it

Fix #1: Full Network Reset

I went to Settings → Network & Internet → Status → Network reset.
Clicked Reset now, then waited a full 5 minutes before doing anything else.
Windows eventually rebooted on its own.

Fix #2: Deep command-line network reset

After reboot, I opened an elevated command prompt and ran:

• netsh int ip reset

• netsh advfirewall reset

• netsh winsock reset

• ipconfig /release

• ipconfig /renew

• ipconfig /flushdns

That flushed everything—old routes, DNS, firewall rules—and gave me a clean slate.

Fix #3: Reconnect and test

• Reconnected to BYU‑WiFi (forgot and re-added it)

• Reopened WireGuard, re-imported my tunnel, and activated it

• Opened Chrome (instead of Edge this time)

• Went directly to http://captive.apple.com/hotspot-detect.html

This time, I had a valid DHCP lease in the 10.x.x.x range, DNS was automatic, and the BYU login portal finally appeared.

---

Optional checks I did

• Verified that I had a real IP address (not 169.254.x.x) using ipconfig /all

• Temporarily disabled antivirus/firewall to make sure they weren’t blocking HTTP

• Also tested the portal using http://msftconnecttest.com just in case

---

Final thoughts

The full reset cleared out everything that could’ve been silently interfering with captive portal authentication—stale DNS entries, old routes, broken VPN adapters, bad proxy settings, all of it.

Once the stack was fully flushed and I used a direct trigger URL, the BYU portal finally loaded.

This has been Truncat3d 00000000111100010100110______________end of line

2025-07-09 - Active Directory 4.0 - Joining both Windows 11 Virtual Machines to the Domain

 

How I Solved the Windows 11 Domain Join Fail in My Proxmox AD Lab

I couldn’t get my Windows 11 Enterprise VMs to join the testlab.local domain hosted in Proxmox. I kept running into errors like "Domain not found" or "Active Directory Domain Controller could not be contacted."

Turns out, the issue was DNS not resolving properly over IPv6. Here's how I figured it out and got Win11Ent‑1 to finally join the domain.

---

Background

• Lab is running on a Lenovo M910 with Proxmox

• Domain: testlab.local

• Domain Controller: Server 2025 VM WIN‑BCCTIROV6RS
  → Static IP: 192.168.50.191

• All client VMs are pointed to that IP for DNS

• FSMO roles confirmed using netdom query fsmo

• Two Windows 11 Enterprise VMs (only one runs at a time with the DC)

---

Symptoms

• nslookup testlab.local on Win11Ent‑1 returned a non-existent domain and showed an IPv6 address

• Attempting to join the domain failed with “Domain not found” errors

• DNS was definitely running: the zone existed and all SRV records were in place

---

What I Did

How I Tried to Add the Workstation to the Domain

Before attempting to join the domain, I made sure the workstation was pointing to the correct DNS server:

• Set DNS Server to the Domain Controller IP

• Press Win + R, type ncpa.cpl, press Enter

• Right-click the Ethernet adapter, select Properties

• Select Internet Protocol Version 4 (TCP/IPv4), click Properties

• Select Use the following DNS server addresses:

• Preferred DNS server: 192.168.50.191

• Leave alternate blank

• Click OK, then close all windows

Attempting to Join Windows 11 Enterprise to the Domain

• Press Win + R, type sysdm.cpl, press Enter

• In System Properties, go to the Computer Name tab, click Change…

• Select Domain > entered: testlab.local

• Got error: “An Active Directory Domain Controller (AD DC) for the domain ‘testlab.local’ could not be contacted.”

  Ensure that the domain name is typed correctly. If the name is correct, click Details for troubleshooting information.

• nslookup testlab.local indicated that Windows was querying an IPv6 DNS server (instead of my IPv4 DNS at 192.168.50.191)

1. Fixing the problem, Verified DNS server is reachable

Win11Ent-1 > Open Command Prompt > ping 192.168.50.191

• 100% success

2. Checked DNS port connectivity

Win11Ent-1 > PowerShell > Test-NetConnection 192.168.50.191 -Port 53

• Port was open

3. Forced the VM to use only IPv4 DNS

Win11Ent-1 > Win + R > ncpa.cpl
Right-click Ethernet adapter > Properties
Uncheck Internet Protocol Version 6 (TCP/IPv6)

Click on Internet Protocol Version 4 (TCP/IPv4) > Properties
Set DNS server manually: 192.168.50.191
Clear alternate DNS field

4. Flushed and re-registered DNS

Win11Ent-1 > Run Command Prompt as Admin:

ipconfig /flushdns
ipconfig /registerdns

5. Tested DNS directly against the server

Command Prompt > nslookup testlab.local and also nslookup testlab.local

192.168.50.191

• Returned 192.168.50.191 as expected

• Still said "Server: Unknown" but that’s fine for now

• Entered > echo %userdomain%

• Returned TESTLAB (finally!)

6. Tried joining the domain again

Win + R > sysdm.cpl
Computer Name tab > Change…
Select Domain and enter: testlab.local
It worked this time and prompted for credentials

---

Success
Disabling IPv6 fixed it. Domain join prompt came up.

I used:

• Username: Administrator

• Password: WinServ2025

Got the “Welcome to the testlab.local domain” message. 

Restart Required After Domain Join

After successfully joining a Windows 11 workstation to the domain, a restart is required before domain credentials can be used to log in.

Here’s what I did:

• Joined the domain:
  Win + R > sysdm.cpl > Computer Name tab > Change… > Select Domain > enter testlab.local

  Enter credentials: TESTLAB\Administrator > Password: WinServ2025

• Got the success message saying the machine was added to the domain.

• Prompt appeared:

  “You must restart your computer to apply these changes.”

So I followed the prompt:

• Restarted the workstation.

• Upon Rebooting, I clicked Other User and entered TESTLAB\Administrator as the username and WinServ2025 as the password, which successfully logged me into the domain account. 

• It took a minute but it logged into the account.

•  I set up the other machine and it was very straightforward after that. Changed the DNS address statically, turned off IPv6, entered the nslookup TESTLAB and echo %userdomain% commands and added the machine to the domain, and got the right results!

---

Summary

• DNS was fine on the server.

• Client prioritized IPv6 and tried resolving via ::1 and a public IPv6 resolver.

• That broke DNS resolution until I disabled IPv6.

• Fix was: disable IPv6, force IPv4 DNS, flush and register, reattempt domain join.

If your lab VM won’t join a domain but DNS looks fine, check if IPv6 is getting in the way.

This has been Truncat3d 00000000111100010100110______________end of line

2025-05-28 - Active Directory 3.0 - Setting Up Virtual Machines to Join the Active Directory Domain

Setting Up Windows 11 Enterprise LTSC VMs and Windows Server 2025 Domain Controller in Proxmox

        I went to https://www.microsoft.com/en-us/evalcenter/evaluate-windows-11-enterprise and downloaded the LTSC version of Windows 11 Enterprise since what I am using these ISOs for is very short-lived and not wide in scope. I will be doing this on a server that I don’t believe has much power, even though my friend already in IT said it does. Now to create the VMs. I think maybe I’ll set up two for now. I will probably create a few more but not run them at the same time.

        Before I went any further I wanted to find out how much time I had left on my evaluation of Windows Server. I have been running it for several months now, not even sure how many but I just assumed I was coming up on the end soon. Wouldn't have surprised me if I had a week left because it seemed like it was such a long time ago. But I looked up the command to find out how many days or minutes were remaining on my evaluation in windows server, I don't know if this works in other OS's but I entered:

    slmgr /dlv

          This command gave me the info:

      I was told I had 181,899 minutes and 127 days left on the Windows Server evaluation. It also showed I had a remaining Windows rearm available. After looking into that, I found I can refresh the evaluation one time before needing to reinstall. That sounded like something I wanted to keep in mind.

        I hadn’t uploaded the OS ISOs to Proxmox yet, so I went to the Proxmox web interface:
Datacenter > Proxmox node > Local (proxmox) storage (where OS images go) > ISO Templates > Upload > Select File > navigated to my file server to pick the ISOs.
It took quite a while, barely passing 6% after five minutes.

        I first tried uploading the Windows 11 ISO via the Proxmox web interface, but it kept failing with error 0. Switching to SCP from my Windows laptop terminal to copy the ISO directly to the Proxmox server also failed, despite several tries.

        I discovered my 256GB NVMe drive was partitioned by Proxmox with only about 68GB for root partition, which was almost full. Running df -h and du on Proxmox showed most root space was taken up by VM backups in /var/lib/vz/dump. Apparently, my recent work to protect the Windows Server evaluation from expiring caused this space issue.

        I deleted older backups in /var/lib/vz/dump, keeping only the latest one, and adjusted Proxmox backup retention to keep just one backup going forward. This freed up significant space, and now I had plenty of room for uploading ISOs and creating VMs.

To check disk usage in /var/lib/vz and find largest folders:
du -h --max-depth=1 /var/lib/vz | sort -hr

To list backups sorted newest first:
ls -t /var/lib/vz/dump/

To delete all backups except the newest one:
ls -t /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst | tail -n +2 | xargs -r rm -f

        This command deletes all .vma.zst backup files except the latest.

        I also learned how Proxmox splits storage between root and volume groups, and how VM disks, backups, ISOs, and system files are stored separately. This helped me understand why I thought I had enough space but actually ran out on root.

        I retried uploading via the web interface, and this time it finished within a few minutes. Now I’m thinking about shrinking the thin provision size for my Windows Server VM since it’s currently 50GB and might not need that much. I thought I had 256GB total, but partitioning changes the available space significantly.

---

2025-06-10

        Yesterday I spent hours trying to get the first Windows 11 VM to boot properly in Proxmox. I must’ve recreated the VM at least 15 times chasing the same errors. Every time I tried UEFI, I got the “BdsDe: failed to load Boot0002 UEFI EMU QEMU HARDDISK” error or similar boot failures. When I switched to SeaBIOS, I could reach the installer but setup complained about not meeting Windows 11 system requirements.

        At first, I suspected specs—cores, RAM, or disk size—so I tested different virtual disk sizes: 30GB, 60GB, 64GB. I needed to keep drives small to fit multiple workstation VMs on my limited storage. The errors kept happening, and I started wondering if I really needed more than one VM.

        I imagined a job interview: “Why do you want this job if you can do advanced work like this?” they’d ask. Then, “You mean you only added one VM?” Me, smiling, “Yep!” “Well, we’ll let you know… don’t call us, we’ll call you!”

        I also experimented with many VM creation settings: toggling QEMU Agent, switching between SATA, IDE, SCSI, and VirtIO Block for system > Bus/Device, changing RAM. Nothing fixed it. I followed many instructions—some swore by VirtIO Block, ChatGPT by IDE, others recommended SCSI. I even mistakenly chose SATA once. None of these solved the two persistent errors blocking Windows install.

        Each time I recreated the VM, I followed the same process:
Datacenter > my node > right-click > Create VM.
In the wizard, selected OVMF (UEFI) under System > BIOS and added TPM 2.0 support.
For storage controller, chose VirtIO SCSI single.
Mounted Windows 11 ISO and VirtIO drivers ISO under CD/DVD.
Hard drive bus set to SCSI with 60GB or 64GB.

        Eventually, I noticed the “Press any key to boot from CD or DVD…” prompt flashed for a fraction of a second before the UEFI error. I kept missing it and letting it timeout. Once I caught it and pressed a key fast enough, the Windows 11 installer launched successfully. All previous errors were just because I wasn’t actually booting the installer.

        After wasting so much time testing drive sizes, tweaking settings, switching BIOS types, and trying to outsmart Proxmox, it was that simple. So if you get “BdsDe” boot failures or your Windows VM won’t boot from ISO, make sure you’re not ignoring the “Press any key” prompt like I did.

---

        Trevor, my second instructor at MTECH, helped me with this. When the installer finally worked, I thought, I need two VMs, and if I can’t recreate this, I’m stuck. I deleted the VM and started fresh to reproduce errors for Trevor.

        He kept suggesting starting fresh, and once I stepped away, he started the VM. Suddenly it worked. We reviewed every step from another guide online, sure we had solved the issue. We agreed to document every detail. Trevor suggested deleting that VM too since it worked now, and I reluctantly agreed.

We recreated the VM but it still didn’t work for about another half hour.

From there  went BROWSE >

I selected the drive that had VIRTIO-WIN-0.1.271 loaded in >

I selected VIOSTOR >

Selected W11 > 

AMD64 > pressed OK >

Selected RED HAT  VIRTIO  SCSI CONTROLLER > pressed INSTALL >

 selected the available disk in the case of whichever VM I was making (this is a different one)  > pressed NEXT >

From there, the installation proceeded normally. I thought it was weird the drive didn’t show up immediately like before, but it worked. Since drive space was tight, I decided to recreate the first VM rather than jump straight to the second one. For safety, I kept the first VM Trevor and I made successfully—no way I wanted to lose that progress and be stuck again. After all, I needed to keep moving forward.

        However, when I tried making the second VM, I ran into the same issue: the drive wouldn’t show up at the window prompting me to select the install location. I repeated the process of loading the VirtIO driver but was confused—why hadn’t I needed to do this for the previous VMs?

        After many failed attempts and Trevor also stumped, I researched online and found three differences in my setups:

• The successful VM didn’t use QEMU Agent

• It used VirtIO Block for the hard drive bus

• I had set disk sizes at 64GB, then 60GB (which worked), because both Windows 11 VMs had to fit within Proxmox’s 125GB partition limit (about 12GB actually allocated per VM)

        On my next attempt, I aimed for two VMs with only 30GB each, but after failing many times and retrying 60GB again, I stuck with 60GB.

        Online resources clarified the issue: VirtIO Block requires the VIOSTOR driver to show the drive during installation, while SCSI requires VIOSCSI. I had been using SCSI without understanding this.

        VirtIO Block is simpler and faster but needs VIOSTOR; SCSI is more flexible with advanced features and uses VIOSCSI.

        When I recreated the VM following this knowledge, it worked. I don’t remember if I used VirtIO Block or SCSI in the end, but I suspect VirtIO Block with VIOSTOR since I knew where to find those drivers and didn’t see VIOSCSI drivers afterward.

        Windows installed! I’m glad I kept that initial 60GB VM. Now I feel confident I know what’s needed to get Windows 11 installed on Proxmox VMs. Both VMs have 60GB disks, fitting within my 125GB limit. I don’t see a need for more VMs right now, so I’m sticking with these two and moving on.

        Setting Up Windows 11 Enterprise VMs for Active Directory Domain Join on Windows Server 2025 (Proxmox Lab)

I’m building an Active Directory lab using Proxmox with:

• A Windows Server 2025 VM promoted to domain controller with AD DS and DNS installed

• Two Windows 11 Enterprise LTSC VMs ready to join the domain

What I’ve done so far:

• Confirmed the domain controller VM is running and promoted to domain TESTLAB

• Checked the domain controller’s IP address inside the server with ipconfig — it’s 192.168.50.191

• Powered on the two Windows 11 VMs, named Win11Ent-1 and Win11Ent-2

• Noted their IPs: 192.168.50.51 and 192.168.50.106 respectively

• Changed the DNS server on both Windows 11 VMs to point to the domain controller’s IP 192.168.50.191 by:

  Pressing Win + R, typing ncpa.cpl, pressing Enter
  Right-clicking Ethernet adapter > Properties
  Selecting Internet Protocol Version 4 (TCP/IPv4) > Properties
  Setting Preferred DNS server to 192.168.50.191 > OK > Close

• Verified network connectivity between the clients and server (e.g., ping, nslookup)

• Preparing to join the Windows 11 VMs to the TESTLAB domain next.

This has been Truncat3d 00000000111100010100110______________end of line

2025-07-03 - How to Stop “Open File - Security Warning” When Opening Network Shortcuts

How to Stop “Open File - Security Warning” When Opening Network Shortcuts

If you’ve recently started seeing the annoying “Open File - Security Warning” every time you open a movie shortcut stored on a file server, you’re not alone. This is a common problem caused by Windows treating files from network locations as untrusted, especially after recent security updates.

Here’s how I tackled the issue step-by-step, and what worked.

---

Why This Happens

• Windows flags files from network shares as potentially unsafe.

• This triggers a security warning every time you open shortcuts or files.

• It can appear suddenly after Windows updates tighten security.

• Running shortcuts from a file server or mapped drive triggers this.

---

What I Tried and Why

Unblocking the Shortcut File

• Right-click shortcut > Properties > Unblock checkbox

• This often works for downloaded files but doesn’t help much for network shares.

Moving the Shortcut Locally

• Copying the shortcut to the local PC removes the warning.

• Not practical if you want to keep files centralized on the server.

Adding Server to Trusted Zone via Internet Options

• Tried going to inetcpl.cpl > Security > Local Intranet > Sites > Advanced

• No “Advanced” or “Sites” button visible — likely due to Group Policy restrictions.

---

The Solution: Adding the File Server IP to Local Intranet via Registry

Since GUI options were locked down, I edited the registry directly:

1. Open Registry Editor (regedit).

2. Navigate to:

   pgsql
   
   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Ranges
   

3. Create a new key called Range1.

4. Inside Range1, add a new String Value named :Range and set it to your server’s IP, for example:

   192.168.50.153
   

5. Add a new DWORD (32-bit) Value named file and set it to 1 (leave as Hexadecimal).

6. Close Registry Editor and reboot.

---

How to Find Your Server Name or IP for This

• Check your shortcut properties for a UNC path (\\ServerName\Share), or

• If you use a mapped drive (like S:), run net use in Command Prompt to see the real UNC path.

• Use the server name or IP from that UNC path in the registry keys.

---

Result

After reboot, the security warning disappeared when opening shortcuts on the network drive.

---

Summary

• The warning is Windows protecting you from untrusted network locations.

• GUI options to add trusted sites may be blocked by domain policies.

• Editing the registry is an effective workaround.

• Always back up your registry before making changes.

---

Feel free to share this if you’re frustrated by this recent Windows annoyance. I was too until I cracked it.

This has been Truncat3d 00000000111100010100110______________end of line