Evan Ireland

My New Work Laptop Was Not Quite What It Said on the Box

Thu, 01 Oct 2026 12:30:00 -0600

Windows Autopilot device preparation is Microsoft’s newer way of setting up a work computer: you unbox a Windows laptop, sign in with a work account, and the laptop configures itself - joins the company’s identity system, enrolls in management, installs the company’s apps, turns on encryption - without IT ever touching it. Microsoft’s documentation calls it “Autopilot device preparation”; most of the internet calls it “Autopilot v2.”

Documentation at Microsoft Learn.

Cards on the table before we start: this is my own business laptop, and I used it as a lab. I could have turned it on, clicked through setup, and started working in twenty minutes. Instead I set it up exactly the way I would set one up for a client, so I would have done it once for real before anyone pays me to do it. That took two evenings instead of twenty minutes. Worth it - and as you are about to see, the laptop made it worth it in ways I did not plan on originally.

How I got here

My own small-business tenant runs on Microsoft 365 Business Premium (with Copilot). That license includes Intune, which is Microsoft’s tool for managing company devices, and Entra ID, which is the identity system behind every Microsoft 365 sign-in. I built the tenant a week earlier. What it did not have yet was a single managed device in it - which is a strange state of affairs for someone who wants a job managing other people’s devices.

So the new laptop had a job before it ever opened a spreadsheet: be the first managed endpoint, built the client way, documented well enough to hand to the next person.

The goals, in plain terms:

Join it to the business with Microsoft Entra join - the cloud-only kind, no server in a closet.
Have it set itself up with Autopilot device preparation.
Strip out the consumer bloatware without losing Copilot, which I am paying for.
Make sure I am not an administrator on my own daily laptop, and prove that the emergency admin account (Windows LAPS) works end to end - something my old homelab never quite achieved.

Real enthralling stuff I know. Let’s get into it, shall we?

Three ways to join a Windows PC, explained with an office building

If you have ever worked in an office, you have seen all three of these, you just did not know it.

Picture the old way first. Your company owns the building. There is a front desk in the lobby, and every computer in the building has to check in with that desk to let anyone sign in. That front desk is a domain controller, and joining a computer to it is a domain join. It works beautifully - as long as you are inside the building. Take the laptop home and it is trying to check in with a front desk it cannot see.

Hybrid join is what happens when that company also signs up for a cloud office. Now your laptop has a badge for the building and a badge for the cloud, and the two front desks keep copying notes to each other. I built exactly that in my homelab. It works, and it is a lot of moving parts.

Microsoft Entra join gets rid of the building. There is no lobby and no front desk on site. Your badge is issued by the cloud, checked by the cloud, and works the same at the office, at home, or in a hotel. For a one-person business with no server room, it is the only one of the three that makes any sense (I mean, for now anyways. I am someone who recreationally builds server clusters in their basement after all…).

Simply put: domain join trusts a building, Entra join trusts the company.

Back to the laptop…

The prep work happens before the laptop is ever turned on

A note on names: real device and account names are swapped for placeholders below (<ORG> is the business prefix), and identifiers in the screenshots are blacked out.

Most of this build happened in a web browser before the laptop came out of the box. Autopilot device preparation needs the tenant ready for it, and the tenant preparation is the part that transfers to every client.

Step	What was configured	Why
Entra device settings	Users may join devices; Entra LAPS on; “registering user is local admin” None; “Global administrator role is added as local administrator” No	The last one is the setting that stops the daily-driver account becoming an administrator on every device it joins
Automatic enrollment	MDM user scope set	This is what turns “joined to Entra” into “managed by Intune”
Two security groups	A user group (who the setup policy targets) and a device group (where new laptops land)	The device group is owned by Intune’s own provisioning service, so Intune can drop a new laptop into it mid-setup
Required apps	Company Portal and Microsoft 365 Apps, to the device group	Only what has to exist before first sign-in
Platform script	A logged, exact-name removal script for consumer apps, Copilot explicitly protected	Debloat as code, not a click-through tool
Security policies	BitLocker (XTS-AES 256, key escrowed to Entra) and Windows LAPS (managed account `<org>-lapsadmin`, passphrase, reset 24 hours after use)	The laptop arrives encrypted with an emergency admin account already in place
Setup policy	User-driven, Entra joined, standard user, name template `<ORG>-%SERIAL%`	The policy that ties everything together

Entra device settings - the Global Administrator role is not added as a local administrator, and Entra LAPS is on The device preparation policy (support message, device name template and script name blacked out)

One snag surfaced immediately. The device group has to be owned by a Microsoft service called the Intune Provisioning Client, and in a brand-new tenant that service did not exist yet. It was created with one PowerShell command (New-MgServicePrincipal with Microsoft’s App ID), then added as the owner. Every new client tenant will need the same step, which is exactly the kind of thing I wanted to find on my own tenant first.

Creating the missing service principal with Microsoft Graph PowerShell (object ID blacked out)

Why not a pre-built bloat tool

I have used the Chris Titus Tech utility on personal machines and I like it. On a managed business device it is the wrong tool. Its tweaks change services and settings that the management platform is also trying to control, and none of it is repeatable or auditable across ten clients. The skill worth practicing is removing apps through the management platform, so the same script runs the same way on every device and leaves a log behind.

Honest performance note, because someone will ask: on a Ryzen 7 with 32 GB of RAM, removing Solitaire buys you approximately nothing you can measure. The real gain from this build is a clean Windows install with no reseller software on it. Which brings us to the reseller.

The laptop

inb4: Do NOT automatically trust a PC you bought on Amazon just because you bought it on Amazon - especially if it’s not SOLD by Amazon. You can definitely see where this is going.

Before wiping anything, the laptop was checked. A read-only PowerShell script was run from a USB stick at the very first setup screen, offline, to record what the seller had actually shipped before that evidence was erased by a clean install. Lenovo’s own warranty site was checked by serial number at the same time.

Check	Expected from the listing	Found
Warranty	On-site, full term	Depot, under six months left, registered ship-to location India
Windows license in firmware	A Pro key embedded by Lenovo	None
Windows activation	Retail or OEM Pro	Volume license (MAK) key - a key issued to an organization, on a laptop sold to an individual
Memory	32 GB as a matched pair	One 32 GB stick from an unidentified manufacturer - so the memory runs single-channel
Secure Boot	On	Off
Activation hacks / reseller software	None	None found

Lenovo’s records: depot warranty ending March 2027, ship-to location India (serial, model suffix and QR code blacked out) The BIOS as received - Secure Boot off (serials, UUID and MAC address blacked out)

Nothing malicious turned up. That is not the same as clean, and a business laptop gets treated as untrusted until it is proven otherwise.

The part worth explaining is the license, because it fooled Windows itself. The installed copy said “Licensed (activated).” Activated is not licensed. A volume key belongs to whatever organization bought it; it does not legitimately ride along on a single laptop sold on Amazon. And the Microsoft 365 Business Premium subscription does not fix that: its Windows rights are an upgrade on top of a legitimate Windows Pro license, not a license on their own.

I had a choice: return it, or keep the hardware and fix everything else. With memory prices where they are in 2026, I kept it. The decision was to scrub it, reinstall from Microsoft’s own media, buy a retail Windows 11 Pro key, and replace the memory.

I’m far too lazy to try and return something I bought online, so onwards we continue.

Scrub, wipe, reinstall

The firmware was reset before anything else, in this order:

The TPM security chip was cleared, removing any keys left by the previous builder.
BIOS defaults were loaded, then Secure Boot and AMD virtualization were turned back on.
A supervisor password was set - stored in the password manager first, because Lenovo supervisor passwords cannot be recovered.
The SSD was erased with the BIOS Secure Wipe, which would not run without that supervisor password.

The erase method was a single pass of zeros. I was tempted by the DoD multi-pass option, because it sounds the most thorough. It is the wrong tool for an SSD: multi-pass overwriting was designed for spinning disks, and an SSD’s controller remaps writes across its flash cells, so extra passes add wear without reaching anything more. The drive’s own erase is the correct method.

Lenovo Secure Wipe complete - single pass of zeros

Windows 11 Pro was then installed clean from Microsoft’s Media Creation Tool, and the laptop was left sitting at the first setup screen.

Device association, and an unplanned trip upstairs

Autopilot device preparation launched without the step the original Autopilot depended on - a hardware ID registered by the manufacturer or reseller at purchase. A laptop bought from a third-party seller never gets that registration. In August 2026 Microsoft added device association, which closes most of that gap: at the first setup screen, the laptop proves its identity with its TPM chip and stores a marker for the company’s tenant in its firmware. That marker is what lets the company name the device, mark it as corporate-owned, and skip most of the setup screens.

The mechanics:

At the region screen, the Windows key was pressed five times to open the Autopilot menu.
The device information was exported to the USB stick as a CSV file.
The CSV was uploaded in Intune under Device association, and the setup policy was attached to it.
Back on the laptop, association was completed.

The feature was one month old, so a rough edge was expected. The one that appeared: on Wi-Fi, the association option refused to continue until the laptop was on Ethernet. My workbench is in the basement and the wired drop is not.

Once again, I’m secretly lazy so carrying two laptops up two flights of stairs at 10:00 PM was not on my bingo card for the evening. However, I also wanted this to work so I gritted my teeth and headed upstairs to my router. I always keep a cable plugged into my managed switch so I can easily connect a laptop for circumstances like this but ya know…it’s like…all the way upstairs…

The Autopilot menu, reached with the Windows key pressed five times at the region screen

Once wired, association completed at 22:09.

Nine minutes

At 22:14 I signed in with my work account. The region, keyboard, license, privacy and “personal or work?” screens never appeared - device association skipped them, as designed. The laptop showed a percentage while it joined Entra, enrolled in Intune, landed in the device group, installed Company Portal and Microsoft 365 Apps, and ran the removal script.

At 22:23 I was at a desktop. The laptop had named itself <ORG>-XXXXXXXX from the template, was marked corporate-owned in Intune, and had a managed local admin account waiting.

Windows Hello was set up with a PIN only. I do not use fingerprint or face sign-in on anything, and nothing about this build changes that.

Then I went to bed. I learned on previous projects that pushing through tired is when I start skipping steps and stop actually learning anything.

The green checkmarks lied (typical)

The next morning the BitLocker status was checked from the laptop itself rather than from the Intune portal. The drive was encrypted with XTS-AES 128. The policy said XTS-AES 256. Intune reported every BitLocker setting as “Succeeded.”

Intune reports every BitLocker setting as Succeeded (device and policy names blacked out) The device itself says XTS-AES 128 (account name blacked out)

