I travelled to Ghent with my colleagues Florian Vogler and Franz Walder, and together we had the privilege of delivering a workshop and three sessions. What follows is my personal recap — the sessions, the booth, the social moments, and the themes that stood out.

We kicked off on Monday, April 20, with our half-day panagenda workshop — a fast-paced, deliberately fun tour through what AI is actually doing to our work right now. Highlights:

Franz Walder — “Data Retention Compliance: Know What You Must Keep” (Tue & Wed morning). A practical framework for using Content Age and retention analytics to separate legally protected Domino records from content that can be safely archived.

Florian Vogler — “Move It! 64-Bit, Nomad & more” (Wed morning). Classic Florian — a no-fluff decision framework on why, how, what, and when to modernise Notes clients and applications without breaking what already works.

Marc Thomas — “Inside HCL Notes 2026 Upgrade” (Wed afternoon). Everything admins need for a clean 14.5.1 rollout, with one headline many people took away: HCL Notes 14.5.1 installs 61% faster than 14.5.0 — 24s vs. 62s per endpoint. Bonus track: Daniel Nashed’s nshcpuset workaround for the hybrid-CPU E-Core scheduling issue.

Our booth ran full-portfolio demos all week. A small spotlight this year was on iDNA for application intelligence and modernisation readiness. One prototype we were most excited to show was a working MCP server as a Notes Client plugin — a real, live integration that lets AI assistants talk to Notes/Domino in a structured way. It wasn’t a slide; it was running on a laptop and happy to answer questions. The number of “wait, you can already do this?” reactions made the week.

No Engage recap would be complete without coming back to the giveaway we ran in the run-up to the conference. As Platinum Sponsor of Engage 2026, we gave away one exclusive Engage 2026 Experience Package — three nights in Ghent, a full conference ticket, and a seat at the official VIP Dinner.

The drawing took place at the end of our webinar “HCL Notes 2026 durchleuchtet“ on 31 March 2026, and we’re delighted that Dirk Kirchhof from our customer Nolte Küchen walked away with the package. It was great to welcome Dirk on-site in Ghent, to shake hands at the booth, and to share a few of the conversations and experiences that make Engage such a special week for the community.

A huge thank you to everyone who entered, and congratulations once again to Dirk. See you all at the next one!

Richard Jefts and the HCL keynote on Tuesday morning were unmistakably shaped by AI. The direction for the next 12 months was clear: Agentic AI, Vibe Coding, and Generative AI across the product line. Richard also announced new partnerships with Collabra and IONOS, and teased Domino Workspace, expected mid-year. Throughout the conference, every product area — Domino/Notes, Sametime, Connections — had its own dedicated roadmap session. Seeing that progress, publicly and consistently, was genuinely well received by the community.

And one more moment I have to mention: during the Welcome speech, our colleague Christoph Adler made it onto the big stage with a short message. Christoph couldn’t be with us in Ghent this year for private reasons, but he still managed to wish everyone a great conference from afar. He would have loved the reaction from the room — it was exactly the kind of appearance that feels like family.

Ghent is a beautiful city, and the organisers used it well. On Monday evening, after the workshops, we joined the other speakers and attendees at the Ambassadors Welcome Reception at RAY, right in the heart of the city. Reconnecting with the HCL Ambassadors in person is one of those things that never gets old.

Tuesday evening then delivered the traditional highlight: the engage Dinner at Wintercircus. At 19:00 the whole conference travelled together to this beautifully restored old circus building for an evening of great food and even better conversations. Unusual venue, perfect atmosphere — exactly the kind of shared experience that makes Engage feel less like a conference and more like a reunion.

That’s the feeling I’m taking home from Ghent: AI is changing our daily work faster than any of us expected, the HCL roadmap is moving visibly forward, and the Notes/Domino community still knows how to gather, share, and celebrate. Whether you dropped by our booth, attended one of our sessions, or simply shared a Belgian beer with us — thank you. Already looking forward to the next one.

panagenda was proud to be sponsoring, on stage, at the booth, and around every dinner table at Engage 2026. If you’d like to pick up any of the topics above — Domino upgrades, 64-bit/Nomad modernisation, retention compliance, or our AI work around iDNA — just reach out, we’re happy to continue the conversation.

Meeting assistant bots have become a fixture of modern work life. Whether AI-powered or a simpler automated tool, they transcribe, record, summarize, and follow up so you don’t have to. The productivity gains are real. But so is the risk.

Uninvited Bots joining your Microsoft Teams meetings are a potential security nightmare. We touched upon this in an earlier blog, Meeting Bots: Helpful Assistant or Security Nightmare?  Bots were sometimes hard to distinguish from human attendees. For that reason, Microsoft previously allowed admins to enforce lobby use and set up an additional verification check that forced anyone entering the lobby to complete a CAPTCHA challenge.  —  This approach was designed to block non-human attendees, but it created unnecessary friction for legitimate users in the process. Microsoft is changing this.

Here’s what you need to know.

Microsoft has announced a significant update that directly addresses the bot visibility gap in Teams meetings. Under Message Center notification MC1251206 (Microsoft 365 Roadmap ID 558107), Teams will now natively detect and label external meeting assistant bots as they attempt to join meetings hosted by your organization.

