Akzium
  • Home
  • AI Solutions
  • Solutions
    • VMware-to-Proxmox-Migrations
    • Digital Twin Lite
    • Distributed File Systems
    • Security
    • Cloud Computing >
      • Enterprise File Sync and Sharing
    • SD-WAN
    • Secure Internet
    • Virtualization
    • Backup and Replication >
      • AS400 Backup and Replication
      • DICOM Image Backup and Archival
    • Disaster Recovery
  • Services
    • Cloud Migration Services
  • About
  • Blog

Updating Windows Secure Boot Cert for Proxmox-hosted VMs

6/27/2026

0 Comments

 
Picture
Windows Secure Boot Certificate Remediation for Proxmox VE Windows VMs


This runbook documents a safe process for remediating the Windows Secure Boot certificate expiration / Microsoft UEFI 2011-to-2023 certificate transition for a Windows virtual machine running on Proxmox VE 9.2 or later.
Scope

Applies to Windows VMs running on Proxmox VE that use OVMF/UEFI firmware with Secure Boot enabled.

This process covers:


  • Suspending BitLocker before Secure Boot key changes
  • Enrolling the updated Microsoft UEFI 2023 certificates in the Proxmox VM EFI disk
  • Triggering or verifying the Windows-side Secure Boot servicing process
  • Verifying update status
  • Re-enabling BitLocker protection


Important Concepts
1. Proxmox certificate enrollment updates the VM's virtual UEFI/OVMF Secure Boot certificate store.
2. This does not automatically guarantee that Windows has completed its own Secure Boot servicing process.
3. Windows may still need to deploy the 2023 Secure Boot certificates and install the PCA2023-signed boot manager.
4. If BitLocker is enabled, Secure Boot certificate/key changes can trigger BitLocker recovery because TPM measured-boot values may change.
5. In most cases, BitLocker should be suspended, not decrypted or permanently disabled.

Pre-Change Checklist
[ ] Confirm the VM uses UEFI/OVMF firmware.
[ ] Confirm Secure Boot is enabled for the VM.
[ ] Confirm the VM has an EFI disk.
[ ] Confirm the VM has a current backup.
[ ] Confirm the backup includes the VM's EFI disk.
[ ] Confirm the Windows BitLocker recovery key is documented and accessible.
[ ] Confirm you have administrative access inside Windows.
[ ] Confirm you have Proxmox administrative access.
[ ] Schedule a maintenance window.
[ ] Notify users/application owners as appropriate.

Step 1 - Check BitLocker Status
Start the Windows VM and log in.
Open PowerShell as Administrator and run:
manage-bde -status
Check whether drive C: or any other attached volumes are BitLocker protected.
To view protectors for C:, run:
manage-bde -protectors -get C:
If additional protected data drives exist, repeat the relevant commands for each protected drive.

Step 2 - Suspend BitLocker Protection
Do not decrypt the drive unless there is a separate operational reason to do so.
Suspend BitLocker protection on C::
manage-bde -protectors -disable C: -RebootCount 0
Alternative PowerShell cmdlet:
Suspend-BitLocker -MountPoint "C:" -RebootCount 0

Why use -RebootCount 0?
This prevents BitLocker protection from automatically resuming after a single reboot. That is useful because the Secure Boot servicing process may require more than one reboot.
If there are other BitLocker-protected volumes, suspend protection on those volumes as well.

Step 3 - Gracefully Shut Down the VM
From inside Windows, perform a normal shutdown.
Do not simply power off the VM unless Windows is hung or unavailable.

Step 4 - Enroll Updated Certificates in Proxmox
Use either the Proxmox GUI or the Proxmox CLI.
Option A - Proxmox Web GUI
1. In the Proxmox web interface, select the Windows VM.
2. Go to the Hardware tab.
3. Select the EFI Disk.
4. Click Disk Action.
5. Click Enroll Updated Certificates.
6. Confirm the action.
7. Start the VM after the enrollment completes.
Option B - Proxmox CLI
1. Make sure the VM is powered off.
2. Open the shell on the Proxmox node.
3. Run the following command, replacing <VMID> with the actual VM ID:
qm enroll-efi-keys <VMID>
Example:
qm enroll-efi-keys 104
4. Start the VM after the command completes.

