Skip to main content

Homelab Out-of-Band Management

· 11 min read
Bob Devitt
Bob Devitt
Author

Intel AMT / Active Management Technology allows remote management of hardware, virtualizing things like KVM or device mounting through a network.

Was this worth the cost of implementing it into my homelab server versus something like GLi.net's comet + fingerbot or PiKVM devices? Walmart.com's $95 deal on an Asus Q670 motherboard seemed like a steal...

My use-case​

In my own homelab, my Beelink N100 serves as the base. It's unencrypted, runs Pihole, Wireguard, and is the gateway into my home network. It is also set to power-on automatically after a loss of power. ("State after G3" -> "S0" setting under Chipset / PCH-IO Config in the BIOS. I include this tidbit here because Beelink documentation can be elusive to find)

ACPI States are an important concept to be familiar with, and are very relevant to Out-of-Band Management

OOB Management is something I can "let go" of with the Beelink, as its ability to auto power-on after a power cycle is enough for me when I am away. However, with my NAS server, it has become a higher priority.

The NAS runs several critical services in my homelab, including security systems and personal data. My NAS is LUKS encrypted, and asks for the password on boot. It is set to power-on after a power failure, but due to LUKS encryption it currently needs an attendent to pass the decryption prompt on boot.

The LUKS+TPM security debate​

There exists a solution to automatically solve the LUKS decryption prompt using TPM-based LUKS decryption with systemd-cryptenroll. There is also a nice write-up about implementing it along with Secure Boot on Github.

Booting without having to enter the decryption password sounds nice, but I don't think it fits my use case of added layers of protection vs theft. Yes, another password prompt at the OS level, along with Secure Boot to prevent a rogue OS or kernel cmdline is probably enough... but in my current view "probably" is not enough.

For this time I'll err on the side of caution. We'll allow LUKS its default behavior of prompting instead of nullifying it using a motherboard security chip. (There are quite a few heated debates if you search "TPM LUKS security")

Back to OBB Management​

OOB Management is also not a 'perfect' solution. In the event of a power cycle at say 3am, it would still require me to login and enter the decryption password. However, now I have a bit more control over pathways. One such pathway could be an Intel AMT script to send the decryption password over the network provided several conditions were met.

Intel and AMD both implement their own versions of OOB Managment: Intel AMT and AMD DASH.

In the server world, it is also well established on motherboards that have a BMC / Board Management Controller. These boards tend to be pricy and the IPMI interfaces seem to be heavily dependent on OEM / Vendor support. However If you can find/afford one that supports it, the OpenBMC project is a great open-source firmware solution that comes with its own mature ecosystem of supporting software.

For now, due to budget+time constraints, I decided to proceed with the Intel AMT solution.

Let's clarify the tree of tech here: Intel ME is a proprietary subsystem implemented on nearly all Intel chipsets since 2008. It consists of several "modules" including AMT, Secure Boot, TPM, and so on. However Intel AMT does not become "available" on the chipset unless the chipset itself supports Intel vPro and it is also paired with an Intel vPro processor.

Intel makes a nice processor finder that includes a vPro filter here which seem to be mostly Xeons and Core i5+ processors on the non-embedded side. I could not find the same convenience for chipsets, but to my understanding only Q and W series chipsets may support it (always look at the vendor specs)

The tale of hardware not being... easy​

My current NAS features a 14th gen i3 and an ASRock Z690M with 32GB of DDR4. Unfortunately this means I need both a new CPU and a motherboard. I shouldn't need more RAM, right?

I was able to narrow my search to the Asus Q670M and a Core i5-14600K. A $250 processor upgrade and a $95 motherboard seemed liked the logical way to get enterprise-level features vs compared to a more limited $350 PiKVM.

Wrench #1: DDR4 vs DDR5​

The DDR4 versions of LGA1700 Q/W-series motherboards are quite elusive. It seems almost none exist, or are bought up fairly quickly in the used market.

Manufacturers also seemed to proceed to upgrade their Q/W series LGA1700 mobos to DDR5 fairly quickly. $$$

Ok, whatever. Walmart.com still sells the Asus Q670M-C-CSM cheaper than anyone else, including the Asus store, at $95. It's a hell of a deal. (As of 11/13/2026)

Maybe I don't need 64GB of DDR5 in my main machine that I got for $220 at Microcenter in 2024, I can lend my NAS some. And maybe in the future I can set something up with all this extra DDR4.

Wrench #2: Ancient BIOS versions​

The Asus site proclaims the Q670M-C-CSM supports 14th gen Intel processors.

The fine print here is "with a BIOS update".

The Walmart deal is so cheap because they are extra stock from 07/2022 loaded with BIOS version 1401 (dated 04/2022). The manufacturer bios version is listed at the end of a sticker in between the CPU and RAM slots.

Out of the box, these will not boot or post on anything but a 12-gen Intel processor. And they do not include an Asus "FlashBack" button that allows flashing without a processor.

4 days later, ASUS support still has yet to respond with an answer. I was hoping for perhaps a BIOS update service, or CPU lender program.

Do I have an extra 12th-gen lying around? Nope. $$$

One amazon order later I have procured a 12th-gen i5.

We will flash the mobo with version 4003 dated 2026/06/17. There is a newer version 4005, but it is tagged as "beta", and it appears its main feature is increasing compatibility/performance for CXMT made memory, which interestingly politicians are currently wanting to ban in the US market.

