jholzhey_bu · Technical Administrator, Bruin Support Services · ✭✭✭✭✭

Not if it doesn't support SAML 2.0. I'm trying to get SAML 2.0 working again in 2026.1 LEGACY.

Most of our team uses either Firefox or Chrome with no problems. Same instance of WHD. Create a new Firefox profile and see what happens.

I need to know more. First, just for context, our Test WHD environment used to be connected to our Test SAML 2.0 solution (OKTA). Then, a while back, I copied the WHD Prod database over to WHD Test to assure a properly configured and (nearly) identical test system. However, in doing that, I lost the ability to properly…

OK, found it. The following features are temporarily unavailable in NextGen WHD. They are continuously available in the legacy Client user interface… Which means I can upgrade, but then disable the new interface so SAML will still work, or no matter what, SAML doesn't work in NextGen?

Wait, what??? So I can't upgrade in accordance with the security alert released last week about the "critical (9.8) bug?" And I read the release notes, but didn't see that part. Lemme take my dyslexia and go read it again.

12.8.8 has tested successfully in our Test env. Waiting for tonight to upgrade Prod.

The "existing link" scenario isn't working. I tested it twice. I unlinked, then linked back up. Only then did I get my points.

This is no longer an option. OAuth 2.0 must be supported by September 2025 or those products (WebHelpDesk) must be abandoned. Deprecation of Basic authentication in Exchange Online | Microsoft Learn Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) - Microsoft Community Hub

So, the migrate.bat process has been completely done away with?

Very funny, team. I had completely forgot. In what day this was.

The answer is User Error. Or User Impatience, which is causing panic, and thus, user error. Then there's the IT student (I work at a university) who can't figure out the basics, and/or wants us to help them with their homework. NO! Then there's the guy who says, "Look, I work in IT...", as if that will give him credibility…

This is actually really good news. Can we import the price from WHD as well? Same data. That counts, right? 

Who's going first??? Rock-paper-scissors?

To add to this, I realize there are times when you may already be logged into MS365, thus never be prompted with the login box. However, perhaps WHD could display a warning whenever it sees that the login prompt was bypassed? I don't know if any of this is possible, but I do know that the consequences of authorizing access…

T'weezy!

Oh! Is that what he's talking about? So the top-level Request Type? If that's it, j.s, it's still just a request type. That's why Save & Email is so important, or maybe come up with an action rule to email a list of recipients based on Request Type and Ticket Type. However, you still have to Save for that to do anything,…

The message coming back over and over is a version issue. It's been fixed sense 12.8.6, I think.

Yeah, what do you mean by it gets assigned to a group?

My advice is to limit admin level to the actual admin and 1 backup. Just because one is a AVP/VP doesn’t mean they need admin access. No admin, no notification. 

If you figure this out, I hope it can help us, too. We have the largest on prem dbase in the org, and I’ve never gotten a suitable answer on how to reduce its size. And I don’t have enough dbase knowledge to do my own maintenance.

If I remember right, permissions for restricting techs to their own tech groups may prevent other tickets from coming up in queues, but if they have the ticket number, I think they can still pull up that ticket. I think. 

From support: "Our development team has fixed the issue, and the resolution will be included in the next release."

From support: "...issue is due to a known defect with the bug number WHD-6271, that our development team has prioritized a fix according to the severity and scope of impact."

OK, good. This is exactly what I assumed. And we admins have been doing it for them, since we don't want 120 sysadmins.

Then they have no problems. That how our newer techs are set up.

In my ticket, I told them that I think the solution is to NULL out all the tech passwords (hashes), because those with no password have no problems. I already tried once, but the tech table field for password apparently isn't the only place it's saved. All of this because it's not OKTA that is the problem, it's the fact…

Ticket submitted, #01995729

Ticket submitted. #01995607

Interesting. We did indeed have an issue with our LDAP connections not too long ago, and I had to re-save every single one. 27 of them. A through Z, and then 1 for Employees. The problem is, when I tried replacing the password in one of the affected tech accounts (enable PW settings, change PW, disable PW settings),…