Diagnosis. The policy values in the laptop’s registry were correct - the 256-bit setting had arrived. The drive had simply been encrypted before it arrived: Windows automatic device encryption started during setup, at its 128-bit default, and a cipher-strength setting does not re-encrypt a drive that is already encrypted. “Succeeded” in Intune means the setting was delivered. It does not mean the disk matches it.

First attempt - failed. The drive was decrypted so the policy could re-encrypt it at 256-bit. It never did. After fifteen minutes and two scheduled tasks meant to nudge it, the drive sat at “Fully Decrypted, 0.0%.” The policy had already been processed on this device, and Intune has no equivalent of on-premises Group Policy’s gpupdate /force to replay it.

Resolution. The drive was encrypted by hand at the correct strength, and the new recovery key was uploaded to Entra:

manage-bde -on C: -UsedSpaceOnly -EncryptionMethod xts_aes256 -RecoveryPassword -SkipHardwareTest
$rp = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rp.KeyProtectorId

Verified with manage-bde -status C: (XTS-AES 256, protection on) and the new key showing in Entra.

After manual re-encryption: XTS-AES 256, protection on (account name blacked out)

The takeaway I will carry to every client: check the disk, not the report. A management portal tells you what it sent. Only the device tells you what happened.

The same morning the retail Windows 11 Pro key was bought from the Microsoft Store and activated, and the BIOS was updated from 1.18 to 1.29 - with BitLocker suspended for one reboot first, so the firmware change did not trigger a recovery-key prompt.

Installing apps without being an administrator

This is where the “not an admin on my own laptop” decision gets tested. Every app I wanted was published in Intune as Available to my user group, which puts it in the Company Portal app as a self-service catalog. The Intune agent installs it as the system account, so a standard user never needs an administrator password.

App	How it was delivered
Bitwarden	Microsoft Store app (new)
Visual Studio Code, Adobe Acrobat Reader, Signal	Microsoft Store app (new) - these come through as vendor installers hosted by the Store
Google Chrome	Chrome Enterprise MSI, uploaded as a line-of-business app
Gemini, Grok	Installed as web apps from the browser - no desktop package exists
Proton VPN, GitHub Desktop	Not in the Store catalog - deferred to a future project on packaging Win32 apps

Two things were learned the slow way. First, a new “Available” app took about an hour to show up in Company Portal the first time, and syncing the device does not speed it up, because the list comes from the Intune service. Second, Bitwarden installed from Company Portal with no administrator prompt at all - which is the whole point.

Company Portal as a self-service catalog (organization name blacked out) Bitwarden installed by the standard user with no elevation prompt; Intune reports one installed

And one honest gap. A standard user can still install software that only writes to their own profile folder. Brave did exactly that, no prompt. Closing that requires Microsoft’s application control features, which are a lot of overhead for a one-person shop. I am accepting the gap for now, and saying so.

Proving LAPS end to end

“Verify LAPS end to end - actually retrieve a rotated password” has sat on my homelab to-do list for a month. This time: the <org>-lapsadmin password was retrieved from Intune, used to sign in for the BitLocker fix, and then rotated with Intune’s “Rotate local admin password” remote action, which reported Complete. The account exists, the password lives in Entra, and it changes on demand.

Remote rotation of the managed local administrator password (device name, serial and model blacked out)

Accounting

Cards on the table, again. Claude (Anthropic’s AI) was in this build from start to finish. It wrote the runbook, the inspection script and the app-removal script, walked me through every step in a chat, kept the build log, and drafted this post. I did every click and every command, and made every decision - including several where I overruled it.

It was also wrong, more than once, and it is worth listing exactly where, because these are the same mistakes a person reading documentation would make:

It said the Global Administrator role would be a local admin no matter what. There is a setting for that.
It said a Microsoft change on 14 September had fixed the BitLocker timing problem. On this laptop, it had not.
It expected the 25H2 installer. Microsoft was already shipping 26H2.
It expected device association to work on Wi-Fi.

Every one of those was caught by doing the work on a real device rather than trusting a document. That is the lesson I am taking from it, and it applies to my own notes as much as to an AI’s.

It definitely pays to not just be a meat-proxy: pay attention to what the AI is saying, because pushback is necessary (cue: “You’re right to push back” meme).

Lab compromises

So nobody has to ask:

My account is still a Global Administrator for the tenant while also being my daily account. It is no longer an administrator on the laptop, but the tenant-level risk stands. It is reversible and on the list.
BitLocker unlocks with the TPM alone, no pre-boot PIN.
The memory is still the single stick until the replacement arrives.
There is no compliance policy or Conditional Access yet. Intune currently marks the laptop “Compliant” only because the tenant default treats a device with no policy as compliant - which is the first thing the next project changes.

What is next

The work phone arrives today, and it gets the same treatment as its own project. After that, one hardening project covers both devices at once: compliance policies, Conditional Access, update rings, Defender for Business, and the decisions this laptop surfaced - application control and stopping Windows from encrypting before the policy arrives.

Most people just drink beer and play pickleball in their spare time. I apparently like to Entra Join laptops, deploy debloat scripts via Autopilot and Intune. I need new hobbies….

Thanks for reading! - Evan

The full technical record - tenant settings, design decisions, every issue and its fix - is in the project write-up: Entra Join, Autopilot & Intune - Cloud-Native Windows Endpoint.

The IT Field Manual, version 1.4

Sat, 19 Sep 2026 09:00:00 -0600

The IT Field Manual is now at version 1.4. It runs approximately 104,000 words across 36 sections, up from roughly 93,500 words and 31 sections in version 1.3 - about 10,300 more words.

That is three separate pieces of work landing as one release, not three. Here is why, what is actually new, and one placement call I made against my own staged source material’s explicit advice.


Version	1.4, 19 September 2026
Size	~104,000 words · 36 sections · ~493 headings
New since 1.3	§31 - §33 (A+ hardware/OS layer) · §34 - §35 (site survey and vendor due diligence)
New doctrine	`[DOCTRINE-13]` - `[DOCTRINE-15]`, up from 12
Corrections logged	74 in `[APX-C]`, up from 54
Read / download	Online · raw Markdown

Why one v1.4, not three version bumps

By the time I sat down for this pass, three separate staged modules had piled up against the vault master: a filtered A+ Study Guide, a vendor-assessment-and-site-survey module, and a cloud-migration-economics-and-tooling module. Alongside them was one still-open problem - a wording divergence I had found and partially fixed three weeks earlier.

Shipping each of those as its own version bump would have meant a v1.4 that was superseded by a v1.5 within days, and a v1.5 superseded by a v1.6 not long after that. Nobody reading a changelog gets anything out of that sequence except noise. So all four went in as one release instead.

The wording divergence is worth explaining, since it is the least glamorous fix in this release and the one that mattered most. In early September I caught the phrase “keeps it honest” sitting in several places in the manual - language my own voice reference bans in favor of “legitimate,” “proper,” or “truthful.” I fixed it on the published site immediately. I deliberately left the vault master - the actual source file everything gets built from - unfixed, because a one-word patch outside a real release is exactly the kind of silent drift this manual exists to prevent. For about three weeks, the file I write from and the file the site serves were not the same document. That is fixed now, as part of this release, not around it.

New: the parts of the job that are not Microsoft

The A+ Study Guide module was the biggest single source this round, and it got filtered harder than its own “not exam-specific” bar - the standard was field relevance in 2026, not “not literally a test question,” so roughly 60% of the source was discarded as scaffolding or ground the manual already covered better.

§	Section	What it is for
31	Printers and imaging `[PRN]`	The laser imaging process step by step, symptom-to-cause tables, and the one thing you never point at toner
32	macOS field reference `[MAC]`	A Windows-to-Mac translation table for a technician who lives in Windows but supports mixed fleets
33	Physical layer and connectors `[CONN]`	Cable standards and a connector-identification table rebuilt for what actually turns up in the field in 2026, not a 2015 study guide

[PRN-06] is the one I would flag first if you only read one new entry: never compressed air or a standard vacuum on toner. Compressed air aerosolizes a combustible fine powder, and a standard vacuum’s motor brushes can ignite it. HEPA, ESD-safe toner vacuum, nothing else.

The connector table in §33 is not a straight copy of the source material either. USB-C got added as its own row, Lightning got marked legacy rather than current, and the mnemonics the study guide used to help you memorize the table got dropped entirely - this is a lookup reference, not something you are studying for a test, so a device you can Ctrl+F does the memorizing for you.

New: reading a company and a site before you trust either

The vendor-assessment-and-site-survey module added two full sections and two new doctrine entries, and this is the part of the release aimed less at fixing something broken and more at a skill I did not have a section for at all: judging whether an inherited environment or an incumbent vendor is what it claims to be.

§	Section	What it is for
34	Site survey `[SITE]`	A shot list ordered by priority, evidence-handling rules, and the fact that a service tag is worth more than an estimate
35	Vendor and platform due diligence `[VEND]`	Reading whether a product line is actually alive, and reading an incumbent’s invoices instead of its marketing

[DOCTRINE-13] is the one I keep coming back to: a search that returns only aggregators has told you the company is dead. ZoomInfo, Manta, Dun & Bradstreet, and similar directory sites never delete a listing - they are populated once from a public filing and persist indefinitely, which means a defunct company can look extremely well documented. Nine hits feels like evidence. It is nine copies of one filing. The fix is requiring a live company website or a current state business-entity registry record before you call anything active - the registry check takes about two minutes and settles it outright.

[DOCTRINE-14] is the physical-inspection companion to it: paper describes the part of the world its author touched, and nothing else. A complete set of one vendor’s invoices says nothing about a second vendor, a decommissioned appliance, or anything installed before the first invoice in the set - not because the documents are wrong, but because that is the definition of their scope. An hour walking a site with a written shot list routinely finds what weeks of document review cannot.

New: the migration pitch, split into the two numbers it actually is

The cloud-migration-economics-and-tooling module was the smallest of the three by section count - it landed as one doctrine entry and one extension, not a new section - but [DOCTRINE-15] is doing real work: a cloud migration’s real saving for a small organization is avoided capital spend, not a recurring discount.

The generic pitch - “the cloud saves you money on IT” - is not reliably true, and treating it as automatic is a credibility risk in front of a technically literate buyer. Recurring cost is usually close to even and depends entirely on what the organization already owns; the real, defensible number is almost always on the capital side, where aging on-premises hardware needs periodic replacement on a schedule that a cloud migration can remove entirely. And administrative labor does not disappear - it changes shape, from unplanned hardware-failure recovery to ongoing identity and policy administration. Any total-cost argument that blends those two halves into one “savings” figure is exactly where the misleading version of the pitch hides.