Notes
- The Proxmox warning commonly references the marker ms-cert=2023k.
- If the VM is missing the 2023 Microsoft certificates, Proxmox may display a warning about outdated UEFI certificates.
- The CLI method requires the VM to be shut down.

Step 5 - Start Windows
Boot the Windows VM normally.
Expected result:
- Windows should boot normally.
- BitLocker should not prompt for a recovery key if protection was properly suspended.
- If BitLocker recovery still appears, use the documented recovery key.

Step 6 - Trigger or Verify Windows Secure Boot Servicing
The Proxmox certificate enrollment updates the VM firmware certificate store, but Windows still needs to complete its own Secure Boot update process.

Windows uses the Secure-Boot-Update scheduled task:
\Microsoft\Windows\PI\Secure-Boot-Update

For IT-managed or manual deployment, Microsoft documents using the AvailableUpdates registry value.
Open PowerShell as Administrator and run:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
-Name AvailableUpdates `
-Type DWord `
-Value 0x5944

Then run the scheduled task:
Start-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update"

Reboot as required.
The Secure Boot servicing process may require more than one reboot.

Step 7 - Verify Windows Secure Boot Update Status
After Windows has rebooted, open PowerShell as Administrator and run:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
-Name UEFICA2023Status,UEFICA2023Error,UEFICA2023ErrorEvent
Expected successful status:
UEFICA2023Status : Updated
Common status values:
- NotStarted
- InProgress
- Updated
If the status is InProgress, allow the servicing process to continue and reboot again if required.
If an error is shown, record:
- UEFICA2023Error
- UEFICA2023ErrorEvent
- Any related Windows Event Viewer entries
Step 8 - Re-Enable BitLocker Protection
After confirming that Windows boots normally and Secure Boot servicing is complete, re-enable BitLocker protection.
Command-line option:
manage-bde -protectors -enable C:
PowerShell option:
Resume-BitLocker -MountPoint "C:"
Verify status:
manage-bde -status
Confirm that protection is enabled again.
Step 9 - Final Validation
Perform the following checks:
[ ] Windows boots normally.
[ ] No BitLocker recovery prompt appears.
[ ] BitLocker protection is enabled again.
[ ] Secure Boot remains enabled.
[ ] Windows Secure Boot servicing status shows Updated, if applicable.
[ ] Applications/services start normally.
[ ] Event Viewer does not show new Secure Boot or BitLocker errors.
[ ] Backup system recognizes the VM normally after the change.
[ ] Change-control ticket is updated with results.

Rollback / Recovery Notes
If the VM fails to boot after certificate enrollment:
1. Do not repeatedly force power off the VM without capturing the error.
2. Record the exact boot error message.
3. Confirm whether the VM is using OVMF/UEFI and Secure Boot.
4. Confirm whether the EFI disk is present.
5. Confirm whether the correct VMID was used for CLI enrollment.
6. Attempt boot repair only after confirming a valid backup exists.
7. If BitLocker recovery appears, enter the documented recovery key.
8. If necessary, restore the VM from backup, including the EFI disk.
Change-Control Summary
Enroll updated Microsoft UEFI 2023 Secure Boot certificates for Windows VM running on Proxmox VE and verify Windows Secure Boot servicing status.

Risk:
Secure Boot certificate/key changes may alter TPM measured-boot values and trigger BitLocker recovery if BitLocker protection is not suspended first.

Mitigation:
- Confirm current VM backup.
- Confirm BitLocker recovery key.
- Suspend BitLocker protection before certificate enrollment.
- Enroll updated Proxmox EFI certificates while VM is powered down.
- Verify Windows Secure Boot servicing status.
- Resume BitLocker after successful validation.

