The new TrueDEM macOS agent will be released in October. It provides in-call analytics and full parity on call quality analytics with the TrueDEM Windows agent.

macOS is common in many organizations. Not just among developers and techies. Many of our customers have indicated that they would like a macOS agent with the same capabilities of monitoring Teams calls as our TrueDEM agent for Windows, as it is popular with management and executive layers. Exactly the users who depend heavily on Teams to run their calls and meetings. And when their call breaks up, they expect immediate action.

TrueDEM already had a macOS agent. It retrieves deep-dive network information and device performance data. But it was limited when it came to collecting real-time call data. On Windows, our TrueDEM agent provides more. Through our integration with the Teams client, it collects not just device and network information but also in-call call quality metrics. For all calls, meetings and PSTN calls a user makes. This extends what Microsoft call analytics and the Call Quality Dashboard (CQD) capture with deep-dive analytics. With the new TrueDEM for macOS agent, we now provide this same level of deep call quality telemetry for macOS users. No matter whether the user is on macOS or Windows.

Administrators now have access to call quality data while the call is in progress. For Windows as well as macOS users. They see exactly how audio, video and screen sharing are performing, if there are any issues and what is going on. The data refreshes every 30 seconds.

TrueDEM covers all calls a user makes. It provides immediate insight during the call, as well as retrospective insight afterwards, without any prior admin interaction.

Picture this. An executive joins a meeting from a MacBook. Five minutes in, video freezes and the audio drops. They call support. Rather than asking them to reproduce the problem or waiting for post-call data to be processed, the administrator opens the call inside the TrueDEM Portal while it is still running, sees heavy packet loss on the Wi-Fi, and tells the executive to switch to a wired connection so they can rejoin. The same data supports a follow-up review of the Wi-Fi at that location.

Microsoft offers real-time data through Real-Time Analytics in the Teams admin center. It is however limited to scheduled meetings and Meet Now. It does not cover 1:1 calls, group calls or PSTN calls. Without a Teams Premium license, an admin has to actively open the meeting while it is going on, and even then, the real-time data is kept for up to 24 hours. With Teams Premium, the data is collected automatically and kept for 7 days.

Microsoft call analytics and CQD do cover all call types. But only after the call has ended and only in aggregated form, causing the moment-by-moment timeline crucial for effective troubleshooting to be lost. TrueDEM collects call data for every call automatically and with full details. Including 1:1 calls, group calls and PSTN calls. You can see it live, and look back for up to six months.

1. Monitor important calls for quality disruption as they happen. For multiple users at a time.

2. Access call quality data in real time or retrospectively. No special admin actions and no Teams Premium license needed. It is covered by the TrueDEM Advanced license.

3. Real-time insight not just for scheduled meetings and Meet Now, but also for 1:1 calls, group calls and PSTN calls.

4. Call quality data retention for up to six months. For retrospective analysis and comparison over time.

5. One overview of call, device, network, applications, and M365 service data. Covering the full end-to-end journey between user and the cloud. For faster troubleshooting and more proactive administration. Read here how this works for Dräger, a customer who has been working with TrueDEM since 2024.

Interested in knowing more? Contact us for a free consultation or try out TrueDEM yourself with your own data and in your own environment.

It started with an online meeting where one colleague, who had been working on a new idea, was updating another colleague on what he was doing. The topic was complex and he was adamant about making sure his counterpart got every detail. Even after the colleague had expressed multiple times that he got the gist of things which was all that was needed as it was just an update, not a handover. Weirder yet, he wasn’t looking at the camera while doing so. Making it look like he was not at all paying attention to the other person’s reactions.  The other person, quite puzzled by all this, shrugged it off but was clearly unsure about what this conversation was all about.

I’m very much an eye-contact person so when people avoid it (or seem to avoid), I immediately notice it. Are they angry? Is something going on? So, afterwards I contacted my colleague privately to ask if he was ok, as it all seemed a bit weird.

What followed was something I had not expected.

After working with Claude on this idea for so long, it had become second nature to him to be curt and directive, making sure every detail was clear. Actively avoiding any wording that wasn’t directly related to the task. He hadn’t realized he was doing the same in the conversation with our colleague. In regard to looking into the camera, working with Claude had never required it so unconsciously, he had shifted his gaze away from the camera, to focus on the text on his screen as was usual while working with Claude.

He hadn’t realized he was doing it but did recognize it when I asked him about it.

Like in many companies, AI has quickly become an integral part of our day-to-day business, from ideation and design to streamlining processes, speeding up research and improving content creation. It is changing the fabric of work, but it seems it’s also changing our ways of communicating with each other.

This is not a new topic. There has been research done on the effects of AI in multiple areas of human interactions. From how cognitive spillover from AI influences shared language, collective attention, shared mental models, and social cohesion by Riedl, Savage, and Zvelebilova, to research of how people collaborate with a partner if they believe that partner is a bot versus a human.

In this last one by Harrell (Duke) and Traeger (Notre Dame), over 4,000 people were asked to play a simple game where players had to choose between cooperating or not, and where going it alone paid more than cooperating but left the other person with almost nothing. Those who thought they were interacting with a bot were noticeably less cooperative than those who thought they were interacting with a human.

The more relevant part came next. The researchers ran a second round in which everyone played against someone they were correctly told was a real person. Those who thought they had been playing a bot in the first round were still markedly less cooperative with the human in the second round than those who believed they had been playing a human before.

No. It has long been established that interaction with someone will likely influence how you interact with the next person you encounter shortly after. We’ve all experienced it. You walk out of a heated argument and the next person you encounter gets their head bitten off, regardless of whether they did anything wrong. The emotional carryover from your last interaction.

The difference is that in those situations there are two human beings interacting. Emotion, actions and arguments that feed each other. With a bot there is no emotion coming back at you, and no real argument unless you ask for one. Furthermore, there is no need for empathy with a bot from the get-go so you already start differently.