The migration tooling itself - the file-share-to-SharePoint/OneDrive table - went into a new [FILE-10], which is the placement call from the intro.

The placement call I made against my own source material

Both staged modules that added new sections came with their own integration instructions, and I did not follow either one exactly as written.

The vendor-assessment module’s own draft for §11 proposed a full second product-overlap table for [M365-21]. I wrote it short instead - a cross-reference to [M365-13] and [M365-20], which already cover that ground, plus only the material that was genuinely new: checking for seat-by-seat license overlap, and the rule that “we already own an equivalent” never extends to backup. Restating a table that already exists two sections over is the kind of redundancy that makes a tagged, search-first document worse, not more complete.

The cloud-migration module’s own instructions named [SPO] or [AZ] as the candidate home for the file-share migration tooling - it listed both as options. I put it in [FILE-10] instead. [SPO] is scoped tightly to sharing and guest access; [FILE] already carries the full lifecycle of on-premises file-share administration and reads naturally as ending with “now retire it.” Cross-references went in from both [SPO]’s intro and [AZ-07]’s Data Box entry, so the content stays reachable from every path someone might search it from.

[TRANSITION SLOT - he may want to make this a joke] Neither of those was the module’s fault. A module is written against a snapshot of the manual that gets more stale the longer it sits staged, and both of these had been sitting for a couple of weeks.

The correction log is the part I would read

Appendix C is where every claim in my source material that turned out to be wrong gets recorded, alongside the correction and where it was verified. Version 1.3 shipped with 54 entries. Version 1.4 has 74 - 20 in this release alone, which is the largest single batch since the initial 16 that shipped with v1.0.

A representative handful:

SMB is not a Linux protocol. It is Microsoft’s. Samba is the Linux/Unix implementation of it - implementing a protocol does not make you its native platform.
Mixing RAM modules of different sizes and speeds does not waste capacity. The system uses the full combined capacity of every installed module, running at the speed of the slowest one. The speed penalty is real; the capacity loss is not.
gpedit.msc and gpmc.msc are not interchangeable, and only one of them is installed by default on a client OS. gpedit.msc is the Local Group Policy Editor. gpmc.msc manages domain GPOs and their AD links, and it is an RSAT feature you have to add.
Telnet does authenticate you - with a username and password, in cleartext. No encryption is not the same claim as no authentication, and conflating the two is a worse mistake than either fact alone.
Azure Data Box does not have a flat 80 TB usable capacity anymore. Current Microsoft documentation shows a tiered lineup - roughly 35 TB, 120 TB, and 525 TB usable, depending on the tier. I found this one myself while placing the cloud-migration content, not from either staged module, which is exactly the kind of catch this appendix exists for.

What is actually next, which is not what I said last time

Version 1.3’s closing line said the next release would most likely be Linux and Samba. It was not. A+ hardware content, vendor and site-survey due diligence, and cloud migration economics came due first, and I would rather ship what was actually ready than force a plan I made three weeks earlier onto a release it no longer describes.

The Linux Field Manual is still a separate, not-yet-started document - a full bare-metal Proxmox cluster build guide is staged and waiting for it, untouched, exactly where it was last time. Section 25, “Personal additions,” is also still empty, on purpose, same as every prior version.

[TRANSITION SLOT - self-deprecation about predicting his own roadmap goes here]

That all being said, the manual stays public for the same reason it always has: a document I know somebody might actually read is a document I write more carefully. If you find something in it that is wrong or out of date, Appendix C is where it goes, and it is the appendix I expect to keep growing fastest.

Read the Field Manual → · Browse the Reference Library →

I Put a Server Cluster in My Basement

Sun, 30 Aug 2026 16:00:00 -0600

Proxmox Virtual Environment is a free, open-source server platform that lets one physical machine run many virtual machines and containers at once, managed through a web browser instead of a command line. It is built on Debian Linux, it is used by everyone from home labbers to actual businesses, and several machines running it can be joined into a “cluster” so you administer all of them from one screen.

Documentation and downloads at proxmox.com.

Cards on the table before we start: I had never used Proxmox before this build. Not once. Everything below is a first-timer working through it in real time, which means you get the mistakes too, and there were some good ones.

How I got here

My previous home lab was a Windows Server domain controller running on bare metal on an old HP ProDesk, with a second controller virtualized on my main PC, pretending to be a small business called HomeBiz. It worked. It taught me an enormous amount about Active Directory, Group Policy, and hybrid identity. It also had a fairly serious problem, which is that every time I wanted to build something new I had to destroy the thing that was already there, and there was no backup of any of it anywhere.

That is fine when the lab is only a lab. It stops being fine the moment you want the same hardware to also run things your household actually depends on - DNS, file storage, connecting the printer to the network because wi-fi prints suck, ya know…stuff that gets noticed within about ninety seconds of going down.

So the plan became: stop treating these three machines as three machines.

The parts had been sitting around for a bit. Two used HP ProDesk business desktops that I already owned, and a box of components for a new build I had not assembled yet. Then the used CPU I had bought for that build turned out to be dead, which meant buying a brand new one, which meant the whole thing slipped again.

Parts for the new node.

The new machine came together fine once the working CPU arrived. Bench tested it outside the case first, which is one of those things that feels like an unnecessary extra step right up until the moment it saves you from disassembling an entire build to find out which part is bad.

Bench tested outside the case before assembly. The completed build.

The basement problem

Here is the constraint I could not engineer my way out of. The coax comes into the second floor. The modem and the router live up there. The servers needed to live in the basement utility room, because that is where it is cool, where there is space, and where my wife does not have to look at them.

Running actual ethernet between those two points is not something I can do in this building. So the link between upstairs and downstairs is a powerline adapter pair, which sends network traffic over the electrical wiring, and which gets me approximately 30 Mbit/s. That is not fast. On a gigabit home network that number looks genuinely bad.

Here is the thing though, and this is the part I actually think is worth writing down: 30 Mbit/s being “bad” is meaningless until you say what it is carrying.

I sat down and worked out what actually crosses that link. Cluster heartbeats - the constant chatter the three servers use to confirm each other is still alive - do NOT cross it, because all three machines sit on the same little switch in the basement. Backups do not cross it either, same reason. What crosses it is me loading the web interface, software updates, DNS queries, and eventually file transfers.

Only that last one actually hurts. And the first one, the cluster heartbeats, is the one that would have been genuinely dangerous, because that traffic is extremely sensitive to delay and a flaky link carrying it would have made the whole cluster fall over intermittently for reasons that would have looked like absolutely anything else.

THE LINK LOOKED LIKE THE BIGGEST RISK IN THE ENTIRE BUILD AND IT TURNED OUT TO CARRY ALMOST NONE OF THE TRAFFIC THAT MATTERS. I would not have known that without writing out the list.

The rack. It is a shelf.

That is my rack. It is a shelf. Anyways, moving on…

Building the thing

The installs themselves were unremarkable, which is the correct outcome for an installer. Three machines, three installations, roughly the same screens each time.

First login to the PX-03 web interface.

The first genuinely interesting decision came at the point of joining the three machines into a cluster, and it went against the advice I had written down for myself weeks earlier.

The conventional wisdom is to wait. Get the layout settled first, then cluster, because leaving a cluster later is much harder than joining one now. That is true and it is good advice. It is also outweighed by a hard mechanical rule that I did not know about:

/////BEGIN QUOTE///// A Proxmox node that already holds any virtual machine or container CANNOT join a cluster. The join command refuses. The node has to be emptied first. /////END QUOTE/////

Which flips the whole thing. Waiting does not defer the cost - it creates one, because every VM I built in the meantime would have to be destroyed before its machine could join. All three were empty right at that moment. That was the cheapest the operation was ever going to be, so we did it right then.

Three nodes, three votes, quorum of two.

Three nodes, three votes, quorum of two. Which means the lab machine can be powered off whenever I want without anything else caring. That was the whole point of having three boxes instead of one.

And then DNS did not work for two days

I was building a DNS resolver. Not the filtering kind that blocks ads - the layer underneath that, the part that actually goes out and finds the answer.

Every single query came back SERVFAIL. Every one. Including the test that is specifically designed to succeed.

Every query came back SERVFAIL.

And here is the trap I nearly walked into, which I think is the most useful thing in this whole post. There is a standard pair of tests for checking that DNS security validation is working. One name is supposed to come back fine, and one name is supposed to fail. Mine failed. Correctly!

Except the other one failed too. And so did everything else. A TEST THAT GIVES YOU THE RIGHT ANSWER FOR THE WRONG REASON IS WORSE THAN A TEST THAT JUST FAILS, because a failing test makes you go look, and a falsely passing one makes you move on.

What a resolver actually does

Worth a plain-language detour here, because the rest of this does not land without it.

Think about how you would find a specific office in a large government building with no directory in the lobby. You ask the security desk at the front, and they do not know where that office is, but they know which floor handles that department. You go to that floor and ask the desk there. They do not know either, but they know which wing. You ask at the wing. Eventually somebody actually knows, and tells you the room number.

That is recursion. Nobody in the chain knows the whole answer, and every one of them knows who to ask next. A recursive resolver starts at the root servers - the front security desk of the entire internet, and there are thirteen of them - and walks down until it reaches a server that is actually authoritative for the name you asked about.

The alternative, which is what most people’s computers do, is to ask one big public resolver and take its word for it. That works fine. It also means that resolver sees every single thing you look up.

Simply put: recursion means finding out for yourself instead of asking somebody who will remember that you asked.

Finding it

Two commands solved this, and neither of them was a guess.

The first one splits the problem in half. There is a flag you can send with a DNS query that says “do the lookup, but skip the security validation step.” If the query works with that flag and fails without it, your problem is validation. If it fails both ways, your problem is the lookup itself.

It failed both ways. So validation was innocent, and the actual lookup was broken. Half the search space gone with one command.

The second one asked a root server directly, with a flag telling it not to go asking anyone else. And the answer that came back was wrong in three separate ways at once:

It said REFUSED. Serving that particular record is the one job a root server has. It cannot refuse.
It came back in 7 milliseconds. From a basement, over a powerline adapter, to a root server. My own queries to a machine sitting three feet away were taking 200 milliseconds.
It had the “recursion available” flag set. Root servers do not do recursion. They never set that flag. Not ever.

A response that could not have come from a root server: REFUSED, ra set, 7 ms.

So whatever answered that query was not a root server. Something in between was grabbing DNS traffic and answering it itself.