This is a big improvement — and a direct response to growing enterprise demand for meeting governance.

Starting mid-May 2026 (Targeted Release) through mid-June 2026 (General Availability, including GCC tenants), Teams will:

Bot detection will be enabled by default for all tenants, with no action required to activate the feature. Microsoft recommends keeping the default approval-required setting, and admins can choose stricter or more permissive options based on organizational needs.

It’s worth noting that Microsoft classifies this change as one that introduces AI/ML detection logic — specifically, it analyzes meeting join metadata to identify external automated bots. This is not a passive change. It’s an active detection layer, and it signals that Microsoft is treating meeting bot governance as a first-class compliance concern, not an afterthought.

Here’s where organizations need to stay sharp: not all bots will be detected. Microsoft is transparent about this — some bots may evade detection based on their intrinsic behavior. Microsoft is actively asking users to report undetected bots from within the app to help improve the system over time.

That’s not a criticism of the feature — it’s a realistic acknowledgment of the cat-and-mouse nature of bot detection. But it does mean that Microsoft’s built-in detection is a necessary layer, not a sufficient one.

Microsoft’s detection is a solid foundation, but as stated it’s not foolproof. For organizations that want to close that gap and need to know  if bots joined and if so, which version, and which backend host it communicated with,  panagenda TrueDEM will provide  meeting-level bot attribution that native tooling simply doesn’t surface.

For a thorough look at why this level of visibility matters, Stefan Fried’s research paper “What Powers Your Teams Meetings?” is well worth a read.

Microsoft’s MC1251206 update is a step in the right direction — one that every Teams admin should pay attention to. Here’s what we recommend:

Because knowing exactly who’s in the room shouldn’t be left to chance.

To help IT leaders better understand the evolving landscape of digital collaboration, we are excited to release our latest research report: “What Powers Your Teams Meetings – A Research Driven Breakdown of Microsoft Teams Meeting Applications“.
In this data-driven report, we move beyond the basic metrics to explore what call data can tell us about applications and bots running in Teams calls. Utilizing a data set of over 1 million calls in a period of 30 days, this report is a culmination of extensive analysis and real-world telemetry, giving insight into:

At panagenda, we believe that data is only as good as the expertise behind it. That’s why we are proud to highlight the author of this report: Stefan Fried. Stefan is Senior Program Manager and one of the industry’s leading voices in Teams call analytics.
With over 20 years of experience in collaboration infrastructure, Stefan has spent his career decoding the complexities of digital experience monitoring. His deep understanding of how Teams behaves both in the cloud, as well as across home Wi-Fi, local ISPs, and diverse hardware, is what powers our most innovative solutions like TrueDEM.

Take Control of Your Collaboration Strategy

Whether you are troubleshooting a single CEO call or optimizing a global rollout, understanding the “why” behind your meeting performance is critical. Our experts and products provide the blueprint for moving from reactive troubleshooting to proactive optimization.
 

Bots and AI meeting assistants are great for productivity but are a potential security nightmare if left unattended. Even if not intended as malicious, they can cause all kinds of red flags from data residency concerns to the loss of legal confidentiality. Bots can pose a bigger liability than you might realize. Reclaim control by hardening your Teams Lobby settings, training your “Human Firewall,” and using advanced monitoring to see exactly which bots are joining your organization’s calls.

Are bots taking over our meetings? And if so, what are they doing?

More and more bots are being introduced that add value to meetings & calls. From native Microsoft bots that perform tasks like translation, recording or managing call queues, to external tools like Otter.ai and Fireflies.ai that perform notetaking and virtual assistant tasks, to self-built bots your organization deploys to do anything from compliance monitoring and security to simple call handling.

End users will generally see these bots appear as attendees. Often with names related to the task they perform (e.g. “[users name] note taker”) or the product they represent. Rarely enough for users to fully understand why they are there and what that implies.

Then there is the situation where bots are not shown or try to hide their identity. Most of Microsoft’s native bots for instance do not show up in the attendee list which is probably not very concerning as these are after all part of the standard toolkit of Teams but there are other bots that are, or might try to be, unnoticed. Not necessarily for malicious purposes, but still, they can pose risks you might not be aware of.

In theory, any bot joining a meeting has a participant ID and is shown in the participants roster as well as has a video tile. However, bots can try to hide or subdue their presence. Sometimes on purpose, for malicious purposes, or to not intrude, like in the case of compliance bots. And sometimes, it’s actually just unintended like this forum post highlights. It does mean though that there are ways in which a bot can go undetected and not show up in the participant roster or video tiles.

Another way in which bots try to hide their identity is by simply taking a name that could be seen as a normal person. Especially in larger meetings it can go undetected like that. Fireflies.ai’s virtual assistant is for instance called ‘Fred’. If you’re organizing a larger meeting with externals and one of these uses Fireflies.ai, you might be forgiven to not know that the ‘Fred’ in the lobby is not an actual person. Especially if your own organization doesn’t use Fireflies.ai.