There is something else too. When you bite someone’s head off, they push back. They go quiet, they look hurt, or they tell you off, and that reaction is what makes you aware and pulls you back into line. A bot does none of that. Whatever tone you bring to it, it answers pleasantly and carries on. Nothing corrects your behavior. In fact, cordial or overly polite behavior to an AI will sometimes get you sycophantic results. Stimulating a blunt, direct, task oriented, emotionless communication style. Do that for periods at a time and no wonder the changed mode of interaction gets engrained. My colleague had been in that mode for weeks, several hours a day.

Which is, I suspect, what happened to him. Not the empathy part that the researchers measured, but the same direction of travel: what he had practiced with the AI leaked into how he then dealt with a colleague. And the lack of eye contact simply got overlooked, because the AI had never called him out on it.

We all know AI is influencing the way we work but often overlook that it is also seeping into the interpersonal relations we have with our colleagues. And that is something organizations should be aware of and be vigilant on.

Human-human interaction is what team trust is built on, trust that is hard to build, and easy to lose. Acknowledging what someone just said. Noticing they’re uncomfortable. Giving them the benefit of the doubt when a message comes across blunt. Those are exactly the things being worn down here when interacting with AI for longer periods.

And none of it shows up anywhere. There’s no dashboard for it, and nobody files a ticket to say a meeting felt cold. People might be hesitant to even call each other out on it. Worst yet the people it affects most are your heaviest AI users.

Use AI less? Nope, that’s no solution, that’s simply closing your eyes to reality. Instead, drive awareness. Focus on building interpersonal skills within your team and say something when you notice it in a colleague. Privately and without making it a thing. My colleague hadn’t noticed it himself at all and wasn’t the least bit defensive. He was rather intrigued by it himself to be frank.

Also, ask someone you trust to tell you if they spot it in you, because you won’t catch it yourself. That’s kind of the whole point of the story.

And lastly, consciously make an effort to look at people, even if just through a camera. Not only does it make other people feel acknowledged and seen, it also allows you to see the (non-verbal) effects of what you are saying.

Collaboration within organizations has been my topic for the last 20 years. How AI is changing it, from how we communicate, to how we work together, to how we share what we know, is one of the biggest shifts I’ve seen in all that time. And it’s happening largely undetected within most companies. Like in this example where it changed both the way this colleague:

So, what about you? Is any of this remotely recognizable? And if so, what are you seeing happening around you?cognizable? And if so, what are you seeing happening around you?

Here’s the short version of why it matters, for anyone who doesn’t spend their days thinking about information security: ISO 27001 isn’t a badge you put in a footer. It’s proof, checked by an outside auditor, that we handle customer data, partner data, and our own systems with a real, repeatable process, not just good intentions. For a company that works inside other people’s IT environments every day, building software around HCL Notes and MS Teams, that’s not a nice-to-have. It’s the whole basis of the trust customers and partners put in us.

This wasn’t a one-year project, not really. Getting to certification took close to four years, but we weren’t starting from zero. We already had a lot of the substance: security practices, technical safeguards, and know-how that had grown organically over years of running a software company responsibly. What we didn’t have was all of it written down, structured, and provable to an outside party. So a good part of those four years was learning what an ISMS formally requires and taking stock of what we already had against it. The last year is where that turned into concrete work: documenting and tightening policies, running formal risk assessments, reviewing suppliers, building out incident response plans, and doing internal audits where we went looking for our own gaps before anyone else did. It was less about building security from scratch and more about making it visible, consistent, and audit-ready. The external audit, carried out by the Österreichische Computer Gesellschaft (OCG), was the last step, and the one that mattered most. Everything we’d built either held up under scrutiny or it didn’t. It held up.

None of this happened in one department. IT, development, HR, legal, and management all pulled their weight, answered the awkward audit questions honestly, and fixed things without being asked twice. That’s the part I’m most proud of, not the certificate itself, but that so many people took it seriously and made it real. Thanks are also due to the OCG and their auditor team. The audit itself was thorough but genuinely collaborative, and that made a demanding process a lot easier to get through. And because after the audit is before the audit: this certificate isn’t a finish line, it’s a checkpoint. The ISMS keeps running, the risks keep getting reassessed, and the next audit is already somewhere on the calendar. The work doesn’t end here, we’ll keep improving.

For panagenda customers, however, there is one particularly important fix: HCL has resolved an issue where the MarvelClient configuration database specified through NOM_MC_DB in notes.ini was not being utilized. This restores the expected behavior for environments using a custom MarvelClient configuration database.

There are no new features in this release. HCL describes 1.0.21 simply as a bug fix release. The update addresses twelve issues across HCL Nomad for web browsers.

One of the fixes is particularly relevant for environments managed with panagenda MarvelClient:

NWASM-10172 | KB0131809

This issue was introduced with HCL Nomad Web 1.0.20. As described in our information about the previous release, Nomad Web 1.0.20 did not correctly honor the NOM_MC_DB setting. As a result, environments where MarvelClient used a configuration database with a non standard database name or path could experience problems because Nomad Web was unable to locate the configured MarvelClient database.

With version 1.0.21, this has been fixed.

This is particularly important in larger environments where the MarvelClient configuration database is intentionally located at a specific path or uses a customer specific database name. The database should not have to be renamed or moved simply to accommodate Nomad Web.

Administrators can use a Domino Desktop Policy to set the NOM_MC_DB value in notes.ini and point Nomad Web to the required MarvelClient configuration database. With the fix in 1.0.21, Nomad Web once again respects this setting as expected.

For customers affected by the issue in 1.0.20, upgrading to 1.0.21 therefore restores the intended configuration and removes the need for the temporary MC_DB workaround that was available for the previous release.

In addition to the MarvelClient related fix, HCL Nomad Web 1.0.21 contains the following corrections:

The complete details are available in the HCL Nomad for web browsers 1.0.x Release Notes.

HCL Nomad Web 1.0.21 is available through the My HCLSoftware Portal. HCL announced the release on September 15, 2026.

My HCLSoftware Portal

HCL Nomad Web 1.0.21 is a focused maintenance release with no new features, but it contains several useful fixes for stability and compatibility.

For panagenda customers, the most important change is the fix for NOM_MC_DB. Nomad Web once again honors the MarvelClient configuration database specified in notes.ini, including environments where the configuration database uses a customer specific name or path.

If you are using panagenda MarvelClient with HCL Nomad Web, upgrading to 1.0.21 is therefore particularly relevant. The fix ensures that the existing NOM_MC_DB configuration can be used as intended without requiring changes to the MarvelClient configuration database itself.

This year, Let’s Connect is coming to the Nordics once again, with events in Oslo on October 20 and Stockholm on October 22. Both events bring together customers, the HCL community, HCLSoftware experts, business partners and enthusiasts to share what is new, what is coming next and, perhaps even more importantly, what is actually happening in the real world.

And that is exactly what I like about Let’s Connect.

One of the things I personally love about the format is the single track.

There is one room, one agenda and one session happening at a time. No need to stare at a conference schedule and think: “That sounds interesting, but so does the other session. Which one should I miss?”

You simply sit down, listen, learn and enjoy the next session.

And then there is the timing.

The regular sessions are just 20 minutes long. That may sound short, but I think it is one of the strengths of the event. Twenty minutes is enough time to get a focused insight, see a demo, hear about a new technology or learn from someone else’s experience, without turning every session into a lengthy presentation.

It keeps the day moving. It keeps things interesting. And you get a lot of information in a relatively short amount of time.

The agenda covers many of the topics that are currently shaping the HCL ecosystem.

HCLSoftware executives and product managers will share the latest developments and give insights into where Domino and the broader Domino+ portfolio are heading. Topics such as Domino Workspace, digital sovereignty, Agentic AI and Vibe Coding are also part of the programme.

But what makes Let’s Connect particularly interesting is that it is not just about HCL.

The agenda also brings in people from the community and from the partner ecosystem, with practical experiences, ideas, demos and discussions around how these technologies can actually be used.

And there is a nice little detail for anyone considering attending both events: Oslo and Stockholm do not have exactly the same agenda. There are sessions that are specific to one city, while other sessions appear at both events. So if you happen to have the time and opportunity to attend both, you will get a slightly different experience in each location.

I am particularly looking forward to this year’s Let’s Connect because panagenda is a sponsor again and will be there in person.

I will also be on stage for a 20 minute session called “From Domino Data to AI Insight: panagenda’s Journey So Far”.

I will be sharing what we have explored around AI over the past 18 months, what worked, what did not, and how we see AI integrations adding real value to existing Domino data, applications and tools. There will also be some demos, because sometimes seeing something in action is much more useful than talking about it.

But honestly, the session is only one part of why I am looking forward to being there.

For me, Let’s Connect is really about the people.

I have attended Let’s Connect twice before, and 2026 will be my third time.

And I love it.

It is one of those events where you can have a technical discussion in the morning, bump into someone you have known from the community for years during a coffee break, talk about a completely different topic over lunch and then continue the conversation again in the afternoon.

There is a great atmosphere around the event, and that is something you cannot really recreate with webinars, online meetings or presentations.

You can ask questions.

You can challenge ideas.

You can share experiences.

You can talk about the things that worked, the things that did not work and the things that perhaps nobody has figured out yet.

That exchange is incredibly valuable.

And then, after a full day of sessions, there is the Get Together, which is another great opportunity to simply spend some time together, continue conversations and meet even more people from the community.

Because ultimately, that is what the name says: Let’s Connect.

If you are somewhere in Europe, this is a fantastic opportunity to bring the year to a close with one more deep dive into the HCL ecosystem.

And of course, you do not have to be from the Nordics to attend. If you are travelling from somewhere else in Europe or even from further afield, you will be very welcome.

So if you are interested in HCL Notes, Domino, Nomad, Sametime, Connections, Domino Workspace or related technologies, and you want to hear what is new from HCL, learn from business partners and community members, exchange experiences and spend some time with the people who make this community what it is, come and join us at Let’s Connect 2026.

Oslo
October 20, 2026
8:30 AM – 5:30 PM
Kulturhuset
Youngs gate 6
0181 Oslo, Norway

Stockholm
October 22, 2026
8:30 AM – 5:30 PM
A house Katarinahuset
Stadsgården 6
116 45 Stockholm, Sweden

Before I wrap this up, I also want to say a big thank you to the team behind Let’s Connect.

Wannes Rams, Arne Nielsen, Ulf Stider and everyone else involved in making these events happen: you are doing a fantastic job.

The events so far have been absolutely great, and the atmosphere, the content and the community you bring together really make Let’s Connect something special.

So, thank you for all the work you put into it. I really appreciate it, and I am already looking forward to seeing you all again in Oslo on October 20.

See you there! Let’s Connect!

All of that is necessary. But they all have one glaring omission. 

Think about the following: in many tenants, the most visible AI output is not a Copilot chat prompt at all, it’s the meeting recap that appears automatically after every meeting: The Intelligent Teams meeting recap. Depending on licensing and usage, it may well be the most used Copilot feature you have, responsible for:

Basically, all of this rests on a single item: the quality of the audio capture. 
Now, the transcript is not a document that anybody curated. It is a computer generated transcript in real-time, captured through whatever microphone, room and network path each participant happened to be using during that meeting. So, the quality of the capture determines the quality of all that is derived from it.

So who is actually governing that? 
 

I am not a Copilot readiness person. But from my understanding, the readiness conversation rests mostly on two pillars, and both of them are about data that already exists. 