It was my router. It has a feature that transparently intercepts DNS to cache and filter it, which is a genuinely good feature for the devices in my house and an absolute catastrophe for a machine whose entire job is going out and asking questions directly. My resolver was getting its very first question answered by something that had no idea what the root of the internet looked like, and it never got past step one.

The fix took about ninety seconds once I knew what it was. The router lets you exempt individual devices from that feature. One device exempted, nothing else on the network touched.

DNS interception and DNS-over-HTTPS excluded for VLAN 30.

Two days. Ninety seconds. That is just how it be sometimes.

The part I got wrong

I want to be specific about my own mistake here rather than vague about it, because the mistake is more instructive than the fix.

I had written in my own notes, weeks ago, that this router feature would need to be turned off before the ad-blocking layer would work. I had it filed as a client-side problem. Turn it off before pointing the household at the new DNS server.

That was incomplete, and the incompleteness is the whole lesson. A recursive resolver’s own outbound questions are also DNS traffic. Interception does not just stop clients from reaching the resolver, it starves the resolver itself. So that step was not part of a later cutover at all. It was a prerequisite for anything working, and I had it scheduled dead last.

Once the exemption was in place: cold query 294 milliseconds, same query again 1 millisecond from cache, security validation confirmed with the flag that only gets set when the cryptographic chain actually checks out.

The ad flag: DNSSEC validation succeeded.

Backups, and one thing worth stealing

I will not walk through the whole backup build, but there is one decision in it that I think is genuinely worth copying regardless of what you run.

The backup server has its own user accounts and its own permission roles. The obvious move is to point the servers at it using an admin account, because that definitely works. What I did instead was create an account with a role that can create and read backups but cannot delete them.

The credentials sitting on my servers can add to backup history. They cannot destroy it. Which matters because the way ransomware actually beats backups is not by being cleverer than the encryption - it is by finding the credentials on the machine it just compromised and using them to wipe the restore points before it starts.

The trade-off is real and I had to configure around it: since that account cannot delete anything, the cleanup schedule has to live on the backup server itself instead of being driven by the servers. Which is fine. That is one setting.

Creating the backup job for PX-01.

And then I ran the job manually and went and looked at the datastore to confirm a snapshot actually landed in it. A BACKUP JOB THAT HAS NEVER BEEN RUN IS NOT A BACKUP, IT IS A HOPE. I have an untested restore sitting in my notes from a previous project that has been quietly bothering me for weeks, and I did not want a second one.

The Deliniation of Work

Cards on the table, because I think this matters and because the alternative is letting people assume.

I did not do this alone. I worked through the entire build in a live conversation with Claude (Anthropic), and the division of labour was roughly this.

Claude did: the architecture reasoning, most of the “here is why this option beats that option” analysis, the exact commands and what every flag in them meant, the troubleshooting methodology when DNS broke, and the documentation. It also caught things I would have missed - it flagged that I was about to build a container with the wrong security setting, it caught that I was about to buy a Windows license I did not need, and it noticed that I had my own settled decision written down and was about to contradict it.

I did: every command, every physical action, every decision, and all the pushback. I built the machine. I ran the tests. I made the calls on what to do and what to skip.

And I want to be clear that the pushback was not decorative. Claude got things wrong, more than once, and in ways that cost me time:

It recommended a permission role that turned out to be structurally incapable of doing the thing I needed, and I hit a 403 error because of it.
It sent me down a completely unnecessary SSH rabbit hole to solve a problem that had a one-command answer sitting right there.
It told me to run a command without telling me which machine to run it on.
It handed me a config file reference and then never actually told me to create the file, so I sat there wondering why nothing worked.
It predicted a default setting that turned out to be the opposite of what my system actually had.

Every one of those got corrected, most of them because I pushed back rather than because it noticed. THAT IS THE ACTUAL SKILL HERE. Not prompting. Reading the output, noticing when it does not match what you were told to expect, and saying so.

The documentation came out of the same conversation, and I want to name that plainly rather than let it read as though I typed it all up afterwards. What I did do is decide what goes in it, correct it where it was wrong, and refuse the parts I did not want.

Where it stands

Three machines, one cluster, one screen. Always-on services on one node, backups on another, a lab machine on the third that I can power off whenever I want without anything else noticing.

There are two things I deliberately did not do, and I wrote down the condition that would make me change my mind rather than a date to reconsider:

SSH root password login is still enabled. It is only reachable from inside my own network, and the moment I put any remote access in front of it - a VPN, a port forward, anything - I close it. Not before.
The lab’s isolated network does not exist yet. Because building it now means guessing at a design decision that belongs with the lab itself.

Next up is the ad-blocking layer, then network file storage, then rebuilding HomeBiz on top of all of it - this time as something I can tear down and stand back up from code instead of by hand.

Onward and upward, I say.

The full technical writeup, with the architecture decisions and verification evidence, is on the project page. The complete build procedure is published separately as a runbook, for anyone who wants to do this themselves - or for me, in a year, when I have forgotten all of it.

Create a "Second Brain" using Claude

Sat, 29 Aug 2026 09:30:00 -0600

“An AI second brain is a personal knowledge system that captures your ideas, references, notes, and projects in one connected workspace, and is continuously read by an AI assistant that uses that context to answer questions, surface forgotten material, and generate new work. It is the AI-native evolution of the “second brain” concept popularized by Tiago Forte in 2022, where the AI does not replace your thinking, but reads everything you have captured before it responds.”

Definition from storyflow.so, author Justkay.

Inb4: I’m into Claude-maxxing. Use your preferred frontier AI model for this, but my bias should be known upfront.

How I got here

I had first heard of this concept while briefly skimming YouTube videos as I lay rotting on my couch looking for something to watch. At first it didn’t really register and I didn’t click on it because (definitely with my algorithm) my feed is full of plenty - and arguably an unhealthy amount - of coding, AI, tech, and Cyberpunk 2077 videos with the occasional Japanese micro apartment tour video sprinkled in for good measure. Especially nowadays, I’m so hesitant to watch any video about AI from some random dude with a snapback hat with like 15K subscribers and has a folder on his desktop labeled “Chess Moves” where he keeps his “business strategy” files - basically reeks of internet guru slop and frankly I’m not about that.

Yeah, these kinds of videos.

However, the idea of using AI as a “second brain” did capture my attention conceptually for a moment as I’m all in on using frontier AI models to significantly increase productivity across multiple domains. Despite that, I did keep scrolling because my dinner was getting cold as I was trying hard to find something to watch while I eat and inevitably nap.

A few weeks later my brother shot me a much more interesting video (admittedly I didn’t watch, see reasoning above), but my brother is a serious, tech-savvy guy who does insane work teaching himself programming, 3D printing, making a mobile app (makes homemade drones too, as one does) and that really sparked the thought into my head that hey maybe this is something worth looking into. My brother and I do have pretty good discussions regarding utilizing AI for personal things as well as work, and are in agreement that an individual’s ability to efficiently utilize AI frontier models will be a legitimate differentiating skill in the modern/future workplace.

I like to think of AI as a tool - say, like a hammer: There are skilled tradesmen who use hammers in creating beautiful buildings, works of art, high quality furniture, and so on; and then there are people who can only use a hammer to throw a couple thumbtacks into the dry wall to hang “Live, Laugh, Love” signs in their dining rooms. Not throwing any shade to Target though - Target’s great, generic kitchen artwork aside.

Enough about hammers - back to the Second Brain: After my conversation with my brother I naturally turned to Claude to try and understand what the concept actually is, how it can be useful, and is it even something worth trying to set up. I must admit I did also turn to some of the internet guru videos (tried to find some good ones - couldn’t), and I was able to gather the gist quickly enough to at least make a more informed prompt.

Asking Claude to explain the concept before building anything

To quote the esteemed author, Claude:

/////BEGIN QUOTE/////

Where the idea came from

“Second brain” as a term is Tiago Forte’s, from his 2022 book Building a Second Brain. But the concept is old and the book is mostly repackaging. The lineage runs back through David Allen’s Getting Things Done (1999), Niklas Luhmann’s Zettelkasten (a German sociologist’s index-card system from the 1950s-90s, credited with letting him publish 70 books), and further back to commonplace books - the notebooks Renaissance scholars kept of quotes and observations, cross-indexed by theme.

The claim underneath all of them is the same: your brain is good at thinking and bad at storage, so stop asking it to store things. Offload retention to a system you trust, and free up working memory for the part machines can’t do.

Forte’s framing is CODE: Capture, Organize, Distill, Express. Worth knowing because you’ll see it everywhere, but three of those four are filler. The one that matters is Distill. Everything else is logistics.

What AI actually changed

This is the part worth being precise about, because the marketing overstates it badly.

Before LLMs, the bottleneck in any note system was retrieval. You had to remember that you’d written a note, roughly what you called it, and roughly what words were in it. Keyword search only works if you can guess the keyword your past self used. This is why so many vaults die: people write notes and then can never find them again, so they stop trusting the system, so they stop writing.

LLMs collapsed that bottleneck. You can now ask a fuzzy question - “didn’t I hit something like this before, where a thing looked fine locally but 404’d live?” - and get the right note back without knowing its name. That’s real, and it’s the whole delta.

What AI did not change:

Capture still requires you. Claude doesn’t know what happened in your day.
Judgment still requires you. Claude can’t tell what mattered.
Understanding still requires you. A summary you didn’t write teaches you nothing.

So the accurate statement is: AI fixed the retrieval problem in note-taking, and note-taking still has all its other problems.

/////END QUOTE/////

I love that line: “Your brain is good at thinking and bad at storage, so stop asking it to store things.” I think that made the concept click a lot faster for me than Chess Moves bro and his failed ecommerce drop-shipping business (maybe I’m just projecting here, I’m sure he’s a nice guy). This is definitely an area in my entire student and work career I’ve come incredibly short in: I’ll take plenty of notes in class, while doing a course, listening to a lecture, highlighting stuff in books I read, all of it - and then…I like, never go back and read them. Fortunately, I’ve been quite blessed with very good memory and I’m at least on the good end of the normal distribution curve of average IQ (total midwit though, I am what I am) so I’ve been a perpetual B+/A- student my entire life just by paying attention to the material presented. Where I’ve struggled though is having good, accessible, and more importantly usable reference material to draw from when I need it most. My memory is good but it’s not THAT good to be able to recall obscure data, quotes, niche concepts from economic literature, what I ate for breakfast, etc. All to say, utilizing the new hot tool in the modern world to solve a shortcoming of mine sounds like an excellent use of my time.

Turns out I was already doing this

In my dialogue with Claude, it turns out that I’ve been doing this informally, yet structurally for quite awhile already - case in point, the website this article is hosted on:

The whole point of me creating evanireland.tech is to serve two goals:
- Primarily as a portfolio to showcase my work, skills, and domain knowledge for potential employers/clients/colleagues.
- Very close second is to be my own personal hub of reference material (the IT Field Manual, playbooks, runbooks, the to-be-published script repo, and so on) so I always have it available to me as long as I have an internet connection.
I do the work firsthand (I do the projects, I save the reference material I find useful, I find the appropriate scripts and save them to VS Code), I take notes and screenshots as I go along, but then I utilize Claude to distill what I’ve done, clean up my digitally chicken-scratched, disheveled notes and documentation, turn it into a legible document, and integrate into the existing website files.
What I accomplish doing this way is a very efficient way to leverage what I’m good at, and what I could still do but could instead use an AI assistant to do much better and faster.
I do work, I learn skills, I find helpful resource material I would REALLY LIKE TO BE ABLE TO CONTINUE TO USE, I write it down, save it, and ask Claude to store it in a legible and accessible manner - and thanks to Claude I can do this veeerrryyy quickly and much better than if I were doing it by myself.
The IT Field Manual is the single best example I have of this: Cards on the table, do you think I wrote that start to finish? Helllll noooooo. What I did actually do is run through and find everything that’s listed there though, I tried out the scripts to make sure they worked, I did the troubleshooting steps to verify they were legit, but then Ol’ Buddy Claude distills the chaos into a very organized, singular reference complete with fancy hyperlinks, tags, tables, and so on. And it comes in handy to fill in gaps that I missed and/or didn’t properly articulate in my note taking process.

That’s really what is meant in Claude’s response: “the bottleneck in any note system was retrieval. You had to remember that you’d written a note, roughly what you called it, and roughly what words were in it. Keyword search only works if you can guess the keyword your past self used.”

One of the reference pages this system is supposed to make easier to find again

Another quite righteous example of a way I’m going to use this concept: This article. What I’m presently doing as I type is:

Writing the prose for the article, stream-of-conscious, thinking as I go along and making nice sounding words
I do the setup for the Second Brain utilizing Claude and the system it’s helping me develop
I take screenshots of the things I find interesting
Continue taking notes and refining
And when I’m done I’m going to drop all of this into the upcoming 00. Inbox folder to test the concept.
You’ll know I’ve been successful by reading the article.
And now I’ll have a reference to be shared with anyone who wants to set up their own second brain by yet another dude in his 30s wearing a snapback hat who has his own website. Oh God, what have I become…

Also, for the sake of argument - yes I do indeed do my own writing (see below). Will I use Claude to help clean up my monkey brain writing and make it way prettier? You’re absolutely right.

Yes, this is a screenshot of the article you’re reading, mid-draft, placeholders and all

Now let’s set this Bad Johnson up.

Setting it up

So my big brain move after watching some videos on “How to Set Up Your Second Brain to Run Your Affiliate Marketing Site Slop” and listening to these guys with their convoluted setups was to… (I’m not even kidding, when I asked Grok to help come up with internet guru slop business ideas to make fun of, one of the examples was: “Notion Templates / Swipe Files / ‘Operating System’ - A second brain that is just folders. Sold as leverage.” That is so awesome)

…just ask AI to help me set it up and show me how to use it. What a concept - off to a great start already!

I forgot to tell him “Make no mistakes.” Dang it…

First step I did was to create a simple, blank folder on my desktop. I felt like eschewing Obsidian because it looks way too annoying to setup for this and like, it’s just an .md text editor anyways. I reserve the right to set it up on Obsidian in the future out of curiosity, but to learn this I opted for the path of least resistance.

So a simple folder living on my desktop (backed up to OneDrive) it is. I felt like naming mine the Cogitator because 40K is cool, the Adeptus Mechanicus are cool (shouldn’t surprise anyone that a dude with a site like this is Ad Mech-down), and it gave me an excuse to create an Ad Mech icon to keep on my desktop.

The empty folder that started it all

Anyways, when I submitted this prompt, I switched to Cowork mode and utilized the Opus 5 model set to High. I pointed Claude to the empty Cogitator folder and let it run.

Claude asking for three decisions before writing a single file

First pass at the architecture

And a rundown of what actually landed on disk

Simple as that, no internet guru slop course required. Just use the AI model you’re guaranteed already paying for - or will end up paying for - if you’re going to set up a complicated storage system with it. Use the hammer for making useful things, not hanging “Live, Laugh, Love” signs in your kitchen, Madison.

How Claude actually remembers things

An important note here for understanding about how Claude/AI actually uses your saved context:

Think of AI memory like writing on a physical whiteboard in a specific meeting room.

Conversations are like temporary room whiteboards. Everything you discuss during a chat is written on that room’s whiteboard so the AI can read it and respond in real-time. But the moment you start a fresh chat, you walk into a brand-new, empty room. The AI can’t see the whiteboard in the old room.
Projects are like permanent notice boards in the hallway. Files and instructions you explicitly upload to a Project act as permanent reference boards posted in the hallway. Whenever you start a new chat inside that Project, the AI reads the hallway notice board first, but it still cannot see what was written on the whiteboards of your previous chats.

Because an AI cannot automatically carry past chat notes to a new conversation, you have to summarize the important details from an existing chat and explicitly post them onto the Project’s notice board so future chats can read them.

Simply put: A single chat is keeping track of what you’ve told it in a single chat, AI doesn’t necessarily know what you discussed in a different chat - even if they’re in the same Project umbrella. That is unless you have given the Project specific instructions and reference material to work with. Granted, Claude and some AI models do keep a persistent memory file about you generally, but it is very limited in what it’s going to keep track of.

Which is the point of what we’re doing here - bridging the gap between these conversations by using the “Second Brain” file system which is going to comprise instructions and references. We’re basically building a library for Claude to refer to when we ask it questions. I only have to tell it my favorite TV show as a kid was Hey Arnold one time and save it into an instruction file - not relitigate it every time I ask it about peak television. The flipside of this being, should heaven forbid I forget what my favorite TV show was as a kid I can ask Claude who now has perpetual access to that information no matter when I ask it or what we’re discussing in the first place.

There is one more piece worth knowing, and it’s the critical connecting piece: Cowork mode can read the folder directly. A regular chat inside a Project only sees the hallway notice board. A Cowork session with your folder connected sees the notice board and walks into your actual filing room. That is the difference between Claude knowing a summary of your projects and Claude reading the current state of them.

So, although Claude was able to write me the architecture directly into my folder - I didn’t quite like the way it had set it up. The structure felt a little off to me and I had to click through a bunch of confusing sub-folders, things were nested weird and weren’t where I as the user would expect them to be - all of that. However! You know what’s nice about using an AI agent for this in the first place??

I can just ask it to redo it in a way that makes more sense to me…and then it does it…and it works.

One important note for anyone who isn’t used to intelligently prompting AI models: You have to be specific. My go-to example is going to the barbershop: If you walk in and simply just ask for a haircut, you’re definitely going to get a haircut but it might not be the one you wanted - perhaps not even close to what you wanted. You HAVE to be specific - tell the barber exactly what you want or give him some references to work from. In this case - I have my OneDrive setup in a way that maps directly to how my brain likes folders/files set up. All I had to do to fix the Second Brain set up was point Claude at both my Cogitator folder and an offline copy of my OneDrive (with selected files deleted from it - I don’t want Claude to have access to specific things), and re-prompt “Make the Cogitator look more like this.” In short order I was able to have a file system in my Cogitator that is usable for both my brain and Claude programming. Simple as that.

Pointing Claude at a folder I already navigate without thinking, and asking it to match that instead

Current layout, derived from existing OneDrive conventions

The thing I want to flag here, because it is the actual lesson and not just a step: the layout does not have to be good for someone else, it has to be good for you. Claude’s first attempt was a widely-recommended structure, and is the type of structure you’d pay dude bro to be able to take his affiliate marketing course. It was also one I would have probably stopped using in a month, because every time I went looking for something I would have had to think about where it lived. Mine is numbered folders in Title Case because that is what my OneDrive already looks like and my hands already know it. Yours should look like whatever you already navigate without thinking.

The point is to build a tool YOU will use for YOUR work - you don’t have to take a cookie-cutter, boiler plate template; make the tool work for YOU.

Getting your existing chats out of their silos

So good - I have a file system architecture I like and organized the way that I want it. Next up is I need to get the relevant information to put in it. Personally, I have six Claude Project umbrellas I use:

Ireland Capital: My personal finance and investing project
IT Skill Development: Improving my IT domain knowledge skills
IT Cert Study Guides: Self-explanatory
Beginning Coding: Also self-explanatory
IT Field Manual: The project I use to distill the knowledge I find out in the wild and integrate into one cohesive study guide
Branding: For my resume, LinkedIn, social media posts, etc.

Here’s something I actually learned doing this and didn’t already know; worth internalizing before you try this: a new chat inside a Project cannot read your old chats in that same Project. Not “struggles to.” It cannot. Back to the whiteboard - every conversation is its own room, and the door locks behind you.

So you can’t open a fresh chat and say “summarize everything we’ve worked on.” It does not know. It will either tell you so, or - worse - it will do the very 2023-ish AI thing where it will very confidently make things up.

What that means practically is that the distillation has to be run at the bottom of the existing chat, while that conversation still remembers itself. You are not asking Claude to go retrieve something. You are asking it to write down what is currently in the room before you leave it.

The prompt Claude gave me (pro-tip: ask the AI how to best use it) looks like this:

I am building a persistent knowledge system and I need to capture the state of this
work before this conversation's context is lost.

Write me a single markdown document that a future version of you - one with **zero**
memory of this conversation - could read cold and immediately be as useful as you
are right now. Assume that reader knows nothing except what you write.

Use exactly these headings:

## Purpose
What this project is for, in two or three sentences. Why it exists, not just what
it is.

## Current state (as of <today's date>)
Where things actually stand. What is built, what works, what is half-finished, what
is broken. Be concrete. "The deploy script works" is useless; "deploy.ps1 pushes to
the gh-pages branch, but does not handle the custom domain CNAME" is useful.

## Key decisions and why
Every real decision we made, with the reasoning. This is the most valuable section -
it stops a future conversation from talking me back out of a decision I already made
for good reasons. Format each as: decision, then the reason in one line.

## Dead ends - do not try these again
Approaches we tried that failed, and why they failed. Be specific about the failure
mode. This section saves me the most time and it is the one people forget to write.

## Conventions and vocabulary
Naming schemes, file layouts, terms we use in a specific way, formatting rules,
anything where "how we do it here" differs from the generic default.

## Open threads
Unfinished work and unanswered questions, ordered most-important first. For each,
say what the actual next action is - a verb, not a topic.

