0.5 Building the Triage Lab: Steps and Costs

Introduction

Building a triage lab means assembling, from trials and free licenses, an environment where the course's portal steps and searches can be performed for real. Section 0.4 set out the paths and why the in-page records come first. This sub builds the two labs most students add: a Microsoft lab from a Microsoft 365 E5 trial, an Azure free account and a Sentinel trial workspace, and a Splunk lab on the Free license. Each step comes with its cost and its clock, as checked against the vendors' own pages on 27 September 2026. Two parts of the build are the ones people skip and regret: checking how far back the lab's evidence actually reaches before trusting any result from it, and ending each trial deliberately rather than letting it convert or expire on its own. By the end you'll have a lab you can build in an afternoon, a list of what it costs, and the reminders that stop it costing more.

Every part of both labs can be run at no cost, and every part has a condition that ends that, set by its vendor and not by the course. The conditions are what matter, because they are where bills come from. As checked on 27 September 2026:

Three of the five run on clocks of about a month, and each of them ends in a different way.

The card at sign-up is not a trick, and it is not optional. Microsoft uses it to verify the account and, for the E5 trial, to start the paid subscription when the trial ends; Azure uses it for verification and a temporary authorization. Both are stated on the vendors' own sign-up pages. The practical consequence is that the Microsoft lab is only free for students who end it on time, which is what the rest of this sub is built around. The E5 trial converts to a paid subscription, which is the one that bills; the Azure credit expires and its subscription is disabled unless upgraded; the Sentinel trial ends and ingestion is billed if the workspace keeps running on a paid subscription. Splunk Free and a self-managed Elastic Basic install do not expire at all, which is why they suit long-term practice.

The student's invoice came from the first entry on that card, and only from it. The E5 trial asked for a card at sign-up, as Microsoft's trials do, and converted when nobody canceled it. Nothing about that is hidden; it is on the trial's own page. It is simply easy to forget three weeks after a lab was last used.

None of the costs on the card include time, which is the other resource a lab consumes. Building the Microsoft lab takes an afternoon; keeping it useful takes a few minutes a session to check its sources. A lab that is not checked drifts: a diagnostic setting that stopped when a license lapsed, a workspace whose trial ended, a test user whose password expired. The check in Section 3 is the few minutes that keep the afternoon's work worth something.

The costs are also why the course recommends starting the Microsoft lab when a module needs it. A trial started on the first day of the course runs out, or converts, before the modules that most need the portals; a trial started on the day you reach Module 5 covers the modules that use it and ends soon after.

The Microsoft lab is built in seven steps, most of them a few minutes each, in an order that makes each step's prerequisite available when it is needed:

The order of the steps matters in two places, and both are easy to get wrong. The E5 trial comes first because it creates the tenant and brings the Entra ID P2 license that step 5 needs: exporting sign-in logs to a SIEM requires P1 or P2, and a tenant without it shows a warning at the diagnostic settings page and exports nothing. And the workspace comes before the logs, because a diagnostic setting needs a destination.

The lab also uses the same tenant for the E5 trial and the Azure free account, which keeps the identity, the workspace and the logs together. Signing up for Azure with the tenant's own administrator account keeps everything in one directory, which is the simplest setup; linking a workspace in a different tenant is possible but adds steps the course does not need.

Step 5 is the one that makes the lab genuinely useful for this course:

Test users matter more than they seem at first. A new tenant with only an administrator produces almost no sign-in records, so a lab without users gives the course's sign-in queries nothing to find. A handful of users, each signed in once from a browser and once from a phone, is enough to make the sign-in and audit queries return rows.

Step 6 brings Defender XDR's alerts and incidents into the Sentinel workspace, so the incident queue the course reads is the one the lab has. A new tenant will have few alerts, and that is expected: the lab is for performing steps, and the alerts to triage come from the Northgate records.

Before trusting any query result from a lab, check what each of its sources actually holds: when its records start, when they end, and whether they are still arriving. It is the check most people skip, and it is the one that every conclusion about absence depends on. At Northgate, the same check looks like this:

union
    (SigninLogs
        | summarize Earliest = min(TimeGenerated), Latest = max(TimeGenerated),
            Rows = count() | extend Table = "SigninLogs"),
    (AuditLogs | summarize Earliest = min(TimeGenerated), Latest = max(TimeGenerated),
        Rows = count() | extend Table = "AuditLogs"),
    (DeviceProcessEvents
        | summarize Earliest = min(Timestamp), Latest = max(Timestamp),
            Rows = count() | extend Table = "DeviceProcessEvents"),
    (EmailEvents | summarize Earliest = min(Timestamp), Latest = max(Timestamp),
        Rows = count() | extend Table = "EmailEvents")