Data access asks who may see what Copilot produces. Data quality asks whether the stored content is accurate and current. The owners of these two pillars are usually different people and often in different departments. 

What is missing in my eyes is a third one: Capture quality.  
Was what we recorded and transcribed actually faithful to what happened in the meeting? 

Now you could argue that capture quality is just part of data quality. Conceptually you would be right. However, I would still keep it separate, because of one property it does not share with the other two: it cannot be remediated afterwards. 

An error in a document can be updated or deleted next week. A wrongly assigned permission can be corrected. Both of those workstreams are retrospective and repeatable.  
A meeting that was captured badly cannot be re-captured. There is no easy second pass and no cleanup and no “we will fix it in phase two” as the recording and transcription are already unreliable.  The Meeting organizer can, in theory, run through the transcription and adjust it, but what you cannot do is re-capture the audio. And that is where the loss has already happened.

That asymmetry is worth discussing. Two of the three inputs to Copilot are fixable later. The third one you get exactly one attempt at, it happens live, thousands of times a week, and usually nobody is watching. 
  

A Teams meeting produces a single transcript. It is generated in the cloud, from the audio as the cloud service receives it. There is no per-attendee version. Everybody reads the same text. 

That single fact splits network impairment into two categories: 

Incoming impairments: Your inbound audio stream degrades. Bad home Wi-Fi, everybody sounds like a robot, you miss half of the discussion. Your experience is ruined, but the transcript, though, is unaffected and the service already had everyone’s audio cleanly. 

Outgoing impairments: Your outbound audio stream degrades. Packet loss on your send path or simply using a faulty microphone. Your audio arrives at the transcription service degraded, and that degradation is written into the shared transcript. Permanently. For all thirty attendees and for every AI agent that consumes it afterwards. 

So Poor Call Rate and transcript integrity are actually pointing in different directions. You can drive the first one down and still learn almost nothing about the second one. The only way you can is if you know what the AI agent’s experience is.

The picture below indicates that the recording bot service in the cloud had issues in receiving a good audio media stream in a specific meeting. Exactly the thing you want to capture but that most tools won’t. Nor will Copilot tell you it struggled. It will simply interpret what it ‘gets’, good or bad without ever raising an alarm. Producing a transcript that might not be what you expected….

What causes the call quality for a participant or AI agent to fail is a topic of its own, and not the focus for this article. 

And here is what I think should be brought up. Governance actually makes defective transcripts more dangerous, not less. A retention policy commits you to keeping it. A sensitivity label dignifies it as an official record. eDiscovery guarantees that somebody will find it in three years. And unlike a wrong number in a spreadsheet, you cannot spot a bad transcript by reading it. A confidently mis-transcribed sentence reads perfectly. So, we end up applying enterprise strictness to something whose accuracy nobody ever validated. 

You don’t necessarily need a new program. You mainly need to add one pillar to the existing two, and measure the distribution. Which users, sites, networks, rooms or even recurring meetings are systematically producing audio that the AI Copilot layer shouldn’t really be trusted on?  

That is a cohort question, and whereas the original bad capture can’t be fixed, cohort findings allow you to remediate the causes and prevent future capture issues. For example by replacing old headsets or fixing Wi-Fi coverage, etc.

Key elements to improve capture quality:

Data access asks who may see it. Data quality asks whether it is accurate. Capture quality asks whether we heard it correctly in the first place and it is the only one of the three that you cannot go back and fix. 

Bad audio used to be a user experience complaint. Meanwhile it has quietly become a AI data quality problem where more and more crucial Copilot functionality depends on, and I think it belongs on the governance checklist. Capture quality is the one pillar where the only available action is measurement, not remediation. So, perhaps it’s time to start adding that to your Copilot readiness program .

Disclosure: I work at panagenda. Our TrueDEM product measures inbound and outbound media stream quality per call and per participant, including the recording and transcription agent. Feel free to reach out if you want to know more.

Only after starting the upgraded Notes client did the real problem become visible: optional Eclipse/RCP components were missing.

Embedded Sametime was the most noticeable example, but the issue was not limited to Sametime. Other optional plugins managed through the same installation mechanism could also be removed, leaving the Notes client in a state that no customer should receive after an apparently successful enterprise deployment.

Finding the reason took us several days.

Most troubleshooting processes begin with the obvious questions:

In our case, the MSI completed normally. That made the issue particularly difficult to diagnose.

From the perspective of the deployment system, the upgrade had succeeded. From the perspective of the resulting Notes installation, however, something had gone seriously wrong: optional components that should have remained installed were removed during the final stages of the installation process.

This is an important distinction for enterprise deployments. A successful MSI return code confirms that the installer completed its work. It does not necessarily confirm that the final Notes client contains every component you expected.

The issue occurred at more than one customer, but our first laboratory tests did not reproduce it.

That was confusing. We used the same Notes versions, the same installation packages and comparable command lines. Yet the upgrade worked perfectly in the lab.

The reason turned out to be something many of us naturally do when testing software installations: we start with a clean system.

We removed old installation data, cleaned temporary directories or reverted virtual machines to a known state. That is normally good practice, but in this case it also removed the exact condition required to reproduce the defect.

We therefore changed our testing approach. Instead of preparing perfectly clean machines, we created virtual machines that had gone through previous Notes installations and upgrades. We deliberately stopped cleaning temporary installation data and began reproducing the installation history more accurately.

That was when the pattern finally became visible.

The problem occurs when the TEMP directory of the account executing the Notes 14.5.1 installer still contains the following file from an earlier Notes installation:

rcpInstallerTemp.properties

This distinction is important: we are talking about the TEMP directory of the executing security context, not necessarily the TEMP directory of the currently logged-on user.

For example:

Temporary directories belonging to administrative accounts, service accounts or Windows SYSTEM are frequently not cleaned on a regular basis. A file created during a previous Notes installation can therefore remain in place for months or even years.