Another element of these virtual meeting assistants is that they often request access to the user’s calendar, allowing them access to each meeting invite the user has in their calendar which they will then try to automatically join. Even those in which you really might not want that. For example: in an HR meeting or a financial or confidential meeting. Especially as services like that tend to send out meeting summaries to all participants afterwards, even those that did not attend.

An example of how damaging this could be for an organization is nicely explained in this blog from MLT Aikins.

So, what are the risks of bots in meetings in general?  There are several risks associated with bots, and not all include malicious intent.

Data residency & security: Bots that collect information store that data on a server. In the case of third-party vendors, this could mean sensitive information is stored outside of the IT department’s control. Which could compromise security as well as regulatory, industry and company compliance. Worse even, when the application is a ‘free’ app and there is no formal contract arranging data ownership, security and residency.

Data quality & ownership: Bots interpret and process data, this means that some of the data might not even be accurate. This brings us to the next risk, which is that vendors might use the collected data to train their bots. Which could mean that knowledge derived from your meetings and (correctly or incorrectly) interpreted by a bot is used to assist other customers.

Legal consequences: Apart from the obvious jurisdiction, compliance and security risks, having bots in meetings could also pose some other, perhaps not expected, legal consequences. There are some interesting articles on what the implications of data collected by third-party bots during meetings could be. Including loss of client-lawyer privilege and altered disclosure status. 

Needless to say that it is important to be aware of the risks of having bots in meetings and to take steps to both monitor and safeguard the use of them.

The most effective way to block unwanted bots is to ensure that they cannot enter a meeting without human intervention.

Microsoft realizes the risks of bots entering meetings unwanted and has recently added options that allow you to have automatic verification if it is a bot or human before even admitting them to the lobby.

Many bots join because a user has “installed” a 3rd-party application (like a note-taker). Admins can control this at the source.

This one can be tricky. Most legitimate bots have a name & icon that makes clear what it is and what it does. Some however don’t. Microsoft’s 2026 UI now makes it somewhat easier to identify these entities. In the meeting roster:

All of the above makes one thing clear. None of this will be waterproof. Even if you restrict external access, block anonymous access, or harden the lobby restrictions, there will always be situations or users that require exceptions. Based on their specific role or on the meeting context. Furthermore, users might join meetings initiated by external users where other configurations are at play. You have no control over those meetings and what bots join those calls. Deliberately or unintentionally.

And that’s why it is crucial to not just look at this as a ‘technical’ problem to solve with settings and restrictions but as one that requires active training and awareness from your users.  Users should know how to identify a bot, be aware of what the risks are, and been given instructions on how to act when they do not trust the situation. Most importantly, they need to feel empowered to speak up so meeting organizers can take steps, be cautious with information until the situation is clarified and report to an administrator what they encountered if they feel uncomfortable.

Finally, is it enough to just rely on settings and user awareness? No. As said, there are almost always exceptions that do require active monitoring. Even for legitimate bots where you want to know if things like the host changed or if it’s running on the right version.

Monitoring which bots are joining users’ meetings can be a challenge for admins. Microsoft’s Team Admin Center tells you a non-native bot joined the meeting but often just names it “bot”. Which doesn’t explain if this was a sanctioned or unsanctioned bot. Nore does it provide any other details important to ensure that it’s a trusted bot. With TrueDEM, in-depth bot information is available, from name & version to the backend-host they run on. This allows admins to directly see which bots joined which meeting and which backend-host they utilize. For more on Native and non-native meeting bot monitoring and it’s importance, check out Stefan Fried’s paper.

Microsoft AppLocker is an application intended to provide control over applications and files on local systems. In my case, however, it led to some severe headaches and, ultimately, an unexpected outcome; one even Microsoft did not anticipate. So, let’s dive into the topic.

At panagenda, we offer a Digital Experience Monitoring solution which requires customers to install a packaged application on Windows. This application has a simple design with minimal requirements, and is signed by a certificate issued by the Global Root CA.

Customers who use AppLocker Rules are requested to add our application to the list of trusted packaged apps if there is no existing rule that trusts all signed packaged apps.  Typically, an AppLocker Administrator adds the rule on an administrative computer. The policy is then exported and applied to Endpoint Manager (formerly Intune) to be deployed to all client devices.

The problem arose tough, when the app got blocked although the allow rule was active and available. Windows Eventlog didn’t provide much detail, other than a very generic message without any details other than that there is no rule which would allow this application. Very helpful, right?

When adding an AppLocker rule in the MMC UI, you typically select the app and make a few adjustments. We advise customers to use wildcards for the package name and version, restricting the rule at the publisher level only (see screenshot).

You might think everything is set up correctly, but it is not.

If you take a look at the Publisher String of the certificate within the app, it looks like this:

Not really special. Pretty much the same as if you would take the publisher’s information for any other application like for instance Adobe.

After creation, the rule needs to be exported as XML and then imported into Endpoint Manager for further distribution to the endpoints. And here is where things went south.

It turns out that in the exported rule, the PublisherName string was truncated after 260 characters!

Microsoft specifies that the Publisher string must match exactly when AppLocker evaluates its rules. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/understanding-the-publisher-rule-condition-in-applocker. The truncated string meant that the evaluation would always fail.