Commands Summary
Check BitLocker:
manage-bde -status
manage-bde -protectors -get C:
Suspend BitLocker:
manage-bde -protectors -disable C: -RebootCount 0
Alternative:
Suspend-BitLocker -MountPoint "C:" -RebootCount 0
Enroll Proxmox EFI keys:
qm enroll-efi-keys <VMID>
Set Windows Secure Boot update registry value:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
-Name AvailableUpdates `
-Type DWord `
-Value 0x5944
Run Windows Secure Boot update task:
Start-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update"
Verify Windows Secure Boot servicing:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
-Name UEFICA2023Status,UEFICA2023Error,UEFICA2023ErrorEvent
Resume BitLocker:
manage-bde -protectors -enable C:
Alternative:
Resume-BitLocker -MountPoint "C:"

Source References
Proxmox forum - UEFI 2011 certificates expire in June 2026:
https://forum.proxmox.com/threads/uefi-2011-certificates-expire-in-june-2026.183799/

Proxmox VE 9.2 release announcement:
https://forum.proxmox.com/threads/proxmox-virtual-environment-9-2-available.183742/

Microsoft - Secure Boot troubleshooting guide:
https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d

Microsoft - Registry key updates for Secure Boot Windows devices with IT-managed updates:
https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

Microsoft - manage-bde protectors command:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/manage-bde-protectors
0 Comments

Proxmox Networking Linux Bridge vs OVS Bridge

6/1/2026

0 Comments

 
Picture
Proxmox virtual switches and networking demystified: Trunk-mode Ports and Access-mode Ports

One common question regarding Proxmox network setup is WHICH of the options to use when creating Proxmox network interfaces when you need to pass multiple VLANs across a Trunk-mode switch port versus simple access-mode port setups.

Here's a quick cheat sheet:

Trunk mode required:

Linux VLAN interfaces (eno1.10, bond0.20)
Physical NIC (eno1)
└── VLAN interface (eno1.10)
└── Linux Bridge (vmbr10)
└── VM vNICs

VLAN-tagged OVS IntPorts
Physical NIC (eno1)
└── OVS Bridge (ovsbr0)
├── OVS Port (eno1) ← uplink, trunk to switch
└── OVS IntPort (vlan10) ← internal port, tagged VLAN 10
└── Linux Bridge (vmbr10) ← optional, for VM attachment
└── VM vNICs

Trunk mode optional These can run as simple access bridges or VLAN-aware bridges depending on how you configure them:

Linux Bridges
Physical NIC (eno1) ← trunk port on switch
└── Linux Bridge (vmbr0) ← VLAN-aware bridge
├── eno1 (uplink port, trunk)
├── VM vNIC (VLAN 10) ← tagged or untagged per port config
└── VM vNIC (VLAN 20) ← tagged or untagged per port config

OVS Bridges
Physical NIC (eno1) ← trunk port on switch
└── OVS Bridge (ovsbr0) ← single bridge, all VLANs
├── eno1 (uplink port, trunk)
├── VM vNIC (port tagged VLAN 10)
├── VM vNIC (port tagged VLAN 20)
└── VM vNIC (trunk port, multiple VLANs)

Access-mode switch port connections:

A Linux Bridge itself can have multiple IP addresses (small configuration with management and corosync on the same bridge for example).

Physical NIC (eno1) ← access port on switch (single VLAN)
└── Linux Bridge (vmbr0) ← simple bridge, no VLAN awareness
├── eno1 (uplink port)
├── VM vNIC (VM1)
└── VM vNIC (VM2)

vmbr0 ← bridge interface itself gets IPs
├── 192[.]168[.]10[.]1/24 ← primary IP (host management)
└── 192[.]168[.]10[.]2/24 ← secondary IP (additional host service)

An OVS Bridge is different than a Linux Bridge in that while OVS is just a Layer-2 virtual switch, you can't assign an IP directly to the OVS bridge itself, you need an OVS IntPort for that.

Physical NIC (eno1) ← access port on switch (single VLAN)
└── OVS Bridge (ovsbr0) ← single broadcast domain
├── eno1 (uplink port)
├── OVS IntPort (ovsbr0-mgmt) ← internal interface exposed to kernel
│    ├── 192[.]168[.]10[.]1/24 ← primary IP
│    └── 192[.]168[.]10[.]2/24 ← secondary IP alias
├── VM vNIC (VM1)
└── VM vNIC (VM2)

A Linux Bond or an OVS Bond can connect using Access Mode or Trunk Mode.