// the check most people skip: how far back each source reaches, and is it current?
| extend DaysCovered = datetime_diff("day", Latest, Earliest)

(sourcetype="azure:monitor:aad" (category="SignInLogs" OR category="AuditLogs"))
    OR (sourcetype="ms:defender:eventhub"
    (category="AdvancedHunting-DeviceProcessEvents"
        OR category="AdvancedHunting-EmailEvents"))
| stats min(_time) as Earliest, max(_time) as Latest, count as Rows by category
| eval DaysCovered=round((Latest - Earliest) / 86400)

Four rows, one per source. Each of the four sources runs from 13 February to the late morning of 15 March, thirty days of records, and each is current to within about an hour of noon on 15 March. That is what a healthy source looks like, and it is the pattern to compare a lab against: a start date that covers the period in question, and a latest record close to now.

The check is also the fastest diagnosis when a lab query returns nothing. Four things can make a result empty: the query is wrong, the activity did not happen, the source is not collecting it, or the source did not exist at the time asked about. The how-far-back query rules out the last two in seconds, which leaves the question the analyst actually cares about.

In a Microsoft lab, the same check starts one step earlier, with the license that allows sign-ins to be exported at all. From Graph PowerShell:

Connect-MgGraph -Scopes "Organization.Read.All", "AuditLog.Read.All"
# the license: the E5 trial carries the Entra ID P2 service plan
Get-MgSubscribedSku | Select-Object SkuPartNumber,
    @{ n = "EntraP2"; e = { "AAD_PREMIUM_P2" -in $_.ServicePlans.ServicePlanName } }
# the source: the earliest and latest sign-in the tenant holds
$signIns = Get-MgAuditLogSignIn -All | Sort-Object CreatedDateTime
"Earliest: " + $signIns[0].CreatedDateTime
"Latest:   " + $signIns[-1].CreatedDateTime

In a new lab, the same query shows something different, and that difference is the point. Sign-in records start the day the diagnostic setting was saved, not the day the tenant was created; audit records start when auditing began. A query for last week's sign-ins in a lab built yesterday returns nothing, and the right reading is not that nobody signed in but that the source did not exist yet. Section 10.6 set the rule for absence claims: a source's silence means something only inside the window it covers.

The check also finds a source that has quietly stopped, which happens whenever a trial or license behind it lapses. A latest record from three days ago, in a source that should be current, means ingestion has failed, often because a trial has ended or a license has lapsed. Running the check at the start of every lab session catches that before a query's empty result is mistaken for a finding.

The query is worth saving in the lab itself, as the first thing run in every session. It costs a second and it answers the question every other query depends on: is there evidence here to find.

The same check belongs in every triage, not only in labs. The capstone found a web server whose sensor recorded one process all month; the check would have shown that before anyone relied on the server's silence.

The Splunk lab is simpler and lasts longer. Splunk Enterprise starts on a 60-day Enterprise Trial and then converts to the Free license, which has no expiry:

The fourth step deserves the most care of the five. Switching to Free removes authentication, so there is no login page, and any alerts defined stop triggering. Doing it deliberately, before the trial ends, avoids discovering those changes by surprise. The fifth step protects the lab's future: loading more than 500 MB in a day triggers a license warning, and three warnings in a rolling 30 days stop searching.

Sizing the loads is easier than it sounds, because most practice data is small compared with the limit. At Northgate, the sign-in table's daily volume looks like this:

SigninLogs
// how much a source produces per day, which is what trial limits are measured against
| summarize SignIns = count() by Day = bin(TimeGenerated, 1d)
| summarize Days = count(), Fewest = min(SignIns), Most = max(SignIns),
    Average = round(avg(SignIns), 0)

sourcetype="azure:monitor:aad" category="SignInLogs"
| bin _time as Day span=1d
| stats count as SignIns by Day
| stats count as Days, min(SignIns) as Fewest, max(SignIns) as Most,
    avg(SignIns) as Average