Is export the issue here, or is something else causing the problem?

In fact, it was not the export, but indeed something else. Basically, you create the rule, pick the application and then set the publisher level – you would assume that everything is fine, right? Wrong, if you reopen the rule in the MMC UI you will notice that the Publisher string is already truncated. As the export simply takes what is there, the result is an incorrect publisher string in the export as well.

Even Microsoft was surprised when we brought up this topic to them.

Pretty simple: Export the rule and update the exported XML to include the full Publisher String. Inject the modified XML into Endpoint Manager and deploy it. To verify if the Publisher Condition is configured correctly, run the following PowerShell cmdlet on the user’s PC.

You should see the correct Publisher condition on the Client PC which matches exactly the publisher’s name on the installed packaged.

Remember however that you will need to update the exported XML whenever you modify the rule or create a new export at a later stage, as Publisher will still only have the truncated Publisher String.

Trusting the UI cost hours – even for Microsoft. Next time, question everything, document the weird, and remember: “Wildcards might save the day, but understanding the details saves your sanity.”

If 2025 had a winning personality, it wouldn’t be the loudest person in the room.
It would be the one who stayed a little longer. Asked better questions.
Listened carefully. And quietly changed things in ways that brought people together.

For us, 2025 wasn’t just about milestones or metrics. It was about movement.
Forward, sideways, sometimes backwards – but always together.

We launched ideas that started as half-sentences.
We turned challenges into conversations.
We learned that progress doesn’t always look like speed – sometimes it looks like clarity.

To our clients and partners:
Thank you for trusting us with your problems, your ambitions, and occasionally your beautifully incomplete support tickets. Thank you for choosing collaboration over convenience, depth over shortcuts, and long-term thinking over quick wins. Thank you for choosing us.

To our team:
Thank you for showing up – not just with skills – but with personality: curiosity, courage, and care. For asking “why” one more time. For challenging each other respectfully. For proving, again and again, that great work is never just about talent – it’s about mindset and how we work together.

And to everyone who followed, supported, recommended, questioned, or quietly believed in us: You were part of our 2025, whether you know it or not.

⸻

Looking Ahead to 2026

We’re entering 2026 with fewer buzzwords and more conviction.
With sharper focus, stronger foundations, and an even clearer sense of what we stand for – and what we don’t.

2026 won’t be about doing more.
It will be about doing what matters – better.

More meaningful relationships.
More honest conversations.
More work we’re proud to put our name on.

We don’t know exactly what 2026 will bring. But we do know how we’ll meet it:
With openness. With ambition. And with the belief that sustainable growth is never built alone.

So here’s to the next chapter.
To ideas worth pursuing.
To progress worth the effort.
And to growing – together.

Thank you, 2025.
We’re ready, 2026.

⸻

Wherever and however you celebrate, we wish you a restful festive season and a healthy, successful year ahead – together.

HCL kicked things off with a webcast about what’s coming on Thursday, November 20, 2025. You can now watch this webcast on YouTube.

There’s lots of news! Of course, there’s a new version of HCL Domino, as well as updated versions of HCL Sametime and HCL Traveler. But today, I want to focus on the HCL Notes client.

Notes 14.5.1 provides the following general enhancements:

Enhanced installation process for the Notes and all client kits on Windows
The Notes installation program now installs deployed modules and places them in the file system, similar to the fast and robust installation methods already in use for the Mac client.

Updated the default font
Enhanced the design by updating the default font to Inter font. This font is recognized in the industry for its clarity and modern aesthetic, contributing to a more polished and professional look.

Notes 14.5.1 provides the following user interface enhancements:

Enhanced the user interface framework
Improvements include: The colors of the tabs have been refined to achieve a more cohesive visual presentation.
The Open menu is now docked by default, making its navigation icons readily available.
The focus color on the navigator has been updated to enhance visibility.
The color of the action bar has been revised to elevate the overall visually appeal.

Enhanced the Properties panel
The Properties panel offers a modern interface within the side shelf, allowing for user-friendly navigation. You can choose to open it in a new window for increased flexibility. Additionally, it supports round-trip editing. When you’re finished, the panel can easily be closed to free up your area.

If Designer is installed, old Properties panel will be shown in Notes and Designer. Contact you administrator to turn off this new properties panel in the Notes ini: DISABLE_ENCHANTED_INFOBOX=1.

Enhanced forms
The user interface of Notes Mail, Calendar, Contact, Notebooks and To Do forms are more visually appealing and user-friendly experiences.

Enhanced dialog boxes
The following dialog boxes are updated: Quick find, Create folder, Move folder, Login, Add calendar, Sametime, Alarms panel and Replication schedule dialog box.

Updated Controls
The following controls are updated: radio box, check box, time-zone control, date picker, list box, picker fields, text field delimiters and tabbed table.

Restyled templates
The following popular templates have been given a new look and feel.

Notes Log
Directory
Directory Catalog
Widget Catalog
Monitoring Configuration
Subscriptions
IdP Catalog
Cluster Analysis

Others: The color orange is used in templates for Notes, while blue is used in those for the Administrator client.