Get this one decision right before you touch anything else, and the rest of your Proxmox network config starts to make a lot more sense.
0 Comments

CISA SCuBA Goggles and SCuBA Gear

4/24/2026

0 Comments

 
Picture
In 2023 the Cybersecurity and Infrastructure Security Agency (CISA[.]gov) introduced their Secure Cloud Business Applications (SCuBA) project with two sub-projects: SCuBA Gear for M365 and SCuBA Goggles for Google Workspace.

These secure configuration baselines (SCBs) for Microsoft 365 (M365) and Google Workspace (GWS) provide easily adoptable recommendations that complement an organization’s unique requirements and risk tolerance levels. The baselines include automation features to help federal agencies, businesses and organizations rapidly assess their M365 and GWS services.

ScubaGear is a no-cost assessment tool that verifies M365 tenant configuration alignment to the policies described in SCuBA’s secure configuration baselines. CISA has made this tool and the baselines available to all agencies and private sector organizations seeking security improvements. Visit CISA’s GitHub and PowerShell Gallery to view the M365 baselines and download the ScubaGear assessment tool.

ScubaGoggles is a no-cost assessment tool that verifies a GWS organization’s configuration conforms to the policies in SCuBA’s secure configuration baselines. ScubaGoggles provides a breakdown of security vulnerabilities in GWS, allowing organizations to see where changes should be made to their configuration. CISA has made this tool and the baselines available to all agencies and private sector organizations seeking security improvements. Visit CISA’s GitHub or Python Package Index page to view the GWS baselines and download the ScubaGoggles assessment tool.

Source: CISA[.]gov: https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project
0 Comments

Deploying IBM Virtual HMC (vHMC) 11 on Proxmox

4/11/2026

0 Comments

 
Picture
IBM Virtual Hardware Management Console 11 (vHMC-11) Dashboard Example
IBM only provides instructions for deploying the Virtual Hardware Management Console on KVM running on Red Hat or Ubuntu, neither of which will probably be running in most datacenters that have an IBM Power system.

So, we undertook the task of figuring out how to deploy the new vHMC version 11 on Proxmox and the IBM instructions for KVM deployment are of no help for this endeavor. After downloading the ~6.8GB IBM vHMC tar.gz file, you'll need to unzip to a folder, resulting in a nearly 13GB .tar file. Don't try to expand this file unless you have about 510GB (yes, gigabytes) of extra disk space on your PC. If you DO have that extra space, the .tar file expands into a 500GB disk1.img file and four other files (see image below)
Picture
Files in the IBM vHMC 11 for KVM tar archive
If you have the extra disk space on the PC to expand the .tar file you can then use WinSCP to secure copy the file over to the Proxmox server, again taking care to make sure you have enough disk space (510GB EXTRA Gigabytes) to /tmp or /var/tmp.

In our case, we needed a "bridge" to park the expanded tar archive so we elected to use a NAS storage device that supported both SMB/CIFS as well as NFS 4.x.

​Then, on the Proxmox server we mounted the shared folder as an NFS mount on the Proxmox server (see image below) which created three subfolders: images, import, and template . After mounting the shared folder on the NAS to the PC and using an archive extraction tool we unzipped the files to the shared folder's subfolder named IMPORT.
Picture
Proxmox - mount NFS storage
Next, you need to create a virtual machine definition on the Proxmox server, but on the tab for Disk you remove the default disk, creating a VM definition with CPU, RAM and networking but no pre-provisioned disk space. Now that the VM is created, notate the VM ID number, in our example here the ID is 101.

Now, we will use the QM IMPORTDISK command to convert the disk1.img file into a Proxmox QEMU disk image file.

​Select the Proxmox server node you want to use for the import, click on >SHELL to get a command line, and navigate to the mounted NFS share:

cd /mnt/pve/vz/INSERT_NFS_NAME_HERE/import

If you do a ls -la command you will see the files extracted from the .tar file
Picture
List of files from vHMC .tar archive
The syntax for the import command is as follows:

qm importdisk VMID /LOCATION_OF_img_FILE/disk1.img TargetStorageName

In our example the command is as follows, which places the converted .img file onto our internal ZFS storage array:

qm importdisk 101 /mnt/pve/synnas01/import/disk1.img pxmxsvr1ZFS

***(remember, do NOT leave the SHELL environment until the import is COMPLETE or it will abort the command)***
Picture
qm import disk command example to import .img file
Once the disk1.img file has been imported you can go back to the Proxmox manager and select your VM and go to the Hardware tab. You will see a device name Unused Disk 0.
Picture
Click on the Unused Disk 0 and select EDIT from the top menu, which will initiate the Add Unused Disk wizard. Click on ADD and the imported disk will now be added to the new vHMC virtual machine.
Picture
Once this process is complete, you can edit any other VM hardware items as needed. The base vHMC image configures four (4) network adapters within the virtual machine. Eth0 is intended to be the management interface and Eth1 is the primary interface for the HMC port vLAN. In smaller environments your vHMC and the Power System HMC port may be configured on the same VLAN. Adjust the quantity of network adapters as needed. IBM's default recommendation is for (4) virtual CPUs and 16GB of RAM.

Once these items are modified as necessary, there is one more order of business to tend to: adjusting the BOOT ORDER of the devices so that the VM will boot when you start it.

​Navigate to Options -> Boot Order, and check the box for Enabled next to the scsi0 disk, then grab the hamburger menu next to the #3 and drag the scsi0 device to the top of the boot order list. Then click OK.
Picture
Change VM virtual disk boot order
Click on START to power on your new vHMC virtual machine and then >Console to watch the boot process. Once the boot cycle completes (yes, it takes FOREVER to boot) then you can log into the management GUI (hscroot / abc123) and begin the configuration process for setting up the network(s) devices.

​Your mouse will NOT work on the two initial setup questions that pop up, you will need to use the keyboard arrow keys and the TAB key.
​
*note: network changes will not take effect until the vHMC is rebooted.
Picture
IBM vHMC 11 login screen
Picture
IBM vHMC 11 Main Dashboard
0 Comments

Multiple DHCP Scopes in Windows Server DHCP

2/5/2026

0 Comments

 
Picture
If you're using a Windows server as a DHCP server, you can configure multiple DCHP scopes for different VLANs. 


There are two main concepts to understand for this setup: 


1) Each scope needs a route to reach the intended VLAN via the route setting in the scope; 


2) Your core switch that controls your VLAN settings needs to have a "helper IP" set to know where to route DHCP requests on each VLAN. In addition to these settings, the DCHP server's assigned VLAN and static IP address must have the ability to reach each VLAN segment that it is serving via inter-VLAN routing if the DCHP server only has a single network interface.

So, don't put your DCHP server on a VLAN with other servers or devices that should not be reachable by endpoint devices that it is servicing for DCHP requests. For example, don't put your DCHP server on your servers VLAN and have it serve up DCHP requests for your Guest Wifi VLAN.

Also, just a quick note about the Filters setting. Filters are applied to the entire DHCP server instance, not on a per-scope basis. If you enable ALLOW filtering, only those MAC addresses listed in the Allow filter list will get an IP address via DCHP. All other DHCP requests will be denied. If you enable DENY filtering, any MAC address in the Deny filter list will be denied an IP address while all other devices will be assigned an IP.

0 Comments

Installing Uptime Kuma on Ubuntu 24.04

5/5/2025

0 Comments

 
Picture
These instructions assume the installation of Ubuntu 24.04 has already been done. The example USERID for the Ubuntu login will be UbuntuUser. The example USERID for the Uptime Kuma admin screen will be KumaAdmin. Adjust instructions accordingly.

Log in to the Ubuntu instance and launch a terminal window.
In our example, this will put us in the /home/UbuntuUser folder.
Verify your folder ID by typing pwd at the terminal command promt 

sudo apt-get update -y

sudo apt-get upgrade -y

sudo apt-get install nodejs -y

sudo node -v to check the nodejs installed version

sudo apt-get install git -y

sudo git clone https://github.com/louislam/uptime-kuma.git

You can verify the git clone process by typing ls -l at the prompt which should now show an uptime-kuma folder

sudo apt-get install npm --no-install-recommends

at the /home/InsertUserIDHere prompt type: cd uptime-kuma

sudo npm run setup
*this will install uptime-kuma