When the Notes 14.5.1 installer encounters this outdated rcpInstallerTemp.properties file, it may interpret the information inside it as valid state for the current installation.

Based on our analysis, this stale installer state can affect the final component-removal phase of the Notes 14.5.1 installation. The installer then concludes that optional Eclipse/RCP components should be removed, even though this does not reflect the intended configuration of the current upgrade.

The result is an installation that technically completes, but produces the wrong client configuration.

The Windows installation process changed significantly with HCL Notes 14.5.1.

A substantial part of the previous RCP installation logic was redesigned. Content is extracted and installed, after which the installer determines which optional components should be retained or removed based on the selected configuration.

There is nothing inherently wrong with this approach. The problem is that temporary state from a previous, independent installation must not influence the decisions made during the current installation.

In earlier installer generations, including the versions we examined from the Notes 12.0.x, 14.0.x and 14.5.0 streams, the temporary properties file was removed/cleaned early in the installation process. That prevented state from an older installation from being reused accidentally.

With Notes 14.5.1, this cleanup appears to be missing. The installer can therefore consume an outdated file that was never intended to survive beyond the previous installation run.

This is also why the issue can be so difficult to identify:

In our tests, the problem was not tied to a specific Notes 12.0.2 Fix Pack. It was also independent of whether the previous Notes installation was 32-bit or 64-bit.

Organizations should pay particular attention when the following conditions apply:

This makes the issue especially relevant for enterprise software distribution.

Manual test installations are often performed with relatively clean user profiles. Production deployments, on the other hand, commonly run through accounts and services that have existed for a long time. Their temporary directories may contain artifacts from numerous previous installation attempts.

The conditions found in a production deployment can therefore be very different from those in a clean test environment.

Before starting an HCL Notes 14.5.1 upgrade, remove the following file from the TEMP directory of the account that will execute the installation:

rcpInstallerTemp.properties

The crucial part is identifying the correct execution context.

Deleting the file from your own user profile will not solve the problem when the installation is actually performed by Windows SYSTEM or by a separate deployment account.

The safest approach is to include a pre-installation step in the deployment process that:

After removing the outdated file, we were no longer able to reproduce the unwanted removal of the optional Eclipse/RCP components.

Once we had isolated and reproduced the issue, I opened a support case with HCL and provided the technical findings, affected scenarios, suspected root cause and proposed workaround.

I also explicitly asked HCL to publish a public defect article. This was important to us because the installation does not visibly fail, making it extremely difficult for other customers and partners to identify the cause independently.

HCL has now published the following article:
Notes 14.5.1 Upgrade Removes Sametime Plugin — HCL Defect Article KB0132505

Although the article title refers specifically to Sametime, administrators should keep in mind that Sametime is the most visible example of a broader issue involving optional Eclipse/RCP components.

Publishing the article makes the issue searchable, gives customers an official reference and documents the required workaround. We have also asked HCL to address the underlying behaviour in a future Notes installer release.

At the time of writing, we hope that a permanent correction will be included with HCL Notes 14.5.2. Ideally, future installer versions will either remove obsolete state reliably at startup or use a unique temporary directory for every installation process.

Customers using the current version of MarvelClient Upgrade 14.5.22 and higher are protected against this Notes 14.5.1 upgrade scenario.

We have already updated MarvelClient Upgrade to handle this scenario automatically. Before the HCL Notes 14.5.1 installation is executed, MarvelClient Upgrade removes or avoids the outdated temporary installer state that triggers the problem.

As a result, the issue described in this article cannot occur when the upgrade is performed using the current MarvelClient Upgrade version.

As always, customers should ensure that they are running an up-to-date MarvelClient release before beginning a major Notes client upgrade.

More information is available on the MarvelClient Upgrade Release Notes page.

This case is a good reminder that installation problems do not always produce installation errors.

The most difficult defects are often caused by invisible state: an old file, a persistent service account, a temporary directory that is not really temporary or a previous installation that continues to influence the next one.

Clean laboratory environments remain essential, but they do not always represent the history and complexity of real enterprise endpoints. Sometimes the decisive troubleshooting step is to stop cleaning the test environment and reproduce the imperfections of production instead.

For organizations deploying HCL Notes 14.5.1 without MarvelClient Upgrade, add the removal of rcpInstallerTemp.properties to your pre-installation checks.

For MarvelClient Upgrade customers, the current version 14.5.22 and higher already takes care of it.

In this post we break down what’s inside Fix Pack 1, group the fixes by area, and help you decide whether to roll it out.

HCL’s release notice states that Notes/Domino 14.5.1 FP1 contains fixes for approximately 46 known issues. The public Notes/Domino Fix List currently shows 49 entries for the release — a small discrepancy that is entirely normal, since the fix list is maintained continuously and entries can be added after the release notice is written. Either way: a solid, focused Fix Pack.

Fix Packs are always cumulative and language independent, so FP1 can be applied on top of any language version of a 14.5.1.x installation. The selection criteria are unchanged: low-risk, high-impact fixes addressing defects that affect the broadest set of customers, plus proven hot fixes, security patches, and JVM updates. Translation fixes are explicitly not included.

Here is the breakdown by area.

This is the biggest block in FP1 with eleven fixes — and it is where most 14.5.1 users will feel the difference immediately.

If you want the full, always-current list of included fixes and SPR numbers, you can find it here in the HCL Fix List.

FP1 also carries six Embedded Sametime fixes. These are tracked separately from the Notes/Domino Fix List, so they are easy to miss but if your users live in the chat window, this is the part of the release notice worth reading twice.

That last one deserves a moment of silence. Three minutes to open a chat window is enough time to walk over to your colleague’s desk and ask them in person.

Nothing dramatic changed here, but a few points are worth confirming before you roll out:

Full details are in HCL Notes 14.5.1 and 14.5.1 FP1 System Requirements (KB0128971).