Notes 14.5.1 provides the following calendar improvement

Calendar view improvements

Designated colors and icons for various calendar types, providing clarity and enhancing the visual organization of scheduling tools.

The color scheme of the action bar has been updated.

Notes 14.5.1 provides the following Workspace improvement:

The workspace has been enhanced with a set of new icons that maintain a consistent size by default. Additionally, the interface layout has seen significant improvements, and a new feature allows users to enlarge the previous workspace icons for better visibility and usability. See Preferences – Quick reference

Notes 14.5.1 provides the following Sametime web chat enhancement:

Sametime web chat is integrated with HCL Notes, now offering a modern chat experience that supports read receipts and chat reactions, as well as search chat messages and a new preference to switch back to the older chat experience within the chat window. See How do I set up integrated web chat or change chat settings?

Note: Windows Sametime server 12.0.4 (provided on My HCLSoftware Portal with Domino 14.5.1 EA1) is required to support this feature. To install the new 12.0.4 server, administrators can follow the steps in Installing Sametime Chat on Windows in the Sametime 12.0.3 documentation.

As usual, HCL makes new versions available on its download portal. If you look under “HCL Domino” there, you will be directed to the “Domino Early Access Program.”
(Direct link)

An overview of the release notes

System requirements
System requirements are available on the HCLSoftware Support site:

Performance is something we at panagenda have always been concerned with. And I would say we are good at making the Notes client fast. With this release of Notes 14.5.1, the installer only takes 38 seconds to install in my environment. That’s mind-blowing compared to older client versions.

Early Access Forum

As always, your input and feedback are crucial to HCL. Let them know what you think about the product and new features by submitting your feedback in their HCL Domino 14.5.1 Early Access Discussion Forum. If you participated in a previous Domino Beta or Early Access Program, you can continue to use that account and no sign-up is required.

We were also excited to test the new Notes Client in conjunction with the MarvelClient upgrade.

I can announce, we support HCL Notes 2026 with MCUpgrade. Try it out! (> MCU 14.5.x)

HCL is setting a strong pace with the launch of the new Early Access phase for HCL Notes and HCL Domino 2026. With a more modern user interface, streamlined installation, upgraded templates, and meaningful improvements across the Notes client, this release already feels like a confident step toward the future of the platform. The combination of visual refinements and practical usability enhancements shows that HCL is listening closely to community feedback—and acting on it.

For us at panagenda, performance has always been a core focus, so seeing the Notes client install in just 38 seconds was a standout moment. And with MarvelClient Upgrade already supporting HCL Notes 2026, organizations can start testing without hesitation.

As always, the Early Access Program is only as strong as the feedback it receives. If you work with Notes and Domino, now is the perfect time to explore what’s new, share your thoughts, and help shape the final release.

I’m excited to see where HCL takes us from here 2026 is already off to a promising start.

We are currently seeing the EA1 release. There are usually three EA versions before a final release is available. Things are progressing rapidly. Take advantage of this opportunity to find out more at an early stage and provide feedback.

Many organizations rely on Virtual Desktop Infrastructure (VDI) to provide a flexible work environment for their end-users. Running Microsoft Teams calls within a VDI session, however, requires specific configurations to ensure optimal performance.
Crucial to this are the Microsoft Teams optimization settings supported by the VDI vendor. Currently, two main types of optimization are available:

If you are interested in learning more about the technical aspects or configuration processes for VDI optimizations, I would recommend reviewing MVP Jon Towles’ article on “Teams on a Diet: SlimCore Optimizes Microsoft Teams on VDI” or to check vendor documentation. In this blog, I will not focus on how to set it up, instead, I will focus on the challenges IT administrators face when monitoring and troubleshooting Teams call issues in this complex landscape, and how TrueDEM can help provide the necessary visibility.

The first aspect to assess is whether VDI optimization is even enabled as not enabling it will significantly increase the potential for issues with Teams.
This can be checked in two ways:
User Visibility: If optimization is not active, the user will see a “Not optimized“ message in the Teams title bar. While visible, the true impact often only becomes apparent once a call is initiated.

Administrator Visibility: Administrators can only verify if VDI Optimization is on by going to the  Settings / About Teams in the client, or by checking the vdi_debug.log.

The limited options for administrators to verify this do make it something that is hard to keep track of. Especially as settings can get changed due to updates for example. So careful testing and regular monitoring are required.

Monitoring Teams Calling performance in a VDI environment differs significantly from the standard configuration where users access the Cloud directly from their devices. I often refer to this as “The Monitoring Triangle”.
It depicts the special relationship between the involved data streams and how they are routed between the VDI Host, the local device and the M365 cloud. As the VDI setup makes the setup a bit more complex.

With all media streams being routed from the local client to the Cloud rather than from the VDI Host, capture metrics at the client level is important. The Teams client on the VDI Host however, also plays a key role by managing signaling and session control with the Cloud. If there is significant CPU or memory utilization on the VDI Host, users may experience issues even when media streams are offloaded to the local endpoint. For example, a mid-call failure might occur if there is a network hiccup between the VDI Host and the Cloud.
Comprehensive monitoring would involve covering all three areas and correlating their metrics to provide a holistic and aggregated overview. This process is challenging due to factors such as data delays and unsynchronized timestamps, preventing a holistic and aggregated overview.