sudo npm install pm2 -g

**PM2 is a production process manager for Node.js applications with a built-in load balancer. It allows you to keep applications alive forever, to reload them without downtime, and to facilitate common system admin tasks.

sudo pm2 install pm2-logrotate

*You should see output similar to the image below:​
Picture
Verify your location is still /home/InsertUserIDhere

cd uptime-kuma
*type pwd to verify location is /home/InsertUserIDHere/uptime-kuma

sudo pm2 start server/server.js --name uptime-kuma

*You should see output similar to the image below:
Picture
If you do not see this output, then type:

sudo pm2 status

Now, type:

sudo pm2 startup

sudo pm2 save

cd /etc/systemd/system

sudo nano pm2-root.service

find the line labeled Environment=PATH=....

go to the end of the line

add the following:  :/home/InsertUserIDHere/uptime-kuma/server
*note: be sure to include the : and do not put a space after the end of the previous entry on the line

Ctrl+O to write file edits to disk. Ctrl+X to exit nano editor

Now, we'll install the Nginx web server:

sudo apt-get install nginx -y

sudo nano /etc/nginx/conf.d/kuma.conf

Add the following lines:
​
server {
   listen 80;
   servername kuma.example.com;
   location / {
        proxy_pass                http://localhost:3001;
        proxy_http_version  1.1;
        proxy_set_header     Upgrade $http_upgrade;
        proxy_set_header     Connection "upgrade";
        proxy_set_header     Host $host;
   }
}

Ctrl+O to write file to disk. Ctrl+X to exit nano editor.

Now, copy the kuma.conf file to /etc/nginx/sites-available folder by typing:

sudo cp /etc/nginx/conf.d/kuma.conf /etc/nginx/sites-available/kuma
*note: leave the .conf off of the target filename

Now, create a symbolic link in the /etc/nginx/sites-enabled folder to the kuma file in the /etc/nginx/sites-available folder

sudo ln -s /etc/nginx/sites-available/kuma /etc/sites-enabled/kuma

Verify the link by:
cd /etc/nginx/sites-enabled
sudo ls -la
There should be a kuma symbolic link file in the /etc/nginx/sites-enabled folder

Remove the Nginx default website link
cd /etc/nginx/sites-enabled
sudo rm /etc/nginx/sites-enabled/default
sudo ls -la 

Reboot the host:
sudo reboot 

Now, you should be able to navigate within the Kuma host linux system using a browser to:
http://localhost:3001

This will bring up the initial setup Kuma administrator login screen.

**NOTE:  Be careful in choosing your admin USERID here as there is not a simple process for changing this ID once it is created and written into the SQLlite database.
Picture
0 Comments

Remove Ghost Network Adapters in Windows

4/19/2025

0 Comments

 
Picture
Ghost adapters left behind by physical-to-virtual conversions have been an issue since the early days of virtualization. The Great VMWare Exodus has brought this issue back into the limelight as Broadcom customers begin to abandon VMware in favor of more customer-friendly Type 1 Hypervisor companies.

If you're preparing to migrate a VMware virtual machine over to, let's say a KVM-based Type-1 Hypervisor environment, there are several preparation steps that should be undertaken, the first of which will be to change the network adapter from a static IP addresss to a DHCP address, and to remove the VMware Tools. If you forget to remove VMware tools prior to conversion, the converted VM may not boot. If you forget to manipulate the network LAN adapter settings, you could end up with a "ghost" adapter, one that has entries in the Windows registry, but that does not show up in device manager. If you also forgot to change the static IP address to a DHCP address, the static IP could be "trapped" by the ghosted adapter and Windows will give you error messages saying another adapter already has that IP address.

Here's how to "reveal" those ghosted adapters so you can clean up the mess left behind by a hypervisor platform migration.

1. Launch a command prompt as administrator in the VM.
2. Run: set devmgr_show_nonpresent_devices=1 (press enter)
3. Launch Device Manager (devmgr.msc or devmgmt.msc)
4. In Device Manager -> View select "Show Hidden Devices"
5. Scroll down to Network Devices and expand
6. Ghost adapters will be greyed out - right click and Uninstall
7. Select Action -> Scan for Hardware Changes to refresh device list
8. Repeat as necessary until all ghost adapters are removed