## What Claude should know about working with me on this
Anything about my skill level in this area, my preferences, or how I like this
particular kind of work handled.

Rules for writing it:

- **Do not flatter the work and do not inflate progress.** If something is barely
  started, say barely started. An over-optimistic brief is worse than no brief,
  because I will act on it.
- **Do not include anything you are not confident actually happened** in this
  conversation. If you are unsure, mark it `[uncertain]` rather than smoothing it
  over.
- Prefer specifics over summary. File names, commands, versions, exact errors.
- If a section genuinely has nothing in it, write "None yet." Do not pad it.
- Output raw markdown in a single code block so I can copy it cleanly.

Two things about that prompt are doing most of the work, and they are not the obvious ones.

“Dead ends - do not try these again” is the section nobody writes and the one that pays for the whole exercise. Every project has three or four approaches you tried that failed for a specific reason, and six months later that reason is completely gone from your head. Mine has entries like “Jekyll silently drops future-dated posts, with no build error” - which cost me a genuinely annoying afternoon once and will now never cost me one again. Nice try!

“Do not flatter the work and do not inflate progress” exists because the default failure mode of an AI summary is optimism. A brief that says a thing is “largely complete” when it is half-built is worse than having no brief at all, because you will plan against it.

I ran that prompt on the two or three load-bearing chats inside each Project - not every chat, just the ones actually carrying the work - and ended up with eleven documents. Then I saved all eleven into the 00. Inbox folder and did not sort a single one of them.

And then we get to the part that still feels slightly illegal. I opened a Cowork session, pointed it at the Inbox, and said “file these where they go.” It read all eleven, worked out which Project each belonged to, merged the three-per-project ones into single briefs, and put them away. It also caught two things I would not have: one of my distillations described the website as being on a theme I had migrated away from days earlier (the “as of” date on a distillation is the date you ran it, not the date the work happened), and two different briefs described my own skill level in flatly contradictory ways.

While I’ll be a son of a gun… Also worth doing: Make Claude audit your folder through multiple iterations; make it catch these inconsistencies early and often. AI is good but it’s not perfect, feel me?

What is actually in the folder, and what each piece does

This is the part I wanted to lay out plainly, because “second brain” gets used to describe everything from a Notion template to a paid course, and in practice mine is about five ideas.

Here is the whole thing:

Cogitator/
├── 0. About Evan.md          <- who I am. the one file Claude always gets.
├── 0. START HERE.md          <- how the system works. rules and conventions.
├── 00. Inbox/                <- dump zone. no rules. emptied weekly.
├── 1. Ireland Capital/       ┐
├── 2. IT Skill Development/  │
├── 3. IT Cert Study Guides/  │  one folder per Claude Project.
├── 4. Beginning Coding/      │  the number matches the project.
├── 5. IT Field Manual/       │
├── 6. Branding/              ┘
├── 7. Resources/             <- stuff that serves more than one project
├── 8. Logs/                  <- learning log, weekly reviews
└── 9. Archive/               <- finished or superseded, kept anyway

And every one of those six project folders is identical inside:

2. IT Skill Development/
├── 0. Brief.md      <- the state of this project
├── 1. Working/      <- what I'm actively doing
├── 2. Reference/    <- finished stuff I'll look up later
└── 9. Archive/      <- superseded, kept

That sameness is deliberate and systematic - which when building a “system” is kind of the point, yeah? Claude can open any project folder and already know where things are without hunting, and more importantly I never have to decide where something goes.

0. About Evan.md is the master context file - who I am, my background, what I’m working toward, my certs, how I want Claude to talk to me (bluntly, explain the mechanism behind commands, don’t inflate progress), and what I’m currently focused on. This is the only file I upload into a Claude Project’s knowledge base, so even a plain chat on my phone knows who it’s talking to. It changes maybe monthly.

0. START HERE.md is the operating manual - the naming conventions, the map of the folders, how the projects feed each other, and a list of things that are already decided so a fresh Claude doesn’t spend three paragraphs re-raising them. This one stays on disk. Cowork reads it live.

N. <Project>/0. Brief.md is the per-project state file, and it is the workhorse. It carries the seven sections from that distillation prompt - purpose, current state, decisions and why, dead ends, conventions, open threads, and how to work with me on this specific thing. When I finish a session, this is the file that gets updated. When I start a session, this is the file that gets read.

00. Inbox is a dump zone with zero rules. Screenshots, half-thoughts, exports, files I pulled off OneDrive, whatever. The rule is that capture has to be frictionless or you stop capturing, and deciding where a thing belongs is a completely separate job from writing it down. I empty it about once a week by pointing Claude at it and saying “file these.”

7. Resources holds anything serving more than one project - my writing style reference, reusable prompts, and a running “field lessons” file that is every “dead ends” section from every brief pulled into one searchable place. That last one gets used more than I expected, because a dead end is a fact about a tool, not about a project, and I go looking for it by symptom.

The one rule that keeps this from rotting: the folder is the source of truth, and only 0. About Evan.md gets uploaded into Claude’s project knowledge. Briefs stay on disk and get read live. If you upload a copy of a brief and then edit the original, you now have two versions and Claude will confidently use the stale one. Ask me how I know.

Dumping in everything else

And you can extrapolate from there and drop in other information you need organized. For example, before I was doing this I had files saved on my OneDrive or otherwise on my PC locally. Previously I would drag and drop these into the chats/Projects manually and instruct Claude from there. As previously alluded to: This can become quite cumbersome and I’m storing data/information/documents across multiple streams with varying degrees of uniformity - another issue that the Second Brain concept aims to solve. To bring the quote up again: “Your brain is good at thinking and bad at storage, so stop asking it to store things.”

With this in mind, I more or less grabbed every file I could find that I would want ingested and integrated into this data borg - spreadsheets from my OneDrive, odd Word documents with notes, other study guides, reference material, etc; basically anything I wanted organized by Claude, analyzed, stored for future reference while still providing easy enough access for me to update things manually (e.g. a financial spreadsheet I make manual updates to, but save directly in the Cogitator for Claude to access and store). Drop all of that in your inbox and re-prompt “Analyze and store these documents into the proper projects.”

That run was 157 files and about 71 MB - screenshots, playbooks, study guide PDFs, four versions of my IT Field Manual, a pile of resume drafts going back to March. A few things worth knowing about how that actually went, because it was not purely magic:

It sorted everything by project and put active work in 1. Working/ and finished material in 2. Reference/, which is the split I would have made by hand and did not have to.
It found 28 groups of exact duplicates by checksum - the same AZ-900 study guide saved in two places, and 26 screenshots that existed twice under different filenames because I had renamed them for the website. It kept one copy of each and wrote a small mapping file so the rename is still reproducible. That is roughly 9 MB of my own mess that I did not know I had.
It did not delete anything. Everything it pulled out went into a _to_delete/ folder for me to review and empty myself, which is the correct behavior and I would be suspicious of a setup that did otherwise.

Then the actual payoff. An example:

Previously I had been using Grok for resume writing and help, storing all of my resume related documents in my OneDrive.
I created the Branding Project in Claude for the explicit purpose of helping me build a cohesive “brand” for myself - a resume being a part of this line of effort.
Up until I created this project, Claude had zero reference to work from other than what I’ve manually edited in its Memory or stored in a project context/instructions.
With this Second Brain, I simply dragged and dropped all of my previous resume stuff (master resume, tailored resumes, bulleted lists of notes, and so on) into the 00. Inbox, pointed a Claude instance under the Branding umbrella, said organize/ingest these files, analyze them, and update my master resume based on the information you’re able to find in the Cogitator folder. For example, my new Microsoft certifications hadn’t been reflected anywhere in my OneDrive resume folder. But Claude knows that I passed/acquired these certifications from another Project. Since all the information canonically lives in one place, Claude is able to pull information together from different projects to enable its task under a single project.
And in a matter of minutes I had a brand new, updated, revised resume.

That last bullet is the whole “thesis” in one example, so I want to be precise about what happened. The resume lives in the Branding project. The certifications live in the Cert Study Guides project. The homelab build that supplies half the resume’s technical bullets lives in IT Skill Development. Those are three separate Claude Projects that cannot see each other - but they are three folders in one vault, and a Cowork session reads all of it. The Project boundary stops mattering the moment the material is on disk.

Things that broke, because they will break for you too

I am not going to pretend this was clean nor quite as straightforward as I’ve alluded to - which is also a big point of writing this all down in article-form. Three things went wrong, all of them mine, and all three are the kind of thing you will hit if you build one of these.

1. I renamed a file and broke the system’s own start-up prompt.

Early on, the master context file was called CONTEXT.md. Two rounds of reorganizing later it was called 0. About Evan.md - but the “start of session” prompt I had saved still told Claude to go read CONTEXT.md. So I opened a fresh chat, pasted my own prompt, and the first thing that happened was Claude telling me the file I had asked for did not exist.

The fix is boring and it is the actual lesson: when you rename something, grep the whole vault for the old name. Instructions that point at files rot the instant you move the files, and you will not notice because you know where everything is.

2. My instructions told Claude to upload files, so it did.

Every project brief had a line at the top saying “upload this file to that Project’s knowledge base.” That was written as a note to me. A Cowork session with folder access read it as an instruction to itself, and helpfully uploaded three files into my Branding project - creating exactly the duplicate-copies-that-drift problem I had spent an hour building rules to prevent.

It did the reasonable thing. The instruction was just written for the wrong reader. If your notes-to-self live in a file an AI reads, they are not notes to self - they are instructions. Write them accordingly, and be explicit about what the AI should never do on its own.

3. I let a priority list turn into a gate.

My context file has a “current focus” section so answers land in the right frame. I had let it end with the line “Everything else waits. This is the honest priority order, not the interesting one.”

Read that as a human and it is a note about my own scheduling. Read it as an AI and it is a rule, so a fresh Claude opened by informing me that the thing I had just asked about was supposed to be waiting behind my A+ prep. Which - no. It is my vault and they are my questions.

That one is now explicit: priorities are context, never gates. It can flag that something is outside my stated focus in one line, and then it does the work anyway. Be careful about writing anything into your context files that an AI could enforce against you. You are building a reference, not a supervisor.

The actual step-by-step

Here is the whole thing with the storytelling stripped out. This is genuinely all of it.

1. Make an empty folder. Anywhere you will actually see it. Mine is on my desktop, synced to OneDrive so it’s backed up. Name it whatever your heart desires.

2. Open a Cowork session and connect that folder. In the Claude desktop app, add the folder as a connected folder. This is the step that lets Claude read and write files directly instead of you pasting things back and forth.

