What's New in Hyland Cloud Update Service: Visibility, Self-Service and a Modernized Portal

[JasonBright]

Keeping Hyland OnBase up to date is what maintains the security, stability and efficiency your organization depends on. Doing it manually is another matter. Managing monthly updates by hand across multiple environments invites errors and delays, and without a consolidated view of the components in your solution, versioning and status are difficult to track and harder still to prove when someone asks about version currency and compliance.

Cloud Update Service (CUS) strengthens the connection between OnBase instances, hosted or on premise, and the Hyland Content Innovation Cloud. It gives you one place to see your OnBase footprint and apply the latest monthly updates to the environments of your choice, at the time of your choice.

What's New in the Q2 2026 Release

This release focuses on visibility, self-service and a modernized administrative experience.

• A dashboard view of your servers. A new grid layout in the Cloud Update Admin Portal shows your OnBase servers and the components installed on each, replacing the server-by-server check.
• Server details that inform your planning. A new detail view, available from Worker details, reports operating system, installed memory, free drive space, number of CPUs, and dependencies such as installed .NET versions. You learn whether a server has the headroom for an update before you schedule the window.
• Installers available in the portal. The latest Broker and Worker installers are available directly in the Admin Portal, so there is no need to track them down on Hyland Community. After initial setup, both stay current automatically.
• A familiar interface. The Admin Portal has completed its migration to Hyland's newest design framework, so CUS now looks and behaves like the other Content Innovation Cloud products your administrators use.

Take control of your OnBase solution's security and performance with Cloud Update Service. 

Learn more: Join the OnBase 26.1: Built for What's Next webinar on September 2, 2026 at 11:00 AM EDT

[MVannLeicester]

Compelling.

This line:

"apply the latest monthly updates"

Should I interpret that to mean that, like the Server Updater, you still cannot do major version upgrades seamlessly?

Asking because...monthly updates aren't the problem, frankly.  Server Updater may take time to get the packages, but once you've done so, with a few minor quirks it's fairly painless.  It's the major version upgrades that (opinion) still need attention.

The other question is how this impacts those that have changed database passwords; because from what I see, that still requires manual intervention anyway.

It also seems to only pull the EXE name instead of a task name (Unity Scheduler) - which would require looking at folder paths to understand multiple Scheduler instances on the same server.

[CurtisFox]

Hi @MVannLeicester - Thanks for the questions and feedback!

You are correct, CUS currently only supports the monthly updates within the same major version (e.g., 25.1.10.1000 to 25.1.25.1000, etc.). We are working towards upgrades within CUS. The first step will be providing general upgrade guidance to help support best practices during upgrades, while surfacing information from your own environment. Then, an upgrade pre-check report tailored to your environment to surface important information such as possible upgrade risks, breaking changes, known issues, and more. We plan to layer in automation of specific upgrade processes to the upgrade guides where it makes sense to help speed that along and eliminate the need to manually download and deploy upgrade packages. This is all on our roadmap and we don't have committed dates for some of these things yet but will be communicating them as they're released. 

For manual database password changes, those are retained by CUS during the update process. For example, when updating core-based applications such as the Application Server, CUS retains all of the configuration files and only updates the assembly bindings. Therefore, connection strings are not modified and will continue to work. For OnBase Thick Client Windows services, CUS handles updating the obClnt32.exe files (as well as renamed Client executables) with the same database passwords configured in your current Client executables. 

You are correct that we primarily look at the install path as that contains the files that will need to be updated. We are in the process of releasing functionality that will allow you to see a count of the number of instances in the main row, as well as the ability to see the instances in a new side sheet. For the Instance Name, we will display the Service Name (not the Display Name) of the Windows service, as shown here:

Please don't hesitate to reach out if you have any additional comments or questions.

Correction: This comment previously incorrectly stated the following: "In the case of multiple Unity Scheduler instances, we would anticipate only one Unity Client executable still." Per current Unity Scheduler documentation, Unity Scheduler instances must each be installed in separate directories in order to avoid issues with Unity Form processing. For more information, see link 1, link 2, link 3. 

[MVannLeicester]

"In the case of multiple Unity Scheduler instances, we would anticipate only one Unity Client executable still"

Wouldn't that risk collision/locking/memory allocation issues?  Not to mention SPOF (Single Point of Failure) risk - one exe failing taking down your entire service system vs. just one solution group?

[CurtisFox]

@MVannLeicester - let me get back to you on that. Looks like a caution was added starting in the 24.1 Unity Scheduler documentation that says not to use the same install path for Unity Scheduler services. When I still worked with the Unity Scheduler on a regular basis, that warning wasn't there. We used to simply run the command line to install additional Unity Scheduler Windows services for other Task Groups using the same Unity Scheduler executable. I don't think that caused any SPOF issues since multiple instances of the executable would be running. However, it's possible that the other issues you mentioned could be the cause for the warning being added to the documentation. I'm following up internally to understand the expectations so I can provide you the best response. 

[MVannLeicester]

If you had a situation where multiple services are calling the same exe at the same time (i.e. after a reboot), I would think it wouldn't consistently work.  Windows is notoriously picky about launching the same exe simultaneously.

It's for this reason that when creating Thick Client services they would all be a different path (and in that case, Hyland had changed the recommendation to even rename the exe to make them distinctly identifiable).

[CurtisFox]

@MVannLeicester, I was able to find the root cause for the following caution being added to the Unity Scheduler documentation: 

This came from an issue with Unity Schedulers processing Unity Forms when multiple instances of the Unity Scheduler service were pointed at the same set of files. See: OnBase: "Could not save Form to file. Please contact your Administrator" errors when multiple Unity .... I confirmed with our internal Unity Scheduler team that there are no other known issues that led to this warning being added to our documentation. 

I will edit my original comment on this post to reflect the current documentation. If, at some point the Unity Forms issue is resolved in the Unity Scheduler (which is a possibility), it may again be safe to install multiple Unity Scheduler instances using the same set of Unity Scheduler files. For the currently available OnBase versions, however, the warning above does apply.

Thank you for bringing this to my attention! If you have any other questions/concerns about the Unity Scheduler, please don't hesitate to post in the OnBase group here on Connect.