Understanding the complexities of troubleshooting Teams call issues in a VDI environment, our latest release of TrueDEM now fills the gaps on VDI monitoring.

To get Teams call insights for your VDI users, install the TrueDEM Agent on the VDI Host (as a provisioned app package for non-persistent VDIs or an app package for persistent VDIs). This setup covers resource utilization and network monitoring on the VDI Host itself.

As media streams are offloaded to the local client during calls, TrueDEM captures them directly via the Teams Client in the VDI session. Collecting audio, video, and screen sharing metrics during active Teams calls as well as network connectivity information for the data routed via de local endpoint. TrueDEM detects that your call is on WiFi even though the VDI Host has a wired connection.
Lastly, the TrueDEM also helps in identifying  if VDI Hosts are properly configured for any optimizations.

Because the TrueDEM Agent is running on the VDI, and not on the physical endpoint, we currently do not track CPU and memory on the local machine level. We do however track all the other major elements and connectivity that make up the complex monitoring triangle of Teams calls in a VDI environment. Giving you unparalleled insight into what’s going on with your VDI users’ Teams calls for proactive monitoring and effective troubleshooting.
 

Would you like to more about monitoring your VDI users’ Teams call experience? Contact us to try it out for yourself.

Content age analysis reveals which applications are inactive and which remain actively updated and essential. iDNA Applications analyzes document metadata to expose creation/modification history at scale, turning scattered Notes applications into age distributions you can act on.

This matters because most jurisdictions require you to keep certain records for set periods, but not longer than necessary. Under GDPR, the storage limitation principle demands that personal data be retained only as long as necessary for its intended purpose but may be kept longer if a legal obligation applies. So, in many cases you may end up in a situation where you must balance minimum sector retention with “no longer than necessary” privacy rules.

Across industries, those rules are concrete. Financial services record-keeping (e.g. SEC/FINRA) typically mandates retention of books, records, and some communications for five to seven years, with regulators increasing scrutiny of electronic record-keeping across legacy and multi-platform systems. Healthcare documentation under HIPAA must be retained for at least six years (often longer under state law), including policies, authorizations, and other PHI-related records. If your organization operates in the EU, country-specific schedules cover HR, tax, safety, and environmental records — often extending to decades.

Archiving isn’t about dumping old data into cold storage—it’s about making smart, defensible decisions. Content age gives you the clarity to do exactly that:

For true compliance-oriented content retention, how you archive inactive Domino applications determines your organization’s compliance, cost, and audit readiness.

A compliant archive isn’t just about meeting retention schedules—it’s about ensuring your organization’s Domino data remains under your control through compliance-oriented content retention. By archiving inactive applications and sensitive records within your own HCL Domino environment, you safeguard against the uncertainties of cloud hosting. Recent events have shown that cloud providers can be subject to external government demands, potentially compromising access and sovereignty over your data.

Keeping your archive on premises means you retain the ability to prove compliance, respond to audits, and fulfill regulatory requests—without risking unexpected interference or loss of control. In a world where data governance is under increasing scrutiny, on-premises Domino archiving is your strongest defense for both compliance and business continuity.

A common misconception during transformation is that Domino is “legacy” and therefore marginal. Content age often proves the opposite: the crucial fact that many applications show recent edits and ongoing active document creation. Paired with usage analytics, you are able to gain a clear indication if Domino remains central to live workflows and may be essential in many business processes.

iDNA Applications combines content age with real usage data for a complete picture of your Domino environment. By analyzing each database’s activity records alongside server logs it quickly delivers actionable insights — so you can distinguish business-critical apps from those ready for archiving without lengthy discovery cycles.

This insight shapes your portfolio strategy:

Modernization isn’t a simple binary choice between migrating everything or deleting what’s old. Content Age enables a nuanced, compliant path: archive inactive applications to satisfy retention obligations and keep them discoverable. At the same time, prove with evidence, where Domino remains integral to your business today. If you want a faster way to get that clarity, iDNA Applications unifies Content Age, usage history, and portfolio context so you can make the right call, first time.

When remote employees join a Teams call, they need a direct, low-latency connection to the Microsoft 365 cloud. But what happens when their entire internet connection, from basic web browsing to streaming video, is forced through the corporate VPN gateway first? The result is often frustrating: choppy voice, dropped frames, and significant delay. This isn’t just about bandwidth; it’s about the Round-Trip Time (RTT). By forcing Teams media traffic onto a full-tunnel VPN, you add extra hops, layers of encryption, and unnecessary congestion. The constant performance issues users experience often go undetected as IT teams check local devices and home networks, missing the real culprit: the corporate VPN is routing all traffic, and Split Tunneling is not enabled.

A Virtual Private Network (VPN) secures remote access by masking the user’s IP and routing all data through a secure, encrypted tunnel to the corporate network for security and compliance.

