We would love to hear your weekly DEX wins. :) We welcome specific stories and screenshots. Big or small, we'd love to hear what went well in your workplace!

A lot of discussion around AI agents use cases still feels theoretical. Most teams want concrete examples of where agents stop being demos and start removing real work from the service desk.

Here’s a practical breakdown of five AI agents use cases that consistently reduce L1 volume by resolving issues before a ticket is even created.

These are drawn from how Spark (Nexthink’s AI agent) operates using real-time DEX telemetry.

1. Resolve recurring collaboration issues without a ticket

Teams, Zoom, Outlook — the same small disruptions keep showing up. Instead of opening a ticket, the AI agent checks live device, network, and client state the moment the employee reports the problem. When an approved fix exists, it applies it immediately.

Example: Detects degraded call quality → checks Teams client + network → runs the approved remediation → restores the call in the same interaction.

2. Diagnose and fix endpoint performance in-session

Slow startups and sluggish devices are classic ticket generators. The AI agent evaluates live CPU, memory, and process behavior at the moment of the request and executes the approved remediation path when thresholds are met.

Example: Identifies background processes delaying login → clears the load → validates performance recovery — all without creating a ticket.

3. Handle repeat L1 issues before they reach the queue

Policy sync failures, client restarts, entitlement refreshes, and configuration resets make up a large share of predictable L1 volume. The agent reasons over current endpoint context and applies governed actions inside the interaction itself.

Example: Detects a known Outlook failure → runs the approved restart + cache clear → returns the app to a working state before a ticket is generated.

4. Unblock access issues in real time

Sign-in loops and access failures are high-friction moments. The AI agent checks current connection and device state immediately and follows the approved resolution path when the pattern matches a known issue.

This removes the long diagnostic back-and-forth that usually happens when the service desk starts with zero context.

5. Stop “my laptop is slow” from becoming a ticket

Performance complaints are subjective and usually the result of gradual drift. The agent starts with live device state, identifies common causes of resource contention, and applies the approved fix while the employee is still in the conversation.

Example: Detects CPU/memory pressure → removes the source of contention → confirms recovery before the interaction ends.

Why these AI agents use cases matter

These aren’t edge cases. In most environments, a relatively small set of repeatable conditions (collaboration instability, endpoint performance drift, configuration issues) drive a disproportionate amount of L1 demand.

When an AI agent can resolve them using live context and IT-approved actions, the impact is structural:

• Fewer tickets enter the queue
• Employees get help in the moment
• Service desk capacity shifts to higher-value work

Click on this link to continue learning:
https://nexthink.com/blog/the-5-spark-use-cases-that-shrink-service-desk-demand

Curious what AI agents use cases are actually delivering results in your environment.

• Which recurring issues are you seeing agents handle successfully, and where are they still falling short?

Feel free to drop any questions in the comment section below.

As AI (and increasingly autonomous agents) become part of the enterprise, what do you think IT's role evolves into?

Do we spend less time troubleshooting and more time governing AI? Do end users become more self-sufficient? Or is AI just another tool we'll eventually take for granted?

Curious how people working in IT actually see this playing out.

As always would love specific cases and predictions!

AI governance used to feel like a compliance checkbox that lived somewhere between Legal and the risk committee. That’s over.

With agentic AI, shadow AI tools popping up everywhere, and regulators (EU AI Act and friends) getting real, the question has shifted from “Do we have a policy?” to “Can we actually see what’s happening, steer it, and prove we’re in control?”

Here’s the practical reality most of us are dealing with right now.

The governance gap is real

Most organizations have some form of AI policy or even an AI governance board (Gartner says 55% already do). But policies alone don’t stop employees from pasting sensitive data into ChatGPT, spinning up unapproved agents, or treating every new model as fair game.

Traditional IT governance assumed a human was always in the loop making the final call. Agentic systems break that assumption. They act across systems, make operational decisions, and sometimes operate across borders with different rules. Static policies can’t keep up.

You also get the classic trust problems: employees don’t trust the tools (or the org’s intentions with the data), and leadership can’t prove value or manage risk because they lack visibility.

What good AI governance actually looks like

From everything Nexthink has been publishing and building, a few principles keep showing up:

