If you manage Windows devices long enough, you will end up here:
“Microsoft support needs TSS logs.”
And immediately your soul leaves your body.
Collecting Microsoft TSS (Troubleshooting Support Script) logs is something every Intune admin eventually needs to do, but it’s way harder than it has any right to be in a cloud‑managed, user‑not‑local‑admin world.
The Usual TSS Experience (aka PITA)
Let’s just be honest about how this normally goes:
- User reports an issue (WU, Autopilot, setup, servicing… pick one)
- You open a case and they ask or you already know support will ask for logs
- You send the user instructions to pull TSS logs:
- Download this .zip and extract it
- Use PowerShell to run it as admin
- Use the right command line
- Don’t close the window no matter how long it takes
- Don’t forget to clean up temp files
- User runs it wrong, or not at all
- You wait…ticket SLA ticking
- User sends the wrong ZIP
- Or worse… nothing
Hey Microsoft: users aren’t admins, devices are remote, and asking users to run PowerShell scripts is fantasy land!
So anyway, let’s stop doing that.
Instead, how about something that provides:
✅ Zero user interaction
✅ SYSTEM‑context execution
✅ Always downloads the latest TSS.ps1
✅ Consistent log scenarios
✅ Centralized log collection
✅ CMTrace‑compatible logging
So, basically what we Intune admins need, is an enterprise‑ready PowerShell script that automates the entire TSS workflow so it can run silently as SYSTEM, triggered by an Intune Remediation script run on-demand against a specific device, and delivers logs directly to a central share—ready for support or Microsoft escalation. Why that capability is not part of the service already when support asks for it every single time we open a case is beyond me, but I digress.
What is needed is something purposely built for Intune Remediations that cleans up after itself. Something purpose‑built for modern endpoint environments (a.k.a. reality) where:
- Devices are remote
- Users are not admins
- Support needs logs from multiple machines, now not later
End‑to‑End Workflow Overview
I’m not going to go into all the nitty gritty details about the script here because that’s what GitHub ReadMe’s are for (and I’ll probably add something to the script by the time you read this blog post), but at a high level, here’s what Get-TSSLogs.ps1 does:
- Enforces 64‑Bit PowerShell. TSS will not run reliably in a 32‑bit host so the script checks architecture and relaunches itself using SysNative when needed.
- Verifies Network Share Permissions. Before doing any work, the script confirms the computer account has write access by writing a test file to the share you’ve specified and then deletes it. This prevents wasting time collecting logs that can’t be uploaded.
- Cleans Old Local TSS Output. TSS loves dumping ZIPs into C:\MS_DATA. If you don’t clean that up, you end up copying stale or multiple ZIPs and wondering which one is “the right one”. If previous TSS runs have left random ZIP files behind in C:\MS_DATA, they’re removed first. This ensures uploads are always clean and bonus: you don’t have gigs of collected TSS log files clogging up your devices.
- Downloads the Latest TSS Package. Instead of embedding a static copy, the script pulls TSS dynamically from: https://aka.ms/getTSS (this guarantees you always use the newest supported TSS—and they do update it occasionally).
- Extracts and Executes TSS Silently. TSS.zip is extracted to a temporary location (C:\Windows\Temp) and executed with: -CollectLog <Scenario>. Where <scenario> is a supported TSS script -CollectLog scenario like DND_SetupReport (most likely candidate), DND_WUfBReport, DND_SETUPReport, MCM_Report, etc. I’ve hard-coded DND_SetupReport but changing scenarios requires only a single variable update in the script.
- Transfers Logs to a Central Share. After collection is completed, TSS .zip log files are copied to somewhere you actually control. Any failures cause a non‑zero exit code. If the logs aren’t on the share, the script fails. Period.
- Cleans Up Everything. Once the remote upload is validated, the script deletes C:\MS_DATA, extracted TSS folders, and any downloaded ZIP files. Devices stay clean. No log hoarding.
- Logging that doesn’t suck. All execution is logged to C:\Logs\TssLogCollection.log with custom log function outputs in CMTrace‑compatible entries, you know, so you can read it and stuff.
When run as a remediation, as it should be, the script also writes explicit [PASS] or [FAIL] output to integrate cleanly with the Intune Admin Center remediation detection output. [PASS] means it worked, [FAIL] means…well, I’m sure you know the opposite of worked. Also, don’t panic if you see pre‑remediation detection errors. TSS tends to fail several checks while it runs amuck on your devices for 20+ minutes. What matters is the detection output generated by the script.
Things to consider before using the script as an Intune remediation
- Network share must allow computer account writes
- Internet access to aka.ms/getTSS is required
- Remediation must run in 64‑bit PowerShell
Why I Actually Use This
Because the moment someone says:
“We need TSS logs”
I don’t:
- Email a user
- Schedule a call
- Send instructions
- Hope they follow them
I trigger a remediation and wait for the ZIP to show up.
That’s it.
Final Thoughts
TSS.ps1 is Microsoft’s supported, internal‑grade diagnostic collection framework for Windows. It replaces most of the old standalone tools we used to juggle so instead of asking you to manually gather half a dozen things, Microsoft bundles all of that logic into scenario‑based collections via the TSS.ps1 PowerShell script. That’s what the -CollectLog parameter does. So, when you run:
TSS.ps1 -CollectLog DND_SetupReport
You’re telling Microsoft’s own tooling:
“Collect everything engineering would normally pull if this machine was in a Microsoft lab.”
This is why support trusts TSS output more than screenshots, manual exports, or “here’s my WindowsUpdate.log”.
All that being said, pulling TSS logs should not feel harder than fixing the issue itself. Use this script instead because:
- Users aren’t reliable log collectors
- Intune runs as SYSTEM
- And diagnostics should be automated, not negotiated
If you’re tired of chasing logs, this pattern will save you real time — and probably your sanity.
You’re not alone.