Booted, inserted a USB drive loaded with the uncompressed firmware file, reset BIOS to defaults, and proceeded to EZFlash.

One wonky thing here is that you need to flash twice from the same file. Once for the BIOS firmware, and another for the ME (Intel Management Engine, underlying tech for VPRO/AMT) firmware. EZFlash will actually warn you about it if you try to exit prematurely. After a successful 2x flash, the system will reboot itself.

Always reset BIOS to defaults before and after flashing. My 14th-gen i5 booted perfectly afterwards.

Wrench #3: Dead CMOS battery​

Fast forward a bit. All my bios settings, AMT settings, memory settings, suddenly disappear everytime there is a power cycle. What gives?

A dead CMOS battery, of course. This thing has been sitting on a shelf for 4 years.

After replacing the CMOS battery, all settings including Intel AMT survive power cycles perfectly.

Setting it all up​

So after flashing and replacing the battery on the ancient Q670, I can finally get AMT setup and my NAS restored.

A few notes on the BIOS settings:

Nearly everything on default except the following:

I wanted my DDR5-6000 memory to be near peak performance. So I opted to load its XMP profiles by switching the performance modes under AI Tweaker. The board only supports up to DDR5-5600, so it autoset the DDR5 frequency at that after loading the XMP profile.

Ensured Intel VMT was disabled (Advanced -> SA Agent -> VMT settings) as my RAID setup was handled by the filesystem. Luckily, I opted for native RAID under my BTRFS filesystem. It did not skip a beat from replacing a motherboard and CPU, with the filesystem RAID still recognizing the HD UUIDs, confirmed with a sudo btrfs filesystem show. I am VERY thankful for this!

Under Advanced -> APM Configuration. After a power cycle, I want the server to automatically come back on. Here we set "Restore AC Power Loss" to "Power On".

Lastly we get to the AMT settings which are under MEBx. For my use case, I will assume an unattended NAS server. For this section, I have to use cell phone photos as the system will not let you view the MEBx settings with AMT connected.

First it will ask you to set a password after asking you for the current. The default password is "admin". The latest password requirements from Intel are as follows: "The password character string length should be 8-32, should contain at least one upper-case letter, one lower-case letter, one digit, and one special character."

Redirection Features: Ensure all are enabled

User Consent -> User Opt-in: NONE. Due to our unattended use case, we do not want to require user consent.

Network Access State: Network Active

Network Setup -> Network Name Settings -> FQDN: NAS

Network Setup -> TCP/IP: Fixed IP configuration. We do not want DCHP here due to the fact that both AMT here and our server operating system will be sending the same MAC address to our DHCP server.

Some sources claim that the ME has its own MAC address, but that was not the case I saw for this board - it shares the same MAC address with the host. The Network Stack and AMT->Mac Address Pass through BIOS settings made no difference. Due to its OOB behavior, the AMT should have its own fixed IP separate from the host.

So we configure a fixed IP for AMT, and we will use DHCP with a static/reserved IP lease for our host using the MAC address. This way our DHCP server doesn't assign a random IP to our in-band side due to the static lease already being taken by out-of-band AMT.

Software Options​

How do we use it?

There's a few options:

  • Intel EMA (Endpoint Management Assistant). (PDF Download)
    Intel's own proprietary management software. The older one, "Intel Management Commander", is deprecated.

  • Device Management Toolkit / OpenAMT (Github)
    Intel also sponsors an open source cloud based package that exposes APIs

  • MeshCentral (Github)
    MeshCentral is a pet project of the ex Intel engineer Ylian Saint-Hilaire that has been embraced by the open source community. It works with a wide array of hardware and does not require Intel AMT, but includes great support for it. It also includes quite a few sub-projects, including: an android agent, command line tools, and a router utility

  • You can also directly access the AMT web portal on your server at port 16993 with HTTPS. ex: https://yourserver.local:16993 though features here are limited.
    [Port 16992 / HTTP was disabled after the discovery of "Her Majesty" / CVE-2017-568 (PDF Download)]

I decided on MeshCentral for now. It's quite capable, easy to learn+setup, supports 2FA, and has great community support. For more enterprise-y environments, OpenAMT may be the way to go.

Scanning for AMT devices on the network found my NAS quickly. After adding my credentials, I was able to go to the "Intel AMT" tab and click "connect".

To activate KVM features, the client needs to send an initial request. That is done by clicking the blue text next to "Active Features" enabling KVM checkboxes, along with everything else.

Now I can go to the "Desktop" tab, click "connect" and voila - I see the LUKS decryption screen. I type my password, and boom, NAS is up.

A quick power cycle test confirms that the NAS will automatically power on, and MeshCentral again works as expected.

Conclusion​

I'm not so sure after all the wrenches if this was financially worth the additional cost of more DDR5 ram + a 12th gen CPU to use just for flashing purposes (perhaps worth keeping or lending?).

Additionally, Intel ME/AMT is proprietary in itself which is a bit against the homelab ethos. Though with some good network security, I do not think it is worth sweating about.

Also! AMT functionality being dependent on the CMOS battery is something I did not expect. (If it dies, and there is a power cycle, AMT settings get reset) An interesting quirk and risk to consider, but also another reason to get a battery backup.

However I am quite happy with the setup and access to these enteprise level features. MeshCentral also comes with some CLI features that will make scripting a breeze.

Would I do it again? Absolutely. Alternative paths may be to look into OpenBMC supported server boards when I have the budget, and also looking into the potential of OpenAMT for CLI scripts vs MeshCentral.