Windows OS Hub has a write-up on this process here: https://woshub.com/remove-hidden-ghost-network-adapter-windows/

Interworks has a blog post about the topic here:
https://interworks.com/blog/ijahanshahi/2014/08/21/removing-hidden-device-device-manager/

The official VMware-to-Proxmox conversion instructions are here: 
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE

Scale Computing has their own SC//Migrate toolkit to make VMware to Scale migrations easy:
https://www.scalecomputing.com/resources/sc-migrate-data-sheet
0 Comments

Windows Server Change Time Commandline

4/15/2025

0 Comments

 
Picture
Ever join a server to the domain and forgot to change the time zone beforehand, then the Time Zone GUI change options are greyed out? There's a way around that using either a command line option or via PowerShell.

Option1: Invoke CMD as administrator
tzutil /g (displays current time zone)
tzutil /l (displays all time zone options)
tzutil /s "Central Standard Time" (sets time zone)
tzutil /g (to verify change)

Option2: Invoke Powershell as administrator
Get-TimeZone
Get-Timezone -ListAvailable
Set-Timezone -Id "Central Standard Time"
Get-TimeZone
​
0 Comments

Add email aliases to personal Gmail accounts

4/14/2025

0 Comments

 
Picture
Creating email aliases for work emails is common, but did you know you can also create emails aliases for your (at)gmail(.)com email address using Gmail+ email aliases? Example: if your email is bobsmith(at)gmail you can create an alias email such as bobsmith+myamazonorders(at)gmail, use that alias for receiving emails and they will come to the inbox for your primary email account.

Here are the steps:
1. Log in to your personal gmail account in a browser
2. Go to the Settings gear icon at the top right
3. See all settings
4. Go to the Accounts and Import tab
5. Navigate down to Send Email As section
6. Click on Add another email address
7. The the email address box type your email addres and a + sign and whatever you want to add to it (ex: bobsmith+myamazonorders(at)gmail, but use the actual at sign. LinkedIn keeps trying to link when I attempt to use it in a post.
8. Make sure the "Treat as an alias" box is checked

Now you can use this alias email as a filter or in some cases to sign into a website that is having problems directing you do different sign-in functions using the same email address.

MailMeteor has a good write-up outlining the steps here: https://mailmeteor.com/blog/gmail-alias

Streak has a blog post about the process here: https://www.streak.com/post/gmail-plus-addressing-trick

*kudos to Streak for the cool graphic below this post. 


0 Comments

Easy File Server Migrations

4/7/2025

0 Comments

 
Picture
The registry key that contains all of the shares and share permissions on a Windows file server is located: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
and the Security subkey. You can export this key set from your current file server, mount the shares data drive to a new server with an updated OS and import this registry key to restore all of the shares and their associated permissions. Since you've moved the data drive to the new server, all files retained their NTFS permissions. Also, this detach/re-attach process assumes you're not using DFS.

So, step by step (assuming you're doing this in a virtual environment):
1) Create new VM with virtual HDD for OS
2) Install new OS, patch, update, etc. (Do not join to domain yet)
3) Export registry key from old file server
4) Copy registry key file to new file server
4) Unjoin old file server from domain
5) Change server name and IP address of old file server and shut down
6) Detach data volume virtual disk from old file server
7) Change server name and IP address of new file server to match old server and reboot sever
8) Join new file server to domain
9) Attach data drive virtual disk to new file server and mount with same drive letter as it had on the old file server
10) Import registry key from old file server
11) Reboot new file server

Instructions for Exporting Registry Key from old server:
Navigate to:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
Right click on Shares in the left-side view window
Select Export
Name file. Example: filesharesexport.reg
copy this file to the new server

Instructions for Importing Registry Key to New Server:
Open Registry Editor on the new server. 
Go to File > Import
Navigate to the location where you copied the .reg file. 
Double-click the .reg file to start the import process. 
You may be prompted to confirm the import, click "Yes" to proceed. 
The registry key will be added to the registry on the new server. 

