Every backup thread ends with "an untested backup is not a backup," everyone upvotes, and then (in my experience) nobody has an automated restore test anywhere.

Genuinely curious about the state of practice:

1. Do you restore-test on a schedule, or only when something breaks / an audit demands it?
2. If you automated it, what did you build? (ephemeral instance? scripts like pgbackrest_auto? CI job?)
3. If you didn't, what stopped you? (time? nowhere safe to restore to? nobody asked?)
4. For those with SOC 2/ISO: did the audit change anything, or did you just produce a doc that says you test quarterly?

Trying to understand if this gap is real or if I just keep landing in teams that are bad at it.

When I looked at my phone when I was waking up:

>You requested that we alert you when the forecasted cost associated with your My Monthly Cost Budget budget exceeds $100.00 for the current month. The month forecasted cost associated with this budget is $183,965,812,157.54. You can find additional details below and by accessing the AWS Budgets dashboard.

By the time I disabled access to S3 & Cloudfront in my personal account, and opened a ticket, this finally started being displayed by AWS at https://support.console.aws.amazon.com/support/home?region=us-east-1#/

>Inaccurate Estimated Billing Data >Beginning on July 16 7:38 PM PDT, we began displaying incorrect estimated billing data in the Billing and Cost Management Console. > >For more information on this issue, please refer to the AWS Service Health Dashboard: https://health.aws.amazon.com/health/status

My boss is pulling me in to chat that apparently some staff have complained to them about not getting support or feeling supported. They feel put off when they are asked to reboot their device which 80% of the time fixes their problems.

My boss will also experience small hiccups that they interpret as IT issues, when a reboot again also solves their problem or they are using something incorrectly and they remember this in their head as "an issue" when they just needed to click through a warning prompt.

We have an MSP to escalate to and had another issue at our office with RDPing to our Sage server in another location over VPN. We recently had the internet upgraded and hope it would resolve the RDP disconnects, but one user still expierences them from time to time. Our MSP essentially said "minor drops in the tunnel can cause these things to disconnect sometimes" and left it at that.

I'm going to have a chat with my boss about supporting people better and maybe there is more I can do, but I feel like part of the problem is that non-tech people are misunderstanding the nature of their issues and falsely reporting problems with IT through their own misunderstanding.. I'm by no means an IT wizard, I've only been in IT for 5 years, but there is no one else remotely technical at our company and I feel like it's causing this misunderstanding that is leaving me frustrated and blamed for people not understanding IT and why I reccommend that people simply reboot so often.

I've been in IT since I was 18 or 19. I'm 38 now. My first job was in the USAF as Cyber Systems Operations (helpdesk, some junior admin type stuff, on prem AD). I did that for 6 years, bounced around a few contract jobs with Microsoft, Boeing, and a SIP telephone company, did some junior network admin and installer work, got a few certs, got into systems, and have been a sysadmin for about 8 years now. I was promoted 3 months ago, so I run the helpdesk and am the highest admin on the team, second only to the IT director.

I feel like I've waded through a bog of shit to get where I am, and I still don't even make all that much compared to some of you folks (125k for the curious).

But I am so thankful that I'm not simply a task rabbit. I don't just show up and do task X, Y, and Z every day. I get to think. I get to provide input on what projects are worth doing and which are a waste of time and money. I can openly speak my mind, and my opinion is well regarded.

I'm just very thankful that my life isn't some punch list of duties that has to be checked off every day. My job is to figure things out and solve complex problems that are confusing and opaque. Some days I have 15 RDP sessions open to a whole host of apps with integrations and interoperability mechanisms, and I just sit there trying to visualize how all the gears turn. Then, at 4 PM or 7 PM, the answer just materializes, and it's exhilarating.

Keep on trucking.

https://preview.redd.it/9dhomhgqztdh1.jpg?width=554&format=pjpg&auto=webp&s=8a5e919e9eee7ec6244e1af6779387c8bed269e2

Happy Friday, Dexperts!

As we wrap up the week, what's one small (or big) DEX win you're celebrating?

Could be a proactive fix that prevented tickets, a dashboard insight that changed priorities, an automation that saved hours, or just smoother employee feedback this week.

Share yours below: no matter how big or small. These stories are gold for all of us.

If you're still fighting fires, we get it. What's one thing you're hoping to tackle next week?

Looking forward to hearing your wins.

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?

Everyone seems to be in a different place with AI right now.

Some companies have approved tools, clear guidelines, and encourage employees to use AI where it makes sense. Others have blocked most services entirely. And I know plenty of people who say employees are using AI anyway because it helps them get work done faster.

I'm curious what you're actually seeing.

• Do you have an official AI policy?
• Are certain tools approved while others are blocked?
• Has your company provided any AI training that was actually useful?
• Are employees clear on what's okay to upload and what's off limits?
• Do you think most AI-related compliance issues come from people trying to cut corners, or from people who simply don't know the rules?
• Has your organization changed its approach over the last year?

Feels like the conversation is shifting away from "Should we allow AI?" to "How do we help people use it responsibly without getting in their way?"

Interested to hear what's working (or not working) where you are.

Hi Qualcomm Redditors!

Next Wednesday r/nexthink is hosting an AMA with Chrisopher Ord. Christopher is a Senior Staff IT Engineer at Qualcomm and a DEX & Endpoint Performance Strategist. We would love for any of you to join us at the event. Here's the link: https://www.reddit.com/r/nexthink/s/iqmOZfhBLT

If you cannot attend live we would love for people to post early. Christopher will be responding to a variety of use cases and questions. We're looking for:

• Your most inventive Nexthink/Digital Employee Experience use case.
• An idea you've never had the chance to test.
• A problem you're wondering if DEX could solve.
• A workflow, automation, or integration that's made people say, "I didn't know you could do that."
• Also feel free to ask questions more generally, about DEX, Nexthink, Christopher's views on hot topics etc

Join us, drop your questions and use cases, and follow the subreddit we would love to have some cross community participation. :)