Lucidity specializes in optimizing data storage volumes, helping you improve performance and manage costs across your IT infrastructure.
When a server joins a failover cluster, Windows automatically activates a special 'Clustered Storage Subsystem' to manage all disks. This subsystem takes priority, even when the server only uses its own local storage. Because Lucidity is designed to work with the standard Windows storage system, this automatic change would normally prevent our agent from analyzing your local volumes.
To solve this, Lucidity performs a one-time, automated configuration. We set up our agent to run under a dedicated, secure service account which allows it to safely bypass the cluster's storage layer and continue to work with your local disks.
This process is completely safe and does not alter your cluster's configuration. Your cluster remains fully functional for its primary roles, such as hosting SQL Server Always On availability groups, while allowing Lucidity to effectively manage and optimize your local storage volumes.
The Challenge: Why is a Special Step Needed?
Your VM isn't just a standalone machine; it's part of a highly-coordinated team. The clustering software that manages this team is very sensitive, especially about how it controls the local disks. Standard backup or onboarding processes can sometimes interfere with it, which could disrupt your services.
Because Lucidity always prioritizes the safety and stability of your environment, we can't just onboard your disks the usual way. We use a smarter, more careful approach.
The Solution: Our Safe & Automated Configuration
To work with your unique setup, our Lucidity agent performs a small, one-time reconfiguration on your VM. This process is designed to be completely safe and non-disruptive.
Here’s a simple, step-by-step breakdown of what happens behind the scenes:
Step 1: Create a Secure Helper Account
We create a special, secure local service account on your VM. This account is typically named LuciditySvc_Cluster.
This is not a regular user account. It's locked down with minimal permissions, cannot be logged into interactively, and exists only for our agent to do its job safely.
Note
The LuciditySvc_Cluster account is a non-interactive, locked-down account with only the “Log on as a service” permission. All other login methods—local, RDP, or network—are explicitly denied, ensuring it can only be used by the Lucidity service and remains inaccessible for any other purpose.
Step 2: Isolate Our Agent from the Cluster
We cleverly adjust the settings so that the main Windows Clustering service doesn't "see" our new helper account.
Think of it like putting special blinders on our agent. It can see and access the local disks it needs to onboard, but it becomes completely invisible to the sensitive clustering operations. This guarantees we won't interfere with your failover setup.
Step 3: Fine-Tune Storage Settings
We disable a specific Windows setting called AutomaticClusteringEnabled.
This does not disable your cluster! It simply prevents Windows from automatically trying to group the local disks for clustering, which is what allows our agent to see them as individual drives ready for onboarding. Your existing cluster configuration remains completely untouched.
Step 4: Relaunch the Agent
Finally, we restart our Lucidity agent service, which will now run securely under the new LuciditySvc_Cluster account.
Once these steps are complete, your pending onboarding request will automatically resume and complete successfully.
Note
The configuration is performed only once per machine. Whether you onboard one or multiple volumes, the setup runs just one time, making the process fast and efficient.
Frequently Asked Questions (FAQ)
1. Is this process safe for my applications and my cluster?
Yes, absolutely. This entire process is designed with safety as the top priority. We are not changing your cluster's configuration or how it operates. We are only changing how our own agent interacts with the VM to prevent any potential conflict.
2. Will this affect my VM's performance?
No. The changes are minimal and have no impact on the performance of your VM or its applications. The helper account uses virtually no resources.
3. Do I need to do anything?
Nope! The entire process is 100% automated by Lucidity. You don't need to lift a finger.
4. How is the LuciditySvc_Cluster account password managed?
The password is automatically generated and managed by Lucidity. It is securely stored in Base64-encoded form and is never directly accessible to users. It is unique per account, meets standard complexity requirements (minimum 12 characters, including uppercase, lowercase, numbers, and special characters), and is cloud-agnostic. For consistency, all instances within the same account share the same password.