- BitLocker card on the PC Information page is now cloud-aware. On Windows 365 Cloud PCs and Azure Virtual Desktop session hosts the card incorrectly read “Not encrypted” even though the disk IS encrypted — just at the Azure host layer using platform-managed keys, not by BitLocker inside the guest. It now shows a green Cloud-encrypted status with a one-line explanation, matching the home page's Drive encryption card.
- Detection is the same two-factor check the home page uses — the PC must be a Hyper-V VM AND carry a Cloud PC / AVD signal (hostname starts with
CPC-, theCloudDesktopregistry marker exists, the firmware model contains “Cloud PC”, or the AVDRDInfraAgentregistry key is present). Physical PCs can never be misclassified, even with the Windows 365 client app installed.
Welcome to My365 Device
Your IT helpdesk in one place. See what your IT department has set up on this PC through Intune, run quick fixes, and look up plain-English how-to guides — all without calling support or opening a command prompt.
What is this app?
My365 Device is a Windows 11 desktop app — branded for Netlogic My365 — that gives end users a friendly window into their Intune-managed PC. The home screen tells you in one glance whether everything IT has pushed to your device is working, the Managed by IT page lists every app, setting, and script with a plain-English status, and the User Guides and Troubleshooters pages cover the most common things a Windows 11 + Microsoft 365 user might want to do.
Why would I use it?
Who is it for?
Anyone using a Windows 11 PC that your IT department manages. You don't need to be technical — the app reads through all the complicated Windows behind-the-scenes information for you and shows you only what's useful: what happened, when, what it means, and what (if anything) you should do about it.
What this guide covers
Opening it for the first time
The first time you launch My365 Device, the app does some background work to make every later session fast. Here's what's happening and what you'll see.
What happens behind the scenes
- The app scans known log locations on your PC — about a dozen folders Windows and Microsoft 365 use to record what's happening (Intune, OneDrive, Defender, Office, Edge, Windows Update, and more).
- It pre-reads the most recent logs in parallel so the first time you click into one, it opens instantly instead of having to parse a multi-megabyte file on demand.
- It loads the bundled Netlogic My365 user guide (146 topics) so the User Guides page opens instantly.
All of this finishes within a few seconds and never sends anything off your computer.
What you'll see
On first launch the window opens in the middle of your screen at 1480 × 940 logical pixels (it scales up on high-DPI displays). After that, the app remembers the size, position, and maximized state you left it in and restores them on the next launch — so once you’ve sized the window the way you like, it stays that way. The window uses the Windows 11 Mica backdrop — the soft frosted-glass look — and follows your system’s light/dark theme automatically. You can override that in Settings if you prefer.
On the left is the navigation rail. At the top of the window you'll see a date filter showing "Today" by default. Across the rail, in order, you'll find:
- Overview — the home page
- Logs — the log viewer
- Troubleshooters — Microsoft's fix-it tools
- User Guides — 146 plain-English how-to articles
- Settings — theme switcher
- About — version info
The "Show:" drop-down at the very top of the window controls how much history every page looks at. Choose:
- Today — just things that happened since midnight (the default).
- Last 7 days — the past week.
- Last 30 days — the past month.
- Custom date range… — pick any From / To.
The filter applies everywhere — the Overview page's counts, the Logs page's lists, and the entries shown when you open a specific log.
By default the app follows your Windows 11 system theme. To override:
- Open Settings from the navigation rail.
- Choose Light, Dark, or System default.
Your choice is saved per-user and survives app restarts.
The Overview page
The home page is the answer to one question, in one glance: is everything IT has set up on this PC working right now? Quick actions, in-depth views, and how-to guides are all one click away from here.
What's on the home page
At the top of the page is the welcome card with the My Device icon, the app name (“My365 Device”), and a one-line description of what it does. It's signposting only — there are no actions here. The work happens in the rows below.
Four big buttons for the things you'll do most often:
- Sync with Intune — pulls the latest policies, apps, and scripts from your IT department's Intune service. Use this when IT tells you "I just pushed an update — sync your device."
- Check for Windows updates — opens Settings → Windows Update and kicks off a real online scan in the background. Use this if you suspect updates are pending or stuck.
- Update apps — opens a native in-app dialog listing every app with a newer version available. Pick which ones to update (everything is checked by default), see live per-app progress bars as each one installs, and read clear per-row outcomes when it's done. A small red badge on the tile tells you when updates are waiting. Works for standard users — apps that need admin to install are flagged rather than failing silently.
- Restart PC — confirms with you, then restarts in 5 seconds. Many issues clear up after a fresh boot — this is the IT classic for a reason.
See the Quick actions section for what each one actually does, and when to use it.
Three large cards under the “What would you like to do?” heading. Each takes you to a major area of the app:
- User Guides — 146 plain-English how-to topics from the bundled Netlogic My365 guide. Search the one you need or browse by app.
- Run a troubleshooter — 42 official Microsoft fix-it tools for Microsoft 365, Outlook, Teams, OneDrive, Copilot, Edge, audio, Bluetooth, camera, and others.
The biggest, most useful element on the home page. A compact version of the chart from the Managed by IT page that answers in one card whether everything IT has pushed to this PC is working:
- Compliance donut — the ring on the left with the percentage of currently-applied items in the center. 100% healthy is the goal. Any amber or red on the ring is a visible signal that something's pending or has failed.
- Plain-English headline next to the donut, summarising the state in one sentence (“All clear — every Intune item on this device applied successfully” / “3 items are still applying” / “2 items need IT's attention”).
- Per-category counts — how many apps IT has deployed, how many settings are applied, how many scripts have run, and how many items need IT's attention (red number when non-zero).
- The whole card is a button — click it to jump to the full Managed by IT page with the same chart plus filter chips, search, and the grouped item list.
At the bottom of the page is a small one-line link to the diagnostic Logs page. It's deliberately understated — for typical end users the Managed by IT card above answers the “is anything broken?” question without needing to open a single log file. IT support staff and curious power users can still click this link (or the Logs entry on the left nav rail) to read the raw Intune, Windows, Defender, Office, OneDrive, and Edge logs in plain English.
The full Logs page is documented in detail under Reading your logs.
Quick actions
Four things you'll do over and over. Each one is a single click — but it's worth knowing what they actually do, and when each one is the right call.
What it does
Asks your PC to check in with your IT department and pull down the latest apps, settings, and scripts they want you to have. The app tries a few different ways behind the scenes to make sure the sync goes through, so you don't have to know which one your PC uses.
Use it when…
- IT just pushed a new app or setting and asked you to “sync your device.”
- You expected a new app to appear and it hasn't shown up yet.
- An IT-managed setting (Wi-Fi profile, certificate, sign-in option) didn't appear when you expected it to.
What you'll see
A progress bar walks through the steps and tells you what's happening at each stage. Most syncs finish in 30 seconds to 2 minutes. When it's done you'll see either Sync complete or a friendly note if it took longer than expected (in which case the sync may still finish in the background).
What it does
Opens Windows Settings to the Windows Update page and triggers a real online scan in the background. The app uses four layered methods to make sure the scan actually starts (the deep-link alone doesn't always work on managed devices):
- Runs the canonical Windows scheduled tasks (
UpdateOrchestrator\Schedule Scan,InstallService\ScanForUpdates) — the same ones Settings uses internally. - Calls
UsoClient.exe StartInteractiveScan— the user-mode update orchestrator. - Falls back to the modern
Microsoft.Update.SessionCOM API. - Final fallback to the legacy
Microsoft.Update.AutoUpdate.DetectNow()for older builds.
Use it when…
- You haven't updated in a while and want to make sure nothing's pending.
- Settings says "You're up to date" but you suspect updates are stuck.
- IT mentioned a security patch and asked you to install it.
What it does
Opens a clean in-app dialog that lists every installed app with a newer version available. You pick which ones to update (everything is checked by default) and click Update selected; each app installs one at a time with a live progress bar so you can see exactly what's happening. No command-prompt windows, no installer pop-ups — everything stays inside My365 Device.
- A quiet WinGet scan runs in the background on every app launch and surfaces the available-update count as a small red badge on the Update apps tile (caps at “99+”). Click the tile when the badge tells you something needs updating.
- The dialog opens with every available update pre-checked. Untick anything you'd rather skip — the button live-updates from “Update all (12)” to “Update selected (8)” so you always know what's about to happen.
- Updates are grouped by where they come from — From WinGet community catalog, From Microsoft Store, or Unknown source — so you can see at a glance which catalog manages each app. Packages installed outside any catalog show a small amber “Version unknown” badge.
- Click Update selected. Each app installs in turn with a thin green progress bar that climbs from 0 % to 100 %, parsed live from WinGet's own output. Installers that don't emit percentages fall back to a spinning ring.
- Per-app status: Done (a real install applied), Already current (WinGet decided nothing needed to change — shown with a blue info icon, broken out separately in the summary so it doesn't read as a failure), Needs admin, Close app & retry (the target app was open during install), or Failed with a View log link that opens the full WinGet log in Notepad.
Use it when…
- You see the red badge on the Update apps tile and want to clear it.
- You haven't restarted in a while and want to make sure your installed apps (Notepad++, VLC, Zoom, etc.) are up to date.
- You've heard about a security update for a specific app and want to be sure you have it.
- An app is acting up and you suspect it just needs the latest version.
What you'll see
Click any row (outside its checkbox) to open a small flyout with the publisher, description, homepage, and license — fetched live from WinGet's package manifest. After the run finishes, the summary tells you how many succeeded, how many were Already current, and any that need attention. A Check again button re-runs the scan without closing the dialog so you can verify everything caught. If you click Cancel mid-run the dialog says “Finishing <app> — then stopping” so you know the cancel was received (we don't kill in-flight installers; that could corrupt data).
What it does
Asks Windows to restart in 5 seconds. You see a confirmation dialog first — "Restart your PC? Save any open work first…" — and after you confirm, the restart can still be canceled with the Cancel restart button in the message that appears.
Use it when…
- Something feels off and you haven't restarted in a few days.
- An update finished and asked for a restart that you've been postponing.
- An app is acting strangely after install or upgrade.
Reading your logs
The Logs page is where the app does its real work. It reads dozens of cryptic Windows and Microsoft 365 log files and turns them into a one-sentence verdict: healthy, has a heads-up, or needs attention.
The Logs page layout
When you open the Logs page you'll see four things:
- Filter chips at the top — All, Needs attention, Intune, My365, Windows, Defender, Office, OneDrive, Edge. Click any chip to narrow the list. The Needs attention chip is the same filter you reach by clicking the “Logs that need attention” tile on the home page — only files with at least one error or warning.
- “Show advanced logs” toggle in the top-right corner. Off by default. Eight diagnostic sources are noisy or full of routine non-errors that drown out real problems — CBS Windows servicing, Delivery Optimization, Office telemetry, Office add-in (WEF) tracing, OneDrive settings snapshots, Defender platform internals, Defender for Endpoint telemetry, and the Edge browser debug log. Flip this toggle on to include them when IT support tells you to look at one specifically; flip it off to get back to the curated set.
- The file list on the left — every log file the app found, grouped by category and sorted with the most recently modified at the top. Search at the top of the list searches by name.
- The detail pane on the right — empty until you click a file. Once you do, two tabs appear: Summary and Full details.
The Summary tab (your default view)
The Summary is what the app was built for. It shows:
- What this log is about — a one-line description (e.g. "Intune Management Extension keeps app deployments and PowerShell scripts in sync with what your IT department configured.")
- A big status verdict — green checkmark, yellow warning, or red error icon, with the headline like "Looks good — no problems" or "3 problems found."
- Last activity / Last successful step / Last problem — the three most useful timestamps, in MM-DD-YYYY HH:MM AM/PM format.
- Issues you should know about — a plain-English list of the most recent errors and warnings. Each one is translated from the raw log line.
The Full details tab (every log entry)
Click Full details to see every log entry the app parsed. This view has its own controls:
- Search — type any text and the list narrows to matching lines.
- Severity chips — toggle Error, Warning, Info, Success, Other on or off. By default all are visible.
- Time, component, message — every row shows when, who reported it, and what they said.
- Color coding — red for errors, yellow for warnings, green for success, gray for everything else.
The app translates technical jargon into plain English wherever it can. For example, in the Windows Update log, lines like ERROR: 0x80240024 are automatically downgraded to "No updates were available at the time of this check." — because that hex code literally means "no updates needed."
How to tell if a log is actually broken
| Status | What it means | What to do |
|---|---|---|
| Looks good | No errors or warnings in the active date range. | Nothing — move on. |
| Heads up | Warnings present, but nothing fully failed. | Read the Issues section. If they're all routine ("Windows handled this automatically"), move on. |
| Needs attention | One or more real errors. | Read the Issues. Try the matching Troubleshooter. |
| No recent activity | The log hasn't been written to in 30+ days. | Probably fine — just means the underlying service hasn't been busy. |
Troubleshooters
Microsoft's official fix-it tools — the same ones used by Microsoft Support — packaged as one-click cards. Pick the right one for your problem and the app runs it for you with live progress.
What's available
The app ships 42 troubleshooters across 12 categories. Use the buttons at the top of the Troubleshooters page to narrow the list to a single area — Microsoft 365 / Office, Outlook, Teams, OneDrive, Copilot, Edge, networking, Windows system tools (including audio, Bluetooth, and camera), or your work sign-in.
Tools for checking and repairing the connection between your PC and your work account. These are the same checks IT runs when something's wrong with your sign-in — now one-click buttons you can use yourself.
- Generate diagnostic report — bundles up everything IT needs to investigate a sign-in or device-enrollment problem into a single ZIP file. File Explorer opens with the file pre-selected so you can drag it into a helpdesk ticket.
- Show work account status — tells you whether your PC is properly signed in to your organization, whether single sign-on is working, and whether Windows Hello is set up correctly. Just shows information — doesn't change anything.
- Refresh work account registration — repairs the connection between your PC and your work account when single sign-on stops working or you can't get into a work app you should have access to. Windows will ask permission before it runs.
- Force policy refresh — tells your PC to immediately pull the latest settings from IT, instead of waiting for the usual hourly background check. Use this when IT just changed something and asked you to make sure it's applied. Windows will ask permission before it runs.
- Run System File Checker — scans every protected Windows system file and repairs any that are damaged. The first thing Microsoft Support asks you to run when Windows is acting strange.
- Repair Windows image — fixes deeper Windows corruption. Run this first if System File Checker says it couldn't fix everything, then run System File Checker again.
- Reset Windows Update — clears Windows Update's cache and restarts its services. Microsoft's official fix for stuck Windows updates.
- Reset Microsoft Store cache — clears the Microsoft Store's cache so stuck Store app updates can finish. No permission prompt needed.
- Install available app updates — the same button that's on the Overview page. Updates every app installed on your PC (except Office, Teams, and Edge, which update themselves). A window opens so you can watch the progress.
- Restart Print Spooler — restarts the Windows printing service and clears any stuck print jobs. Use this when a document is stuck in the print queue.
- Fix audio playback or recording problems — restarts the two Windows services that broker audio between apps and your speakers/headphones/microphone. Use this when you have no sound, your speakers don't appear in the volume mixer, or your microphone isn't picking up sound. (New in v1.0.6)
- Fix background download problems (BITS) — resets the service Windows Update and the Microsoft Store use to download files in the background. Use this when Windows Update keeps failing or Store apps won't install or update. (New in v1.0.6)
- Fix Bluetooth connection problems — restarts the Bluetooth services. Use this when a Bluetooth device won't pair, keeps disconnecting, or won't actually connect after pairing. Your existing pairings are preserved. (New in v1.0.6)
- Fix camera or webcam problems — restarts the Windows Camera service that brokers your webcam between apps. Use this when your camera isn't detected, shows a black preview, or apps complain it's already in use even after closing every app. (New in v1.0.6)
- Reset network stack — resets all of Windows' networking back to defaults. Use when you have “no internet” problems that don't go away after restarting. Windows will ask permission before it runs.
- Flush DNS cache — clears Windows' memory of which websites are at which addresses. A quick fix for “this site can't be reached” errors after your IT department changes something, or after you connect to a VPN.
- Test Microsoft 365 connectivity — tests whether your PC can reach the 10 main Microsoft 365 service endpoints (sign-in, Exchange, Teams, SharePoint, OneDrive, the Microsoft 365 portal, and content delivery). Use this when Office apps can't connect even though your internet otherwise works. Read-only; doesn't change any settings. (New in v1.0.7)
Native PowerShell-script equivalents of Microsoft's two Copilot web troubleshooters — useful when you have a Copilot license but Copilot isn't showing up or won't respond. Both are read-only.
- Fix missing Copilot icon in Microsoft 365 apps — checks the four most common reasons the Copilot button doesn't show up in Word, Outlook, Excel, PowerPoint, or Teams even when you have an active license: which Office build is installed, what update channel you're on (Copilot needs a recent build), whether your IT department has disabled Copilot through policy, and whether the Office “Connected experiences” privacy toggles in Trust Center are turned on. Read-only; produces a plain-English report. (New in v1.0.8)
- Test Copilot connectivity — tests whether your PC can reach the seven Copilot service endpoints (the Copilot app, Copilot for Work landing page, Office substrate that powers Copilot in Word / Outlook / etc., Microsoft Graph, sign-in, and the Bing services Copilot uses for web grounding). Use this when Copilot is visible but says “something went wrong” or hangs. (New in v1.0.8)
Most of these troubleshooters use Microsoft's Support and Recovery Assistant — the same tools Microsoft Support runs over the phone — packaged as one-click buttons. The four newer Classic Outlook troubleshooters (added in v1.0.5) are native PowerShell-script equivalents of Microsoft's web-based Get Help troubleshooters, so they run inside the app's standard one-click dialog instead of opening a browser.
- Fix Office sign-in or activation — for “Office keeps asking me to sign in.”
- Reset Office sign-in — clears stored sign-in state so you can sign in fresh.
- Shared computer Office sign-in — for kiosks, conference rooms, VDI.
- Remove Office completely — last-resort uninstall.
- Outlook & Office scan (deep diagnostic) — produces a configuration report for IT.
- Check Outlook calendar — finds stuck or corrupted appointments.
- Repair Teams meeting add-in for Outlook — brings back the missing Teams button in Classic Outlook.
- Reset Classic Outlook offline data — renames the OST so Outlook rebuilds its offline cache from scratch.
- Set up a classic Outlook email profile — opens the Windows Mail control panel so you can add or repair a Microsoft 365 email profile. Use this when Outlook keeps asking you to pick a profile, can't find your email account, or you're setting up your mailbox for the first time. (New in v1.0.5)
- Fix classic Outlook startup problems — closes Outlook and relaunches it with Microsoft's
/resetnavpaneswitch, which rebuilds the navigation pane and resolves the most common “Outlook won't start” / “Loading profile” hang cases. Your mail and settings are preserved. (New in v1.0.5) - Fix classic Outlook password prompts — clears Office credentials cached by Windows Credential Manager and resets the cached Office identity so Outlook is forced to sign in fresh on next launch. Use this when Outlook keeps prompting for your password or shows “Need password” in the status bar. (New in v1.0.5)
- Fix classic Outlook connection problems — tests reachability to the Microsoft 365 mail servers, flushes Windows' DNS cache, and clears Outlook's cached server-discovery data. Use this when Outlook shows “Disconnected” / “Trying to connect” or mail isn't syncing even though other apps have internet. (New in v1.0.5)
- Fix Excel crashes, hangs, or startup problems — closes Excel and relaunches it in Safe Mode (with add-ins disabled) so you can tell whether an add-in is the cause. Your spreadsheets and settings are unaffected. (New in v1.0.7)
- Get help installing Microsoft 365 — scans the registry for existing Microsoft 365 / Office installations and reports what's installed (version, channel, bitness), then opens office.com in your browser so you can sign in and download the installer. (New in v1.0.7)
- Generate a Microsoft 365 / Office inventory report — lists every Microsoft 365 and Office product on this PC along with version, update channel, and bitness. Read-only; useful when IT asks “what version of Office are you on?” for a helpdesk ticket. (New in v1.0.7)
- Reset new Outlook for Windows — clears the local copy of your mailbox and starts over. After it runs, new Outlook will ask you to sign in again and re-download your email from the server.
- Start new Outlook in Safe mode — turns off add-ins so you can read email while you figure out what's broken.
- Start new Outlook in Recovery mode — for when new Outlook crashes during startup. Lets the app stay open long enough to apply pending updates.
- Clear new Teams cache — for stuck notifications, missing chats, or "something went wrong" errors.
- Reset new Teams (full) — last-resort full reset that clears every setting and signs you out.
- Reset OneDrive sync — for stuck sync, missing files, or "OneDrive isn't responding" errors. Your local files are not deleted.
- Sign OneDrive out and clear cached credentials — useful after a password change or work account migration.
What happens when you click Run
- A dialog opens with the troubleshooter's full description, what changes (if any) it'll make, and a yellow "Makes changes" or red "Admin needed" badge if appropriate.
- Click Start. The dialog shows a live transcript of what the tool is doing in plain English — for example, "Running checks on your PC — this can take a few minutes."
- If the tool asks a yes/no question, you'll see big Yes / No buttons.
- When it finishes you'll see one of: Healthy, Fixed, Found things to follow up on, Failed, or Canceled.
- Click Cancel at any time to terminate the troubleshooter and everything it spawned.
PC Information
A whole-PC dashboard — 22 at-a-glance cards covering everything Windows knows about this machine, plus four safe one-click actions. Built for the moment when IT asks “what does your PC look like right now?”
Why use this page
Whenever you're on the phone or chat with IT, the first thing they need is a snapshot of your PC. Edition, build, BitLocker state, TPM, Wi-Fi signal, public IP, disk health, recent reboot — that sort of thing. Hunting for all that across Settings, Device Manager, Network Connections, and PowerShell can take ten minutes. PC Information shows it all on one page in about a second and gives you a one-click way to copy any of it for IT.
How it's organized
22 cards, grouped into six sections, in this order:
- Windows version — edition (Pro / Enterprise / Home), build number, feature update (25H2 etc), and the date your Windows install was first set up.
- Activation — whether this PC's copy of Windows is fully activated, and the licensing product name.
- Uptime — how long since you last fully restarted. The card turns amber after 7 days as a gentle nudge that a reboot is overdue.
- Pending reboot — whether Windows is sitting on a half-installed update waiting for you to restart.
- BitLocker — whether your system drive (C:) is encrypted, plus the algorithm in use (XTS-AES 256 etc).
- Secure Boot — whether your PC's firmware blocks untrusted boot software.
- TPM — the version of the security chip your PC uses for BitLocker keys and Windows 11 attestation. Reads via TPM Base Services so it works for everyone, not just admins.
- Windows Defender — whether Microsoft's built-in antivirus is on, real-time protection is enabled, signatures are current, and how recent the last scan was. If you have a third-party AV that disables Defender, the card says “Managed by another product.”
- Firewall — whether all three Windows Firewall profiles (Domain, Private, Public) are active.
- Processor — the CPU model, core count, and thread count.
- Memory (RAM) — how much you have and how much is currently in use. The card turns amber when usage hits 90%.
- Graphics — primary GPU name, VRAM, and driver version.
- Battery — current charge and whether you're plugged in. Skipped on desktops without a battery.
- Disk health — the system drive's SMART self-report (the same data Windows uses to warn you about a failing drive).
- Public IP — the IPv4 address the internet sees from your connection. Useful when IT needs to confirm where you're connecting from.
- Wi-Fi — the SSID you're connected to and signal strength. Turns amber when the signal drops below 40%.
- Network adapters — how many physical adapters are connected, with the fastest one's name + speed.
- DNS cache — one of the safe action cards. Click Flush to clear Windows' local DNS cache when websites stop loading correctly.
- Temporary files — another safe action card. Shows how much disk space is taken by your
%TEMP%folder; click Clear to delete its contents. Only your per-user temp folder is touched — the system one (which needs admin) is left alone. - Recycle Bin — how much space is held by deleted-but-not-purged files. Click Empty to permanently remove them.
- Drive space — total free space across every fixed drive attached to the PC. Turns amber when free space drops under 10%.
- Power mode — the same picker Windows shows in Settings › System › Power & battery. Switch between Best Power Efficiency, Balanced (Recommended), and Best Performance. Changes apply instantly — no restart, no admin prompt.
Status pills — how this PC is doing in one glance
A small row of colored pills sits at the top of the page once probes finish. Each pill shows how many cards landed in that state:
- Green “OK” — the card is healthy and there's nothing to act on.
- Amber “need attention” — the card has a warning or error worth looking into.
- Gray “informational” — the check ran but didn't find anything that maps to OK or attention (e.g. a desktop without a battery).
- Gray “still checking” — a probe is still running. Usually gone within a second of opening the page.
If everything's healthy you just see a single green pill (“22 OK”) — clean signal that the PC is in good shape.
Filter chips — jump to what matters
A row of chips below the status pills lets you narrow the view:
- All — default; every card grouped by section.
- Needs attention — only the cards in Warning or Error. The chip itself shows the count, e.g. “Needs attention (2)” when there are two problems. If everything's OK you see a friendly “Everything looks good — no issues detected.” placeholder.
- System / Security / Hardware / Network / Storage / Power — drill into one area at a time.
The four safe actions
Most cards are read-only. Four cards include a small action button you can click without any admin prompt:
- Flush on the DNS cache card — clears Windows' DNS lookup cache. Use this when websites stop resolving or when IT just changed DNS records and you want to see them immediately.
- Clear on the Temporary files card — deletes everything in your
%TEMP%folder. After it finishes, the card shows how much was cleared (e.g. “1.2 GB cleared”). - Empty on the Recycle Bin card — permanently removes everything in your user's Recycle Bin.
- Power mode picker — switch between the three Windows 11 Power Modes. Same effect as the dropdown in Settings › System › Power & battery.
Each action gives a brief on-card confirmation (“Cache cleared”, “Switched”, etc.). Errors show in red.
Open in Windows Settings — one click to the matching OS page
Each card whose subject has a corresponding Windows 11 Settings page carries a Settings button in its lower-left corner — a small gear icon with the word “Settings” next to it. Click it and the Windows Settings app opens directly on that exact page — no navigating the Settings tree yourself. For example:
- Activation → System → Activation
- Windows version, Processor, Memory → System → About
- BitLocker → Privacy & security → Device encryption
- Windows Defender, Firewall, Secure Boot, TPM → the Windows Security app
- Wi-Fi → Network & Internet → Wi-Fi
- Network adapters, Public IP, DNS cache → Network & Internet (Status / Advanced)
- Battery, Power mode → System → Power & battery
- Drive space → System → Storage → Disks & volumes (the Storage page itself now elevates — Microsoft change in January 2026 — so this routes to Disks & volumes instead, which stays standard-user friendly)
- Graphics → System → Display → Advanced display
- Pending reboot → Windows Update
Cards whose subject doesn't have a standard-user-friendly Settings page (Uptime, Disk health, Recycle Bin, Temporary files) hide the button entirely so it never opens somewhere unhelpful or triggers a UAC prompt you can't pass. Hover any button for a tooltip describing what page it'll open.
Copy buttons — share with IT in one click
Every card has a small copy icon in its top-right corner. Click it to put a paste-ready text block on your clipboard:
My365 Device — Windows version
Status: OK
Checked: 2026-05-21 17:55:23
Windows 11 Pro
Build 26100.4040 · 25H2 · Installed Jan 5, 2026
Paste that straight into a helpdesk ticket, an email, or a chat with IT — no screenshots needed.
There's also a Copy all button next to Refresh all in the page header. One click puts a sectioned snapshot of every card on the clipboard:
My365 Device — PC Information snapshot
Captured: 2026-05-21 17:55:23
== SYSTEM ==
Windows version (OK): Windows 11 Pro
Build 26100.4040 · 25H2 · Installed Jan 5, 2026
Activation (OK): Activated
Windows Operating System
…
Use this when IT says “send me a snapshot of your PC.”
Refreshing
All 22 cards run when you first open the page. To re-run everything (e.g. after you've changed a setting elsewhere) click Refresh all in the page header — the button spins while work is in progress and the cards flip back to “Checking…” until each probe finishes.
ipconfig.exe, which Windows lets standard users run; switching Power mode uses the per-user overlay API. If your IT team has locked any of these down via Group Policy the cards still try gracefully and surface a friendly “hidden from this account” message rather than failing.
api.ipify.org for your IPv4) — everything else is registry / WMI / Win32 API. If the public-IP lookup fails because you're offline, the card just says “No internet” and moves on.
User Guides
146 plain-English how-to topics covering everyday Windows 11 + Microsoft 365 tasks — bundled with the app and pulled from the Netlogic My365 user guide.
What's in there
The bundled guide covers the topics IT typically gets called about, organized into chapters:
- Getting Started — signing in, the Start menu, the taskbar, accessing your files.
- Email & Calendar — Outlook (new + classic), shared mailboxes, calendar sharing, signatures.
- Files — OneDrive, SharePoint sites, file shares, File Explorer.
- Microsoft 365 Apps — Word, Excel, PowerPoint, Teams.
- Microsoft Edge browser — sign-in, sync, profiles, AI features.
- Copilot — using the Copilot app on Windows.
- Security — Windows Hello, MFA, sensitivity labels, Defender basics.
- Managing your PC — Settings, updates, disk usage, printers.
- Productivity tips — keyboard shortcuts, search, snap layouts.
- Contact IT — getting help, escalating issues.
How to use the page
- Click User Guides on the navigation rail.
- Use the filter chips at the top to narrow by chapter, or use the search box to find a specific topic.
- Click any topic card to open the full article in your default browser, deep-linked straight to the right section of the published page.
Managed by IT
Every app, security setting, PowerShell script, and enrollment record your IT department has pushed to this PC through Intune — explained in plain English on one searchable page.
What the page is for
If you've ever wondered “why did this app appear on my PC?” or “is BitLocker actually on, and did IT turn it on or did I?”, this is the page that answers it. Every item your IT department has deployed through Microsoft Intune leaves a trace on this device — in the registry, in IME logs, in CSP-managed settings. The Managed by IT page reads those traces and shows them as readable cards with a status pill so you can tell at a glance what's working, what's pending, and what needs attention.
Nothing on this page is changed by the app. It's read-only, runs locally with no network calls, and doesn't need admin rights.
The four at-a-glance tiles
The row of tiles under the hero card gives you the headline numbers:
- Apps deployed. The number of apps your IT department has installed on this PC and that are still installed today — Microsoft Store apps, Office, and any other tools IT pushed out. Uninstalled apps and older versions don't count.
- Settings applied. The number of settings your IT department has configured on this PC — things like Windows Defender protection, BitLocker disk encryption, password requirements, Windows Update schedules, and many more.
- Scripts run. Automation scripts your IT department has set up to run on this PC.
- Items needing IT attention. Anything that didn't apply correctly — an app that didn't finish installing, a script that hit an error, a setting that couldn't be applied. This number should usually be 0. When it isn't, those items are flagged with a red Failed tag in the list below so IT knows where to look.
Health overview chart
Right below the tile row is a visual at-a-glance health card you can read in a second to know whether Intune is working correctly on this PC:
- Compliance donut on the left, with the percentage of currently-applied items in the center. A full green ring at 100% healthy means every Intune item on this device applied successfully. Any amber or red on the ring is a visible signal that something's pending or has failed.
- Plain-English headline next to the donut summarises the current state in one sentence:
- All clear — every Intune item on this device applied successfully. (everything green)
- 3 items are still applying. IT will retry on the next sync. (amber pending)
- 2 items need IT's attention — the rest are healthy. (red failures)
- Waiting for IT to evaluate this device — sync hasn't finished yet. (brand-new device)
- Per-category stacked bars — one bar each for Apps, Settings, and Scripts — let you see at a glance which category has any issues. Each bar is proportionally divided into green (Active), amber (Pending), and red (Needs IT) segments based on the actual status of every item in that category. Counts appear on the right edge of each bar (e.g. “21 active · 2 pending”).
- Legend beneath the bars explains the color coding so the chart is self-documenting.
The chart is hidden on a brand-new PC that hasn't yet received any settings from IT — the count tiles all show 0, and the chart skips straight to the filter buttons so you don't see a misleading “0% healthy” reading. The percentage focuses on the everyday IT settings, apps, and scripts that actually matter for whether the PC is working as IT intends.
The filter chips
Right below the tiles is the primary chip row. Click one to focus the list on just that bucket:
- All. Everything Intune has deployed, grouped by category.
- Apps. Just the deployed apps — Microsoft Store, Win32, Office Click-to-Run, MSI. (See below for what each label means.)
- Settings & policies. MDM policies your IT department has pushed. Selecting this chip reveals a second row of chips (see screenshot below) that lets you narrow further by topic.
- PowerShell scripts. Automation scripts your IT department has set up to run on this PC, with the result of the most recent run.
- Enrollment. The single enrollment record — tenant, account, MDM provider, server URL.
Apps view: every Intune-deployed type, not just MSI
The Apps filter surfaces four kinds of Intune-deployed apps:
- Microsoft Store apps. Apps your IT department installed from the Microsoft Store — Microsoft 365 Copilot, Microsoft To Do, Loop, Forms, Outlook for Windows, Windows Terminal, PowerShell 7, and similar.
- Custom-installed apps. Apps IT installed using their own installers — Canva, Remote Help, Windows Autopatch Client Broker, and others your IT team chose.
- Office (Microsoft 365 apps). Microsoft 365 Apps for enterprise (Word, Excel, Outlook, PowerPoint), plus extras like Project and Visio when your IT department installs them. Each Office app gets its own card showing the version and update schedule IT set for your PC.
- Other IT-installed apps. Specialized business apps your IT team has installed — vendor tools, agents, and similar.
If the same app shows up more than once, the app combines them so you see one card per app with its best-known status.
Settings & policies view: filter by topic
A typical Intune-managed device has between 60 and 100 MDM policy areas active and hundreds of individual settings inside them. The Managed by IT page handles the volume in three ways:
- Plain-English names and descriptions. Each policy card translates the CSP setting (e.g.
AllowRealtimeMonitoring= 1) into language a non-technical user can read (“Real-time virus protection is turned on as IT requires”). - Topic chips. The 14 topic buckets group related policies under one heading so you don't have to know that Defender lives under Application Management or that BitLocker is under Cryptography. Click Security & antivirus for Defender + SmartScreen + Windows Security app; click Drive encryption for BitLocker; click Sign-in & password for DeviceLock + credentials + local-users-and-groups. The Other chip catches anything that doesn't fit a topic so nothing is ever hidden by the chips alone.
- The Show advanced settings toggle. ADMX-imported policies (Brave, Firefox, Chrome, Adobe Acrobat, OneDrive, Google Update, Office, and Windows-internal ADMX overlays) are real policies your IT department deployed, but their names are admin-facing and the volume is high. They're hidden by default; flip the toggle to include them.
Anatomy of an item card
Every card on the page follows the same shape so you can scan the list quickly:
- Title — the friendly name of the app, policy, script, or enrollment record.
- Subtitle — a one-line plain-English description: what this thing is and what it does.
- Status pill — a colored pill on the right edge of the card with one word:
- Active / Applied (green) — the item is in place and working.
- Pending (amber) — assigned, but not yet finished applying. Common right after a sync.
- Failed (red) — IT's most recent attempt didn't succeed. Worth screenshotting if you call IT.
- Unknown (gray) — the device hasn't evaluated this item yet.
- Status line — a sentence under the description that says what the current value is in plain English (“Installed and working as expected”, “Currently set to: On (allowed)”, “Installed (version 16.0.19929.20090) and updating automatically”).
- Technical details — an expander at the bottom of every card. Click it for the raw OMA URI, the registry path, the app GUID, the raw policy value, or the script's last error code. This is the line to share with IT if you call the helpdesk — it's the breadcrumb they'll need to look the item up in the Intune admin center.
Search
The search box above the list runs across the whole inventory — titles, descriptions, status lines, and technical details. Useful queries:
- BitLocker — jumps to the encryption policy card.
- Defender — surfaces every Microsoft Defender setting your IT department has configured.
- Outlook — finds the Outlook for Windows app card.
- WSUS or Update — pulls every Windows Update policy and the Autopatch broker app together on one screen.
How it works under the hood
The page assembles its view from four read-only sources, all local to the device:
- EnterpriseDesktopAppManagement (EDAM) registry. Catches MSI / Win32-wrapped-as-MSI deployments.
MsiQueryProductStateis called for each EDAM entry so older MajorUpgraded versions are filtered out and only currently-installed MSIs show up. - Intune Management Extension log. The
AppWorkload.logfile (plus the most recent rotated copies) is parsed for Microsoft Store and Win32 deployments that IME tracks but doesn't expose through registry paths a standard user can read. - Office Click-to-Run configuration. The
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configurationregistry tree is read to surface Microsoft 365 Apps, Project, Visio, etc., with their update channel decoded into a friendly name. - PolicyManager. The MDM CSP registry under
HKLM\SOFTWARE\Microsoft\PolicyManager\current\deviceis walked for every active policy. ADMX-imported policies are detected and tucked behind the Show advanced settings toggle.
Nothing here requires network access, admin rights, or write permission. If a source is empty or ACL-blocked on a given device, the page silently falls back to the other sources and tells you (in the diagnostic log) which stage came up empty.
Tips & tricks
Things you don't have to know — but that make the app a lot more useful when you do.
Filter chips remember themselves
The chip you pick on the Logs, Troubleshooters, or User Guides page sticks for the duration of that session. Switch tabs, come back, and you're still looking at the same filtered view.
Ctrl+F doesn't work — but the search box does
Each page that has a search box does the search natively. There's no global Ctrl+F shortcut because each page's search behaves differently (Logs searches by file name or entry text depending on tab, User Guides searches topic titles).
The "Today" filter often hides what you want
If you're investigating something that happened "yesterday afternoon", switch the date filter at the top of the window from Today to Last 7 days. The home page counts and the log lists update instantly.
Long log files are tail-loaded
If a log file is bigger than 25 MB the app reads only the most recent 25 MB and parses that. That's almost always plenty — you see the last few weeks of activity without having to wait for a 100 MB Defender log to fully load.
The diagnostic log can help IT
The app writes its own internal breadcrumb log to %LOCALAPPDATA%\My365LogReader\diag.log. If you ever escalate a problem to IT, this file (max 512 KB, rolls automatically) is the fastest way for them to see what the app was trying to do when something went wrong.
Restart can be canceled
Click Restart PC, confirm — and you've still got 5 seconds to click Cancel restart on the message that pops up. Useful when you forgot to save something.
Privacy & security
The app is designed to keep everything local. Here's exactly what stays on your device, what goes out, and why.
What stays on your device
- Every log file the app reads.
- Every parsed entry, every plain-English translation, every summary.
- Every troubleshooter run's transcript and exit code.
- The internal diagnostic log (
%LOCALAPPDATA%\My365LogReader\diag.log). - Your theme preference (
%LOCALAPPDATA%\My365LogReader\settings.json).
What goes out — and why
| Action | Where it goes | Why |
|---|---|---|
| Sync with Intune | Microsoft Intune service | Pulls policies and apps your IT department configured for you. |
| Check for Windows updates | Microsoft Windows Update | Asks Microsoft what patches your PC needs. |
| User Guide button click | pages.netlogicmy365.com | Opens the published guide page in your browser. |
| Troubleshooter run | Varies — Microsoft's SaRA tool talks to Microsoft for some scenarios | The troubleshooter is doing its diagnostic / fix work. |
| "Sync via Settings" fallback | Local Windows Settings app | Just opens Settings — no data sent. |
What never goes out
- Your log file contents — not even error messages or summaries.
- Your machine name, user name, hardware specs (the app reads them only to display them locally).
- Telemetry. The app doesn't have any.
When to call IT anyway
This app handles a lot — but not everything. Here's when you should stop, take a screenshot, and open a ticket.
Things this app can't do
- Reset your password. Use Settings → Accounts, or contact your IT helpdesk.
- Re-enroll your PC in Intune from scratch. The Sync button checks in; it doesn't enroll.
- Restore deleted files. OneDrive's recycle bin is the right place for that.
- Decrypt BitLocker. Recovery keys are stored by your IT department, not on this PC.
- Repair hardware faults. A failing disk, dying battery, or flaky Wi-Fi card needs IT.
Symptoms that justify a ticket immediately
- The app reports real errors in multiple logs and the matching troubleshooter doesn't fix them.
- SFC reports it found corruption it couldn't fix, even after running DISM RestoreHealth first.
- The Windows Update log shows the same install failed for KB#### error every day for a week.
- OneDrive sync errors persist after a Reset OneDrive sync.
- You can't sign into Office anywhere, even after Reset Office sign-in.
What to send IT
- The name of the log with the problem (e.g. "IntuneManagementExtension.log").
- The text of the headline on its Summary tab.
- A screenshot of the Issues you should know about list.
- The contents of
%LOCALAPPDATA%\My365LogReader\diag.logif the app itself misbehaved.
Frequently asked questions
Quick answers to the things people ask most.
The Windows Update log talks about itself in a confusing way — a lot of normal everyday events show up using words like “failed” or “error” that sound scary but don't actually mean anything is wrong (for example, “failed to find an update” just means there were no updates available). The app knows about these quirks and only flags lines as real errors when something has actually gone wrong. Genuine problems still show up clearly so you don't miss them.
No. The app is read-only on its own — every change-making action (sync, troubleshooter, restart) requires you to click a button.
Yes for everything except the actions that obviously need the network: Sync with Intune, Check for Windows updates, the Microsoft SaRA-based troubleshooters, and clicking through to a User Guide topic. Reading logs and the local-fix troubleshooters (OneDrive reset, Teams cache clear, etc.) all work offline.
The app is deployed by your IT department through Intune. New versions arrive automatically when IT publishes them — usually after a Sync with Intune. Check the About page for the version you're currently running.
The app reads logs from their existing locations — it doesn't copy them anywhere. The only files the app writes are:
%LOCALAPPDATA%\My365LogReader\settings.json— your theme preference.%LOCALAPPDATA%\My365LogReader\diag.log— the app's own breadcrumb log.%LOCALAPPDATA%\My365LogReader\cache\WindowsUpdate.log— converted Windows Update activity (regenerated when source files change).%LOCALAPPDATA%\My365LogReader\troubleshooters\— per-run output from troubleshooters that support a log folder.
Some repair tools change protected parts of Windows itself — system files, services, or settings that affect every user on the PC. Windows always asks permission before letting any program change those, no matter who's running it. The app tells you up front when a tool needs permission, and Windows shows its usual permission prompt when you click Start. If you click No, the tool cancels safely without changing anything.
Your IT helpdesk — the same one you'd call if the app didn't exist. The User Guides page has a Contact IT chapter with the right phone numbers and email addresses for your organization.
Still stuck?
The User Guides page has a Contact IT section with the contact info for your organization's helpdesk. Take a screenshot of whatever the app is showing you, and they'll know exactly where to start.
What's new
Release notes for every version of My365 Device (originally shipped as “My365 Log Reader” through v1.0.0.31). Newest at the top.
Updates are deployed automatically through Intune. To see which version you're running, open the app and go to About on the navigation rail.
Production
The current production line — deploy this on production fleets. 1.0.1 through 1.0.15 are kept under Beta below for historical reference; 1.0.0.x are Alpha builds further down.
- Settings button redesigned and moved to the lower-left corner of every card. The small open-in-new-window icon that 1.0.20 added next to the copy icon is now a clear gear-icon button labelled “Settings” sitting in the lower-left of each card — much easier to spot at a glance, and the gear glyph reads instantly as “this opens Windows Settings.”
- Fixed: Storage cards no longer trigger a UAC prompt. Microsoft added an admin requirement to the System → Storage page itself in the January 2026 cumulative update (KB5074105). The Drive space card now opens System → Storage → Disks & volumes instead, which still opens for standard users without elevation. The Temporary files card no longer has a Settings deep-link — the in-app Clear button is the supported path for that one.
- Per-card “Open in Windows Settings” deep-links on the PC Information page. Every card whose subject has a corresponding Windows 11 Settings page now carries a deep-link button. Tap it and Settings opens directly on that exact page: Activation goes to System → Activation, Wi-Fi goes to Network & Internet → Wi-Fi, Power mode goes to System → Power & battery, BitLocker goes to Privacy & Security → Device encryption, and so on — no more navigating Settings yourself after reading a card.
- Canonical ms-settings: URIs. The deep-links use Microsoft's documented
ms-settings:URI scheme verified against Windows 11 24H2+. The button stays hidden on the few cards whose subject has no Settings page (Uptime, Disk health, Recycle Bin). Hover any button for a tooltip describing what page it will open.
- Update apps is now one experience. Clicking Install available app updates on the Troubleshooters page opens the same native Update apps dialog as the home page tile — per-app checkboxes, source grouping, live per-app progress bars, and clear per-row outcomes (Done, Already current, Needs admin, Close app & retry, Failed with a View log link). Previously the Troubleshooters card ran a legacy script path with an elevated console window. Both entry points now share the in-app dialog.
- Standard-user friendly from the Troubleshooters page too. The card's “Admin needed” badge is gone — the new dialog runs without a UAC prompt up front. Apps that genuinely need elevation are flagged inline in the result column so the affected packages are obvious without blocking everything else.
- Home page “What would you like to do?” row refined. The primary action tiles (User Guides and Troubleshooters) are now arranged in a balanced two-up layout that scales cleanly across window sizes — tighter on narrow windows, generous on wide ones, with the cards always reading at equal height regardless of how much description text either one has.
- Log viewer toolbar simplified. The Summary tab's top-right toolbar is now a single Copy results for IT button — the action IT actually asks for — removing a secondary button that was rarely used and cluttering the layout above the log text.
- About page hero copy tightened. A small editorial pass to the About page's headline and tagline so it better reflects what the app does today.
- Installer footprint reduced. An unused experimental code path and the assets that went with it have been removed, shrinking each architecture's MSI by a few megabytes and trimming a handful of files out of the install directory.
Beta (1.0.1 – 1.0.15)
Pre-production builds during the native-WinGet and PC-Information feature push. Each card below describes what landed in that release. These versions are listed for historical reference — production fleets should be on the latest release above, and the MSI will upgrade in place automatically.
- Available-update count badge on the home page. A quiet background
winget list --upgrade-availableruns on every launch and surfaces the count as a small red pill on the “Update apps” quick action — same pattern Microsoft Store uses for its Library badge. Caps at “99+”. Refreshes automatically after every Update apps run, so it disappears once you've installed everything. - Per-app checkboxes + “Update selected (N)”. Every row in the Update apps dialog now has a checkbox (defaults checked). Untick anything you'd rather skip and the primary button live-updates from “Update all (12)” to “Update selected (8)”.
- Live per-app progress bars during install. Each row shows a thin progress bar that climbs 0 % → 100 % as WinGet downloads + installs, parsed live from
winget's own stdout via a character-by-character stream reader that handles WinGet's\r-based progress redraws. Falls back to an indeterminate spinning ring for installers that don't emit percentages. - Source grouping in the available-updates list. Updates are sectioned by where they come from — “From WinGet community catalog”, “From Microsoft Store”, “Unknown source” — so you can see at a glance which apps update through which catalog. Each section header carries an app count.
- Click a row → publisher / homepage / description flyout. Tapping any package row (outside the checkbox) opens a small TeachingTip with publisher, description, homepage, and license fetched live from
winget show --id <Id> --exact --source <src>. - “View log” hyperlink on failure rows. Every upgrade attempt writes its full WinGet log to
%LOCALAPPDATA%\My365LogReader\winget-logs\<id>-<timestamp>.logand a click-through link opens it in Notepad. Surfaces on Failed, Needs admin, and Close-app rows. - New “Close app & retry” outcome. Detects installer failures where the target app was open (Office, Edge, Zoom, etc.) by recognising patterns like “process is running”, “file is in use”, MSI exit code 1618, and
0x80073D02, then shows “Close [App] and try again” instead of a generic Failed status. - Surfaces packages with unknown installed versions via
--include-unknown. Apps installed outside any WinGet source previously didn't appear at all; now they show with a small amber “Version unknown” badge. - “Check again” button on the Done panel. When some apps failed or needed admin, Check again re-runs the list without closing the dialog — much faster than close + reopen.
- Clearer cancellation copy. Clicking Cancel mid-run shows “Finishing <App> — then stopping” so you know the cancel landed and what's happening before it takes effect (in-flight installers are allowed to finish to avoid corrupting state).
- New “Include pinned packages in app updates” toggle in Settings. Off by default. Power users who use
winget pinto delay specific upgrades can flip it on to bring pinned packages back into the available-updates list.
winget.exeis now invoked directly instead of viapwsh.exe. Saves ~200 ms of startup per package and gives a clean stdout stream that the new character-by-character parser can split on both\r(progress redraws) and\n— pwsh's buffering broke that.- Per-upgrade diagnostic logging. Every upgrade attempt now logs
exit=0xXXXXXXXX; stdout=[...]; stderr=[...]viaDiagnosticLog.Debug(capped to 400 chars per stream) so future failures have evidence on disk.
- Update apps no longer reports false successes. 1.0.13's Update apps dialog occasionally marked an app as “Done” when WinGet had actually returned “No applicable upgrade found” with exit code 0 — meaning nothing was installed. 1.0.14 reads the WinGet output text in addition to the exit code, so we only report Done when an install really applied.
- New “Already current” status. For apps WinGet decides aren't actually upgradable at install time (manifest skew between detection and install, or the app got auto-updated by something else in between). Shows with a blue (i) info icon instead of a green checkmark, and the dialog summary breaks Already-current items out separately from real Failures so you don't get a scary “3 of 8 failed” when really 5 succeeded and 3 were already current.
- Real install failures are now classified correctly. The previous build mapped some no-op WinGet exit codes (
0x8A150014,0x8A15002B) to “Failed” with a red icon — those now correctly read as Already current. --sourcepass-through. The Source column fromwinget list --upgrade-availableis now forwarded as--source <src>to eachwinget upgrade --idcall. Without this, packages that live in multiple catalogs (e.g. both winget and msstore) could install from the wrong source and silently no-op.- Per-package diagnostics. Every upgrade attempt now logs its exit code + a snippet of stdout/stderr to the app's diagnostic log, so when something does fail there's enough evidence to tell IT exactly what happened.
- Brand-new in-app “Update apps” experience. The Update apps tile on the home page now opens a clean native dialog that runs
winget list --upgrade-availablevia PowerShell 7, lists every installed app that has a newer version (current → available), and lets you click Update all to install them one at a time with an overall progress bar + per-app status. No more command-prompt windows or installer pop-ups; everything stays inside My365 Device. Built so standard users (non-admins) can run it — apps that need admin to install are flagged as “Needs admin” rather than silently failing. - New “Windows Settings” item in the navigation rail, sitting right below the renamed PC Information page. Clicking it from any page launches the full Windows OS Settings app via the
ms-settings:URI — same shortcut Windows Start › Settings gives you, but always one click away regardless of which My365 Device page you're on. - PC Settings renamed to “PC Information” to better describe what it is — a read-mostly dashboard of your PC's state across system, security, hardware, network, storage, and power. A prominent Open Windows Settings banner sits at the top of the page so users always know where to go for the OS-level toggles the dashboard doesn't expose.
- New “Popular Guides” card on the home page with quick-link buttons for the four most-used Windows 11 / Microsoft 365 topics: Microsoft 365 Apps, Microsoft 365 Copilot, Sensitivity Labels, and Microsoft Edge. Each opens that section of the live Netlogic My365 Windows 11 guide in your default browser.
- Home page layout cleaned up. The Popular Guides + Managed by IT cards now sit in a 2-column row at equal height. The Managed by IT card shows a friendly “Reading IT-managed items…” loading state with a spinner while it queries WMI / registry / MDM, instead of leaving the slot blank for the first few seconds. The “Get help from IT” card moved up directly below this row so the helpdesk contact info is visible without scrolling through the Quick Fixes row.
- Action result banner colors on the PC Information cards now reflect success vs. error — red text on Failed actions instead of always green.
- The “Run a troubleshooter” home-page card no longer extends taller than the User Guides card next to it. Both are now equal height regardless of how much description text either card has.
- CPU card properly collapses multi-space CPU names — “Intel(R) Core(TM) i7-13700H” → “Intel(R) Core(TM) i7-13700H”. The previous one-pass replace left doubles whenever the original had 3+ spaces in a row.
- Windows 11 PCs whose registry still says “Windows 10 Enterprise” (a known Microsoft quirk that affects every Windows 11 PC — the
ProductNameregistry value was never updated when Win 11 launched) now display correctly as Windows 11 on the PC Information card. Detection is by build number ≥ 22000.
- User Guides page is back to loading all 146 Windows 11 + Microsoft 365 topics. 1.0.11 shipped with the wrong file bundled at
Assets\Guide\UserGuide.html— the in-app User Guides page parses that file to populate its topic list, and the wrong file had no matching content, so the page rendered empty. 1.0.12 restores the correct bundled guide (the published Windows 11 / M365 user-education content atpages.netlogicmy365.com/Windows-11-Get-Started.html, 146 topics across 15 chapters). - Clicking a topic on the User Guides page still opens the live online version in your default browser, deep-linked to the right chapter + accordion via the page's
#page=<section>&accordion=<id>hash route.
- New “PC Settings” page in the nav rail. A whole-PC dashboard sitting between Troubleshooters and User Guides. 22 at-a-glance cards across six sections (System, Security, Hardware, Network, Storage, Power) covering everything Windows knows about this machine: edition + build + install date, activation, uptime, pending-reboot state, BitLocker, Secure Boot, TPM, Windows Defender, Windows Firewall, processor, memory, graphics, battery, disk SMART status, public IP, Wi-Fi signal, network adapters, drive space, and Power mode. See the new PC Settings section in this guide for the full breakdown.
- Four safe one-click action buttons on the cards that benefit most from them:
- Flush on the DNS cache card — clears Windows' local DNS resolver.
- Clear on the Temporary files card — deletes the contents of
%TEMP%and reports how much was freed (e.g. “1.2 GB cleared”). - Empty on the Recycle Bin card — permanently removes everything in your user's bin.
- Power mode picker — the same Best Power Efficiency / Balanced / Best Performance dropdown Windows Settings shows. Applied instantly, no restart, no UAC prompt.
- Status summary pills at the top of the page — colored pills tally how many cards landed in each state (OK / needs attention / informational / still checking). Zero-count pills auto-hide, so a fully healthy PC just shows a single green “22 OK” pill.
- Filter chips — All / Needs attention / per-section (System, Security, Hardware, Network, Storage, Power). The “Needs attention” chip live-updates with the count (“Needs attention (3)”) so you know whether there's anything to act on before clicking. A friendly empty-state appears if the filter has zero matches.
- Per-card “Copy this card” icon button in the top-right of every card. One click puts a paste-ready text block on the clipboard for sharing with IT during triage — title, status, timestamp, primary value, and subtitle. Icon flips to a green checkmark for ~1.4 s as confirmation, then reverts.
- “Copy all” button in the page header — one click puts a full sectioned snapshot of every card on the clipboard. Perfect for “send me a snapshot of your PC's state” helpdesk requests.
- Standard-user safe by design. Every probe and action on the page works under a normal user token — no UAC prompts, no admin required. TPM details come from TPM Base Services (not the admin-only Win32_Tpm WMI namespace); DNS flush uses
ipconfig.exe; Power mode switches use the per-user overlay API. If your IT team has locked any of these down via Group Policy, the cards still try gracefully and surface a friendly “hidden from this account” message rather than failing. - Sub-second performance. All 22 cards run in parallel via native .NET (WMI, registry, P/Invoke, NetworkInterface, HttpClient) — nothing spawns PowerShell, so the page fills in well under a second on a warm cache. The only external process spawn is
netsh wlan show interfacesfor the Wi-Fi card; everything else is in-process.
- “Copy results for IT” button on every troubleshooter result panel. Top-right corner of the “What's been happening” card. One click copies a paste-ready text block to the clipboard so users can drop it straight into a helpdesk ticket without screenshotting or hand-transcribing log lines.
- Format of the copied block:
- Header line:
My365 Device — <Troubleshooter Name> Status:<current run status> — succeeded healthy, succeeded with issues, failed, etc.Run at:<local-time timestamp> inyyyy-MM-dd HH:mm:ssform- Blank line
- The raw output the troubleshooter wrote to stdout, line by line. If the raw output is empty (rare — a script bailed before printing anything), the friendly transcript is used as a fallback so the paste isn't blank.
- Header line:
- Visual feedback: clicking flips the Copy icon to a green checkmark and changes the button label to “Copied — paste into your ticket” for ~1.4 seconds, then reverts. A second rapid click cancels the in-flight revert timer so the button doesn't get stuck mid-animation between a fast pair of clicks.
- Available on every troubleshooter — native PowerShell scripts (the four Outlook, four Windows, four Microsoft 365, two Copilot, plus the existing OneDrive / New Outlook / New Teams scripts) and the original SaRA-backed scenarios all get the same Copy button on their result card.
- Troubleshooter results are no longer cut off at the bottom. Long-output troubleshooters (the Microsoft 365 inventory scan was the most visible case — it can easily produce 30+ lines of output) were having their tail clipped because the run dialog's transcript card used a plain
StackPanelwith no scroller, and the dialog'sContentDialogMaxHeightcapped the whole thing at 760 pixels. v1.0.9 makes three changes:- The transcript card now sits in a
RowDefinition Height="*"row instead ofAuto, so the card grows to fill any extra vertical space the dialog has available. - The transcript
ItemsControlis wrapped in aScrollViewerwith a usableMinHeight, so when even the taller dialog isn't enough the user can scroll inside the bordered card. ContentDialogMaxHeightraised to 1200 pixels — the dialog now uses more of the window vertically before forcing the user to scroll inside the card.
- The transcript card now sits in a
- Troubleshooter descriptions now show real punctuation instead of HTML entities. A handful of troubleshooters added in v1.0.5–v1.0.8 had descriptions written with HTML markup (
—,“,”,→,<strong>,<em>) under the assumption that the run dialog rendered HTML. It doesn't —TextBlockrenders the source as plain text, so the literal—string was showing up in the UI. v1.0.9 replaces all 25 occurrences with proper Unicode punctuation (em dash, smart quotes, ellipsis, right arrow) and strips the<strong>/<em>tags that the dialog couldn't render anyway.
- New Microsoft Copilot category on the Troubleshooters page. The Copilot troubleshooters support page lists two web Get-Help-app troubleshooters — both are now native PowerShell-script equivalents in the app, sitting under a new Copilot filter chip alongside Microsoft 365, Outlook, Teams, OneDrive, and Edge. The category uses the official Copilot for Work brand icon. The two new troubleshooters:
- Fix missing Copilot icon in Microsoft 365 apps — mirrors Microsoft's Copilot-LicensingTroubleshooter. Inspects four classes of state that block Copilot from rendering in Word, Outlook, Excel, PowerPoint, and Teams even when the user has an assigned license:
- Office Click-to-Run build + update channel (decoded from the
CDNBaseUrlGUID underHKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration) — Semi-Annual Enterprise channels are flagged as a likely cause when present, because Copilot features land later on those channels. ProductReleaseIdsfrom the same config — reports whether a Copilot ProductReleaseId is stamped into the install (informational; most Copilot licenses activate via the user's sign-in and don't appear here).- Policy gate at
HKLM\SOFTWARE\Policies\Microsoft\Office\16.0\common\copilot+ the HKCU equivalent — the documented Office ADMX path IT uses to disable Copilot. The script reports whencopilotenable = 0is set anywhere. - Office Connected Experiences toggles under
HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Privacy— specificallycontrollerconnectedservicesenabled,usercontentdisabled,downloadcontentdisabled. Copilot requires all three to permit cloud-backed analysis of the user's content; the script flags any of them in a blocking state and gives the exact Office UI path to fix them.
- Office Click-to-Run build + update channel (decoded from the
- Test Copilot connectivity — mirrors Microsoft's TroubleshootCopilotConnectivity. Runs
Test-NetConnectionagainst seven Copilot service endpoints on TCP 443:copilot.microsoft.com(standalone Copilot app),copilot.cloud.microsoft(Copilot for Work landing page),substrate.office.com(the Office substrate Copilot reads through in Word/Outlook/Excel/PowerPoint),graph.microsoft.com(tenant data access),login.microsoftonline.com(sign-in / Entra),www.bing.com(web grounding), andcopilot.bing.com(Copilot web search backend). Reports each endpoint as reachable / unreachable, with plain-English next steps for the common failure causes (no internet, VPN required, firewall block, DNS issue, proxy / SSL inspection). Exit code mirrors result so the run dialog's status pill reflects success / failure correctly.
- Fix missing Copilot icon in Microsoft 365 apps — mirrors Microsoft's Copilot-LicensingTroubleshooter. Inspects four classes of state that block Copilot from rendering in Word, Outlook, Excel, PowerPoint, and Teams even when the user has an assigned license:
- Excel crash check troubleshooter now uses the proper Excel app icon. Up to 1.0.7 the Excel troubleshooter shared the generic Office icon with the other Office activation / repair tools. v1.0.8 ships a dedicated
Source-Excel.pngin the app's Assets folder and the Excel troubleshooter card now displays it. Visual only; no behavioural change. - Total troubleshooter count is now 42 (up from 40). The home-page card, the Welcome quick-reference, and the Troubleshooters page intro all reflect the new count and the new category total (12, up from 11).
- Four new native Microsoft 365 troubleshooters. Microsoft's Microsoft 365 troubleshooters support page lists eight Get-Help-app launchers. Four of them (Uninstall, Activation, Sign-in, Shared Computer Activation) overlap with existing app coverage and didn't need to be added — the corresponding SaRA scenarios are already exposed as native one-click tools. v1.0.7 adds native PowerShell-script equivalents for the remaining four (Excel crash check, M365 setup helper, inventory scan, network connectivity test) so they run inside the app's standard one-click Run dialog instead of opening Get Help.
- Fix Excel crashes, hangs, or startup problems — closes any running EXCEL.EXE, then relaunches it with the
/safeswitch documented by Microsoft for ruling out add-ins. Safe Mode loads Excel without COM or VSTO add-ins; if Excel works in that mode the user knows an add-in is at fault and can disable them one at a time via File → Options → Add-ins. Spreadsheets and settings are unaffected. Mirrors Microsoft's ExcelCrash web troubleshooter. - Get help installing Microsoft 365 — reads
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configurationand reports the existing Office install (products, version, channel, bitness, SCA state), then opens office.com so the user can sign in and run the official installer. Includes pre-flight troubleshooting tips for the common “install keeps failing” reasons (no active subscription, broken previous install, third-party antivirus interference). Mirrors Microsoft's OfficeSetup web troubleshooter. - Generate a Microsoft 365 / Office inventory report — walks Click-to-Run config + every Office app's
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\<EXE>entry + Appx-registered new Outlook / new Teams + the OneDrive client registry, and prints a plain-English inventory: per-product version + channel + bitness + SCA, plus a per-app list with installed file versions. Read-only; designed to be copy-pasted into a helpdesk ticket. Mirrors Microsoft's RoiscanFull web troubleshooter. - Test Microsoft 365 connectivity — runs
Test-NetConnectionagainst ten Microsoft 365 service endpoints on TCP 443 (portal.office.com, officeapps.live.com, login.microsoftonline.com, login.microsoft.com, outlook.office365.com, autodiscover.outlook.com, res.cdn.office.net, teams.microsoft.com, teams.events.data.microsoft.com, graph.microsoft.com). Reports each endpoint as reachable / unreachable so the user can spot a missing VPN, firewall block, or DNS issue. Suggests follow-up troubleshooters (Flush DNS) and points the user at Microsoft 365 service health when everything passes locally. Mirrors Microsoft's NetworkConnectivity web troubleshooter.
- Fix Excel crashes, hangs, or startup problems — closes any running EXCEL.EXE, then relaunches it with the
- Where each one lives on the Troubleshooters page: Excel check, M365 setup, and inventory scan all sit under the Office filter chip alongside the existing Office activation / repair tools; the M365 network connectivity test sits under the Network filter chip alongside Reset network stack and Flush DNS cache. No new categories were added.
- Total troubleshooter count is now 40 (up from 36). Home-page card, Welcome quick-reference, and Troubleshooters page intro all reflect the new count.
- Four new native Windows troubleshooters. Microsoft's Windows troubleshooters support page lists ten classic system troubleshooters — six of which (Windows Update, Network, Printer, Program Compatibility, Video Playback, Windows Media Player) overlap with existing app coverage or are wizard-only flows that can't be scripted. v1.0.6 ships native PowerShell-script equivalents for the remaining four (Audio, BITS, Bluetooth, Camera). Each one performs the same canonical service-restart / cache-clear sequence Microsoft's troubleshooter would run, but inside the app's standard one-click Run dialog instead of opening Get Help. The underlying mechanics:
- Fix audio playback or recording problems — stops
AudiosrvandAudioEndpointBuilderin dependency order, then restarts them in reverse so the endpoint enumerator is ready before the broker comes back. Clears stuck device state without unplugging hardware. Mirrors Microsoft's AudioTroubleshooter. - Fix background download problems (BITS) — stops the
BITSservice, renames the persistent queue files (qmgr.db,qmgr0.dat,qmgr1.dat) under%ProgramData%\Microsoft\Network\Downloaderso the service rebuilds them clean, then starts BITS again. Microsoft's canonical fix for stuck Windows Update and Microsoft Store downloads. Mirrors Microsoft's BITSTroubleshooter. - Fix Bluetooth connection problems — gates on the presence of
bthserv(Bluetooth Support Service) before doing anything, then bounces bothbthservandBTAGService(Bluetooth Audio Gateway, which handles paired headphones / speakers). The per-sessionBluetoothUserService_XXXis left alone because it's demand-start. Existing device pairings are preserved. Mirrors Microsoft's BluetoothTroubleshooter. - Fix camera or webcam problems — stops the optional
FrameServerMonitorfirst (when present on the Windows build) so it can't auto-restart Frame Server mid-reset, then bouncesFrameServeritself. The Camera Frame Server is the broker between apps and the webcam driver; stuck Frame Server state is the #1 cause of “camera in use by another app” or “camera not detected” symptoms even when the hardware is fine. Mirrors Microsoft's TroubleshootCamera.
- Fix audio playback or recording problems — stops
- All four are categorized under “Windows system tools” on the Troubleshooters page so they appear alongside SFC, DISM, Reset Windows Update, etc. when you click that filter chip. Each one is marked admin-required because stopping / starting Windows services needs elevation, so the dialog shows the “Admin needed” badge up front.
- Total troubleshooter count is now 36 (up from 32). The home-page card under “Run a troubleshooter”, the Welcome page's quick-reference card, and the Troubleshooters page intro all reflect the new count and the broadened scope.
- Four new native Classic Outlook troubleshooters. Microsoft publishes a set of Classic Outlook troubleshooters on the Classic Outlook troubleshooters support page that historically required the Get Help app or a browser to run —
GetHelpCmd.exedoesn't expose these four scenarios as command-line invocations. v1.0.5 ships native PowerShell-script equivalents that perform the same canonical remediations Microsoft's web-based troubleshooters do, so they integrate with the existing one-click Run dialog like every other troubleshooter in the app. - What each one does, and the Microsoft remediation it mirrors:
- Set up a classic Outlook email profile — opens the Windows Mail control panel applet (
control.exe /name Microsoft.Mail) where the user can add or repair an Outlook profile through the canonical Windows UI. Mirrors Microsoft's OutlookSetupProfile web troubleshooter. - Fix classic Outlook startup problems — closes any running classic Outlook, then relaunches it with the documented
/resetnavpaneswitch which rebuilds the navigation pane and resolves the most common “Outlook won't start” / “Loading profile” hang. Mail and settings are preserved. Mirrors Microsoft's olkstart web troubleshooter; the dialog also surfaces follow-up steps (Safe Mode,/resetfolders,/cleanviews) when the primary fix doesn't help. - Fix classic Outlook password prompts — closes Outlook, walks the Windows Credential Manager via
cmdkey /listand removes every cached credential whose target matches Office / Outlook / Microsoft 365 patterns (MicrosoftOffice*,Microsoft_OC1*,msteams_adalsso*,MicrosoftAccount*,*office365*,*outlook.office*), then clears the cached Office identity keys underHKCU\Software\Microsoft\Office\16.0\Common\Identity(and 15.0 for legacy installs). Outlook is forced to authenticate fresh on next launch. Mirrors Microsoft's OutlookPwdPrompt web troubleshooter. - Fix classic Outlook connection problems — tests TCP-port-443 reachability to the three Microsoft 365 mail endpoints (
outlook.office365.com,outlook.office.com,autodiscover.outlook.com) viaTest-NetConnection, flushes the Windows DNS cache withipconfig /flushdns, and clears Outlook's cached Autodiscover data underHKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover(and 15.0). When any endpoint test fails the script reports it plainly so the user can spot a missing VPN or firewall block. Mirrors Microsoft's OutlookDisconnect web troubleshooter.
- Set up a classic Outlook email profile — opens the Windows Mail control panel applet (
- All four are categorized under “Outlook (Classic)” on the Troubleshooters page so they appear alongside the existing Outlook scenarios when you click that filter chip. Each one is marked Classic Outlook only so the dialog warns up front if your PC only has new Outlook for Windows installed.
- Total troubleshooter count is now 32 (up from 28). The home-page card under “Run a troubleshooter”, the Welcome page's quick-reference card, and the Troubleshooters page intro all reflect the new count.
- Cloud PCs now detect correctly — without re-introducing the 1.0.2 false positive on physical PCs. v1.0.3 fixed the false positive by checking only
Win32_ComputerSystem.Modelfor the literal string “Cloud PC”, but it turned out actual Windows 365 Cloud PCs (running as Azure Hyper-V VMs) reportModel = "Virtual Machine"like any other Hyper-V guest. No real Cloud PCs matched the v1.0.3 check, so the home-page Sign-in & access and Drive encryption cards reverted to showing “Hello off” / “Unencrypted” on Cloud PCs even though both readings are misleading in that environment. - New two-factor detection. v1.0.4 requires both conditions before classifying a PC as a Cloud PC:
- Factor 1 (firmware): PC must be a Hyper-V VM. Verified through
Win32_ComputerSystem.Manufacturer = "Microsoft Corporation"+Model = "Virtual Machine", orWin32_BIOSreporting Hyper-V. Physical Dell / HP / Lenovo / Apple PCs fail this factor and stay classified as physical regardless of what other signals are present on disk. - Factor 2 (product signal): any of three Cloud-PC-specific markers. Hostname starts with
CPC-(Microsoft's auto-generated Cloud PC naming convention — e.g.CPC-DSwen-5LV5A), orHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CloudDesktopexists, or the firmwareModelcontains “Cloud PC”.
- Factor 1 (firmware): PC must be a Hyper-V VM. Verified through
- AVD detection tightened the same way. The Remote Desktop Infrastructure Agent registry key is now gated by the same Hyper-V VM check, so a physical PC with leftover RD-agent bits can't be classified as an Azure Virtual Desktop session host either.
- Physical PCs are no longer misidentified as Cloud PCs. The 1.0.2 Cloud-PC detection used the
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CloudDesktopregistry key as one of its signals — but Microsoft's Cloud PC client app creates that same key on physical PCs that connect to a Cloud PC. The home-page Sign-in & access and Drive encryption cards were displaying their cloud-aware variants (“Cloud sign-in” / “Cloud-encrypted”) on regular Dell / HP / Lenovo PCs whose users had ever used Windows 365 from that PC. - New detection contract. v1.0.3 rebases Cloud PC detection on
Win32_ComputerSystem.Model— specifically the “Cloud PC” prefix Microsoft stamps into the virtual firmware of every Windows 365 instance (“Cloud PC Enterprise”, “Cloud PC Frontline”, etc.). The model string is written by the hypervisor and can't appear on physical hardware whose model field is set by Dell / HP / Lenovo / Apple firmware. Azure Virtual Desktop detection was similarly tightened: the RD Infrastructure Agent registry key is now gated by an additional Hyper-V VM check, so a physical PC with leftover AVD bits can't be classified as AVD either. - Result. Physical PCs go back to the standard BitLocker / Windows Hello reading they had before 1.0.2. Actual Cloud PCs and AVD session hosts still get the cloud-aware behavior introduced in 1.0.2.
- Home-page status cards are now Cloud PC-aware. On Windows 365 Cloud PCs and Azure Virtual Desktop, two of the four status cards previously showed misleading information because Windows Hello and BitLocker work differently in a remote / cloud-hosted environment than on a physical PC. The cards now detect when you're on a Cloud PC or virtual desktop and adjust their reading accordingly.
- Windows Hello card. On a Cloud PC, you actually sign in from your physical device (laptop, phone, browser), not via Hello running inside the Cloud PC. The card no longer reports “Hello off” on a Cloud PC; instead it shows a green Cloud sign-in pill and explains that authentication is handled by your host device.
- Drive encryption card. Windows 365 Cloud PC disks are encrypted automatically by Microsoft's cloud at the host layer using platform-managed keys — BitLocker inside the Cloud PC guest is typically off because the protection already happens one layer down. The card no longer reports “Unencrypted” on a Cloud PC; instead it shows a green Cloud-encrypted pill and explains that the disk is protected by the cloud infrastructure.
- Detection scope. The new detection identifies Windows 365 Cloud PCs (via the
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CloudDesktopprovisioning marker), Azure Virtual Desktop session hosts (via theHKLM\SOFTWARE\Microsoft\RDInfraAgentagent), plus generic Hyper-V / VMware / VirtualBox / Parallels / QEMU virtual machines (viaWin32_ComputerSystemandWin32_BIOSidentifiers). On physical PCs nothing changes; the cards behave exactly as before.
- First version your IT department could roll out to everyone. Earlier 1.0.0.x builds were alpha releases (see Alpha section further down) used to shake out bugs in a small test group. v1.0.1 was the first version tested enough to deploy fleet-wide and started the Beta line. Everything you see in the app — the home-page health summary, the four status cards (Sign-in, Drive encryption, Network, OneDrive), the “Help from IT” button in the title bar, the device specs, the Managed by IT page — is the production set.
- If you're upgrading from an alpha version, you don't need to do anything. When IT pushes 1.0.1, the installer will quietly clean up any older versions and leave just one “My365 Device” entry on your PC. No manual uninstalls, no leftovers. Future updates (1.0.2, 1.0.3, etc.) will work the same way.
- Cleaner version display. Alpha versions looked like
1.0.0.43— an awkward 4-part number that confused both Windows and our installer. v1.0.1 onwards uses the familiar 3-part style (1.0.1, 1.0.2, …) you see on most apps. - One leftover name reference fixed. An old error message inside the app still mentioned the original name (“My365 Log Reader”). It only ever appeared if a specific file was missing — practically never — but it's now consistent with the new “My365 Device” name everywhere.
- End-to-end production checks passed. Before promoting to production we verified the app starts cleanly on every supported Windows 11 build, the home page renders without errors, BitLocker and Windows Hello status display correctly for everyday users (not just admins), and the installer properly upgrades older versions in place.
Alpha (1.0.0.x)
Early development cycle (originally shipped as “My365 Log Reader”) that stabilised into 1.0.1, the first Beta. Listed newest-first; click any entry to expand the detailed notes. These versions are no longer recommended for new deployments — install 1.0.22 (Production, above) and the MSI will upgrade in place automatically.
- MSI upgrades now actually replace prior installs instead of stacking up alongside them. Devices that had taken several Intune LOB uploads were accumulating multiple “My365 Device” entries in Add/Remove Programs (one per uploaded version). Root cause: Windows Installer's
ProductVersioncomparison truncates to the first three parts when deciding whether an upgrade is allowed — the fourth component (e.g. the33in1.0.0.33) is recorded for display purposes only and ignored for upgrade decisions. Our versioning scheme bumps only the revision (1.0.0.33, 1.0.0.34, 1.0.0.35…), so from MSI's perspective every release was the same version (1.0.0) andMajorUpgraderefused to fire by default. AddingAllowSameVersionUpgrades="yes"to the WiX<MajorUpgrade>element tells Installer to upgrade even when the truncated versions match. The first deploy of 1.0.0.43 over a device with several stacked 1.0.0.* installs will clean up every prior entry in one shot — no manual uninstall needed — and subsequent releases will upgrade in place. (Suppresses ICE61 build-time warning, which is the expected complement toAllowSameVersionUpgrades.) - “Help from IT” button no longer hides under the system caption buttons. The custom title bar we extend into didn't reserve any space for the OS-drawn min / max / close controls, so the rightmost element — the new global helpdesk button — was being overdrawn by Windows and partly unclickable. v1.0.0.43 adopts the canonical WinUI 3 padding-column pattern: the title bar grid now has empty
TitleBarLeftPaddingColumnandTitleBarRightPaddingColumncolumns whose widths are driven dynamically byAppWindowTitleBar.LeftInset/RightInset. The values come back in physical pixels from the windowing API; we divide by the current DPI scale to translate to DIPs for theGridLength.AppWindow.Changedis wired to re-run the calculation so DPI flips (laptop docking, dragging between mixed-DPI monitors) keep the padding correct without restarting the app.
- Home page now loads again. v1.0.0.41 added copy-to-clipboard buttons via a page-level
StylewhoseSetter Property="Content"embedded aFontIconelement. WinUI's style system materializes Setter values once and shares them across every styled instance — but a UIElement (theFontIcon) can only have one logical parent in the visual tree. The second button to apply the style threw “Element already has a logical parent,” the page failed to instantiate, and the Home rail item navigated to a blank frame. v1.0.0.42 keeps the shared Style for layout / color / padding but declares theFontIconinline on every copy button so each instance owns its own icon. The exception is gone and Home renders.
- Global “Help from IT” button in the title bar. A small button next to the window's caption controls now opens a dropdown with the helpdesk contact info no matter what page you're on. Click — or use any of the three rows (Call / Email / Support portal) — and Windows hands the link off to the appropriate default app (Phone Link for
tel:, your default mail client formailto:, your default browser forhttps:). The flyout is populated from the sameHKLM\SOFTWARE\Netlogic\My365LogReader\Supportregistry values the home-page card reads, so updating contact info via either workflow (MSI re-deploy or the companionSet-My365SupportInfo.ps1script) refreshes both surfaces simultaneously. Hidden entirely when noITSUPPORT_*values were configured at install time, so a vanilla install doesn't show a non-functional control. - Why a title-bar button rather than a footer nav item. Footer nav items take a click and a navigation transition before showing the user anything; a dropdown flyout opens in a single click with no page-load latency, leaves the user on whatever page they were already on, and dismisses with a click outside. Title-bar placement also stays out of the page's content area on every surface, so it doesn't compete for layout space with anything per-page.
- Copy-to-clipboard buttons next to the properties IT asks for most. Each row in About this PC (device name, Windows edition, OS build, processor, memory, battery), plus the supporting facts on the Sign-in & access card (signed-in account), the Network & VPN card (IPv4 address), and the OneDrive backup card (account email), now carries a small copy icon. One click puts the bare value on the clipboard — not the “Signed in as …” / “IPv4 address: …” prefix wrapping it — so it pastes cleanly into a helpdesk ticket. The icon flips to a green checkmark for ~1.2 seconds after a successful copy so the action's registered without a noisy toast. Buttons hide automatically when the underlying value is empty (no battery row on desktops; no IPv4 button when offline; no UPN button on non-joined PCs) instead of putting an empty string on the clipboard.
- “What would you like to do?” moved to the top of the home page. The primary navigation cards (User Guides and Run a troubleshooter) used to live at the bottom of the page after the health card, status row, About this PC, IT helpdesk, Quick fixes, and Recent activity. By the time users scrolled to them they'd already moved past the primary entry points into the app. v1.0.0.41 moves the section directly under the Quick actions row so the navigation anchors are visible the moment Home renders.
- Microsoft Edge troubleshooters now have their own filter chip. The Clear Microsoft Edge cache troubleshooter previously sat under the generic “Windows” filter alongside SFC / DISM / Windows Update reset. v1.0.0.41 adds a new
Edgefilter chip on the Troubleshooters page and reclassifies the existing Edge cache troubleshooter under it. Easier to find when you're hunting an Edge-specific fix; future Edge troubleshooters (reset Edge, repair Edge install) will join the same chip.
- Battery row now updates immediately when you plug / unplug the charger. Previously the row in About this PC was loaded once on home-page navigation and never refreshed — users who unplugged the laptop kept seeing the “charging” label until they navigated away and came back. v1.0.0.41 subscribes to three
Windows.System.Power.PowerManagerevents (PowerSupplyStatusChanged,BatteryStatusChanged,RemainingChargePercentChanged) and refreshes the battery row in real time as power state changes. Subscriptions are cleaned up on navigation-away so the page tree can be garbage-collected. - Date filter only appears on the Logs page. The title-bar date-range filter (Today / Last 7 days / Last 30 days / Custom…) only ever affected the Logs viewer — on every other surface it was a knob that did nothing. v1.0.0.41 hides the control everywhere except
LogViewerPageby subscribing toContentFrame.Navigatedand toggling visibility based on the active page type. The filter still persists across navigations, so returning to Logs picks up the user's last-chosen range immediately.
- Drive encryption card now reads BitLocker status for Standard users — for real this time. v1.0.0.39's fix layered WMI impersonation + a
manage-bde -statussubprocess fallback, but on real-world Intune-managed devices both sources still require admin: the BitLocker WMI namespace's security descriptor denies non-admin callers even underImpersonationLevel.Impersonate(UAC's filtered token doesn't carry the Administrators SID), andmanage-bde.exe -status <drive>for OS volumes returns “An attempt to access a required resource was denied” for any non-elevated caller. The card kept showing gray “Unknown”. v1.0.0.40 switches the primary source to the Shell property store — specificallyPKEY_Volume_BitLockerProtection(canonical nameSystem.Volume.BitLockerProtection, FMTID{2d15a9a1-a556-4189-91ad-027458f11a07}PID 1717). That property is the same data File Explorer reads to draw the lock badge on encrypted drives; it's exposed through the Explorer namespace handler rather than directly through the BitLocker WMI ACL, so it works in user context with no spawn, no service, no admin rights. - Three-tier read pipeline keeps WMI's richer detail when available. WMI is still tried first (it gives us the precise encryption method — XTS-AES 256, AES 128, etc. — which the Shell property doesn't expose); on Standard-user logins the WMI call returns empty silently and the service falls through to the Shell property store for the protection status.
manage-bde -statusstays as a third-tier last-resort fallback (skipped on access-denied) for edge hardware. When only the Shell path succeeded, the card reads simply “Encrypted” instead of “Encrypted (XTS-AES 256)” — honest about what we know. - How the Shell property maps to the card's pill. The Shell property returns codes 1–8 with the following meanings; the service normalizes them onto the legacy
Win32_EncryptableVolume.ProtectionStatusenum the rest of the app uses (1 = encrypted,0 = not encrypted,2 = suspended):- 1 (On) → encrypted (green pill).
- 2 (Off) → not encrypted (red pill).
- 3 (Encrypting in progress) → encrypted (encryption underway; safe to call “encrypted”).
- 4 (Decrypting in progress) → not encrypted (decryption underway).
- 5 (Suspended) → suspended (amber pill).
- 6 (Locked) → encrypted (drive is sealed; recovery key needed to unlock).
- 7 (Encryption paused) / 8 (Decryption paused) → matching encrypted / not-encrypted state.
- Windows Hello status now reads correctly. The v1.0.0.38 Sign-in & access card detected Hello enrollment by reading raw registry hives (
HKLM\SOFTWARE\Microsoft\Windows\NGC\KeyCredentialManager+ biometric provider GUIDs). On modern Windows 11 builds those keys exist even when Hello isn't enrolled, so users who signed in with their fingerprint or face every day still saw “Hello off” in amber. v1.0.0.39 replaces the registry probes with the canonical WinRT APIs —KeyCredentialManager.IsSupportedAsync()andUserConsentVerifier.CheckAvailabilityAsync(), the same calls Settings → Accounts → Sign-in options uses internally — and resolves the biometric subtype (Face / Fingerprint) by enumeratingWin32_PnPEntityBiometric-class devices. The pill is now green “All set” and the supporting line reads e.g. “Windows Hello: PIN + Fingerprint” when biometrics are enrolled. - Drive encryption card now reads BitLocker state for Standard users. The v1.0.0.38 card called
Win32_EncryptableVolumeWMI with default impersonation, which the BitLocker namespace's ACL silently rejects for non-admin callers — the call returned zero rows and the card showed gray “Unknown” even on devices where the OS drive was demonstrably encrypted. v1.0.0.39 explicitly impersonates the caller's token viaImpersonationLevel.Impersonateon the WMIConnectionOptions, which lets a Standard user read the protection status of any volume they have read access to. When WMI still returns nothing (Home SKU, locked-down baseline) the service falls back to shellingmanage-bde.exe -status <drive>and parsing the output for Protection Status / Conversion Status / Encryption Method —manage-bderuns in user context for read-only queries. - Drive card now shows only the primary OS drive (C:). Previously the card iterated every fixed drive, mixing the OS drive with secondary data partitions, USB-attached SSDs, and BitLocker-eligible virtual disks. When users ask “is my computer encrypted?” they mean the OS drive specifically, so the home-page card now focuses on C: exclusively — one supporting line, one headline state. Secondary drives still appear in the diagnostics bundle for IT.
- Detail line wording sharpened. The drive card's summary now reads “Your C: drive is encrypted with BitLocker and has plenty of free space.” when green, “Your C: drive isn't encrypted by BitLocker.” when red, and “Your C: drive is encrypted but is running low on free space.” when amber. The previous phrasing referenced “all drives” even on devices with a single drive.
- Four new at-a-glance status cards on the home page, in a 2x2 grid under the Managed-by-IT health card. Each card has a colored pill (Green / Amber / Red / Gray) plus a one-line summary plus 2-3 supporting facts:
- Sign-in & access — whether the device is joined to Microsoft Entra / a domain, which tenant, the signed-in account UPN, Windows Hello enrollment state, and when the last successful work sign-in happened. Reads
dsregcmd /status+ LogonUI hello-providers registry. - Drive encryption — per-fixed-drive BitLocker protection state (Encrypted with method / Unprotected / Suspended) and the free / total / used-percent for each. When the WMI call requires elevation the card honestly reports “status unknown” with a gray pill rather than misleadingly claiming “Unencrypted”.
- Network & VPN — current connection type + name (Wi-Fi SSID, Ethernet adapter, cellular), IPv4 address, VPN connected / not (heuristically detected by adapter type and vendor name — covers Cisco AnyConnect, GlobalProtect, FortiClient, OpenVPN, WireGuard, Always-On VPN), and a quick ICMP reachability check to a public anycast endpoint to confirm internet works end-to-end.
- OneDrive backup — whether the work / school account is signed in, the account email, whether Documents / Desktop / Pictures are redirected to OneDrive via Known Folder Move, and when the OneDrive client last had sync activity.
- Sign-in & access — whether the device is joined to Microsoft Entra / a domain, which tenant, the signed-in account UPN, Windows Hello enrollment state, and when the last successful work sign-in happened. Reads
- Battery health row on the About this PC card. Laptops now show a sixth row with current charge percent, charging / on-battery state, and the OEM-reported battery health percentage (full-charge capacity ÷ design capacity, clamped at 100%). Desktops with no battery hide the row entirely.
- “Quick fixes” card with six action buttons. Tile-style shortcuts for: Reset Outlook (renames the .ost), Re-sign in to OneDrive, Clear Edge cache (preserves favorites/sign-in/passwords), Reset network stack, Reset Microsoft Store, and a Get diagnostics for IT button that bundles logs + inventory into a timestamped ZIP on the Desktop with Explorer pre-selected on the file for drag-into-ticket.
- Two new troubleshooters backing the Quick Fixes: Reset Classic Outlook offline data (closes Outlook, renames the .ost file with a timestamped
.oldsuffix, restarts Outlook so it rebuilds the offline cache fresh from Exchange) and Clear Microsoft Edge cache (closes Edge, removes Cache / Code Cache / GPUCache / ShaderCache across every Edge profile on the PC, preserves favorites / passwords / sign-in). - Recent activity strip below the Quick Fixes card. The last ~20 events from the past 30 days — Intune syncs, Defender scans, Windows Update installs, OneDrive sync cycles, IME app check-ins — each with a human time tag (“3h ago”, “Yesterday”, “May 10”) and a one-line description. Hides when there's nothing to show so brand-new devices don't have an empty card.
- Red attention badge on the “Managed by IT” nav rail item when the inventory contains anything in a Failed state. The badge value is the count; goes away the moment those items resolve.
- “What's new in this version” modal on first launch after an upgrade. Shows the headline changes for the current version in a small dialog after the home page renders. Tracked via
%LOCALAPPDATA%\My365LogReader\whatsnew.jsonso the modal pops exactly once per version; on a fresh install (no state file yet) the dialog stays hidden so first-launch users don't get told what changed from v0. Content is bundled with the app rather than fetched online so it works on devices with no internet.
- Pushing new
ITSUPPORT_*values via Intune now actually updates the app's contact info. The v1.0.0.36 LOB MSI accepted the four command-line arguments at install time and wrote them toHKLM\SOFTWARE\Netlogic\My365LogReader\Support— but Windows Installer is idempotent at the same version. If v1.0.0.36 was already installed on a device (even with placeholder test values), Windows refused to re-install at v1.0.0.36 again, the new command-line args never reached msiexec, and the registry kept the old values. v1.0.0.37 ships as a version bump so theMajorUpgradechain fires cleanly over the previous install and the updated args land. - New companion script for version-independent contact-info updates:
Installer\scripts\Set-My365SupportInfo.ps1. Edit the four hard-coded values at the top of the script for your tenant and deploy it as an Intune Platform Script (Devices → Configuration → Scripts → Add → Windows 10 and later), set to run as SYSTEM. The script writes the same four registry values directly toHKLM\SOFTWARE\Netlogic\My365LogReader\Support, so IT can push new contact info to the fleet anytime without bumping the MSI version + re-uploading the LOB app. The app reads from the same registry path on every launch, so changes appear automatically on next start. - Two workflows now supported for support-info updates, documented in
Installer/README.mdunder Updating support info AFTER an MSI is already deployed:- A — MSI version bump. Bump the version, rebuild, re-upload to Intune with new
ITSUPPORT_*args.MajorUpgradehandles the rest. Standard MSI flow, always works. - B — Companion PowerShell script. Edit + deploy
Set-My365SupportInfo.ps1via Intune Platform Scripts. Decouples contact-info updates from app releases — useful when you just need to update a phone number or email address without an MSI re-deployment cycle.
- A — MSI version bump. Bump the version, rebuild, re-upload to Intune with new
- Why the v1.0.0.36 deployment looked like a no-op: when an admin re-uploads the same-version MSI with different command-line arguments, Intune triggers a re-install attempt, msiexec sees a product with the same
UpgradeCodeat the sameProductVersionalready installed, and returns error 1638 (“Another version of this product is already installed”) without running the install. From the admin's perspective the deployment “succeeded” but the new args were silently dropped on the floor. v1.0.0.37 makes the upgrade succeed; the script in option B above prevents future repeats.
- “Get help from IT” card on the home page (and About page). IT admins can now customize the app per-tenant by passing four optional public MSI properties on the Intune LOB app's Command-line arguments field when uploading the MSI:
ITSUPPORT_NAME— helpdesk team or contact name, e.g. “Contoso IT Help Desk”.ITSUPPORT_PHONE— phone number in any format (hyphens, parens, and a leading+are all preserved for display; the click handler strips formatting and hands a cleantel:URI to the dialer).ITSUPPORT_EMAIL— helpdesk email (renders as amailto:link).ITSUPPORT_URL— support portal or knowledge-base URL (renders as anhttps://link; bare hostnames auto-prepend the scheme).
- The card appears on both surfaces so users can find the helpdesk info from either entry point:
- Home page — immediately below the Managed-by-IT health card and the About this PC specs card. Three large click-targets (Call / Email / Support portal) for users who need help right now.
- About page — a compact Your IT helpdesk section with the same three channels as hyperlinks. Convenient for users who land on About to copy their version number into a ticket and need contact info on the same screen.
- How it works under the hood. The four MSI public properties are flagged
Secure="yes"so they propagate from the user-context UI sequence into the per-machine elevated execute sequence. The newItSupportRegistrycomponent writes the values intoHKLM\SOFTWARE\Netlogic\My365LogReader\Supportas four REG_SZ values (Name,Phone,Email,Url) plus a constantConfigured=1key-path marker so the component never gets torn down on repair. The app reads them synchronously at startup viaItSupportService.Load(). The MSI re-writes the values on every upgrade, so changing the Intune command-line arguments and re-deploying pushes new helpdesk info to the whole fleet — no separate config push needed. - Example Intune configuration:
ITSUPPORT_NAME="Contoso IT Help Desk" ITSUPPORT_PHONE="+1 555 0100" ITSUPPORT_EMAIL="help@contoso.com" ITSUPPORT_URL="https://help.contoso.com" - Full deployment workflow + example PowerShell test commands are documented in
Installer/README.mdunder IT helpdesk contact info (per-tenant customization).
- Edge browser policies (and dozens more) now show up on Managed by IT. v1.0.0.33 added discovery of GPO/ADMX policies under
HKLM\SOFTWARE\Policies\, but most ADMX-imported policies actually land inHKCU\SOFTWARE\Policies\when IT scopes them to a user-context profile. On a typical Intune-managed device that's where Edge's BrowserSignin, SyncDisabled, PasswordManagerEnabled, SmartScreenEnabled, EfficiencyMode, HomepageLocation, RestoreOnStartup, and 40+ other policies live. Same story for Chrome, Firefox, half of Office. v1.0.0.35's discovery walks BOTH hives so nothing in either tree is missed. - First-class promotion for known vendor paths. v1.0.0.33 hid any policy not in its curated catalog behind the “Show advanced settings” toggle — which meant Edge's URL blocklists, extension forcelists, and the long tail of less-common-but-still-meaningful settings stayed invisible by default. v1.0.0.35 keeps generic catalog-miss policies visible when they're under a top-tier vendor path (Edge, Chrome, Firefox, Brave, OneDrive, Office, BitLocker, Microsoft Defender, Windows core security). Only truly obscure third-party app sub-settings stay behind the toggle.
- Smarter naming for list-style entries. Policies that take a list of values (URL allowlists, extension forcelists, restore-on-startup URLs) are stored in the registry as numerically-named subvalues —
...\URLBlocklist\1,...\URLBlocklist\2, etc. The previous fallback would surface these as “Edge: 1” / “Edge: 2” (technically correct, completely useless). Now they read as “Edge: URL Blocklist (entry 1)” with the actual URL formatted as “Points tocontoso.sharepoint.com”. - 24+ curated friendly translations for common Edge policies, including sign-in & sync (BrowserSignin, SyncDisabled, ImplicitSignInEnabled, AADWebSiteSSOUsingThisProfileEnabled, ForceSync), security (SmartScreenEnabled, SmartScreenPuaEnabled, PasswordManagerEnabled, PasswordMonitorAllowed), browser UX & performance (EfficiencyMode, StartupBoostEnabled, SleepingTabsEnabled, BackgroundModeEnabled, EdgeCollectionsEnabled, WebCaptureEnabled, ShowHomeButton, ShowDownloadsToolbarButton, ShowRecommendationsEnabled, HideFirstRunExperience, PromptForDownloadLocation), network & updates (QuicAllowed, ComponentUpdatesEnabled, AutoImportAtFirstRun), and recommended-tier settings the user can override (HomepageLocation, RestoreOnStartup).
- Curated translations for Office Click-to-Run policies: enableautomaticupdates, hideenabledisableupdates, officemgmtcom.
- Curated translations for deeper Defender + Defender for Endpoint policies: cloud-block level, cloud check timeout, email scanning, threat-capture window, password-reuse / unsafe-app notifications, Web Threat Defense service.
- Curated translations for WinRM client + server policies: basic-auth and unencrypted-traffic toggles on both sides.
- Real-world impact on the test device:
- Settings applied count: 87 → 119 → 351. v1.0.0.32 surfaced what the CSP-only scan found; v1.0.0.33 added HKLM GPO/ADMX (+32); v1.0.0.35 adds HKCU GPO/ADMX + first-class promotion (+232).
- Edge alone went from 1 visible policy (the side-by-side install setting) to 40+ visible policies spanning sign-in, sync, security, browser UX, performance, and recommended user settings.
- The compliance donut on both the home page and the Managed by IT page recompute automatically; the “Settings applied” tile, the chart's Settings bar, and the topic filter chips all reflect the new count.
- Legacy “My365 Log Reader” installs now get cleaned up automatically when the new MSI deploys. v1.0.0.32 renamed the app from My365 Log Reader to My365 Device. The MSI's
MajorUpgradedirective caught most upgrade cases, but devices in the field with installs from earlier dev cycles — whoseUpgradeCodeGUID didn't match the current production code — weren't picked up. End result on those devices: My365 Device 1.0.0.32+ installed cleanly, but the old My365 Log Reader entry stayed sitting in Programs and Features alongside it. - Root cause.
MajorUpgradeonly finds and removes products that share exactly the sameUpgradeCodeas the new MSI. If a previous version of the app was built with a differentUpgradeCode(early dev cycles before the production GUID was finalized, or accidental regenerations during testing),MajorUpgradehas no way to find that product — it doesn't index by name. - Two-part fix in v1.0.0.34.
- MSI custom action. Every new install runs a deferred PowerShell snippet during the install script (after
RemoveExistingProducts, beforeInstallFiles, running as SYSTEM) that enumerates the standard Uninstall registry, finds every product whoseDisplayNameis exactly My365 Log Reader, and runsmsiexec /x <ProductCode> /quiet /norestarton each match.Return="ignore"on the custom action so any quirk in the PowerShell invocation (missing executable on Server Core, broken execution policy, etc.) can never break the install itself. The custom action never touches the current My365 Device install because the name check is exact-match on the legacy string. - Standalone cleanup script.
Installer\scripts\Cleanup-OldMy365Installs.ps1ships with the installer for IT to deploy as an Intune Platform Script or Proactive Remediation against the existing fleet. The script walks both theHKLMandHKLM\WOW6432NodeUninstall trees, finds every My365 Log Reader or older My365 Device install (any version that doesn't match-KeepVersion), and silently removes each one viamsiexec /x. Logs to%ProgramData%\My365\CleanupOldInstalls.log. Supports-DryRunfor preview.
- MSI custom action. Every new install runs a deferred PowerShell snippet during the install script (after
- Going forward. All future MSI upgrades from v1.0.0.34 onwards will work cleanly via
MajorUpgradealone — theUpgradeCodehas been stable since v1.0.0.20 and won't change. The custom action above stays in place as a permanent safety net for any device that still has a legacy install from a pre-stable dev cycle. - Important Intune workflow note. When uploading a new MSI to Intune, ALWAYS update the EXISTING app entry (Properties → App information → Edit → Select app package file). Do NOT create a new app entry per upload — Intune would then track the old and new as separate deployments and could re-install the old one even after
MajorUpgraderemoved it. TheInstaller\README.mddocuments the full upgrade workflow.
- Managed by IT now surfaces every Intune-deployed policy, not just the ones in the MDM CSP registry. The previous discovery read
HKLM\SOFTWARE\Microsoft\PolicyManager\current\device, which catches Settings-catalog policies and modern templates but misses every ADMX-imported policy IT pushes through the “Administrative Templates” profile type. v1.0.0.33 adds a second discovery source — the standard GPO / ADMX policy paths underHKLM\SOFTWARE\Policies\— with a curated catalog of friendly translations for the most common settings:- OneDrive sync client — Files On-Demand, Known Folder Move (with tenant-specific notes), KFM opt-out lock, mass-delete protection & threshold, auto-sign-in, free-up-space on synced SharePoint / Teams libraries, automatic bandwidth throttling, update ring.
- BitLocker drive encryption (FVE) — TPM authentication mode, TPM+PIN / TPM+key / TPM+key+PIN options, BitLocker-without-TPM, recovery to Active Directory / Entra, data recovery agent, recovery password & key allowances, advanced startup.
- Microsoft Edge updates — side-by-side install policy.
- Windows core security — Credential Guard (LsaCfgFlags), LSASS protection (RunAsPPL / Protected Process Light), Kernel DMA Protection for external Thunderbolt / USB4 / PCIe devices, self-encrypting Opal drive activation, MSI “always install elevated”, Windows Sudo command, cross-device experiences (CDP / MMX).
- Windows AI — Windows Recall enablement policy, Settings AI agent toggle.
- Network & connectivity — Personal firewall configuration, Internet Connection Sharing UI, network-location permissions for standard users, network-bridge creation policy.
- File Explorer & UX — Graph-powered recent files, AutoPlay for non-volume devices, Teams Chat taskbar icon, Windows Backup feature.
- Microsoft Defender for Endpoint — onboarding state.
- TPM — owner authorization storage level.
- Diagnostics —
AllowTelemetrylevel (Security only / Required / Enhanced / Optional).
HKLM\SOFTWARE\Policies\that's not in the curated catalog still appears, just behind the “Show advanced settings” toggle with a generic friendly name derived from the registry path. That covers the long tail of vendor-specific policies (Adobe Acrobat sub-settings, Firefox / Chrome / Brave policies). - Real-world impact on the test device: Settings applied count climbed from 87 in v1.0.0.32 to 119 in v1.0.0.33 (+32 first-class catalogued policies). The Managed by IT compliance donut and the home-page health card both reflect the new count automatically.
- About this PC card on the home page. A new five-row card below the Managed-by-IT health summary shows the basic specs IT or support staff most often need to ask for:
- Device name — the machine name.
- Windows edition — e.g. Windows 11 Enterprise (25H2). Translates
EditionIDto the marketing name and readsDisplayVersionfor the release. - OS build — full
CurrentBuildNumber.UBR(e.g. 26200.8457), matching the build line in winver. - Processor — CPU name from WMI
Win32_Processor.Name, plus a (N cores) / (N cores, M threads) tag. - Memory — sum of installed DIMM capacities (
Win32_PhysicalMemory.Capacity), rounded to the nearest 0.5 GB. Uses the installed-RAM figure rather than usable-RAM so a 16 GB machine reads 16 GB, not 15.4 GB.
- Troubleshooter count corrected. The home-page card under “Run a troubleshooter” previously read “14 official Microsoft fix-it tools” — an outdated number from before the v1.0.0.20-era troubleshooter expansion. The card now correctly reads “26 official Microsoft fix-it tools across Office, Outlook, Teams, OneDrive, Windows Update, networking, printers, audio, and more.”
- The app is now “My365 Device”. Renamed from “My365 Log Reader” to reflect what the app has grown into — it's no longer primarily a log viewer; it's the end-user companion for an Intune-managed PC. User-visible name updates land everywhere:
- Window title bar, custom title-bar caption, About page, and the new nav-rail header all read “My365 Device”.
- Start Menu shortcut, install folder (
C:\Program Files\My365 Device), and the Add/Remove Programs display name updated via MajorUpgrade. - Internal executable name (
My365LogReader.exe) and theSoftware\Netlogic\My365LogReaderregistry breadcrumb stay the same so Intune's existing app-detection rules keep working and devices upgrade in place without IT re-deployment.
- New nav-rail icon. The previous wide horizontal Netlogic logo is replaced with the My Device SVG illustration from the brand kit (a small monitor + cube visual that ties the app to Intune-managed device management). Rendered via
SvgImageSourceso the icon stays crisp at any DPI without shipping multiple PNG sizes. The app name “My365 Device” appears as text next to the icon, with the existing “Your IT helpdesk in one place” tagline below. - Redesigned home page. Logs were dropped as the page's main subject — for a typical end user they're not essential day-to-day — and replaced with the most useful single piece of information the app already had: a compact version of the Managed-by-IT compliance donut. New layout, top to bottom:
- Hero card — the My Device icon plus the new product name and an Intune-focused tagline.
- Quick actions row — unchanged: Sync with Intune, Check for Windows updates, Update apps, Restart PC.
- Device health card — this is the new headline element. A 130-px compliance donut showing the percentage of currently-applied items, a plain-English status headline (“All clear” / “3 items still applying” / “2 items need IT's attention”), and a count strip showing how many apps have been deployed, how many settings applied, how many scripts run, and how many items currently need IT's attention. The whole card is a button — click it to jump to the full Managed-by-IT page.
- Two feature cards — User Guides (146 plain-English how-to articles) and Run a troubleshooter (14 Microsoft fix-it tools).
- Advanced: diagnostic logs — a single de-emphasized link at the bottom for power users and IT support staff who still want to read raw Intune / Windows / Defender / Office / OneDrive / Edge logs. The full Logs page is unchanged; only its prominence on the home page is reduced.
- Brand-new-device handling. Devices that haven't been enrolled in Intune yet (or have been enrolled but haven't received any assignments) see a friendly “This PC isn't enrolled in Intune yet” explanation card instead of a misleading empty donut. The User Guides and Troubleshooters cards below still work, so the app is useful even before IT enrolls the device.
- About page refreshed. Uses the new My Device icon (96 px), the updated product name, and a tagline that talks about Intune-managed device management rather than reading logs. Privacy + safety blurb stays unchanged because the underlying guarantees are the same.
- Why these changes matter. The previous home page was log-centric because the app started life as a log reader. v1.0.0.20+ added comprehensive Intune visibility (Managed by IT), and v1.0.0.26–31 added a meaningful health visualization on that page. v1.0.0.32 acknowledges that the center of gravity has shifted — the typical end user's most useful first-glance question (“is anything broken with what IT set up on my PC?”) now has a one-card answer on the home page, with logs reduced to a single line for the power-user audience that actually wants them.
- Visual health chart added to the Managed by IT page. Below the four count tiles, a new at-a-glance card now shows whether Intune is healthy on this device:
- Compliance donut on the left, with the percentage of currently-applied items in the center. Reading the donut in one glance tells you immediately whether the device is fully green (everything applied), partly amber (some assignments pending), or has any red (failures that need IT's attention).
- Plain-English headline next to the donut summarises the state in one sentence — “All clear — every Intune item on this device applied successfully”, “3 items are still applying”, “2 items need IT's attention — the rest are healthy”, or “Waiting for IT to evaluate this device” on brand-new enrollments.
- Per-category stacked bars — one each for Apps, Settings, and Scripts — let users see which category has issues without filtering first. Each bar is proportionally divided into green (Active), amber (Pending), and red (Needs IT) segments based on the actual status of every item in that category. Counts appear on the right edge of each bar (e.g. “21 active · 2 pending”).
- Legend beneath the bars explains the color coding so the chart is self-documenting.
- Chart hides itself when there's nothing to evaluate — a brand-new device that hasn't received any Intune assignments shows the four count tiles (all zeros) and skips straight to the filter chips, so no misleading “0% healthy” reading appears.
- Advanced ADMX-imported policies and the enrollment record are excluded from the chart math. Including them would skew the percentage misleadingly green even on a device with real issues — ADMX entries on a typical fleet are ~1500 items, virtually all of which are Applied. The chart focuses on apps, real MDM policies, and scripts that IT actually pushed, which is what determines operational health.
- Renders entirely with native WinUI primitives (Path geometries for the donut arcs, star-sized Grid columns for the stacked bars). No external charting library — the build artifact size stays unchanged and there's nothing new to keep up to date.
- Colors match the status pills already used on individual item cards (
#107C10green /#CA8A04amber /#C42B2Bred), so the chart and the cards visually agree about what each color means.
- Settings & policies view no longer shows duplicated
_WinningProvidercards alongside every real policy. The MDM PolicyManager registry stores a swarm of bookkeeping values next to each real policy —<Setting>_WinningProvider,_ProviderSet,_ADMXInstanceData,_LastWrite— that record which provider applied the setting and when. The previous filter only caught the older double-underscore variant (__Provider/__Result), leaving ~950 single-underscore metadata entries leaking into the front-facing list as duplicates of every real policy. - Filter extended to drop every known metadata suffix. Values whose name ends in
_WinningProvider,_ProviderSet,_ADMXInstanceData,_LastWrite,_Result, or_Statusare now skipped during discovery. The original double-underscore guard stays in place to keep older PolicyManager schemas clean too. - Real-world impact on the test device:
- v1.0.0.29 surfaced 504 policy cards — ~415 of which were
_WinningProvidershadows of the other 89. - v1.0.0.30 surfaces 89 policy cards, one per real applied setting. The “Settings applied” tile on the Managed by IT hero now shows the accurate count.
- v1.0.0.29 surfaced 504 policy cards — ~415 of which were
- The Technical details expander on each remaining policy card still shows the OMA URI (
./Vendor/MSFT/Policy/Config/...) so IT can trace the setting back to the Intune admin center. If IT needs to know which provider won the policy conflict, that's still available in Registry Editor atHKLM\SOFTWARE\Microsoft\PolicyManager\current\device\<Area>\<Setting>_WinningProvider; we just don't show it on the user-facing page anymore because it's not actionable end-user information.
- PowerShell script cards now have plain-English names instead of GUID stubs. v1.0.0.28 unblocked the script discovery but every card was titled “Proactive Remediation 02a4e7e8…” because IME encrypts the actual script
DisplayNamein its logs (the field is consistentlynull). v1.0.0.29 infers a friendly title from the detection script's stdout, which almost always contains a strong topical signal — the app being checked, the compliance area, or the setting being enforced. - Keyword-based name inference covers 50+ common scripts. Pattern matching against the
PreRemediationDetectScriptOutput+RemediationScriptOutputDetailsrecognizes:- Apps IT commonly deploys: Firefox, Notepad++, Chrome, Edge, 7-Zip, VLC, Adobe Reader, Git, VS Code, OneDrive, Teams, Outlook, Microsoft 365 Apps, Office, Visio, Project, Company Portal, Copilot, Canva, Windows Terminal.
- Security & compliance: BitLocker, Defender, SmartScreen, Windows Firewall, UEFI CA 2023, Secure Boot, UEFI / BIOS firmware, TPM, Windows Hello.
- Updates: Windows Update, Auto-update settings, WinGet, “apps with updates available” checks.
- Agents: Intune Management Extension, Windows Autopatch, Action1, Delivery Optimization, PowerShell version, .NET runtime, VC++ Redistributable.
- Connectivity / hardware: VPN, Wi-Fi, Proxy, DNS, battery, power plan, disk space.
- Generic compliance fallback: anything saying “Compliant” / “C1 COMPLIANT” gets a Compliance check label.
- Detection-output snippet now appears in the card description. Instead of the previous generic line, each Proactive Remediation card now reads “Most recent detection output: “Firefox is not installed - compliant (update-only mode)”” — the actual stdout from the last run, cleaned up and capped at 110 characters. This is enough context for users to understand what the script monitors without having to call IT.
- Fallback when no topical signal is present. When the detection output is just
Running/No_Match/No remediation/The operation completed successfully(genuinely topic-less responses), the card falls back to the first useful line of output, with leading timestamps and===header markers stripped. If even that's empty, the card displays “Proactive Remediation {shortId}…” as a last-resort label so the entry is at least uniquely identifiable. - Regex correctness fix for app-name detection. Trailing word boundaries (
\b) don't fire after non-word characters like+or#, so the initial Notepad++ pattern\bNotepad\+\+\bsilently failed on the input "Notepad++ not detected. Device is compliant." (it landed in the generic Compliance check bucket). Replaced with a lookahead(?=\s|$|[\.,;:])that matches whitespace or punctuation following the trailing++, so the Notepad++ entry now correctly shows as Notepad++ install check. - Real-world verification on the test device: 26 script cards total — 20 with meaningful names (App updates available check, Auto-update setting check, C1 compliance check, Compliance check, Firefox install check, Intune Management Extension health, Notepad++ install check, PowerShell version check, UEFI CA 2023 update, etc.) and 6 fallback-to-PolicyId entries where the detection output offered no topical signal to infer from.
- PowerShell scripts filter on Managed by IT is no longer empty. The legacy discovery path read
HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Policies— the same family of ACL-locked registry trees the apps filter ran into back in v1.0.0.19. On every Intune-managed device we've seen in the wild that key is locked toNT AUTHORITY\SYSTEM+ Administrators, so the call from a standard-user-context app threwSecurityException: Requested registry access is not allowedand the filter rendered blank. v1.0.0.28 falls back to the same log-parsing pattern the apps view added in v1.0.0.26/27 — reading IME's own log files in%ProgramData%, which are world-readable. - Proactive Remediations come from
HealthScripts.log. Each[HS] new result = {...}line carries a JSON status object withPolicyId,Result,RemediationStatus,PreRemediationDetectScriptOutput, andErrorCode. The discovery indexes by PolicyId, keeps the most recent result per script, and translates the codes into plain English (“Last check: nothing to fix on this device” / “Detection found an issue and the remediation script ran successfully” / “Detection found an issue — remediation is pending or in progress” / “Last run reported an error”). The PreRemediationDetectScriptOutput snippet is preserved in the Technical details expander so IT can see exactly what the detection script reported. - Standalone PowerShell scripts come from
IntuneManagementExtension.log. The IME log writes a[PowerShell]component tag with the PolicyId on every script execution. The discovery walks the tail of the active + most recent rotated copies, indexes PolicyIds by “succeeded” / “failed” proximity markers, and emits one card per unique script. - False-positive guard for PowerShell-log parsing. The same log file carries unrelated
[PowerShell]infrastructure lines that reference user-session IDs, AccountIds, and TenantIds. The discovery now requires the word policy / PolicyId in proximity to the GUID AND blocks lines matching common noise patterns (user id,AccountId,TenantId,SessionId,aad user). Caught and fixed during local verification when the first pass over a real IME log surfaced 16 ghost script entries that were really just user-session GUIDs. - Dedupe across registry + log sources. If the device happens to have the registry path readable (admin-context launches, custom GPO carve-outs), the same PolicyId can land in both the registry-based discovery and the log-based one.
DedupeScriptsgroups by PolicyId (extracted from each card's TechnicalDetail string) and keeps the entry whose status is most informative — Failed wins, then Applied, then Pending, then Unknown — so a stale “Applied” registry record can't mask a real log-only failure. - Real-world verification on the test device: previously 0 script entries; now 26 unique scripts (25 Proactive Remediations + 1 standalone PowerShell script). The new diagnostic breadcrumb writes the per-source counts to
%LOCALAPPDATA%\My365LogReader\diag.logafter every scan, so any future “scripts view is blank” report has a one-line answer.
- Apps view now finds Microsoft Store / Win32 deployments on x64 devices that 1.0.0.26 missed. The log-based discovery added in v1.0.0.26 worked correctly on the dev's arm64 device but came up empty for Microsoft Store and packaged Win32 entries on busy x64 fleets. Three independent fixes land together:
- Multi-file log reading. v1.0.0.26 only tailed the active
AppWorkload.log. On devices where IME rotates the log every few hours (large policy sets, many apps, frequent check-ins), the most recent “Get policies” block lands in aAppWorkload-YYYYMMDD-HHMMSS.logrotated copy — not the active file. v1.0.0.27 walks the active file plus the three most recent rotated copies and concatenates the tails, so the policy refresh that lists every Intune-deployed app is always found regardless of when the log last rolled over. - Larger tail window. Bumped from 3 MB to 8 MB per file, giving four logical hours of typical IME activity even on the busiest devices.
- Dynamic ProgramData path. Replaced the hardcoded
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.logwith a%ProgramData%resolution viaEnvironment.SpecialFolder.CommonApplicationData. Catches the corner case where Windows is installed on a non-C drive (re-imaged dev kits, custom OEM partitioning) and ProgramData lives onD:\or another letter.
- Multi-file log reading. v1.0.0.26 only tailed the active
- AppX/MSIX cross-check fallback for apps with no log status. Even with the multi-file tail there's a corner case: IME refreshes its “Get policies” block every 8 hours but writes per-app status reports only when something changes. For Microsoft Store apps that have been installed for months and aren't being reinstalled, the most recent status report can be older than the 8 MB tail. When that happens, the Apps view now falls back to
Windows.Management.Deployment.PackageManager.FindPackagesForUser()— if an AppX/MSIX package with a matching display name is installed on the device, the app is shown as installed regardless of whether the log carries a status. Won't fire when IME has a recent status report (the status report is always more authoritative than a presence check); only steps in when the log is silent for that app. - Diagnostic breadcrumbs for triage. Each discovery pass now writes a one-line summary to
%LOCALAPPDATA%\My365LogReader\diag.log:- Number of log files read and total bytes parsed
- App policy entries found / status reports indexed
- App items emitted, broken down by skip reason (uninstall intent / not detected / salvaged via AppX index)
- Older-IME log shape compatibility. Some Intune Management Extension builds emit
GetPolicies received/GetPolicies responseinstead of the currentGet policies =marker for the policy block. The regex now matches all three variants so devices on older or beta IME builds still light up. The reporting-status regex also handles a second level of nested braces, which newer IME builds occasionally use for assignment metadata.
- Managed by IT → Apps now shows every type of Intune-deployed app, not just MSI. The previous build relied on a single registry source (
EnterpriseDesktopAppManagement) that only tracks MSI / Win32-wrapped-as-MSI deployments. Microsoft Store (new) apps, packaged Win32 apps, and Office Click-to-Run installs were all invisible. v1.0.0.26 adds three additional discovery sources and dedupes everything by display name so each app shows up once with its best status. - Microsoft Store (new) apps. Read from the Intune Management Extension's own
AppWorkload.log— specifically the “Get policies” JSON block IME refreshes on every check-in. Entries withInstallerDatacarrying"SourceName":"msstore"are classified as Microsoft Store deployments and cross-referenced against the per-appReportingManagerstatus reports for the current detection / enforcement state. - Packaged Win32 apps that don't appear in EDAM. Same log source. Catches IT-published
.exe/ wrapped installers that IME tracks per-user under the ACL-blockedWin32Appsregistry. The log file lives inProgramDataand is readable by standard users, so the discovery works without admin rights. - Office Click-to-Run. Read from
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration. TheProductReleaseIdsvalue (e.g.O365ProPlusRetail,ProjectProRetail) is split into one card per product, translated to friendly names (Microsoft 365 Apps for enterprise, Project Professional, Visio Professional, ...), and tagged with the channel name decoded from the CDN GUID (Current, Beta / Insiders, Monthly Enterprise, Semi-Annual Enterprise, Current Preview). - Real-world verification on the test device:
- 5 unique MSI cards from the EDAM source (unchanged from v1.0.0.25)
- 16 additional Intune-deployed apps surfaced from
AppWorkload.log— Canva, Company Portal, Microsoft 365 Copilot, Microsoft Clipchamp, Microsoft Edge for Windows, Microsoft Forms, Microsoft Loop, Microsoft To Do, Outlook for Windows, PowerShell 7, Remote Help, Windows App, Windows Autopatch Client Broker, Windows HDR Calibration, Windows Scan, Windows Terminal - 2 Office C2R cards — Microsoft 365 Apps for enterprise and Project Professional
- Each app card carries the detected version (from IME's
DetectedIdentityVersionfield), the install scope (per-user vs device-wide), and a one-line plain-English status (“Installed and working as expected”, “Installed; a restart is needed to finish”, “Installation in progress”, etc.). The Technical details expander shows the app GUID, raw detection / enforcement codes, and the deployment intent for IT support.
- Stale MajorUpgraded app versions no longer appear on Managed by IT. EDAM retains tracking entries for every ProductCode Intune has ever deployed — including old MSI versions replaced by MajorUpgrade. Filtering on EDAM's
Statusfield alone wasn't enough because that value can stay at 70 (Installed) for ghost entries long after the actual MSI is gone. The fix calls Windows Installer's ownMsiQueryProductStateAPI on every EDAM ProductCode — the canonical “is this MSI installed right now?” check Windows itself uses internally. ReturnsINSTALLSTATE_DEFAULT(5) only for currently-installed MSIs; anything else (Advertised, Absent, Unknown) means the entry is stale and gets skipped. - App names always come from MSI's canonical ProductName property now. The friendly-name lookup tries
MsiGetProductInfo(ProductName)first — same API that drives Programs and Features — then falls back to the Uninstall and per-user MSI InstallProperties registries. Apps that fail both lookups (which means the MSI isn't really installed or has no name) are skipped entirely. No more GUIDs leaking into the Apps view as “App {01A1A484-...}” cards. - Same MSI name — multiple ProductCodes — collapses to one card. The dedupe pass now groups by friendly display name (instead of by GUID, which never merged duplicates from MajorUpgrade chains). When several ProductCodes resolve to the same product name (e.g. seven legacy “My365 Log Reader” entries from prior version installs), only the most recently active entry is kept —
Status=Appliedwins ties, then the most recentEnforcementStartTime. -
Real-world verification on the test device:
- 29 raw EDAM entries on disk
- 12 filtered out as “not currently installed” by the MSI API check
- 17 currently-installed entries — 13 of which collapsed to one card after dedupe by name
- Final result: 5 unique installed apps with friendly names — Microsoft Device Inventory Agent, Microsoft EPM Agent, Microsoft Intune Management Extension, My365 Baseline Builder, My365 Log Reader
- Stale
Installer\Productsname fallback removed. The previous implementation falling through toHKLM\SOFTWARE\Classes\Installer\Products\<PackedCode>\ProductNamewas the source of the “old uninstalled app showing” problem — that registry is a known-MSI database and retains entries even after uninstall. The remaining registry fallback (Installer\UserData\<SID>\Products\<PackedCode>\InstallProperties) is the right place because Windows Installer removes it on uninstall, so its presence is a reliable “currently installed” signal for system-context MSIs that don't write Uninstall entries.
- Policy values no longer leak GUIDs, registry paths, or unreadable blobs into the front-facing card. v1.0.0.21 added generic boolean inference for unknown policies, but values that weren't 0/1 (GUIDs for tenant IDs, URLs for lock-screen images, file paths for proxy configs, XML/JSON blobs, long base64 strings) still fell through to the raw value. v1.0.0.24 expands the inference engine to recognize every common shape and translate it to plain English:
- GUIDs (tenant IDs, enrollment IDs, sensor cluster IDs, content IDs) → “Configured by IT (technical ID — see details)”. The raw GUID stays in the Technical details expander for IT support.
- URLs (lock-screen image, wallpaper, proxy / discovery / WSUS URLs) → “Points to {hostname}”. Users see “Points to pages.netlogicmy365.com” instead of the full path.
- Windows registry paths (
HKEY_LOCAL_MACHINE\...,HKLM\...) → “References another Windows setting”. - OMA CSP paths (
./Vendor/MSFT/...) → “References another MDM policy”. - File paths (
C:\...,\\server\share,%LOCALAPPDATA%\...) → “Configured (filename.ext)” — shows just the leaf file/folder name. - XML / JSON / array blobs over 40 chars → “Complex configuration (see details)”.
- Comma-separated lists → “{N} values configured”.
- Long opaque strings over 80 chars → “Configured (complex value — see details)”.
- Numeric values with unit hints from the setting name. Now translated based on common naming conventions:
*Hour/ActiveHours*(0–23) → “8:00 AM” / “5:00 PM” (12-hour clock).*Days/DaysToRetain*→ “30 days”, with 0 shown as “Disabled (0 days)”.*Hours→ “4 hours”;*Minutes→ “15 minutes”;*Seconds→ “60 seconds”.*Bytes/*Size→ formatted as KB / MB / GB.
- Empty / unset values are now labeled as “Not set” instead of showing as a blank line.
- Short readable strings (country codes like en-US, single keywords) still appear verbatim — the inference only intervenes when the value is technical-looking. The raw value is always available in the Technical details expander.
- Service-side fallback hardened too. Even when the translator can't pick up a value at all, the policy card now hides anything over 60 chars from the front-facing line and points the user at the Technical details expander instead of dumping the raw text into the “Currently set to:” line.
- Topic filter chips for Settings & policies. On a typical Intune-managed device there are 60+ MDM policy areas and hundreds of individual settings — finding the one you care about meant scrolling or guessing the right search term. The Managed-by-IT page now shows a second row of chips when you click “Settings & policies” on the main filter row, letting you narrow to a specific topic in one click. Available topics:
- All topics — the default; shows every policy.
- Security & antivirus — Microsoft Defender, SmartScreen, Windows Security app, Device Guard, Secure Boot, Exploit Guard, MSS legacy security knobs, Web Threat Defense.
- Drive encryption — BitLocker and cryptography settings.
- Sign-in & password — Authentication, Credentials UI, Device Lock, Local Policies / Security Options, Kerberos, Windows Logon, User Rights, Local Users and Groups.
- Windows Update — Update channel, deferrals, pause state, Delivery Optimization.
- Apps & install rules — Application Management, App Runtime, Default Apps, Licensing, Windows Autopilot, PowerShell, Windows Sandbox.
- Network & connectivity — Connectivity, Wi-Fi, Cellular, Wireless, Bluetooth, Remote Assistance / Remote Management / Remote Desktop, Firewall, LanmanWorkstation.
- Privacy & data — Privacy, Data Protection, Experience, Location, Speech, Settings Sync.
- Browser & web — Edge (legacy + Chromium), Internet Explorer.
- Start, search & notifications — Start menu, Windows Search, Notifications, Personalization, News and Interests, Lockdown / Kiosk mode.
- Files, autoplay & storage — File Explorer, Autoplay, Storage Sense, Enterprise Cloud Print, Printers.
- Power & battery — sleep timers, idle behavior.
- AI & Copilot — Windows AI, Maps, Messaging, Games.
- Device health — Device Health Monitoring, Service Control Manager, Task Scheduler, system policy framework.
- Other — anything that doesn't fit cleanly into the buckets above. The catch-all means no policy is ever hidden by the chips alone.
- The topic chip row only appears when the primary kind filter is set to “Settings & policies” — on Apps / Scripts / Enrollment views the row stays hidden so the page stays uncluttered.
- Switching off the policy kind automatically resets the topic chip back to “All topics” so the next time you come back to Settings & policies you don't see a stale narrow filter.
- ADMX-imported policies (Brave, Firefox, Office, OneDrive, Adobe Acrobat, Google Update, etc.) get bucketed by recognized app prefix — flip on “Show advanced settings” and they'll group cleanly under Browser, Apps, Files, etc. instead of all landing under Other.
- Uninstalled apps no longer show on Managed by IT. Intune keeps tracking apps it has uninstalled long after they’re gone — the EnterpriseDesktopAppManagement registry retains the entry with its Status DWORD bumped to 100 (Uninstalled) so the Intune admin portal can show install history. That was useful in the back-end view but confusing on the end-user-facing page, where a card titled “Microsoft Foo Bar” appearing even though the app isn’t actually installed felt like a bug. The Managed by IT page now hides any entry that represents an uninstall:
- EDAM Status ≥ 90 — covers Uninstalling (90), Uninstalled (100), and Uninstall failed (110).
- EDAM ActionType = 2 — covers apps IT explicitly deployed with an “uninstall this” intent, regardless of how far along the uninstall is.
- IME Win32Apps EnforcementState = 1005 — IME’s “Uninstalled as IT requested” status, the equivalent flag for apps coming from the IME registry (when that path is readable).
- Apps that are currently installing (Status 60), pending install (10/20/25/40/48/50), or failed to install but IT is retrying (30/80) all still show — those represent the install-track that the user might want to know about.
- If IT redeploys an app that was previously uninstalled, it’ll reappear on the page once Intune updates EDAM with a fresh install-track entry — no manual refresh needed beyond the next page navigation.
- Friendly app names instead of GUIDs. v1.0.0.20 only looked up the friendly DisplayName from
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<ProductCode>, but many Intune-deployed apps don’t register an Uninstall entry — Intune’s own helper MSIs (Microsoft Device Inventory Agent, IME, etc.) write to MSI’s product database but not to Uninstall, so they showed asApp {01A1A484-A75B-456A-BE98-D98D0609CDAA}with the raw ProductCode. v1.0.0.21 now falls through to MSI’s own product database atHKLM\SOFTWARE\Classes\Installer\Products\<PackedCode>\ProductName— the canonical place every installed MSI registers its display name. On the test PC this resolves 7 of 12 sampled apps that previously had no name (Microsoft Device Inventory Agent, Microsoft Intune Management Extension, etc.). The remaining handful are tracked-but-uninstalled old versions where MSI legitimately has no name on disk anymore. - The packed-code transformation. Windows Installer represents ProductCode GUIDs in a “compressed” / packed form for its Products registry — the first three GUID groups are reversed, the last two are byte-swapped. We now compute this packed form to look up each EDAM ProductCode in the MSI database. Per-machine and per-user MSI Installer products are both probed.
- Plain-English policy values for unknown policies. v1.0.0.19 translated the values of ~80 well-known policies (Defender, BitLocker, DeviceLock, Update, etc.) into friendly text like “On (required by IT)”. Any other policy the dictionary didn’t recognize fell through to showing the raw
0or1. A generic boolean inference now reads the setting-name prefix to determine the polarity and produce friendly text even when the dictionary doesn’t have an explicit entry:Allow*/Enable*/Permit*= 1 → “On (allowed)”; 0 → “Off (not allowed)”Require*/Mandate*/Force*= 1 → “Required”; 0 → “Not required”Disable*/Disallow*/Block*/Prevent*/Restrict*= 1 → “Blocked”; 0 → “Not blocked”Hide*= 1 → “Hidden”; 0 → “Visible”Show*/Display*= 1 → “Shown”; 0 → “Hidden”Skip*/Suppress*/Bypass*= 1 → “Skipped”; 0 → “Not skipped”- Generic fallback: 1 → “Yes”; 0 → “No”
- Multi-valued settings (enums with codes like 0/1/2/3, paths, strings) still show their raw value because translating those without explicit dictionary knowledge would be misleading.
- Explicit dictionary translations from v1.0.0.19 still take precedence — the generic inference is only used when no explicit entry exists.
- “Apps” filter on the Managed-by-IT page is no longer empty. The v1.0.0.19 discovery only read
HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps, which is ACL-blocked from standard users on most Intune-managed devices —Registry.LocalMachine.OpenSubKeyjust silently returned null and we showed no apps even though IT had deployed dozens. - The fix. The discovery now also walks
HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\<SID>\MSI\<ProductCode>— the standard MDM registry path Intune lands MSI and Win32-wrapped-as-MSI deployments at. EDAM is readable by standard users (no admin needed) and on the test device returned 42 deployed apps including PowerShell 7, Microsoft 365 Copilot, Company Portal, Canva, Microsoft Loop, Microsoft Forms, Outlook for Windows, Remote Help, and the rest of the Netlogic My365 standard fleet. - Friendly app names. EDAM stores the ProductCode but not a display name, so the discovery now cross-references the ProductCode against
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<ProductCode>(and the WOW64 equivalent for x86 MSIs) where the installed MSI's DisplayName lives. Apps that don't have an Uninstall entry yet (still installing) get a placeholder name with the ProductCode so the card is still actionable. - Plain-English status for the MDM EnterpriseDesktopAppManagement
StatusDWORD: Installed and working as expected (70), Installing right now (60), Downloading the installer (20), Couldn't download — IT will retry (30), Install failed (error 0x...) (80), and so on. The technical detail expander still shows the raw Status + LastError codes for IT support. - Dedupe across both sources. On devices where the IME Win32Apps registry IS readable (admin run, or admin-relaxed ACLs), apps could surface from both IME and EDAM. The discovery now deduplicates by ProductCode/AppGUID so each app shows once, keeping the entry with the friendlier name.
- Click Managed by IT on the nav rail. The hero card's “Apps deployed” tile should show a non-zero number (matching how many app entries Intune has provisioned via EDAM).
- Click the Apps chip. Every Intune-deployed MSI/Win32 app shows with: friendly name, install status pill, plain-English status line (“Installed and working as expected” for the typical case), version, and a Technical details expander with the ProductCode for IT support.
- New “Managed by IT” page. A whole new section on the navigation rail (next to User Guides) that surfaces everything your IT department has deployed to this device through Intune — apps, security settings, PowerShell scripts, and how the device is enrolled. Each item is shown as a card with a plain-English title, a one-line description of what it does, a status pill (Active / Pending / Needs IT / Not applicable), and a “Currently set to:” line that translates the technical value into something you can read at a glance (e.g. “Real-time virus protection: on (required by IT)” instead of
Defender/AllowRealtimeMonitoring = 1). - Hero card at the top of the page summarizes: how the device is enrolled (UPN + Intune service URL), how many apps Intune deployed, how many settings are applied, how many PowerShell scripts ran, and how many items are currently in a failure state that IT may need to address.
- Filter chips across the top split the view by tier: All / Apps / Settings & policies / PowerShell scripts / Enrollment. Helpful when you want to answer a specific question like “what apps did IT push?” without scrolling past 100 policy settings.
- Free-text search matches across every field of every item — type “BitLocker”, “password”, “Defender”, an app name, or any keyword you remember, and the list narrows immediately. Search also temporarily ignores the “Show advanced settings” toggle so a search for an ADMX-imported policy still surfaces it.
- Plain-English translations for ~80 of the most common MDM policy areas and individual settings, covering Microsoft Defender (real-time protection, behavior monitoring, cloud-delivered protection, sample submission, PUA blocking, scan direction), Windows Update (deferral days, branch readiness, pause state, MS Update channel), BitLocker (encryption requirement, algorithm, recovery key handling), DeviceLock (minimum password length, complexity classes, auto-lock idle time, max failed attempts, expiration days, history depth), SmartScreen, Edge, Authentication, Privacy, Connectivity, Wi-Fi, Cellular, Personalization, Application Management, Power, Storage, TextInput, Experience, and more. Settings that aren’t in the dictionary still appear with a humanized name and their raw value so you can search and see them — no setting is hidden.
- “Technical details” expander on every card reveals the OMA URI / app GUID / registry path for support engineers. The user-facing view stays focused on the plain-English summary; the technical breadcrumb is one click away when IT asks for it.
- “Show advanced settings” toggle (off by default) keeps the page approachable on devices where Intune has imported ADMX policies for third-party apps (Brave, Firefox, Adobe Acrobat, Chrome, etc.) or layered ADMX-style overrides on Windows internals. These are technically real policies your IT department deployed, but on a typical fleet device there are 1500-2000 of them, with admin-facing names that would drown out the core ~100 Windows CSP settings most end users care about. Flip the toggle to see them; flip it off to focus on the curated set. The hero-card “Settings applied” count reflects the visible tier.
- Windows internal “knobs” tier excluded. The MDM
PolicyManager\current\device\knobsregistry path contains ~1300 internal Windows feature-flag toggles that aren’t actually IT-deployed policy — they’re operating-system internals. The new page skips this tier entirely so the counts and lists reflect what IT actually pushed.
- The page reads four registry locations:
HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Appsfor apps,HKLM\SOFTWARE\Microsoft\PolicyManager\current\devicefor MDM policies,HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Policiesfor PowerShell scripts, andHKLM\SOFTWARE\Microsoft\Enrollmentsfor the enrollment metadata. No admin rights needed; each tier is wrapped in its own try/catch so a single ACL-blocked path doesn’t sink the whole scan. - All discovery runs off the UI thread. Page navigation is snappy — the registry walk completes in well under a second on a typical Intune-managed device.
- Home-page “Logs that need attention” tile now matches the Logs page “Needs attention” list. Previously the home tile showed a higher count than the Logs page would actually display. The two scans diverged in three ways:
- The home tile ignored the date filter entirely, so files that had errors yesterday counted toward the tile even though “Today” filtering hid them from the Logs page.
- The home tile scanned the most recent 25 files; the Logs page scanned 30. Different cost caps, different result sets.
- Whichever page refreshed last won the “advanced logs included” state of the shared cache — opening the Logs page with the advanced toggle on would leave advanced files in the cache that the home page would then count.
- The fix.
ScanForIssuesAsyncnow takes an explicit per-file predicate and an explicitincludeAdvancedflag. Both the home page and the Logs page pass the same predicate (active date filter + advanced bypass for opted-in files) and the samemaxFiles=30cost cap, and the method callsRefreshFilesAsyncinternally so the file list always matches the requested advanced state. The two numbers now agree by construction: click the home tile and you see exactly that many files on the Logs page.
- “Show advanced logs” toggle now visibly does something. On most devices, the advanced log sources (CBS, Defender platform, Office telemetry, OneDrive settings snapshots, Edge debug, etc.) write infrequently — days or weeks between updates — so the “Today” date filter that ships as the default would hide every newly-discovered advanced file the moment it arrived. Flipping the toggle ON would correctly fan out discovery to include the advanced sources, but they wouldn’t appear in the list because the date filter immediately filtered them back out. Symptom: toggle the switch, nothing visible happens.
- The fix. When “Show advanced logs” is ON, advanced files now bypass the date filter entirely. The user flipped the switch specifically to find them, so showing CBS.log from last week is the desired behavior, not a bug. Standard log files still respect the date filter as expected.
- Clearer status message. The status line at the bottom of the Logs page now shows the breakdown when the toggle is on (e.g. “Found 270 log files (262 standard + 8 advanced)”) and a hint when it’s off (“advanced sources hidden — flip the toggle to include them”). Even on devices where no advanced files are actually present, the user can see at a glance whether the toggle did anything.
- Belt-and-suspenders backup wiring. The toggle is bound to the view-model via
x:Bind ... Mode=TwoWay, which should drive everything on its own. A code-behindToggledevent handler now also explicitly syncs the view-model and re-runs discovery if the binding ever fails to fire for any reason — defensive against future XAML compiler quirks or refactors. The two paths are idempotent (no double-fire when both work).
- Aggressive noise filtering across all 11 IME log files. v1.0.0.15 only caught the four-or-five chatter patterns visible in the IntuneManagementExtension.log screenshot, but the IME logs folder actually contains 11 separate files (Sensor, Agent Executor, App Action Processor, Win32App Inventory, App Workload, Health Scripts, Client Cert Check, Device Health Monitoring, Notification Infra, plus IntuneManagementExtension.log itself) and each one has its own routine chatter that gets emitted at CMTrace severity
type="2"(Warning) andtype="3"(Error) during normal operation. v1.0.0.16 adds ~30 more specific noise patterns covering:- Component lifecycle markers —
Initializing/Started/Completed/Disposedfor any component name, plus the[Win32App],[Sensor],[HealthScripts],[AppActionProcessor]section delimiters. - HRESULT success codes mis-tagged as warnings —
Returning hresult: 0,hr = 0x0, and similar success returns that the agent logs at type=2. - Detection / hash / cache plumbing —
AppDetectionResultManager,Hash calculated/verified,Detection script returned X,App detected/not detected,Skipping detection. - Steady-state “nothing to do” messages —
Not applicable,No applicable apps/policies/scripts,Skipping app/policy/script,Action skipped,No actions to process. - Intent / queue housekeeping —
Pending intent,Intent queued/processed,Adding/Removing action. - Sensor / telemetry / health-report submissions —
DataPoint captured,Sensor reported,Health check completed,Telemetry submitted. - Certificate / token housekeeping —
Cert chain validation succeeded,Cert expires in N days,Token cache hit/miss/refresh,Acquiring fresh token. - Polling / heartbeat / keepalive cycles —
Polling cycle,Next check in N min,Keepalive. - Retry chatter — anything containing
will retry,retrying,scheduled retry,retry queued, plus HTTP transient codes (401, 408, 429, 503, 504) that resolve on retry. - Expected exceptions — lines tagged
Expected exception,Handled exception,Caught exception, or surfaced viaManagedExceptionFilter. - Defender routine state changes —
Real-time protection enabled/disabled,Signature update succeeded,Scheduled scan started/completed.
- Component lifecycle markers —
- Belt-and-suspenders safety net for CMTrace logs we haven’t seen yet. v1.0.0.16 adds a final-stage rule in the parser: if an IME-style log entry was tagged Warning/Error/Critical by the agent but its message does NOT contain a recognizable real-error keyword (FATAL, CRITICAL, install failed, access denied, certificate invalid, network unreachable, out of memory, etc.), the severity is downgraded to Info. This catches new chatter shapes Microsoft introduces with each IME release without us having to chase a moving target one pattern at a time. Real errors always include one of the recognized markers and continue to surface as expected.
- Where they still live. All downgraded entries remain visible in the Full details tab with their original severity prefixes. The filter only applies to the friendly Summary view’s problem count and the “Issues you should know about” list. IT support can still scroll the raw log when chasing a specific incident.
- Routine IME chatter no longer counts as “problems”. The Intune Management Extension log was the worst offender after the v1.0.0.14 useful/advanced split: even with advanced logs hidden, IME itself logs routine internal events with CMTrace severity types
type="2"(Warning) andtype="3"(Error), so the noise-classification was happening upstream of the source filter. End users would see “9 problems found” and “47 heads-up messages” on the IME log even though everything was working as expected. These patterns are now recognized as noise and excluded from the Summary view’s count and the “Issues you should know about” list:OnSessionChange: SessionUnlock/SessionLock— fires every time the user locks the screen, the screensaver kicks in, or a Remote Desktop session reconnects.Session change detected. IsAgentInitialized=True/False— the follow-up assertion IME logs after a session change. Pure internal state.[Flighting2] CheckEnabledFlights: <list>— IME reads Microsoft’s feature-flag framework on every check-in and dumps the full list of enabled flights. Read-only state, looks alarming but is not a problem.co-mgt feature is not available, ex = System.Management.ManagementException, not fatal— the agent probes for co-management WMI provider that isn’t present on most consumer devices. IME explicitly tags it "not fatal", which is now caught as a general rule for any line ending in, not fatal.Start app check in/End app check in— the canonical IME success markers. Already used elsewhere to compute the “Last Intune sync” tile, so no need to also show them as issues.- Token refreshes, heartbeat sends, cleanup passes, enrollment-ID echoes — background plumbing that’s safe to ignore.
- Win32App / Sensor / HealthScripts / AppWorkload / AgentExecutor section markers (
[X] Start/End/Begin/Complete) — structural log delimiters, not actions. 0 apps / policies / scripts / remediations to process— the most common steady-state outcome of a check-in.
- Same treatment applied to OneDrive and Office. OneDrive’s
GoToState/ state-machine transition lines and Office Click-to-Run’s missing-registry-key reads are now classified as noise. These looked like errors but are normal state-machine and config-default behavior. - Where to still find them. All of the above remain visible in the Full details tab — the noise filter only applies to the friendly Summary view. Power users and IT support can still scroll through every line of the raw IME log to investigate a specific issue; the curated Summary stops counting them toward the “problems found” total.
- Quieter, more useful Logs page. The default Logs view now hides eight diagnostic sources that are mostly noise for non-technical users. These logs are written constantly during normal operation and ship benign “errors” that aren’t actually problems — they used to drown out real issues and inflate the home-page “Logs that need attention” tile. Hidden by default, available via a new toggle:
- Windows servicing (CBS) — the component-store log chats during every Windows update; routine “failed to find package” entries are normal because the engine probes optional components.
- Delivery Optimization — peer-to-peer download chatter; routine “failed to connect to peer” entries are normal because most peers are offline.
- Office telemetry — firehose-level Office app usage and crash diagnostic blobs; the word “error” appears as a JSON field name, not because anything’s wrong.
- Office add-ins (WEF) — web add-in tracing; lots of “failed to load” entries that just mean a tab wasn’t focused.
- OneDrive settings — configuration snapshots (.ini / .dat), not actually logs.
- Defender platform — internal Defender trace data; benign warnings about telemetry submissions dominate.
- Defender for Endpoint — ATP diagnostic telemetry; routine “submission failed, retrying” entries resolve fine on their own.
- Edge browser debug log — empty unless launched with
--enable-logging; pure Chromium internals when populated.
- New “Show advanced logs” toggle in the Logs page header. Flip it on to include all eight sources above — useful when IT support points you at a specific advanced log to investigate a known issue. The toggle is per-session; it resets to off the next time you open the app so the noise doesn’t come back without you asking.
- Home-page tiles now reflect the “useful only” set. The “Logs that need attention” count, the per-category counts (Intune / My365 / Windows / Defender / Office / OneDrive / Edge), and the total “Logs found on this PC” tile all exclude advanced sources by default. The numbers you see on the home page now match the meaningful problems on this device, not the routine chatter from optional components.
- Settings page rearranged. The Log locations list is now split into two sections: “Logs shown by default” (the eight curated sources) and “Advanced logs (off by default)” with a one-line explanation of why each advanced source is opt-in. Useful when IT asks “is this log being read?” — you can see at a glance which tier it’s in.
- PowerShell 7 detection now finds the Microsoft Store install. The v1.0.0.12 production-readiness pass tightened the
pwsh.exelookup to skip App Execution Aliases under%LOCALAPPDATA%\Microsoft\WindowsApps— but in doing so, the lookup stopped finding PowerShell 7 entirely on the most common Intune deployment pattern, where IT pushes PowerShell 7 via the Microsoft Store app deployment type. The Store install lands atC:\Program Files\WindowsApps\Microsoft.PowerShell_<version>_<arch>__8wekyb3d8bbwe\pwsh.exe, which the C# resolver wasn't probing. Symptom: every troubleshooter that needs PowerShell 7 (Generate MDM diagnostic report, Show Microsoft Entra join status, Refresh Microsoft Entra device registration, Force Group Policy refresh, Reset Microsoft Store cache, Restart Print Spooler service, Reset OneDrive sync, Clear new Teams cache, etc.) failed with "PowerShell 7 isn't installed on this PC." - The fix.
ResolvePwshPathnow probes three places in order:- MSI install paths (
C:\Program Files\PowerShell\7\pwsh.exe, etc.) — this catches IT teams who deploy PowerShell 7 via the standalone MSI. - NEW: Microsoft Store / MSIX install under
C:\Program Files\WindowsApps\Microsoft.PowerShell_*__8wekyb3d8bbwe, with architecture-matching package preference (ARM64 package on ARM64 devices, x64 on x64). This catches the Store deployment pattern. - PATH walk as final fallback. The previous build's "skip the WindowsApps directory and reject zero-byte stubs" logic was over-aggressive — the App Execution Alias is launchable via
Process.Start(useShellExecute=false)on Windows 11 even thoughFileInfo.Lengthreports it as 0 bytes. The alias is now honored as a final fallback for users where direct WindowsApps enumeration is blocked by ACLs.
- MSI install paths (
- Both
TroubleshooterRunner(which runs every PowerShell-backed troubleshooter) andEtlConversionService(which converts Windows Update ETL traces toWindowsUpdate.log) got the same fix. The bundled WinGet remediation scriptFind-PwshExealready had this logic — only the C# side was missing it.
A deep audit of the entire app surfaced 115 findings across the C# views, services, PowerShell scripts, app startup, and installer pipeline. The substantive fixes shipped in this build:
- App-level unhandled-exception handler. The app now registers
Application.UnhandledExceptionandTaskScheduler.UnobservedTaskExceptionat startup. A previously-unhandled click-handler exception or a faulted fire-and-forget task would silently terminate the process; both now land indiag.logwith a full stack trace, and recoverable categories (anything that isn't OOM / SO / SEH) are absorbed so the user keeps working. - Fire-and-forget task safety. The background pre-warm tasks kicked off in
OnLaunched(user-guide load, etc.) now run through aSafeFireAndForgethelper that logs faulted continuations immediately, instead of waiting for a future GC to surface them via the unobserved-task hook minutes later. - ContentDialog.ShowAsync calls in the troubleshooter dialog now have try/catch wrappers.
ShowAsynccan throw if the XamlRoot loses its host (system shutdown, multi-window race) — previously crashed the process via async-void; now logged. - Silent catches now log. Several "swallow everything" empty catch blocks in
LogViewerPage(RefreshButton, OnNavigatedTo) andTroubleshooterRunDialog(RunAsync) now write a breadcrumb todiag.logviaDiagnosticLog.Debug. Field support can now triage "nothing happened" tickets that previously surfaced no evidence at all.
- Cancel button no longer freezes the UI. Canceling a running troubleshooter previously called
Process.Kill+WaitForExit(2000)on the UI thread — a 2-second freeze right when the user wanted responsiveness. The kill+wait now runs on a thread-pool worker; the runningWaitForExitAsyncin the runner observes the exit cleanly. - Concurrent
ParseAsyncdeduplication. When multiple consumers (Home page tile scan, sync-progress watcher, etc.) requested the same log at the same time, they each opened the file and ran the regex sweep independently — up to 4× the I/O and CPU on a busy IME log. Now coalesced through an in-flightConcurrentDictionary: the first caller does the work, the rest await the same Task. - WindowStateService.Save is atomic. Previously a crash mid-write left a truncated
window-state.jsonthat threwJsonExceptionon every subsequent launch. Now writes towindow-state.json.tmpfirst and usesFile.Move(overwrite: true)for the swap — an interrupted save leaves either the old good file or the orphan tmp, never a corrupt one. - pwsh.exe lookup skips MS Store aliases. Both
EtlConversionServiceandTroubleshooterRunnerwalk PATH forpwsh.exe.%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exeis a zero-byte App Execution Alias thatFile.Existsreports as a real file butProcess.StartwithUseShellExecute=falsecan't launch — making EnsureWindowsUpdateLog and several troubleshooters silently fail. The walks now skip the WindowsApps directory and reject any zero-/tiny-byte stub. - Window minimum size is enforced at runtime. The initial-rect clamp prevented the window from opening too small, but the user could still drag it down to 1×1 once running, breaking the NavView layout.
OverlappedPresenter.PreferredMinimumWidth/Heightare now set to 800×600 in DPI-scaled physical pixels.
- UserGuidesPage URL-launch hardened. Previously fell back to
cmd.exe /c start "" "{topic.DeepLinkUrl}"ifLaunchUriAsyncreturned false — a string-concatenated argument that would be a command-injection sink if a future catalog entry contained"in its URL. Now validates host (pages.netlogicmy365.comonly) and scheme (http(s)only) before launch, and the cmd.exe fallback is removed entirely. - PDBs no longer ship in the MSI. Release builds now embed debug info into the assembly itself (
<DebugType>embedded</DebugType>) so stack traces stay useful, but the side-by-side.pdbfiles (which leaked the developer's source paths likeC:\Claude Code\My365 Log Reader\…and bloated the MSI by several MB) are no longer produced. The harvester also defensively skips.pdband.xmlfiles in case a future transitive package drops one. - x86 dropped from build matrix. The csproj listed
win-x86in its RuntimeIdentifiers, but the installer pipeline only validates arm64+x64. A straydotnet publish -r win-x86would have produced a silently-broken build. The platform list is now arm64+x64 only.
- Mixed-encoding log fixed. The PS5.1 relauncher path's
Add-Contentcalls had no-Encoding, defaulting to the system ANSI codepage; the PS7 body wrote UTF-8. The sameMy365-AppUpdateRemediate.logfile ended up with two different encodings, garbling non-ASCII characters. All log writes now explicitly use-Encoding UTF8. - Adobe Acrobat Pro no longer killed when updating Reader. The pre-update process kill list for
Adobe.Acrobat.Reader.*containedAcrobat(the executable name for the paid Acrobat Pro/Standard product, NOT Reader). Updating Reader on a device that also had Acrobat Pro installed would silently terminate the user's Acrobat Pro session and any unsaved PDFs. The list is now Reader-only (AcroRd32,AdobeARM,AcroBroker,Reader_sl,AcroCEF,RdrCEF). - Self-relaunch loop guard. If the PS7 detection failed in a child for any reason (corrupted pwsh install, surreal version skew), the relauncher would re-invoke itself indefinitely. An
$env:MY365_PS7_RELAUNCHEDsentinel now caps the relaunch at one attempt; a second failure logs and exits cleanly.
- Two follow-up bugs in the Update apps WinGet remediation script (introduced by v1.0.0.9's engine self-recovery work) are fixed:
Repair-WinGetPackageManager -Forcewas rejected with "A parameter cannot be found that matches parameter name 'Force'." The cmdlet's documented parameters are-AllUsers,-Latest,-Confirm, and-WhatIf— there is no-Force. The bad flag made Repair a no-op every run, so the stale Engine assembly that triggered the original 0x80131534 type-init failure was never refreshed.-Forcehas been removed.- The CLI fallback misreported "winget.exe not found" after winget ran successfully but found 0 upgrades. PowerShell's pipeline unwraps an empty array (
@()) returned from a function into$nullon the receiving side, and the caller'sif ($null -eq $cliPackages)check then treated "winget ran fine, no upgrades" as "winget unavailable" and bailed out.Get-UpgradablePackagesViaClinow returns a hashtable (@{ WinGetAvailable; Packages; ExitCode; Diagnostic }) so callers can distinguish the two cases without relying on PowerShell's quirky array semantics.
- Better diagnostics in the CLI fallback path: the script now logs the resolved
winget.exepath, its exit code, any stderr output, and the first 500 characters of stdout if the upgrade table can't be parsed. Future bug reports get actionable detail inC:\My365 Logs\App Updates\My365-AppUpdateRemediate.loginstead of an opaque "no upgrades reported" line. - "winget ran fine and reports 0 upgrades" is now correctly treated as success (the standard "all apps up to date" message), not as a CLI failure.
- Why isn't
My365-AppUpdateDetection.logbeing modified when I click Update apps? It's working as designed. The detection script is for Intune Proactive Remediations' scheduled run pattern, where Intune calls detection first and only invokes remediation if detection returns a non-zero exit code. The in-app Update apps button is a direct user action, so it skips detection and runs remediation immediately — there's nothing to detect when the user has explicitly asked for an update. Detection still runs on the Intune side via Proactive Remediations on the schedule IT configured.
- The Last Intune sync tile on the Overview page now reflects every sync source — not just syncs triggered from the in-app Sync with Intune button. Previous builds only watched the Intune Management Extension log for ‟End app check in” entries, so a Settings → Access work or school → Sync click, the automatic 8-hour OMA-DM push schedule, or a Company Portal sync wouldn’t bump the time. Users would see a stale value (sometimes 2–3 days old) even though Settings showed a recent successful sync.
- A new IntuneSyncHistoryService aggregates the three authoritative Windows sources for sync timing and returns the most recent across all of them:
- MDM scheduled-task LastRunTime under
\Microsoft\Windows\EnterpriseMgmt\<EnrollmentID>\. The OS updates this every time it kicks off an OMA-DM session — the Settings UI, the 8-hour push schedule, Company Portal, and our app's MDM trigger all hit it. Read directly via the Task Scheduler 2.0 COM API (no admin needed, ~50 ms). - DeviceManagement-Enterprise-Diagnostics-Provider/Admin event log, Event IDs 209 (session started) and 211 (completed successfully). Same data as the scheduled tasks but with explicit success/failure semantics.
- IntuneManagementExtension.log "End app check in" entries — the existing IME app/script check-in marker. Still consulted so syncs triggered through the IME side path (in-app button, Company Portal) are caught even on devices where MDM and IME ran out of step.
- MDM scheduled-task LastRunTime under
- Each source is read concurrently and any individual failure is silently skipped, so a missing event-log channel or an unenrolled device still gets a useful answer from whichever source is available.
- Update apps now self-recovers when the WinGet COM engine fails to load. Some devices were hitting “Could not load file or assembly 'Microsoft.WinGet.Client.Engine, Version=1.21.0.0…'. Uncaught exception during type initialization. (0x80131534)” on the very first
Get-WinGetPackagecall — Microsoft pushes new App Installer / Engine assembly versions out-of-band and a stale combination breaks the PowerShell cmdlets until they’re refreshed. - The bundled remediation script now applies the documented Microsoft fix on every run:
Repair-WinGetPackageManager -Force -Latest -AllUsersis invoked in a childpwsh.exeprocess before the first package query, so a sticky in-process type-init failure can’t poison the parent AppDomain. App Installer + Engine are pulled current on every run, not just first install. - If the COM engine is still broken after Repair (very rare — usually means Microsoft.WinGet.Client itself needs reinstalling), the script now transparently falls back to
winget.exeCLI for the entire run. The CLI is a self-contained executable that doesn’t go through the broken Engine assembly, so updates still apply. The log makes it clear which path was used. - Better diagnostics: when the COM engine error is detected, the script logs the exact exception, notes that Repair already ran, and explains what to check if the next remediation still hits the same error (typically: PowerShell 7 needs reinstalling, or the Microsoft.WinGet.Client module needs a forced reinstall under
-AllUsersscope).
- Added an Update apps quick-action button to the Overview page (between Check for Windows updates and Restart PC). Click it and Windows asks for administrator permission, then the same WinGet remediation script your IT department deploys through Intune runs in an elevated console window — bootstraps the
Microsoft.WinGet.Clientmodule on first use, then walks every WinGet-managed app and updates anything with a newer version. Office, Teams, and Edge are intentionally skipped (managed elsewhere). - Each app update has a 15-minute hard timeout and Adobe Acrobat Reader is routed through
winget.exeCLI directly because the COM cmdlets are unreliable for that package. Live progress is logged every 5 minutes during long updates. Full log:C:\My365 Logs\App Updates\My365-AppUpdateRemediate.log. - The same action is also available as a troubleshooter on the Troubleshooters page under the Windows category, so users who arrive there directly can find it too.
- PowerShell 7 (
pwsh.exe) must be installed — typically deployed via the Microsoft Store on managed devices. The bundled script self-detects PS5.1 and self-relaunches under PS7, so as long aspwsh.exeexists somewhere reasonable, the action works. - Administrator permission. Windows shows the standard UAC prompt when you click Update apps.
- The Logs that need attention tile on the Overview page is now clickable. Selecting it jumps to the Logs page filtered to the same set — only files flagged with errors or warnings — so you can drill in immediately. The Logs page also gained a matching Needs attention filter chip for the same workflow when you're already on that page.
- Added a new Intune & sign-in chip to the Troubleshooters page with four Microsoft-documented end-user diagnostics:
- Generate MDM diagnostic report — runs
mdmdiagnosticstool.exewith the DeviceEnrollment / DeviceProvisioning / Autopilot data areas and produces a single zip in%PUBLIC%\Documents\MDMDiagReport.zip. File Explorer opens with the zip selected so you can attach it to an IT ticket. - Show Microsoft Entra join status — runs
dsregcmd /statusand shows whether your PC is properly Entra-joined, whether you have a valid Primary Refresh Token (PRT) for SSO, whether Windows Hello prerequisites are met, and the results of internal connectivity tests. Read-only; the output is exactly what IT typically asks for when troubleshooting sign-in issues. - Refresh Microsoft Entra device registration (admin) — runs
dsregcmd /forcerecoveryto repair sign-in tokens. Use this when single sign-on stops working or Conditional Access is blocking access to a resource it shouldn't. - Force Group Policy refresh (admin) — runs
gpupdate /forceto apply newly-deployed policies without waiting for the 90–120 minute background refresh.
- Generate MDM diagnostic report — runs
- Added two more under Windows system:
- Reset Microsoft Store cache — runs
wsreset.exefor stuck app updates and "something happened" Store errors. - Restart Print Spooler service (admin) — stops the Spooler, clears stuck print jobs from the queue, and restarts the service.
- Reset Microsoft Store cache — runs
- Restored every navigation-rail icon. Previous builds shipped with empty
Glyph=""attributes throughout the XAML, which made the rail items invisible when the rail was collapsed. Every page (Overview, Logs, Troubleshooters, User Guides, Settings, About) now has its proper Segoe Fluent Icon, plus the date filter, severity chips on the log viewer, status icons in the troubleshooter dialog, action icons in the chat panel, and section headers across Settings, Troubleshooters, and User Guides.
- The About page now has a View user guide button that opens this guide in your default browser. The button is right under the version number so it's easy to find when you're already checking which build you're on.
- The About page now reads the version from the running assembly so it always matches the installed MSI — earlier builds had a hardcoded "1.0.0" string that didn't track upgrades.
- This What's new section was added to the user guide. Future releases will be documented here.
- The user guide HTML was reviewed and tested for Chromium-based browsers (Edge / Chrome 146 and later). Navigation links, accordion behavior, theme toggle, keyboard arrow-key navigation, and the URL hash deep-linking all behave correctly. Embedded base64 screenshots load instantly with no external requests.
- Bigger default window size — the app now opens at 1480 × 940 (logical pixels) instead of 1280 × 820. The new default is centered on your primary display and clamped to fit smaller screens automatically.
- Window state remembered across launches — the app saves your window size, position, and maximized state to
%LOCALAPPDATA%\My365LogReader\window-state.jsonwhen you close it, and restores them on the next launch. If you docked at home and now you're on the laptop alone, the saved position is clamped to the visible display so the window can't open off-screen.
- Sync with Intune — improved Company Portal URI handling so newer Store-distributed CP versions auto-trigger sync on launch. On older CP (typically deployed on x64 fleets), the URI just opens CP to the Sync settings page; the InfoBar now tells you to click Sync there manually if needed.
- "Sync via Settings" action button is now always available after a sync, not just on timeout — that path uses Settings → Access work or school and works on every CP version.
- Auto-discovery and plain-English translation of 14 categories of Windows / Microsoft 365 diagnostic logs (Intune, My365, MDM, CBS, Windows Update, OneDrive, Office, Defender, Edge).
- Three quick-action buttons on the home page: Sync with Intune, Check for Windows updates, Restart PC.
- 19 official Microsoft troubleshooters in 8 categories — Office activation, Office repair, Outlook (Classic + new), Teams (Classic + new), OneDrive, Windows system (SFC, DISM, Windows Update reset), and networking (full network reset, DNS flush).
- Bundled User Guides page with 146 topics from the Netlogic My365 Windows 11 guide, deep-linked into the published page.
- Global date filter (Today / Last 7 days / Last 30 days / Custom) shared across every view.
- Light / Dark theme support that follows the system theme by default.
How updates are delivered
Your IT department deploys this app through Microsoft Intune. When a new version ships:
- IT uploads the new MSI to Intune (the existing app entry is updated, not a new entry created).
- Your PC syncs with Intune on its normal schedule — usually within a few hours, sooner if you click the Sync with Intune button on the home page.
- The MSI installs over the previous version automatically. Your settings (theme, window size, last filter selection) are preserved across the upgrade — they live in
%LOCALAPPDATA%\My365LogReader\, which the upgrade leaves untouched. - Open the app and check the About page to confirm the new version number.
Reporting an issue
If you hit a bug after an update, attach three things when you file an IT ticket:
- The version shown on the About page.
- The contents of
%LOCALAPPDATA%\My365LogReader\diag.log— the app's own breadcrumb log, capped at 512 KB and rolled automatically. - A screenshot of whatever the app was showing when the issue happened.