3. Ask Claude to build the structure - and tell it about you. Not “make me a second brain.” Tell it what you do, what you’re trying to get out of it, what your existing projects are, and what you’re worried about losing. My opening prompt was five sentences of context and two bullet points of concerns, and that was enough.

4. Look at what it made and reject it if it’s wrong. Seriously, I can’t stress this enough. The first layout it gives you will be reasonable and generic. If clicking through it feels annoying, say so. Better: point it at a folder you already navigate comfortably and say “make it look more like this.” Being specific is the entire skill.

5. Create one folder per Claude Project you already use, with the same four things inside each: a 0. Brief.md, a 1. Working/, a 2. Reference/, and a 9. Archive/. Add an 00. Inbox/ at the top level for dumping, and a Resources folder for anything that serves more than one project.

6. Write the two files that make it work:

0. About Evan.md (yours will have your name on it) - who you are, what you’re working on, how you want Claude to talk to you. This is the only file you upload into your Claude Projects.
0. START HERE.md - your naming conventions, what lives where, and any rules you want a fresh Claude to follow.

7. Distill your existing chats. For each Project, find the two or three conversations actually carrying the work. Scroll to the bottom of each one, paste the distillation prompt from earlier in this article, and save the output. Drop them all in the Inbox.

8. Point Claude at the Inbox and tell it to file everything. Then keep doing that. Every time you have a pile of stuff - screenshots, exports, old documents, whatever - it goes in the Inbox and gets sorted later.

9. End sessions by writing back. This is the habit the whole thing depends on and the one people skip (I would also skip it if this was any harder/more complicated - hence Step 4). When you finish a conversation that produced something, tell Claude to update that project’s 0. Brief.md before you close it. Ninety seconds. If you skip this step, you are just building a folder of files you stopped updating.

That’s it. There is no step ten, there is no template to buy, and there is no course.

Wrapping up

This is but a small example of how simple and streamlined this can be. I don’t have to hunt for documents anymore, I don’t have to remember what I did and did not take notes on, when I want to work on something with multiple inputs I don’t have to scramble across multiple systems to get my required data. None of it. Drag, drop, prompt, read, refine, repeat.

The one honest caveat I’ll leave you with: the system is only as good as the writing-back habit. Everything above is logistics - the folders, the numbering, the conventions. The part that actually determines whether this is still useful to you in six months is whether you spend the ninety seconds at the end of a session telling it what happened. Forte’s CODE framing had four letters and Claude was right that only Distill matters. That is the one you have to do, and it’s the one no amount of tooling will do for you.

That’s all there is to it. Nothing complicated, you don’t need to waste an hour watching dude-bro YouTube videos, and you sure as heck don’t need to pay money for someone else’s template (granted you need to pay for Claude/your AI model of choice, but come on you know what I mean). You already have the one tool you need to accomplish this - use it to your advantage and reap the rewards. And once you’ve set it up the way you want with your AI agent’s help - feel free to pick up some nice signs from Target to hang in your dining room; your friends think you’re super clever I promise.

If you want the technical version of all this - the architecture, the migration numbers, and the three failure modes written up like an actual incident report instead of a guy talking about hammers - that’s here: Claude Second Brain - Personal Knowledge System →

Now if you’d like a link to my affiliate marketing course, please see the link at… (kidding)

The IT Field Manual, version 1.3

Mon, 24 Aug 2026 09:00:00 -0600

The IT Field Manual is now at version 1.3. Version 1.0 went up five days ago at approximately 37,000 words across 23 sections. It now runs approximately 93,000 words across 31.

This was not a rewrite. Sections 00 through 21 are unchanged and every tag from version 1.0 still resolves, which was the whole point of tagging blocks instead of numbering them. Three versions landed in five days because three different piles of material came due at once: a set of course notes I had never filed, a study guide I was working through, and the Microsoft 365 project I finished over the weekend.


Version	1.3, 23 August 2026
Size	~93,000 words · 31 sections · ~440 headings
New since 1.0	§22 – §24 fundamentals · §26 – §30 cloud administration
Corrections logged	54 in `[APX-C]`, up from 16
Read / download	Online · raw Markdown

1.1 – the layer that was missing underneath

Version 1.0 had a real gap and I didn’t see it until I tried to explain something out of it. The manual could tell me the command to run, the order to run it in, and what the output should look like. It could not tell me why that was the right command, because there was no protocol or security layer sitting under the operational one.

Concretely: there was nothing on the OSI model, CIDR and subnet math, DNS record types, the DHCP DORA sequence, TCP handshake semantics, cryptography, AAA, or the Kerberos ticket flow. Those are the things a client and/or a senior engineer asks about after the ticket is closed, and “the runbook said so” isn’t an answer either of them accepts.

Sections 22, 23, and 24 close it. The tag prefixes are deliberately split rather than merged:

Prefix	What it holds
`[NET]`	Network diagnostics – the commands you run
`[NETF]`	Networking fundamentals – the reasoning underneath them
`[SEC]`	Security procedures – least privilege, incident response
`[SECF]`	Security fundamentals – crypto, AAA, threat taxonomy
`[SYSF]`	Systems and directory concepts – MBR/GPT, LDAP bind, SAM

When something is on fire I want the first one. When somebody asks me to justify it, I want the second. Keeping the two apart means neither search has to wade through the other, and it costs nothing but a naming convention.

1.2 and 1.3 – the half of the job that is not on-premises

Version 1.0 was straightforward about where it came from. It came out of building a hybrid environment on hardware, so it was strongest on Active Directory, Group Policy, file services, and the sync bridge into the cloud. Actual cloud administration was one thin section.

Five sections now cover it:

§	Section	What it is for
26	Microsoft Purview and data governance	Sensitivity labels, DLP, retention, eDiscovery, and the simulation-mode trap
27	Copilot and agent administration	Oversharing readiness, licensing, RCD vs RSS vs RAC, agent governance
28	Public DNS for mail	MX, autodiscover, SPF, DKIM, DMARC, DNSSEC, and wildcard records
29	Exchange Online administration	Message trace, quarantine, shared mailboxes, delegation, proxy addresses
30	SharePoint Online and OneDrive	External sharing, guest access, and the people picker

Sections 28, 29, and 30 are the M365 project written back into reference form, with the lab’s hosts, domains, and tenant names stripped at the moment of writing rather than later. Sections 26 and 27 came out of the Copilot and Agent Administration Fundamentals material I am studying, with the exam scaffolding removed – the passing score and the domain weighting do not transfer to a job, and the product behavior does.

Two new rules in the doctrine section

Section 01 is ten rules that apply regardless of which technology is broken. It hadn’t changed since version 1.0. It now has twelve.

[DOCTRINE-11] – an override makes your diagnostics lie. A wildcard DNS record, an allowed-sender entry, and a DLP policy left in simulation mode are three unrelated products doing the same thing: the test still runs, still returns a result, and the result still looks like an answer. I wrote about all three in more detail last week.

[DOCTRINE-12] – read the screen before you diagnose. Three separate incidents on one project were answered by information already rendered on the monitor in front of me. The most expensive was a DNS delegation I waited on for forty-five minutes while the admin center displayed a banner saying DNSSEC was enabled and Microsoft 365 DNS hosting doesn’t support it.

That one is the image at the top of this post. It seemed only fair to leave it there.

The correction log is the part I would read

Appendix C records every claim in my own source material that turned out to be wrong, alongside the correction and where it was verified. Version 1.0 shipped with 16 entries. Version 1.3 has 54.

A representative handful:

The DKIM selector CNAME format changed in May 2025 and now includes a dynamically assigned partition character. The target ends .dkim.mail.microsoft.com, and truncated examples missing the trailing .com are still circulating, which leaves the record stuck on CnameMissing.
Message trace is interactive out to 10 days, not 7. Original client IP is retained for 10 days and appears only in the downloadable reports.
The quarantine retention default depends on where the policy was created. Thirty days in the Defender portal, 15 in PowerShell. The correct move is to read it off the policy rather than quoting a number from memory.
Business Premium sensitivity labels can apply encryption, which I had filed as an E3 feature. What Business Premium actually lacks is automatic and recommended labeling.
Sensitivity labels as a DLP condition are E5-tier. On Business Premium the policy saves without complaint and then silently never matches, which is a worse failure than an error message.

Two entries are flagged as unverified rather than quietly dropped, because I could not confirm them against Microsoft Learn, and a labeled maybe is worth more than a confident wrong answer.

The instruction I did not follow

The M365 project produced a tagged module written to be pasted straight into the manual. Its own integration instructions said to add it as sections 23 through 26 under a [PUR] tag prefix.

Both were wrong by the time it was written. Sections 23 through 26 were already occupied by the fundamentals layer added in 1.1, and [PUR] collides with the existing [PURV] prefix badly enough that a search for one returns both. So the Purview material got merged into the existing §26 instead of standing up a second Purview section, and the new material landed at 28 through 30.

I’m noting this because it’s the failure mode of any generated documentation, including the kind I produce with an assistant. The instructions were written against a snapshot of the manual that was already four days stale. Pasting them in as written would have produced two Purview sections, a colliding tag, and a contents table that lied about both. Documentation that arrives with integration steps still has to be integrated by somebody holding the current version.

What is next

Section 25, “Personal additions,” is still empty, and that’s still deliberate. It is the landing zone for entries that have not earned a home yet, and an empty section is a standing invitation to fill it.

Moving forward: an Ubuntu Server file/print services build, which is the next thing the manual has no coverage of at all, and converting the inline scripts into a real parameterized toolkit. Version 1.4 will most likely be Linux and Samba.

That all being said, the manual is public because a document I know somebody might read is a document I write more carefully. If you spot something in it that is wrong and/or out of date, I would be more than happy to hear about it – that is what Appendix C is for, and it is the appendix I expect to keep growing!

Read the Field Manual → · Browse the Reference Library →

Three times in two days, a system told me it worked when it hadn't

Sun, 23 Aug 2026 18:00:00 -0600

I spent two days last week doing the unglamorous half of Microsoft 365 – mail flow, shared mailboxes, distribution lists, SharePoint sharing, and a DLP policy. The full write-up is up now:

Microsoft 365 Administration – Mail Flow, Collaboration & Data Governance →

The last project built a hybrid environment from bare metal, which answered how do you stand this up and never once touched what do you do on Tuesday – and at a small business, Tuesday is almost entirely email. Shared mailboxes, “where did my message go,” “why is this in quarantine,” “can you give Sarah access to the sales inbox.” I had zero hands-on with any of that, so it is what I went after this time.