You can download HCL Notes and Domino 14.5.1 Fix Pack 1 from the HCLSoftware download portal.

Yes and with less hesitation than usual.

The shape of this Fix Pack is a large portion of the fixes which are regressions introduced in 14.5.1 itself. The blurry action bars, the shrunken Preferences font, the Application dialog that forgot its size, the local database copy performance hit, the printers that stopped printing because of the new OTF Inter fonts. None of these will take down your environment, but every one of them generates help desk tickets, and collectively they make 14.5.1 feel less polished than it actually is.

On the server side there is real substance too: the NIFNSF .ndx orphaning fix, the NSFCloseOpenContainers memory panic, the DBMT compactor error, and two OIDC fixes one repairing chained Identity Provider configurations broken by HTTP tell commands, the other adding OIDC_LOGIN_COOKIE_UNLIMITED_DURATION for anyone who has been fighting the 15-minute cookie limit. Add the S/MIME-over-quota fix, the RFC 3464 DSN compliance correction, and the updated Semeru JVM with 2026b timezone data, and the case is straightforward.

My advice: schedule it. Test it against your own application landscape first as always but there is no template change to worry about in this one, and the risk profile is exactly what a Fix Pack should be. If you are still on 14.5.1 GA, you are running a version with a known list of annoyances that already has a fix.

For a MarvelClient Upgrade customer, integrating Fix Pack 1 into your Notes 14.5.1 client setup is very easy. If you would like assistance, or are interested to learn more about MarvelClient Upgrade, reach out and let’s connect.

Ok, granted. Statistically that minor glitch in your last Teams call probably didn’t cost you a customer or relation. But recent research by Brucks et al. from Columbia University shows, that the impact of glitches on video call outcomes is much bigger than most of us suspect, and that it isn’t at all unlikely that a glitch is having more negative effects than you may realize.

And no, we’re not talking about fully broken up calls or completely buggy sessions. We’re talking about minor glitches of just a second or two that can already significantly change how the other person judges you or you judge them.

I’ve been working in digital collaboration for over twenty years. I was there when phone conferences over land lines were still novel, and video conferencing was just a distant dream.

One of my most frustrating memories of that era was having to run a software training for a team spread across Antwerp, New York, Brazil and South Africa…. By phone.

Not just because they couldn’t see what I was doing. Mostly because I couldn’t see them. I simply couldn’t tell if they were following or completely lost. And when two of the New York team members got into a full-blown argument with each other live on the call, one walking out with a door-slam I could hear across three continents, I was completely blind and unable to do a thing about it.

That door slam taught me more about collaboration than any training I ever got. Human collaboration runs on signals we don’t even consciously process. Facial expressions. Micro reactions. The slight shift in someone’s posture when they disagree but haven’t said so yet. Strip those away and you’re not just losing convenience. You’re losing the connective tissue that holds collaborative conversations together.

It’s probably why phone conferences never got the popularity video calls later would have. People kept meeting in person because nothing beats the ability to look each other in the eye.

Tools like Zoom, Webex and Teams revolutionized how we meet. Suddenly we could have that face-to-face without the hassle of finding a free meeting room or booking a flight. The pandemic then solidified what was already exploding onto the corporate market, into everyday life. Kids attended class virtually through Teams. Patients had Zoom video consultations. Families stayed connected through digital meetups. The result? Most of us now regularly have online meetings.

Is it the same as in person? No. But overall, it’s a solid replacement with the pros generally outweighing the cons. Less travel, less time, less physical space required. Worth the trade off.

Or so we thought.

Here’s where the research mentioned before becomes interesting. Seventy percent of people think glitches during video calls have little to no impact on how they evaluate the other person. The researchers tested this and found that that is a wrong assumption. Digital glitches in video calls play a big role in how we perceive the other person.

This underestimating of the impact of digital disturbances is not a new phenomenon. People’s stated tolerance for technical problems is almost never a reliable indicator of how those problems actually affect their behavior. I’ve seen this pattern countless times in software adoption work. Users say the tool is fine. Then you look at the data and see they quietly stopped using a feature three weeks ago.

The same mechanism is at work here. You think you’re being rational and fair. Meanwhile your gut has already filed the other person under ‘something was off about them’ and moved on.

When we think about what makes a video call go wrong, we tend to think about the obvious stuff. The call that drops entirely. The audio so bad you give up and switch to phone. The lag so severe that everyone talks over each other for ten minutes.

But that’s not what this research looked at.

It specifically tested minor glitches. Brief freezes. Fleeting moments where the video pixelates or the audio cuts out for a second. The kind of thing most of us shrug off before the call even ends.

And the results are genuinely surprising.

A freeze that lasts one to two seconds is actually often more damaging to how you are perceived than one that lasts longer.

Let me repeat that. The shorter glitch often does more harm.

The researchers tested this directly. Longer glitches scored higher on disruption. People noticed them more consciously and rated the call as glitchier. But it was the shorter, fleeting glitches that scored higher on what the researchers call uncanniness. And uncanniness, not disruption, is what drives whether you trust the other person.

It does make a difference what type of glitch it is. When it comes to video loss longer video loss also scores badly. Tying in directly with the fact that the part of ’seeing the other’ is key here.

This is where the research gets really interesting. And where I think a lot of organizations get it fundamentally wrong.

We assume a glitch bothers us because it disrupts the flow of the conversation. Or because we missed something that was said. Both of those things can happen. But they are separate problems with separate effects.

The research separates glitch impact into three distinct things:

And uncanniness is the one that does the real damage. Even when you understood every word. Even when the disruption was barely noticeable. That eerie, slightly off feeling bleeds directly into whether you trust someone, whether you want to work with them, whether you believe what they are telling you.

Remember those nineties sci-fi films where a seemingly normal face suddenly glitches to reveal the robot underneath? That image is closer to the truth than it might seem.