One row. Across 31 days the tenant logged between 72 and 425 interactive sign-ins a day, about 265 on average. Sign-in records are typically a few kilobytes each, so even the busiest day at a company this size is a small fraction of 500 MB; a trial tenant with a handful of users produces far less. The limit matters only when loading large bulk exports, which is when to split them across days.

The Splunk lab also teaches something the Microsoft lab does not: ingestion. Loading an export means choosing how Splunk reads it, which fields it extracts and which timestamp it uses, and getting any of those wrong produces searches that return nothing or return the wrong times. A student who has loaded their own sign-in export and made the course's SPL tabs work against it has learned the part of SIEM work that a hosted console hides.

The field names will differ from the course's. The SPL tabs are written against the course's Splunk projection of the Northgate records, and an export loaded by hand will name its fields as the export does. Adjusting a tab to the loaded fields is a small exercise in its own right, and the one most like the work of moving queries between real environments.

Elastic follows the same pattern with different limits. A self-managed install runs on a Basic license with no expiry, so the steps are the same: install, load, search, and keep the load within what the machine can hold.

Every trial ends eventually, and the only question worth planning for is whether it ends by decision or by default. Laid on one timeline from the day each is started:

Three bars end within a day of each other, around day 30, and the first of them converts to a paid subscription. The two long bars, Splunk's trial and the Free license after it, carry no cost at their end; the short Elastic bar ends without one too. The red line at day 28 is the one to plan around: two days before the E5 trial and the Azure credit end, it is the day to cancel, export or decide to keep.

Canceling the E5 trial is done in the Microsoft 365 admin center, by an administrator of the trial tenant:

Export first, before anything is canceled. A trial tenant's sign-in and audit logs are useful practice data for Splunk long after the tenant is gone, and they go when it goes. Microsoft's own terms give a short window after conversion to cancel with a prorated refund, which is worth knowing and not worth relying on.

The Azure free account ends more gently, and needs less from the student: when its credit expires, its subscription is disabled unless you choose to upgrade it, and the Sentinel workspace on it stops with it. The risk there is upgrading by accident, which moves every running resource to pay-as-you-go billing. Splunk's trial ends by converting to Free, which costs nothing and changes what the lab can do.

Ending a trial also ends the lab's evidence, which is easy to forget in the rush to stop a bill. The sign-in and audit records in a canceled tenant go with it, and the workspace's records go when its subscription is disabled. If the lab has produced anything worth keeping, a sign-in export for Splunk practice, a set of audit records from a containment step rehearsed, it is exported before day 28, not after.

Some students will decide to keep a component running, and that is a legitimate outcome. A student whose employer will reimburse a single E5 license for continued practice, or who wants the Azure subscription for other work, can let it convert on purpose. The point is that it happens as a decision with its cost known, not as a surprise on an invoice.

The simplest protection is the one the student did not have: a reminder for each trial, set on the day it starts. Two days before the end is enough time to export, decide and act, even for a student who has not opened the lab in weeks.

The student's lab was built well, used only briefly, and then ended very badly. Read its state on day 34 and make the call:

The call stops the one component that is billing and settles the others, in order of what each is costing. Cancel the E5 subscription now in the admin center, and check Microsoft's cancellation terms for a prorated refund, since the conversion was recent. Confirm the Azure subscription is disabled rather than upgraded, which also stops the Sentinel workspace. Decide about Splunk before day 60: switch to Free deliberately, knowing the three alerts will stop firing, which does not matter for the course because its alerts come from the records.

The student also stood to lose the lab's evidence along with its cost. With the tenant about to be canceled, its sign-in and audit records go with it; had they been exported on day 28, they would be practice data for Splunk now. That is worth doing before any cancellation, even a late one.

The larger lesson here is about when to build. A lab built on day one and used until day 12 spent most of its trial idle and all of its cost after it. The invoice is the visible part; the lost practice time is the larger cost, since the portal steps the lab existed for were never rehearsed in the modules that teach them. The same lab, started on the day the student reached Module 5 and ended after Module 7, would have covered the modules that need the portals, stayed inside its trials, and cost nothing.

The steps fit a card for any lab built from trials:

The second row is the one the student missed. Every other row on the card can be done late; a reminder set late is no reminder at all.

Practice

Build the lab only when a module first calls for it, and put all of its end dates in your calendar on the same day.

If step three finds a change, the vendor's page wins; set your reminders from its dates.

Section 0.6 introduces the three instruments the course is built around: the scorecard, the query pack and the Triage Report.