However, while vital for security, VPNs can introduce latency, potential bandwidth limitations, and routing complexities that are detrimental to real-time communication like Teams. In fact, Microsoft Teams is optimized to work best when media traffic (audio/video) flows directly between clients or through Microsoft’s cloud infrastructure.

Routing Teams media data through VPNs often leads to a phenomenon called “geo-routing inefficiency,” where a user’s data exits the corporate network in a completely different geographical region, or even continent, than where the user is physically located.
For example: User ‘Ann’ in Boston, USA, has her VPN active. Because all traffic is forced through the tunnel, Ann’s media traffic might be routed to the corporate VPN egress point in Vienna, Austria, entering the Microsoft network close to Vienna. This forces her traffic to travel across the ocean unnecessarily, significantly increasing latency, instead of connecting directly to Microsoft’s global network backbone near Boston.

Microsoft strongly recommends that administrators implement Split Tunneling when a Virtual Private Network (VPN) is used in conjunction with Microsoft Teams. In fact, split tunneling is essential to ensure optimal performance, reliability, and call quality for Teams’ real-time communication features, especially for hybrid and remote users.

Let’s dive into why this is:
Split Tunneling is an advanced network feature that provides granular control over which data is using what route. It allows administrators to configure Microsoft Teams media stream traffic to bypass the VPN tunnel entirely and connect directly to the internet. This is the recommended practice for two critical reasons:

Image source: Microsoft

The practice is safe for Teams data because the traffic is already secured at the application layer, meaning it does not rely on the VPN for its core protection. The VPN’s security purpose is also preserved as access to the internal corporate network and its sensitive resources (like file servers or internal applications) remains unchanged. Only the already-encrypted, high-bandwidth Teams traffic is split off, while all other connections remain protected by the VPN.

Implementing split tunneling for Microsoft Teams is a strategic necessity, not a simple setting. Success requires careful planning and coordination across IT and security teams. A thoughtful approach is crucial to avoid introducing vulnerabilities or operational issues.
Below are some helpful resources regarding implementation:

Ultimately, Split Tunneling is the critical configuration that resolves the inherent conflict between VPN security, and the performance demands of Microsoft Teams. By strategically allowing Teams media traffic to bypass the corporate tunnel and connect directly to the internet, organizations eliminate the penalties of double encryption, excessive latency, and bandwidth bottlenecks. This approach ensures a reliable high-quality experience for users engaging in real-time communication while preserving the VPN’s role in securing all other proprietary corporate data. Directly aligning with Microsoft’s strong recommendations for optimizing modern collaboration environments.

With TrueDEM we help organizations identify issues with Teams Call Quality and M365. Incorrect VPN routing is one of the many Insights we detect so that we can help customers determine problems in their Teams environment and setup. If you are interested in learning more about what TrueDEM can do for you, then don’t hesitate and contact us today.

We’ve got a fresh new look & feel for the login process. Honestly, it’s worth mentioning because now the whole procedure feels smoother.

Another feature has made its comeback after being MIA for a while: resetNomadInstance=1. Or as I like to call it, the “Kiosk Light Mode.”

The resetNomadInstance=1 setting forces HCL Nomad for Web Browsers to delete all locally stored data (like user IDs, cache, and settings) the next time it starts.

You can find more about it here.

The newest HCL Nomad Web release packs in 16 key bug fixes, boosting both performance and stability. Check out the full list of enhancements and dive into all the details in the accompanying Knowledge Base article!

Unfortunately, there’s a bit of unwanted behavior when you turn on attachment blocking in the application restrictions — it seems the feature is a little too enthusiastic about doing its job.

For some reason, HCL Nomad Web treats a database tile on the desktop as an attachment. So, whenever you move your DB icon on the desktop, this message pops up.

But I firmly believe that HCL will quickly resolve this minor flaw.

In the past, digging up specific information from the documentation for different versions of HCL Nomad and HCL Nomad Web could feel a bit like a treasure hunt—without the treasure map. But good news: there’s now a new, much more organized portal (in my humble opinion) that gives you easy access to all the Nomad knowledge in one place.

New Portal: HCL Nomad Documentation

For downloading HCL Nomad Web 1.0.17, you can use the following direct link: NOMAD
All other HCL packages are available on the official download portal: https://my.hcltechsw.com/

HCL Nomad Web 1.0.17 may not look like a game-changer at first glance, but it clearly delivers more than meets the eye. With a refreshed startup experience, a smoother login flow, the return of the handy resetNomadInstance feature, and 16 important bug fixes, this release makes Nomad Web more stable, reliable, and user-friendly than ever. Sure, there’s one small quirk with attachment blocking, but it’s outweighed by the many improvements and likely to be fixed soon. Combined with the new documentation portal, upgrading to 1.0.17 is a smart move for anyone who wants a cleaner, faster, and more consistent Nomad Web experience.

We often get questions about frustrating issues that users are having during Teams calls that admins cannot figure out. Even with admin tooling and Microsoft Teams administrator insights, issues can still be hard to diagnose. As they can be caused by any of the many moving parts making up the user experience for Teams calls.  The following case is such an example of an interesting, and hard to diagnose Teams call issue. Involving several variables and highlighting the complexity of troubleshooting multiple factors potentially affecting Teams call quality.