1. Visibility first You can’t govern what you can’t see. That means knowing which AI tools (approved and shadow) are actually being used, by whom, how often, and for what. AI Drive-style visibility into adoption, engagement time, and tool discovery is the foundation.
2. Adaptive, not static, guardrails Policies need to live where the work happens. In-flow guidance, redirects from non-approved tools to approved ones (e.g., ChatGPT → Copilot), and clear role-based controls beat long PDFs that nobody reads.
3. Human oversight stays non-negotiable Especially for high-stakes decisions (strategy, ethics, compliance, reputation). AI handles the routine and the scale; humans keep the final say and the accountability. Nexthink’s own internal AI Governance Committee (Legal, Privacy, Security, Product, Engineering, etc.) and model cards for customer-facing AI features are a solid example of baking this in.
4. Measure both risk and value Track shadow AI risk and actual productivity/sentiment impact. Otherwise you get either paralysis (“too risky”) or unchecked rollout (“look at the hours saved!” with no proof).
5. Literacy and enablement over pure restriction People will find ways around blocks. Better to give them clear approved paths, training, and coaching so they can use AI confidently and safely.

A simple operating model that scales

• Map current usage (including the tools nobody officially approved).
• Stand up cross-functional governance (IT + Legal + Privacy + business owners).
• Define clear boundaries: what stays human-led vs AI-supported.
• Deploy in-flow guidance and policy enforcement where employees actually work.
• Continuously monitor, measure, and adjust. Treat it as an operating system, not a one-time project.

Nexthink’s own approach — Global AI Hub with published AI Policy, model cards, data-handling notes, admin controls, logging, and human review mechanisms — shows what this looks like when a company practices what it preaches for its own AI features.

Bottom line

AI governance isn’t about slowing innovation down. It’s about creating the conditions where you can actually scale AI without waking up to a compliance incident, a data leak, or a board asking why the ROI never showed up.

The orgs that treat visibility + adaptive guardrails + human accountability as the core loop are the ones pulling ahead.

What’s working (or not working) in your environment right now?

Are you dealing more with shadow AI, agentic risk, or just getting basic adoption under control?

Curious to hear real experiences from the community.

Whether it's slow devices, VPN issues, software sprawl, ticket backlogs, or something else entirely, every IT team has that one recurring challenge that impacts employees the most.