The research found that glitches only trigger uncanniness in calls where you are looking at someone’s face. When screen sharing was active and faces weren’t visible, the same glitches occurred but the uncanniness scores were significantly lower. Suggesting that the harm came specifically from the combination of a human face and technical disruption or as the research calls it: Social presence.

It is not the technical failure itself that does the damage. It is the broken illusion of human presence. Video calls work because they create the feeling of sitting across from another person. When a glitch shatters that feeling, even for a fraction of a second, something shifts. And it does not easily shift back.

To test this, the research looked at real world consequences across multiple contexts. Job interviews where glitches reduced the likelihood of a candidate being hired. Telehealth consultations where trust in the doctor dropped measurably if the call was glitchy. And perhaps most starkly, parole hearings where people on calls where glitches occurred were granted parole twelve percentage points less often than those without.

Twelve points. For a minor freeze. In a situation that determines someone’s freedom.

That is not a nuisance. That is a real, invisible impact on human outcomes.

This gets to something I feel strongly about. True digital collaboration success is only obtained when the human element stays intact and takes pride of place.

We don’t just sign contracts because the slides were good. We don’t like to follow medical advice from an AI. We don’t invest our money because the pitch deck was solid. For a large part, we decide those things because we trust the person presenting it to us.

This isn’t new. I once worked with an B2B importer where management wanted to replace the calls their sales team made to notify corporate customers of incoming orders with automated emails. It would save time. It was logical.

The sales team pushed back hard. And they were right to. For them, that innocuous call, simply telling a customer their order was on the way, was one of the rare chances they had to speak with a decision maker without immediately triggering a defensive response. No sales agenda. Just a human moment. That was where rapport was built. Where trust was quietly accumulated. Trust that could result in a favorable outcome during the next negotiations.

Automating wouldn’t have just changed the process. It would have removed the human signal and therefore that chance to build trust from the situation entirely.

Glitches seem to do something similar. They don’t block the information. They corrupt the signal that says this is a real person that you can trust.

Companies increasingly understand the importance of software like Teams, Zoom and Webex for their communication. But the prevailing assumption is still that as long as it performs well ‘most of the time’, it is good enough. Hit the uptime targets. Stay within latency thresholds. Keep packet loss below the acceptable percentage. Green dashboard, job done.

This research proofs otherwise.

A call can be technically within spec and still feel subtly wrong to everyone on it. The frozen face that lasted a second and a half. The audio that cut out just as someone made their key point. Even though it’s small, its impact can be massive. This is why organizations shouldn’t downplay the reliability of their collaboration software and invest in good user experience monitoring.  

A platform with high adoption numbers and quietly degrading call quality is not a success story. It is a slow leak as the cost of poor digital experience is not just measured in downtime. It is measured in trust lost, deals not closed, candidates not hired and patients who walked away with doubt instead of confidence.

Minor glitches. Major consequences.

That is not a network problem. That is a management problem. And it starts with deciding that good enough is not, in fact, good enough.

Two headline items ship in 1.0.20: Kiosk Mode and File → Export on Firefox. The rest of the release is stability and security work more on that further down.

Kiosk Mode lets you nominate a single database that always opens on startup and cannot be closed. Think shop-floor terminals, reception check-in screens, warehouse scanners, training rooms anywhere you want people to land in one app and stay there, without the temptation to wander off into the rest of the Notes world.

A word of warning before anyone gets too excited, and HCL says this plainly in the documentation: Kiosk Mode is a user interface feature, not a security feature. It controls what the application looks like and hides the escape hatches, but it is not a lockdown mechanism you should rely on to keep a determined user out of something. Treat it as “shape the experience,” not “secure the endpoint.” For real restrictions, that is still a job for policies and panagenda MarvelClient.

And yes if the old resetNomadInstance=1 trick from 1.0.17 was the “Kiosk Light Mode,” this is the real, full-fat version.

Enabling Kiosk Mode is a two-part handshake. Both parts have to be in place one without the other does nothing.

First, the database you want to run as the kiosk needs a kioskDB profile document. This profile is what tells Nomad “I am a kiosk app” and carries all the behavior settings (what to hide, whether to open the Workspace, and so on). HCL’s documentation walks through creating it with a small LotusScript agent that writes the profile via GetProfileDocument("kioskDB", "") you run it once against the target database and it stamps the profile in place. There is a matching cleanup agent to remove the profile again if you ever want to take a database out of kiosk duty.

Second, the client has to be pointed at that database using the kioskDBName value in notes.ini. This is the part people forget: the presence of the profile document alone is not enough without the kioskDBName pointer, nothing happens. If the kiosk database lives on a server, use the server!!pathname format (for example CN=myserver/O=mydomain!!AppDirectory/KioskApp.nsf); if you are running against a local replica, just use the local file path (for example /data/KioskApp.nsf). In a managed environment you will almost certainly want to push kioskDBName out centrally rather than touching every client by hand panagenda MarvelClient is the obvious tool for that.

The kioskDB profile is where the fun lives. Through it you can decide whether to hide the application menus, hide the help menus, hide the Recent Apps page and hide the Sametime icon, whether to open the Workspace on startup, and whether to hide the properties panel. You can also rebrand the HCL Nomad: swap the application name for your own logo text, or replace the application icon with your own logo image (the two are mutually exclusive if you set both, the icon wins). Between those switches you can go from “normal Nomad with a locked-open app” all the way to a stripped-back, branded single-purpose terminal. For the full option list and the sample agents, HCL’s Kiosk Mode documentation is the place to look.

The quieter of the two new features, but a welcome bit of consistency: File → Export was already available on the other supported browsers, and now it works on Firefox too. If Firefox is your standard browser, exporting is no longer the odd one out.

