The feature existed. The switch was on their side.

A ServiceDesk Plus admin noticed a security gap: when an account was disabled in Azure AD, the corresponding SDP login stayed active. Disable a departing employee everywhere, and the service desk quietly remains a door left open. He asked the community how to close it.

The answer he eventually pieced together, documented across a patient thread on r/ManageEngine, is a small saga. The capability existed, but it was not in any settings page. It had to be enabled "on the back end," by support, invisibly. A knowledgeable commenter confirmed the underlying behavior from the product's own documentation: SDP checked the account-enabled flag only at import time, and later disabling in Azure did not revoke the login; the one related control was tied to a different state entirely.

So the admin opened a ticket. Then a second ticket, which finally reached someone who knew the feature. Support reported enabling it. His logs showed it was not enabled. Days later the relevant option disappeared from his logs altogether, still without the behavior working. A ManageEngine representative in the thread asked him to DM the ticket number so they could "fast-track the resolution." Eventually, weeks in, the backend flag was truly flipped, two new configuration options appeared in his Azure AD sync page, and the feature worked exactly as hoped. His closing post was gracious, even complimentary about the feature's design.

Read that timeline again from an operations perspective: a security-relevant control, present in the product, took two tickets, a public thread, a vendor social-media intervention, and several weeks to switch on, and for part of that time the customer's logs and the vendor's claims disagreed about whether it was on.

Hidden switches are a product model, and it costs you

Dark-launched features behind server-side flags are normal engineering practice during rollout. What this thread shows is different: a shipped capability whose only activation path is a support ticket, indefinitely. That model has predictable consequences.

Discovery breaks first. You cannot enable what you cannot see; this admin found the feature by reading log lines and asking Reddit. How many SDP environments have the same gap open right now because their admins never guessed a hidden flag existed?

Verification breaks second, and this is the sharper problem. When configuration lives on the vendor's side, "is it on?" becomes a question you cannot answer from your own console. This customer was told yes while his logs said no. For a security control, an unverifiable state is close to worthless; auditors, reasonably, agree.

And time-to-safe stretches from minutes to weeks. A settings-page toggle is a change ticket and an afternoon. A backend toggle is a support queue, a knowledge lottery over which agent knows the feature, and a fast-track that depends on posting publicly enough to attract attention.

What self-service should mean

The standard worth demanding from any management platform is plain: every capability you have licensed is visible, enableable, and verifiable from your own admin console, with its state readable in your own audit logs. Vendor-side flags may exist for staged rollouts, but "contact support to activate" as the permanent path for shipped features shifts operational control from you to a queue.

Two evaluation habits follow. During a proof of concept, pick a feature from the documentation and enable it yourself, end to end, without opening a ticket; note every point where you cannot. And ask the vendor directly: which documented capabilities require support-side activation? The length of that list is a measurement of how much of the product you actually control.

Credit where due: once activated, the SDP feature in this story was well designed, and the customer said so. The design was never the problem. The switch was.

Where Sensaka fits

Sensaka's position is the standard above: licensed capabilities are configured from your console, their state visible in your logs, because a control you cannot verify is a control you do not have. Self-hosted deployment reinforces the same principle at the platform level; the configuration surface is yours.

If you want to test the claim, do it the honest way: take our documentation into a trial and enable things yourself. We will stay out of the way, which is rather the point.

Further reading: explore ManageEngine Alternatives, Multi-Vendor Hardware Monitoring, Sensaka DCOS, and Redfish & IPMI Reference.