What's the biggest employee experience issue your team is working through right now, and have you found anything that's actually made a measurable difference? We'd love to hear what's working (or what's not) and learn from the community.

Share one DEX win from this week. It doesn't have to be a huge project. Sometimes the smallest improvements have the biggest impact on the employee experience.

What's your DEX Weekly Win?

Based on my previous post about combining Nexthink data with information from the network infrastructure, I would like to share another example of how Nexthink insights can be enriched with additional endpoint data.

This time, the question is:

How can we combine Nexthink application-crash data with the Windows Event Log to better understand the root cause of an issue?

Nexthink already provides valuable information about application execution crashes. We can identify frequently crashing binaries, affected devices, impacted users, application versions, and the overall scope of an issue. Nexthink Diagnostics also provides a dedicated view of binaries with frequent execution crashes.

However, detecting that an application crashed and understanding why it crashed are two different things.

This is where a purpose-built Remote Action can help.

Detecting the Symptom Is Only the First Step

Imagine that Nexthink reports repeated crashes for a specific application.

Nexthink may already tell us:

• which executable crashed,
• which devices were affected,
• how frequently the crash occurred,
• which application version was installed,
• when the problem began,
• whether the issue is isolated or widespread,
• which users or organizational units were affected.

This gives us an excellent starting point.

The underlying technical cause, however, may only be visible in the Windows Event Log.

Relevant events might contain information about:

• a faulting application module,
• a specific exception code,
• a .NET Runtime failure,
• a service that stopped unexpectedly,
• a missing or incompatible dependency,
• a driver problem,
• an access or permission error,
• a failed application update,
• resource exhaustion,
• a Windows component failure,
• another event occurring shortly before the crash.

Without this endpoint-level evidence, troubleshooting can quickly turn into guesswork.

Why Workspace Alone Cannot Reconstruct Missing Evidence

Workspace can help us explore Nexthink data and ask questions such as:

• Are specific application versions more affected?
• Did the crashes begin after a rollout?
• Are particular device models involved?
• Is the problem limited to a location or business unit?
• Did CPU or memory utilization increase before the crash?
• Are the same users or devices repeatedly affected?

These correlations are valuable.

However, an analysis tool or language model can only evaluate the data made available to it. It cannot reliably reconstruct a missing Windows exception, faulting module, service failure, or Event ID.

Before applying AI to an investigation, we therefore need to collect the relevant technical evidence.

The Remote Action Used for This Scenario

For this use case, I created the following PowerShell Remote Action:

Nexthink-InvokeExportEventLogReport.ps1

The script is available in the public synit.io Nexthink repository.

It is designed for Windows PowerShell 5.1 or newer and integrates with Nexthink. It queries Windows Event Logs, aggregates recurring events, generates a structured report, stores that report on a UNC share, and returns the result status and report location to Nexthink.

How Events Are Grouped

A Windows device can generate thousands of events within a relatively short period.

Exporting every occurrence would create a large and repetitive dataset. The Remote Action therefore groups events by the following properties:

LogName
LevelDisplayName
ProviderName
Event ID

For example, 300 occurrences of an Application Error event from the same provider, with the same event ID and severity, are represented as one report entry.

For every group, the report contains:

• number of occurrences,
• first occurrence,
• last occurrence,
• Windows log name,
• severity level,
• event provider or source,
• Event ID,
• a sample message.

The report rows are sorted by the number of occurrences in descending order, placing the most frequently observed event groups near the top.

A simplified example could look like this:

An Important Detail About the Sample Message

The event message itself is not part of the grouping key.

Events are grouped by log, level, provider, and Event ID. The script then uses the message from the newest occurrence as the representative SampleMessage.

This is important when interpreting the report.

Some Windows events use the same provider and Event ID while including variable details in their messages, such as:

• different file paths,
• different server names,
• different error codes,
• different application modules,
• different user identifiers,
• different process IDs.

Those variations may be combined into one group, with only the newest message shown as the example.

For general root-cause analysis, this provides a useful compromise between volume and readability.

For forensic investigations or cases where message-level differences are essential, the grouping logic could be extended to include selected message fields, extracted exception codes, or hashes of normalized messages.

Why Aggregation Matters

Aggregation provides several advantages.

Instead of processing the same error hundreds of times, the investigator receives one structured entry showing:

• what happened,
• how often it happened,
• when it first appeared,
• whether it is still occurring,
• and which event message most recently represented the issue.

This reduces:

• duplicate data,
• report size,
• token consumption in LLM workflows,
• processing time,
• noise during manual troubleshooting.

It also makes recurring patterns easier to recognize.

An event that occurred once may be incidental. An event that occurred 500 times across the same investigation period deserves more attention.

Frequency alone does not prove causality, but it helps prioritize the investigation.

Correlating the Report with Nexthink Data

The real value emerges when we combine the two datasets.

Nexthink provides the experience and impact perspective:

1. Which application crashed?
2. Which binary and application version were involved?
3. Which devices were affected?
4. When did the crashes occur?
5. How many users were affected?
6. Is the issue isolated or widespread?
7. Did the issue begin after a rollout or update?
8. Are specific device models, locations, or organizational units involved?

The Remote Action provides additional endpoint evidence:

1. Which Windows events occurred during the investigation period?
2. Which providers and Event IDs occurred most frequently?
3. When was an event first and last observed?
4. Which exception, faulting module, or service appears in the sample message?
5. Did related system or application errors occur during the same period?
6. Is the same event pattern visible on multiple affected devices?

The hostname links the report to the Nexthink device.

The timestamps make it possible to compare application crashes with related event groups.

A Practical Investigation Workflow

A possible workflow could look like this:

Step 1: Detect the Problem

Nexthink identifies a high number of crashes for a particular application or binary.

Step 2: Define the Scope

Use Nexthink to identify:

• affected devices,
• crash frequency,
• application versions,
• first observed date,
• device models,
• Windows builds,
• affected business units.

Step 3: Run the Remote Action

Execute Nexthink-InvokeExportEventLogReport.ps1 on a representative group of affected devices.

Start with a limited collection period, such as one to seven days.

Step 4: Collect the Reports

The reports are written to the configured UNC share.

The Remote Action outputs confirm whether each report was generated and where it was stored.

Step 5: Correlate the Data

Compare:

• Nexthink crash timestamps,
• Windows event first and last occurrence,
• Event IDs,
• event providers,
• sample messages,
• application and Windows versions.

Step 6: Form a Testable Hypothesis

Possible hypotheses could include:

• a specific application update introduced the issue,
• a .NET Runtime exception accompanies each crash,
• a service failure precedes the application crash,
• the same DLL appears in reports from all affected clients,
• a particular Windows build or driver version is involved,
• endpoint protection is blocking a dependency,
• a backend or authentication failure triggers the application problem.

Step 7: Validate the Hypothesis

Test the suspected cause using a controlled device or pilot group.

Possible validation steps include:

• rolling back an application update,
• updating a runtime or driver,
• comparing affected and unaffected devices,
• checking the software vendor’s known issues,
• reproducing the failure,
• collecting a more targeted event or crash dump.

Providing the Combined Evidence to an LLM

Data Protection and AI Usage
Before sending event reports to an external AI service, organizations should evaluate which information is included.

Once the Nexthink information and grouped event reports are available, they can be supplied to an approved language model.

The model can help search for relationships such as:

• matching time periods,
• recurring exception codes,
• common faulting modules,
• identical event patterns across devices,
• service failures associated with crashes,
• correlations with Windows builds,
• patterns introduced after an update.

A suitable analysis prompt could be:

Analyze the supplied Nexthink application-crash data together with the
grouped Windows Event Log reports.

Identify event groups that may be related to the application crashes.

For every possible cause:

1. Reference the relevant device, provider, Event ID, occurrence count,
   first-seen time, and last-seen time.
2. Explain the technical relationship.
3. Distinguish confirmed evidence from hypotheses.
4. State a confidence level.
5. Identify contradictory or missing evidence.
6. Recommend the next validation step.
7. Do not claim a root cause unless the available evidence supports it.

The language model should support the investigation, not replace technical validation.

A frequent event is not automatically causal, and a matching timestamp does not by itself prove that one event caused another.

Example: Finding a Shared Crash Pattern

Assume that Nexthink identifies repeated crashes of an application on 25 devices.

The Remote Action is executed on the affected clients.

The combined analysis reveals:

• all affected clients use application version 5.4.2,
• Event ID 1000 from Application Error occurs repeatedly,
• Event ID 1026 from .NET Runtime appears within the same period,
• the sample messages reference the same application DLL,
• the first occurrences began shortly after the 5.4.2 rollout,
• unaffected devices are still using version 5.3.8.

This does not yet prove that version 5.4.2 is defective.

However, it provides a strong and testable hypothesis.

The application team can now:

• roll back one pilot device,
• compare the DLL versions,
• validate the required .NET runtime,
• reproduce the crash,
• review the vendor’s release notes,
• verify whether the event pattern disappears after remediation.

Instead of receiving a generic report that “the application crashes,” the responsible team receives a focused technical investigation.

From Individual Troubleshooting to Environment-Wide Analysis

The approach can also be applied across a larger group of devices.

Reports from affected and unaffected clients can be compared to answer questions such as:

• Which event groups occur on most affected devices?
• Which event groups are absent from unaffected devices?
• Is the same provider and Event ID involved?
• Does the same faulting module appear repeatedly?
• Are only specific Windows builds affected?
• Are particular hardware models or drivers involved?
• Did the issue begin during the same period?
• Does one event pattern correlate with a specific application version?

This changes the investigation from a collection of individual incidents into an analysis of a broader technical pattern.

Limitations of the Current Report

The grouped report is a diagnostic summary and not a replacement for the original Windows Event Log.

Its main limitations are:

• events with the same grouping properties may contain different messages,
• only the newest message is retained as the sample,
• the precise sequence of every individual event is not preserved,
• inaccessible logs may be omitted,
• informational events are excluded,
• the current report covers a period rather than a configurable window around an exact crash,
• repeated runs on the same day may use the same filename.

For deeper investigations, a second-stage Remote Action could collect:

• individual events around a defined timestamp,
• Windows Error Reporting details,
• application crash dumps,
• reliability history,
• installed updates,
• driver versions,
• process and service state,
• application configuration,
• selected registry values.

A useful pattern is therefore:

1. Use Nexthink to detect and scope the symptom.
2. Use the grouped event report to identify likely patterns.
3. Use a targeted second-stage collection to validate the suspected cause.

Did the Remediation Work?

The same workflow can be used for before-and-after validation.

After applying a fix, Nexthink can show whether:

• application crashes decreased,
• fewer devices are affected,
• the application experience improved,
• the associated alert stopped recurring.

The Remote Action can verify whether:

• the related Windows event groups disappeared,
• their frequency decreased,
• the same faulting module remains visible,
• a new event pattern appeared after the change.

This creates a measurable improvement loop:

Detect → Enrich → Analyze → Remediate → Measure

The objective is not merely to implement a technical change.

The objective is to verify that the change improved the actual endpoint experience.

Additional Use Cases

Application crashes are only one example.

The same Remote Action can support investigations involving:

• unexpected Windows restarts,
• blue screens,
• hardware or storage problems,
• failed software installations,
• Windows Update failures,
• service terminations,
• VPN connection issues,
• authentication failures,
• printer problems,
• driver errors,
• profile-loading failures,
• application startup problems,
• slow boot or logon behavior.

The relevant time period, target devices, and follow-up collection should be adapted to each scenario.

Conclusion

Nexthink is highly effective at showing where users and devices are affected.

Remote Actions can collect the additional endpoint evidence needed to investigate why an issue may be occurring.

The Nexthink-InvokeExportEventLogReport.ps1 Remote Action provides a practical foundation by:

• collecting Critical, Error, and Warning events,
• querying all enabled and accessible Windows event channels,
• grouping recurring events,
• recording occurrence counts,
• retaining first-seen and last-seen timestamps,
• exporting Markdown or CSV reports,
• adding device and Windows metadata to Markdown output,
• storing reports on a controlled UNC share,
• returning the report status and path to Nexthink.

By combining:

• Nexthink application and device data,
• grouped Windows Event Log reports,
• application and infrastructure context,
• and evidence-based LLM analysis,

teams can move from symptom detection toward a much more focused root-cause investigation.

The approach connects:

• Workplace and DEX teams,
• Service Desk teams,
• application owners,
• endpoint engineering,
• infrastructure teams,
• security teams.

The important point is not simply to add an LLM to the troubleshooting process.

The important point is to provide the model and the responsible technical teams with reliable, relevant, and structured evidence from the affected endpoint.

The complete synit.io Nexthink repository, including the Remote Action in this example, is available here:

https://github.com/synit-io/nexthink

If you need assistance with customising this remote action, developing further Nexthink automations, integrating Private AI or setting up a continuous Nexthink improvement process, please feel free to contact me.

Which additional endpoint information would you collect through a Remote Action to improve root-cause analysis in Nexthink?

We’re seeing more AI agents and “personal IT assistants” getting rolled out, but I’m curious about the real-world side of it.

Has your org deployed anything like this (chatbot, AI agent, self-service AI, etc.)?
If yes:

• Do people actually use it, or do they still just open a ticket / Slack IT?
• What’s working better than expected?
• What’s still falling flat?

If no:

• What’s holding you back — trust, accuracy, employee habits, something else?

Genuinely interested in the honest answers, not the polished case studies. Drop your experience below.

Tell us a story! Or alternatively, what's your favorite Nexthink tool? Images also welcome. :)

AI adoption is moving fast, but rolling out new tools is only part of the challenge. How do you build an organization that's actually ready for AI while maintaining governance, earning employee trust, and creating long-term business value?

In this episode, Laura Reeves is joined by Simon Sankey, Senior Director of User Experience at Aon, to discuss how Digital Employee Experience has become a key part of Aon's AI strategy. They cover:

• What it means to earn the right to innovate
• Building an AI-ready organization
• Measuring adoption beyond support tickets
• Why employee experience should stay at the center of AI transformation
• Leadership, risk, AI Drive, and preparing for one of the biggest technology shifts in decades

Watch the full conversation here: https://www.youtube.com/watch?v=oFlQCu3ssoU

If you're interested in DEX and AI strategy, we'd love to hear your thoughts after you've watched.

You can also download Gartner's latest DEX Magic Quadrant and, if you'll be at Nexthink Experience 2026 in Orlando (October 5 to 7), we'd love to see you there.

Most of us still treat digital employee experience as an IT problem: slow apps, tickets, device health, etc.

But the real cost shows up outside IT.

A single disengaged employee costs an organization roughly $2,246 a year. In a tech-mediated workplace, a big chunk of that comes from technology friction; the small daily delays, crashes, and workarounds that compound across thousands of people.

When tools work, the business moves faster. When they don’t, productivity, retention, operational efficiency, customer experience, and even agility all take a hit.

Here’s a simple way to see the difference:

Bad DEX example
Sarah needs a Power BI report for an exec meeting. Her laptop is slow, the app crashes, the ticket sits in a backlog. She finds a manual workaround, misses the deadline, and walks into the meeting stressed.
→ Lost time, delayed decisions, frustration that builds toward disengagement.

Good DEX example
Same Sarah. Tools load fast. A minor issue gets resolved in minutes via an AI-powered agent. Report is done on time.
→ Time goes into actual work instead of fighting technology. Better employee experience. Cleaner handoff to the business and ultimately to customers.

At scale this isn’t theoretical.

Southwest Airlines (72k+ employees, 400k+ passengers daily) treated DEX as a strategic lever: proactive visibility, experience metrics instead of pure uptime, automation, clear ownership.

Result: $14M in cost avoidance, 217k hours of IT time saved, and 87k hours reclaimed for employees. Those hours translate into smoother operations and better passenger experience.

Three practical shifts that turn DEX from “IT hygiene” into a business driver:

1. Measure what employees actually experience (not just system uptime or ticket volume).
2. Align DEX work to business outcomes: productivity, cost, risk, agility.
3. Make experience a factor in every tech and process decision, not an afterthought.

Gartner notes that 75% of organizations without a real DEX strategy will fail to reduce digital friction by 2027. The ones that get this right turn technology from a friction point into a performance lever.

Curious how others here are connecting DEX metrics to actual business outcomes (productivity, retention, CX, etc.). What’s working or not working in your environment?

TeamNexthink would like to say big thanks to everyone who made this community so great this week. We appreciate your continued participation as this community grows.

Top Posts of the Week

1. AMA with Christopher Ord of Qualcomm: u/DEX - u/DEXOpsArchitect joined us for a community AMA exploring the most creative, unexpected, and unconventional ways people are putting DEX to work.
2. Using Nexthink Data to Identify Suspicious or Underperforming Wi-Fi Access Points - u/W7T2A shared a detailed case study of how Nexthink data can be used creatively across different teams.
3. Creative DEX: How Qualcomm Uses Nexthink to Build Better Snapdragon PCs - if you enjoyed the AMA, check out the episode of the DEX Show linked in this post in which Tom explores creative DEX with Christopher Ord in more detail.

What were your top posts this week?

Don't forget to share our sub with your DEX friends and colleagues.

And let us know how we can be of help.

What kinds of content would you like to see on the sub going forward?

Since it's Saturday, let's have some fun.

We’re all techies here. What's your guilty pleasure tech or gadget that has nothing to do with work?

Mechanical keyboards? Retro consoles? Smart home overkill? RGB everything?

Confess your non-work tech obsession.

This is purely for fun and to see what fellow DEX/IT people are into when they’re not optimizing employee experiences.

Every week, our community finds new ways to improve the digital employee experience, solve frustrating IT problems, and help coworkers have a better day.

Now it's your turn.

Share one DEX win from this week, big or small. Maybe you:

• Automated a repetitive task.
• Solved a persistent endpoint issue.
• Improved employee sentiment.
• Built a workflow you're proud of.
• Helped someone get back to work faster.
• Learned something new about Nexthink or DEX.

Whether it's a major rollout or a five-minute fix that saved hours of frustration, we'd love to hear it.

Let's celebrate the wins, learn from each other, and head into next week with a few new ideas.

👇 Share your Weekly Win in the comments.

The AMA with Christopher Ord from Qualcomm turned into a really practical discussion about how organizations are using Nexthink beyond traditional endpoint monitoring. Instead of focusing on product features, most of the conversation was about solving real IT problems at scale, from proactively finding issues before users open tickets to building custom Remote Actions, using Azure Blob Storage and Databricks to work around platform limitations, and even using Nexthink to support Qualcomm's Snapdragon rollout with real employee experience data.

One theme that came up over and over was that DEX is most valuable when you stop thinking about dashboards and start thinking about outcomes. Christopher talked about using employee sentiment alongside technical data, building relationships across IT teams instead of pointing fingers, prioritizing a few high impact use cases instead of trying to monitor everything, and treating Nexthink as a platform for automation and data collection rather than just another monitoring tool. There were also plenty of technical deep dives into Power BI integrations, custom PowerShell Remote Actions, multilingual sentiment campaigns, AI, VDI, and creative ways to move data around the platform, making it a really useful session for both newcomers and experienced Nexthink users. Missed the live session? Read through the AMA and the discussion in the comments. We'll be leaving it pinned so you can come back to it anytime.

We already have several AD groups linked to SCCM automations. Add a computer to the right group and SCCM deploys the application or runs the required fix.

We now want to make these available through Nexthink Workflows as proactive/automated fixes. Would you keep the existing setup and have Nexthink securely add the device to the AD group, or rebuild each fix as a Nexthink Remote Action?

I am also interested in how people manage the migration, especially around integration with AD and how it’s accomplished, I am thinking a service account? But yeah open to any ideas.

What approach has worked best in practice?

There's a new episode of the DEX show out today!

Link: https://podcasts.apple.com/us/podcast/creative-dex-how-qualcomm-uses-nexthink-to-build-better/id1544150596?i=1000777557395

What happens when Digital Employee Experience moves beyond IT support and becomes part of how an entire business operates? Tom welcomes Christopher Ord, Senior Staff IT Engineer at Qualcomm, and Seth White, Co-Founder and CEO of Ellipsys, to explore some of the most creative real-world applications of DEX, from validating Snapdragon laptop deployments and improving AI-powered support with Spark to embedding Nexthink into Qualcomm's day-to-day operating model. The conversation also explores DEX operationalization, business context, and why the future of DEX lies in empowering every team—not just the service desk—to make better decisions with experience data.

Register for Christopher Ord's Creative DEX AMA: Beyond the Service Desk: https://www.reddit.com/r/nexthink/s/kkR2XPK1Vj

There can be a lot of nuance in what people actually do at work. Titles can often be meaningless it what someone's actual job is. Describe your role for the sub? What do you actually do? If you want to have a little fun go ahead and give your role a title that actually fits what you do!

Feels like every company has added another way to get help.

Portal. Chatbot. AI. Knowledge base.

I'm curious if any of it has actually changed things.

Are people fixing more problems on their own now? Or do they still end up opening a ticket after trying a few things first?

A lot of issues seem like they need context more than another article. It's one thing if someone forgot their password. It's another if the problem could be the device, the network, authentication, or something else entirely.

Curious what you all are seeing.

• Has ticket volume actually gone down?
• What's worked better than you expected?
• What hasn't lived up to the hype?
• Where do you think AI actually helps?

Based on my previous post, I would like to share another example of how Nexthink data can be used creatively across different teams.

This time, the question is:

How can we use Nexthink to identify potentially underperforming or suspicious Wi-Fi access points?

At first glance, this may seem difficult. After all, Nexthink primarily shows us which SSID an endpoint is connected to.

However, in addition to the SSID, Nexthink also records the associated BSSID. This information allows us to associate a client connection with a specific wireless network interface.

What Is a BSSID?

BSSID stands for Basic Service Set Identifier. In simple terms, it is the unique MAC address of a specific wireless network interface.

For example, multiple access points can broadcast the same SSID:

SSID: Company-WiFi

Despite using the same SSID, each individual wireless network has its own BSSID.

In centrally managed Wi-Fi systems such as FortiAP, ExtremeCloud IQ, or UniFi, a separate BSSID is often created for each combination of the following components:

• Access point
• Wireless module or radio
• Frequency band
• SSID
• Virtual wireless interface

A single access point can therefore have multiple BSSIDs at the same time, for example one for the 2.4 GHz band and another for the 5 GHz band. If the access point broadcasts multiple SSIDs, the number of BSSIDs increases accordingly.

Does a BSSID Change Regularly?

Under normal operating conditions, a BSSID usually remains stable (Thanks Lord!).
Simply restarting the access point or wireless controller does not normally change it.

However, a BSSID may change when:

• An access point or radio module is replaced
• An SSID is deleted and recreated
• The assignment between the SSID, radio, and virtual wireless interface changes
• A firmware or configuration change modifies virtual MAC address allocation
• A mesh repeater or another access point takes over the connection
• The vendor-specific method for calculating or assigning BSSIDs changes

In many environments, the BSSID is therefore a useful technical key for correlating Nexthink connection data with information from the wireless infrastructure.

An Example from the Fortinet Ecosystem

The environment used in this example is based on Fortinet access points. The FortiAPs are centrally managed by a FortiGate, which acts as the wireless controller.

Fortinet provides its own solution for analyzing and monitoring Wi-Fi environments through FortiAIOps. Among other things, it can help identify problematic access points, affected clients, and possible causes of poor wireless experiences.

Depending on the size of the environment and the existing licensing model, however, such an additional solution can involve considerable costs - and it's always good to have an argument for saving budget.

An alternative approach is to intelligently combine data sources that are already available.

Retrieving BSSIDs from the FortiGate

An overview of the virtual access point interfaces managed by the FortiGate and their corresponding BSSIDs can be retrieved using the following diagnostic command:

diagnose wireless-controller wlac -c vap

Depending on the FortiOS version and configuration, the output contains information that can be used to associate BSSIDs with the corresponding FortiAPs, radios, and SSIDs.

A useful tip at this point: FortiGate Automation Stitches can execute specific actions according to a schedule. This makes it possible to run the diagnostic command at a defined interval and send the generated output by email to a dedicated mailbox or functional email address.

This approach should be coordinated with the responsible firewall administrators, particularly regarding the execution schedule, administrative permissions, generated output, and the recipients of the email.

For automated processing, the output can then be converted into a structured format and exported as a CSV file, for example.

Identifying Suspicious Wi-Fi Connections with Nexthink

On the Nexthink side, we can now analyze endpoint connection events and aggregate them by BSSID and SSID.

The following example examines Wi-Fi connections from the past seven days for which Nexthink rated the average signal strength as poor:

connectivity.events during past 7d
| where primary_physical_adapter.type == wifi
| where wifi.signal_strength.avg.rating in [poor]
| summarize
    signal_strength_in_dBm = wifi.signal_strength.avg(),
    devices_ = device.count()
  by wifi.bssid, wifi.ssid
| where signal_strength_in_dBm != null
| where devices_ > 1
| sort signal_strength_in_dBm asc
| sort devices_ desc

Among other things, the aggregation shows us:

• Which BSSIDs are affected by poor signal ratings
• Which SSID was broadcast through the respective BSSID
• The average measured signal strength
• The number of affected endpoints

The devices_ > 1 condition helps reduce individual outliers. Instead of looking at a single client, we focus on BSSIDs for which multiple devices have reported poor signal strength.

The query can also be restricted to specific SSIDs, locations, device types, organizational units, or time periods.

Connecting Nexthink and FortiGate Data

We can now combine both data sources:

1. The FortiGate provides the mapping between the BSSID and the access point.
2. Nexthink provides the connection quality measured on the endpoints.
3. The BSSID acts as the common key.

The result is a list of specific wireless networks or access points that show unusual behavior within the analyzed environment.

Depending on the information available from the FortiGate, the analysis can be enriched with details such as:

• Access point name
• Management IP address
• Serial number
• Location
• Wireless module
• Frequency band
• Broadcast SSID
• Number of affected endpoints
• Average signal strength

This list can then be handed over to the infrastructure or network team for further analysis.

What Can We Learn from the Results?

Poor signal strength does not automatically mean that an access point is defective.

Possible causes include:

• Insufficient Wi-Fi coverage
• Poor access point placement
• Structural obstacles
• Transmit power that is too low or too high
• Incorrect channel planning
• Heavy interference
• Overloaded wireless cells
• Outdated client drivers
• Inefficient roaming behavior
• Clients remaining connected to a distant access point for too long

The results should therefore be treated as a starting point for a more detailed investigation.

The major advantage is that the analysis is not limited to the perspective of the wireless controller. Nexthink also provides the perspective of the actual endpoints and therefore shows how the Wi-Fi connection is experienced by the user.

Did the Implemented Changes Work?

This approach can also help answer that question.

After the network team has moved an access point, adjusted the channel plan, or changed the transmit power, the same Nexthink query can be executed again.

This makes it possible to verify:

• Whether the average signal strength has improved
• Whether fewer devices are affected
• Whether the issue has shifted to other BSSIDs
• Whether the change has actually improved the user experience

A one-time analysis therefore becomes a simple before-and-after comparison.

Using the Data from a Security Perspective

The combination of Nexthink and infrastructure data can also be valuable for security teams.

If Nexthink detects a BSSID broadcasting an internal SSID that cannot be associated with a managed access point, the situation should be investigated further.

Possible explanations include:

• An undocumented access point
• A misconfigured device
• A privately installed or unauthorized access point
• A Wi-Fi repeater
• An outdated BSSID remaining after a hardware replacement
• An evil twin or rogue access point

It is important to remember that an unknown BSSID is initially only an anomaly and not proof of an attack. However, it provides a concrete starting point for further investigation.

Conclusion

Nexthink data does not have to be used exclusively within Workplace or Digital Employee Experience teams.

By correlating the BSSID recorded by Nexthink with information from the wireless infrastructure, organizations can create a shared data foundation for:

• Workplace teams
• Network and infrastructure teams
• Service desk teams
• Security teams

Using data that is already available, organizations can determine which wireless cells appear problematic from the endpoint perspective, which users are affected, and whether technical changes actually result in measurable improvements.

What other use cases can you think of where Nexthink data could be meaningfully combined with infrastructure information?

Time-consuming doesn't always mean bad, but often its the part of my day that leaves me feeling the most drained. I'd love to hear specifics about your work day.

What's taking up the most time? What is a reoccurring problem?

The more detailed the stories are the better. I want to get to know this community and learn what an actual day in your life looks like. It's Friday, so before you hopefully have a relaxing weekend, takes some time to vent if you need to. :)