A customer approached us asking for help investigating a very challenging topic that had been troubling them. A growing number of their users were regularly facing issues with incoming video or screen sharing not working during calls. Instead of seeing the other party or screen, all they got was a dark screen. It would often resolve itself after several minutes but was annoying and disrupting nonetheless. As there are many factors that can cause it, this was proofing to be quite a challenge to analyze. With more and more users reporting the issue, it was also quickly becoming a major headache.

The client asked us therefore if we, with the help of TrueDEM, could assist them to identify the cause and find a solution.

The reported issue was not just occurring to a single user, but multiple which can be a clue. What do these users have in common that could cause it? This was easily answered as the client mentioned that they were rolling out new hardware (laptops). Most of the affected users were using the new device type. Making it a logical first step to first look into what was happening during problematic calls on such a device.

The problem happened solely on the incoming visual streams (video & screen sharing), so GPU and rendering capabilities would be important. Something that is handled by the graphic card and requires different webview2 processes like Renderer and GPU.

We selected a random call from one of the affected users, and the following immediately caught our attention:

During the call, not one, but two webview2 processes were running with two completely different versions.  Version 135.0.3179 was the evergreen version at that time and was the one which the Teams client was using. Which you can see as it’s the consecutively used webview2 process throughout the call. But apparently there was another application running on the user’s device that was using an older version, namely 122.0.2365.  Seeing an outdated version signals that the invoking app was not programmed to use the most recent Webview2. Instead, it used a static version of webview2 bundled into that app directly.
Shown in the following picture, for a period of 7 minutes (2:25pm – 2:32pm) this other application was using top memory Webview2 resources.

Could this be the issue?

We did not know the exact moment the issue had occurred as the user had not reported on that. So, we checked to see if the running of this outdated Webview2 process coincided with something in the call that could indicate the issues. We didn’t have to look far. At the same time this process was running, the ‘Inbound Video Frames’ started showing significant drops. It even went almost down to zero at one point. Both for video as well as for video based screensharing (shown in two pictures below). A very good indicator for a serious issue!

But does this explain our issue? Not necessarily… When multiple applications run, each runs its own isolated Webview2 process group which can use different versions. So theoretically this alone should not cause the blackouts in the Teams call. We had to dig deeper.

Next step was to look at the graphical processing unit (GPU). Each app uses their own Webview2 processes, but they do still use the same GPU and GPU driver whenever they perform rendering tasks against it. With multiple Webview2 apps contending for GPU and driver resources this can cause an overload, called GPU contention. With a heavy webview2 app like Teams running simultaneously with another heavy Webview2 process, GPU contention could certainly be a factor. If GPU contention occurs to such a level where the driver becomes unresponsive, the operating system could force a restart of the GPU driver, temporarily making it unavailable. This definitely would explain a blackout on the Teams video stream.

So, the next logical step was to check if the GPU was really used in the Teams call during the issues and if so, what driver version was installed.

The user’s device was using NVIDIA RTX 1000 Ada Generation Laptop with the Driver v32.0.15.7216 and all the Calls where the blackout occurred indicated that h264 hardware decoding was being used. This confirmed that the physical GPU was used during the call, and that it could be interesting to look further into the GPU.

The real time insights also showed that the GPU was using the h264 hw codec for decoding, instead of the far more superior AV1 codec that this brand-new device with the NVIDIA card should be able to support.

The fact that the GPU driver was not using the AV1 codec provided a good indicator that the driver of the NVIDIA chipset might be outdated. Checking with the other calls where users reported Teams video issues, we saw the same findings, creating a clear pattern.

We now have all the relevant info together, let’s look at what to do with it.

Based on the findings we knew the following: During the Teams calls in which users reported the issues with incoming video & screen sharing suddenly going black, we see another app using an older version Webview2 process around the time the users reported having issues. We also see the GPU using the less optimal h264 hw codec instead of the supported, and preferred, AV1 codec.

Investigations on public forums show that other people reported similar cases, especially with combinations of Webview2 versions below version 130.x and outdated NVIDIA drivers.

Next steps:

Handed our findings there were now two clear suspects for the problem and two potential solutions for the client to explore:

The first item was straight forward and was tackled by the client team almost immediately. Indeed, the NVIDIA drivers on the devices were outdated and were subsequently brought up to the correct version. Identifying the other app was also no issue but as with any software in an enterprise situation, updating would potentially be a more complex action as it requires proper planning and deployment.

Luckily, the NVIDIA driver update already caused an immediate reduction of Teams video issues being reported. Proofing the problem was indeed a driver issue.

By leveraging both retrospective insights and real-time data, TrueDEM gave us a minute-by-minute look into the affected calls. This allowed us to pinpoint crucial factors that were previously hidden, such as the use of an outdated Webview2 process in another application and the specific encoding/decoding codecs being used throughout the calls. These critical clues ultimately led to the root causes: an outdated driver and/or GPU contention.

With this newfound clarity, TrueDEM was able to provide the client with clear insights and a direct path to resolution. A path that allowed them to proactively fix the problem for every user who had or was going to get the new device and reduce future incidents.