Beyond the new features, 1.0.20 ships 11 fixes, and this batch leans noticeably towards security. There are patches for known CVEs in zlib, libpng, yaml, and Lodash, plus a fix for a Nomad server crash on launch with Domino 14.5.1 when OIDC backchannel logout is enabled worth flagging if you are on the newest Domino. There are also some very visible day-to-day fixes, like gray form and table-cell backgrounds no longer rendering as white. The full list, with links to each Knowledge Base article:

You can find the complete, cumulative list in the HCL Nomad for web browsers 1.0.x Release Notes.

Every release has its little quirk, and here it is one that hits panagenda MarvelClient users directly so consider this a heads-up. In 1.0.20, HCL added some optimizations for how NOM_-prefixed notes.ini values are handled, and one of those optimizations quietly removed a code path that was still needed. The result: if you point Nomad at your MarvelClient configuration database using NOM_MC_DB (as described in Configuring MarvelClient for Nomad), that database is not picked up. Not ideal if you rely on it to manage your clients.

The good news is the fix and the workaround are both simple. The workaround is to use the MC_DB value instead same thing, just without the NOM_ prefix and your configuration database is honored again. And HCL has already restored the missing code path, so this will be resolved in 1.0.21. Details are in KB0131809. Customers who want to keep using NOM_MC_DB need to contact HCL support and open a ticket to get a hotfix.

The MC_DB workaround isn’t great for everyone, the whole point of the NOM_* variables was that they are Nomad specific and won’t affect rich clients.

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

HCL Nomad Web 1.0.20 is a short changelog with a long reach. Kiosk Mode is the standout a genuinely useful way to turn Nomad Web into a locked-open, single-app terminal, as long as you remember it is there to shape the experience and not to secure it, and that it takes both the kioskDB profile and the kioskDBName notes.ini pointer to switch on. Add File → Export on Firefox for a bit more cross-browser consistency, and a solid round of security and stability fixes on top, and this becomes an easy release to recommend especially if you run shared or kiosk-style deployments, or you are already on Domino 14.5.1. Just keep the NOM_MC_DB quirk in mind if you manage clients with panagenda MarvelClient: switch to MC_DB for now, or wait for 1.0.21 where it is already fixed.

First, the part nobody put on the agenda. Mercedes-Benz World in Weybridge turned into a furnace. 42 degrees on Wednesday, 40 on Thursday. No session covered it. Every attendee lived through it. If you were there, you know exactly what I mean.

The reaction that came up again and again: people were surprised at how well TrueDEM can do intra-call analytics in real time.

Most teams are used to working with CQD. It gives you aggregated quality data and solid trend lines. But you read it after the fact, and it works at the level of the aggregate, not the live call.

TrueDEM works while the call is happening, collecting data and making it accessible to you right away. We see the call as the user experiences it, in real time, with real data from the endpoint. For a lot of visitors that was a genuine shift. They are used to looking back at aggregated numbers. We let them watch the call as it unfolds with full insights.

AI was the thread running through the whole event. It was the subject of the opening keynote. It was on stands across the floor, from intelligent call routing to AI based call analytics and conversational AI.

With TrueDEM we enhance what AI can do by providing the data underneath it.

One of the things we were able to demonstrate is our prototype of how TrueDEM is able to expose its data through an MCP integration, which means it can feed AI agents directly. By using MCP, TrueDEM is also AI agnostic, so any tool that supports MCP and OAuth, can work with our data. What struck people was not a clever demo. It was the depth and quality of the data we can hand to an AI system. Good answers need good data. That is the part we bring.

One more thing worth mentioning. Our booth sat next to AudioCodes. No coincidence, as the two solutions line up well.

AudioCodes OVOC gives you a strong view of the voice infrastructure: the SBCs, the gateways, the routing layer, and the carrier side of a call. TrueDEM picks up at the user end, measuring the actual Teams client experience across the wider Microsoft 365 stack. Infrastructure health on one side, real user experience on the other. For organizations running Enterprise Voice, the two together cover the full picture.

Last but not least: Thank you to everyone who stopped by our booth at Commsverse 2026. Events like this test the way we explain what we do, and they sharpen it, helping us hone how to further improve our product.

If you want to see what your Teams users are really experiencing, in real time rather than after the fact, or have full fidelity data on any Teams call, that is exactly what TrueDEM was built for. Take a closer look here.

In total, HCL Notes and Domino 12.0.2 Fix Pack 8 contains fixes for approximately 40 known issues. Clearly, deploying the current Fix Pack isn’t just a good idea — it’s essential for keeping a mature 12.0.2 environment stable and secure. Fix Packs are always cumulative, so HCL Notes Domino 12.0.2 Fix Pack 8 includes everything from FP1 through FP7. They are also language independent and can be applied on top of any language version of a 12.0.2.x installation. The selection criteria remain unchanged: low-risk, high-impact fixes that address the defects affecting the broadest set of customers, plus security patches and JVM updates. Here is the breakdown by area.

If you want to see a detailed list of all included fixes and SPR numbers, you can find it here in the HCL Fix List.

You can download HCL Notes and Domino 12.0.2 Fix Pack 8 from the HCLSoftware download portal.

Here, I would make a clear recommendation. HCL Notes Domino 12.0.2 Fix Pack 8 is a cumulative, low-risk collection of fixes that resolves a good spread of real-world issues — replica bloat from orphaned RRV objects, database cache crashes, an SSO/SAML LDAP group-authentication regression, several iNotes/Verse mail rendering problems, and the macOS native memory growth that many client users will appreciate. The SAML/LDAP and security fixes alone make it worth scheduling. Combined with the updated JVM and timezone data, the direction is clearly right. My advice: download and install it.

One thing to plan for: this Fix Pack ships an updated Forms9.nsf template, so if you have customized that template, review it before rolling out.

If you are a MarvelClient Upgrade customer, integrating Fix Pack 8 into your Notes 12.0.2 client setup is very easy. If you would like assistance, or are interested to learn more about MarvelClient Upgrade, reach out and let’s connect.