At this point your new file server has the data volume mounted from the old file server and the shares permissions have been imported. I'll make a separate post on some ways to consolidate the new VM data files with the old server data virtual disk into a single folder.

*edit: One problem we have become aware of in using this process is the shared folder OWNER permissions. If the shared folder on the source system is OWNED by a LOCAL administrator user, the NTFS and share permissions of the sub-folders WILL NOT be applied on the target system. Local user \\Server1\Administrator is NOT the same as local user \\Server2\Administrator, even though the names are the same. To "fix" the issue, we changed the OWNER of the root folders on the source system to a DOMAIN admin user with local admin rights on the source and target servers. After that change, the sub-folder permissions were applied properly on the target system after the .reg key import. This is also a problem if sub-folder permissions were granted using local users instead of domain users on the source host.

If you are migrating a physical file server to a virtual machine, or possibly migrating a VM-based file server to an new VM on a different platform, you can create a root shared folder on the target system, map a drive to the shared folder from the existing file server, and use a robocopy job to copy the data to the new server.

Example1: robocopy e:\rootshare r:\remoteshare /e /copy:datso /z /MT:128

Example 2: robocoy e:\rootshare r:\remoteshare /mir /z /MT:128 /LOG+:logfilename.log
​
After the copy job finishes and is validated, export the registry key that stores the share permissions data from the existing file server and then import the exported .reg file into the new file server's registry.

I recently had a customer's file server boot drive MBR record get irreparably corrupted. We mounted the boot volume to the new file server as a data disk, used the remote registry mount utility to mount the \Windows\System32\Config\SYSTEM registry file and export the shares registry key. When you use the remote mount utility you have to give it a temporary name. Thus, when you export the key the registry file header data has the temporary name in the (2) header paths instead of the correct header path names. We had to correct those using notepad to edit the .reg file two header data paths as follows before attempting to import the shares key into the new file server.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security]

Don't forget to change the notepad save settings to *.* to preserve the .reg file extension.

Link to all Robocopy Commands: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy
0 Comments
<<Previous

    Author

    Akzium team blog

    Archives

    June 2026
    April 2026
    February 2026
    May 2025
    April 2025
    March 2025
    January 2025
    December 2024
    November 2024
    October 2024
    July 2024
    November 2022
    September 2022
    August 2022
    July 2022

    Categories

    All
    Alias Gmail
    Apache Log4J
    AWS EC2 IIS File Share
    BypassNRO
    Chrome Browser GPU
    CISA
    Default Gateway
    DHCP
    DHCP Backup
    DHCP Restore
    DHCP Scopes
    DiskPart
    Endpoint Security
    File Server Migrations
    File Server Registry Key
    File Server Resource Manager
    File Shares Registry Key
    Fix Windows Secure Boot Certs
    Ghost Network Adapters
    Gmail Alias
    Gmail Email Alias
    IBM 5250 Terminal
    IBM BOMC
    IBM Firmware Updater
    IBM FlashSystem Firmware Update
    IBM VHMC 11
    IIS
    Internet Information Services
    Lenovo BOMC
    Lenovo Firmware Updater
    NTP
    Proxmox
    Proxmox Linux Bridge
    Proxmox Linux VLAN
    Proxmox Networking
    Proxmox OVS Bridge
    Proxmox VLANs
    Proxmox Windows Secure Boot Fix
    RaspberryPi 4b
    RaspberryPi 4b 5250
    Recovery Partition Relocate
    SCuBA Gear
    SCuBA Goggles
    Secure Baseline 365 GWS
    Security Registry Edits
    Self Signed SSL
    Set Chrome To Use GPU
    Time Server Change
    Uptime Kuma
    Uptime Kuma Ubuntu Install
    Virus Scanner
    VMware
    Windows 11
    Windows 11 Developer Console
    Windows File Server
    Windows IIS File Sharing
    Windows Quick Assist
    Windows Route Command
    Windows Sandbox
    Windows Script Host
    Windows Secure Boot Cert Remediation
    Windows Server 2022 Recovery Partition
    Windows Shared Experiences
    Windows Time

    RSS Feed

Akzium, LLC | 601-841-2499     .     [email protected]
Copyright 2011-2026, Akzium, LLC.  All rights reserved.