Nine root-cause findings came out of it. Three of them turned out to be the same finding wearing different clothes, and that one is the reason this is a post and not just a link to the case study.

The pattern

A wildcard DNS record. I ran an inventory script expecting five DNS name does not exist answers for five missing records, and what came back instead was five perfectly valid answers. The registrar’s default * parking CNAME was quietly answering for every subdomain that had no explicit record of its own. Every “does this record exist?” check came back yes, and not one of the five records existed.

An allow-list entry. I had modified an anti-spam policy for a quarantine test and then never reverted it, which contaminated the next task. So I added an allowed-sender entry to stop the interference – which meant my subsequent “is it reverted yet?” test would deliver successfully whether or not the revert had taken. I had destroyed my own ability to tell the two states apart, and I had done it with a fix.

A DLP policy in simulation mode. This is the one that actually bothers me. Outlook showed the policy tip before send, message trace logged three DLP rule evaluations, and I received a notification telling me I had shared content containing a credit card number outside the organization. Every surface a reasonable person would think to check said the policy was working.

The card number arrived at the external recipient in plain text.

I flipped the policy to enforcement and ran the identical test half an hour later, and the message trace came back effectively identical – same events, same rule evaluations, same policy tip, same user notification. The only difference anywhere in the chain was at the far end, where the recipient this time received an encrypted .rpmsg wrapper instead of a readable card number.

Why this is worth a post

An override does not only change behavior; it changes what your tests report, and it does that silently. The test still runs, it still returns a result, and the result still looks exactly like an answer.

Had I deployed that DLP policy for a client and walked away, I would have told them their data was protected. It was not. Nothing on the admin side would ever have contradicted me.

Four rules I am keeping:

Remove overrides before testing, not after. A revert verified while an override is still active is not verified.
Verify at the far end. DNS answering is not mail flowing. A policy tip is not enforcement. Check what the recipient actually received.
When a result matches what you expected, ask what the test could not have told you. Agreement is not confirmation.
In an inherited environment, inventory the overrides before you trust any diagnostic. Wildcard DNS records, allow lists, disabled policies, simulation-mode policies – all invisible until you go looking for them specifically.

The other one I earned the hard way

Separately, and more embarrassingly: I burned approximately forty-five minutes waiting on a DNS delegation to Microsoft that was never going to work, because DNSSEC was enabled on the domain and Microsoft-hosted DNS does not support it.

The admin center had a banner saying exactly that. On screen. The whole time.

Two more of the same shape are in the write-up – a SharePoint share that “never arrived” where the confirmation dialog had named the actual recipient, and an unexplained Drop in a message trace whose detail line carried an SMTP success code. In all three cases the answer was already rendered on the screen I was staring at, well before I started building a theory about what might have gone wrong.

Reading the banners and/or the confirmation dialogs is a cheaper habit than the alternative.

Read the full case study →

The IT Field Manual, version 1.0

Wed, 19 Aug 2026 20:00:00 -0600

Update, 24 August 2026. The manual is now at version 1.3 – roughly 93,000 words across 31 sections, with a fundamentals layer and five new cloud administration sections. Everything below still holds, with one exception: “Personal additions” moved from §22 to §25 when the fundamentals sections were added. See what changed in v1.3.

I have published the IT Field Manual – the single document I work out of. It sits at the top of a new Reference Library alongside the build playbooks and, before long, a script toolkit.

It is version 1.0 of a living document rather than a finished one, and it is going to stay that way.

The problem it solves

For the first few months of building things I took notes the way most people take notes: a file per topic, named after whatever I was doing that day. ad-notes.md. intune-stuff.md. powershell-things.md. A folder of them.

The failure mode showed up the first time I hit a problem I had already solved. I knew I had written down the fix for Folder Redirection failing with Event ID

What I could not remember was which file it lived in, whether I had filed it under Group Policy and/or file permissions, or what I had named it. Finding it again took longer than solving the thing from scratch would have taken.

Notes scattered across a dozen files are not a reference – they are a search problem you built for yourself, and the bill comes due at the worst moment.

What actually changed

One file. Thirty-seven thousand words. And one rule that makes it work:

Every block carries a bracketed tag. Search the tag, not the prose.

A note about domain join failures is tagged [AD-JOIN-FAIL], Group Policy triage is [GPO-TRIAGE], and the Service Connection Point trap that cost me an afternoon is [HYB-SCP]. When I write a new entry that relates to an older one I reference the tag rather than the section, and that reference still resolves after I have reorganized the document twice, because the tags stay stable even when the section numbers do not.

The practical effect: Ctrl+F, type the tag, land on the answer. No folder structure to remember, no naming convention to be consistent about, no decision about where something belongs.

What is in it

Twenty-three sections. The ones I open most:

§18 – Error → cause → fix index. The error text goes in exactly as it appears on screen, and the index does the rest. This is the front door most days.
§01 – Troubleshooting doctrine. Ten rules that transfer between every technology in the rest of the manual. “The error message describes the symptom, not the cause.” “A backup you have never restored from is a hypothesis.”
§06 – Greenfield build order. Fifteen phases, in the order the work should be done rather than the order you learn it in.
§15 – Standard operating procedures. Onboarding, offboarding, workstation deployment, monthly maintenance, FSMO seizure, compromised account response.
§16 – Assessing an inherited network. A discovery block to run before touching anything, and triage trees for what you will find.

Plus PowerShell fundamentals, network diagnostics, AD operations, Group Policy, file services and permissions, hybrid identity, Intune, Microsoft 365, Azure, Windows client builds, storage, decommissioning, a script toolkit pattern, and documentation templates.

The rules

Three, written into the manual’s own maintenance protocol:

Strip the client. No real hostname, IP, username, or domain ever goes in – the placeholder gets substituted at the moment of writing rather than later. A manual full of real client detail is a manual nobody can ever be handed, and the retroactive cleanup never actually happens.

Record the fix, not the workaround – and a workaround that had to be used gets labeled as one. A workaround is a modification to the environment, and the environment remembers it long after the person who made it has forgotten. Unlabeled workarounds are the most expensive category of self-inflicted troubleshooting there is.

Date anything Microsoft can change. Portal click-paths, product names, and CLI switches rot on their own schedule, while facts about protocols – Kerberos clock skew, DNS SRV records, NTFS evaluation order – do not rot at all. The first kind carries a date; the second kind does not need one.

Why publish it

Two reasons, and only one of them has anything to do with other people.

The honest one first: a document I know is public is a document I write more carefully. Vague notes survive in private. They do not survive being read.

The other is that this is the artifact that actually represents the work. The hybrid AD case study describes an environment I built and then deliberately destroyed, so the network itself is gone and what is left of it is the documentation. The only question worth asking about that documentation is whether it was good enough to rebuild from, and that one got answered when I rebuilt the environment out of my own playbook in 5 hours 58 minutes with no rework.

The manual is the same bet, made larger.

What is next

Section 22 is titled “Personal additions” and is currently empty. That is deliberate – it is where entries land before they get filed properly, and an empty section is a standing invitation to fill it.

Moving forward: converting the inline scripts into a real parameterized toolkit, and a second playbook once the Ubuntu file and print services build is finished.

Read the Field Manual → · Browse the Reference Library →

I built a hybrid AD environment, tore it down, and built it again

Wed, 19 Aug 2026 12:00:00 -0600

I have been building a simulated small-business network in my basement – a hybrid Active Directory and Microsoft 365 environment of the kind a 5–50 seat company actually runs. The full case study is up now:

Hybrid Active Directory & Microsoft 365 Environment – SMB Simulation →

The part I think matters most, and this is just my own read on it, is that I built the whole thing twice.

Round 1 was tutorial-led and out of order, and what it produced wasn’t a network so much as a list of failures. A .local domain name that forced me to rewrite every UPN later. Group Policy linked to an OU that held no computer objects, so it never applied to anything. Two separate administrative lockouts from permissions I set incorrectly. Every one of those got traced back to a root cause instead of worked around, and every one became a section of a playbook I wrote for myself.

Round 2 was the real test: rebuild the environment from that playbook, treat the playbook as a checklist, and find out whether the documentation held up under somebody using it. It held up. Five hours and fifty-eight minutes, bare metal to a hybrid-joined client with Intune-deployed apps and a replicating second domain controller, with no rework.

Three problems from the build are written up in full in the case study, with symptom, diagnosis, and resolution:

A domain join failing against a domain controller that answered ping without complaint – the cause was Kerberos clock skew, not DNS.
Hybrid Entra join failing after the users had synchronized perfectly – the Service Connection Point had never been written, because that step sits outside the linear Entra Connect wizard.
Intune enrollment failing completely silently – a group-based licensing group that had been created and assigned a SKU and then never given any members.

That last one threw no error and/or warning in any console, which is the sort of thing you don’t learn until you walk into it.

Read the full case study →

Evan Ireland

My New Work Laptop Was Not Quite What It Said on the Box

How I got here

Three ways to join a Windows PC, explained with an office building

The prep work happens before the laptop is ever turned on

Why not a pre-built bloat tool

The laptop

Scrub, wipe, reinstall

Device association, and an unplanned trip upstairs

Nine minutes

The green checkmarks lied (typical)

Installing apps without being an administrator

Proving LAPS end to end

Accounting

Lab compromises

What is next

The IT Field Manual, version 1.4

Why one v1.4, not three version bumps

New: the parts of the job that are not Microsoft

New: reading a company and a site before you trust either

New: the migration pitch, split into the two numbers it actually is

The placement call I made against my own source material

The correction log is the part I would read

What is actually next, which is not what I said last time

I Put a Server Cluster in My Basement

How I got here

The basement problem

Building the thing

And then DNS did not work for two days

What a resolver actually does

Finding it

The part I got wrong

Backups, and one thing worth stealing

The Deliniation of Work

Where it stands

Create a "Second Brain" using Claude

How I got here

Turns out I was already doing this

Setting it up

How Claude actually remembers things

The first layout was wrong, but refinement is always possible

Getting your existing chats out of their silos

What is actually in the folder, and what each piece does

Dumping in everything else

Things that broke, because they will break for you too

The actual step-by-step

Wrapping up

The IT Field Manual, version 1.3

1.1 – the layer that was missing underneath

1.2 and 1.3 – the half of the job that is not on-premises

Two new rules in the doctrine section

The correction log is the part I would read

The instruction I did not follow

What is next

Three times in two days, a system told me it worked when it hadn't

The pattern

Why this is worth a post

The other one I earned the hard way

The IT Field Manual, version 1.0

The problem it solves

What actually changed

What is in it

The rules

Why publish it

What is next

I built a hybrid AD environment, tore it down, and built it again