Dell Unity 480 (v5.3) - SMB Issues with Windows Server 2025 Domain Controllers

Question

Hi everyone,

I am facing a critical issue after migrating our Domain Controllers from Windows Server 2016 to Windows Server 2025, and I would appreciate any insight from the community.

Environment:

Storage: Dell Unity 480 (Firmware: 5.3.0.0.5.120)
Infrastructure: ~250 PCs/Users accessing SMB shares (Folder Redirection and Group Shares).
The Issue: Since the upgrade to Domain Controller Server 2025, the Unity reports: "The NAS server NASPLAN in the domain bncf.local can't reach any Domain Controller." The shares are marked as "Degraded" in the Unity Unisphere.

Current Status: Surprisingly, the system is still "working" in production: users can currently access the shares, but the Unity cannot establish a fresh management/trust connection with the new DCs. I fear that as soon as Kerberos tickets expire or a reboot occurs, everything will fail.

Technical Analysis:

Dell Support: After a network trace analysis, Dell concluded the issue is on the Unity side. Kerberos authentication seems to succeed, but the SMB dialogue fails to complete.
SMB Signing: It appears the new Server 2025 DCs enforce SMB Signing, and the Unity is tearing down the session during the handshake.
Deep Dive: I checked the advanced CIFS/SMB parameters via CLI and found this:

Plaintext

name                    = smbsigningfacility_name           = cifsdefault_value           = 1current_value           = 1configured_value        = 1param_type              = NAS serveruser_action             = restart NAS Serverchange_effective        = restart NAS Serverrange                   = (0,1)description             = Manages SMB signing on the NAS server

The Dilemma: The Unity has an uptime of 500+ days. This parameter (smbsigning = 1) is not visible in the GUI and seems to be "pending" a restart to actually take effect.

My Concerns:

Is the fact that the parameter hasn't been "applied" (due to the 500-day uptime) the reason why the Unity is failing to negotiate SMB signing with the 2025 DCs?
I am terrified of restarting the NAS Server. If the "Join" fails after the restart, 250 users will be offline.

Questions:

Has anyone encountered specific SMB/Kerberos compatibility issues between Unity OE 5.3 and Windows Server 2025?
Should I try to manually toggle the smbsigning parameter or force a NAS Server restart?
What is the safest way to re-establish the trust relationship without losing the existing ACLs/permissions on the shares?

Thank you in advance to anyone who can spare a few minutes to help with this.

DELL-Josh Cr · Answer

Hi.

Thank you for your question.

Restarting is the best option.

The issue you are experiencing is directly related to a security hardening change introduced in Windows Server 2025. Starting with Server 2025, Microsoft enforces SMB signing for all inbound and outbound SMB connections by default. In previous versions (2016, 2019, 2022), strict signing was only required for SYSVOL and NETLOGON shares.

When your Unity's CIFS service attempts to communicate with the new 2025 Domain Controllers, the stricter SMB handshake requirements are causing the session to be torn down — which aligns with the network trace analysis showing that Kerberos succeeds but the SMB dialogue fails to complete.

Regarding the smbsigning Parameter and Your 500-Day Uptime

Your CLI output confirms that the smbsigning parameter is already correctly set to 1 (enabled). The parameter itself is not the problem. The issue is that with over 500 days of continuous uptime, the NAS server's CIFS stack is holding onto:

Stale Secure Channel states originally negotiated with the old Server 2016 DCs
Cached domain trust parameters that do not reflect the stricter requirements of Server 2025
Older SMB dialect negotiation states

The CIFS service needs a full restart to flush these cached states and renegotiate a fresh SMB session that meets the Server 2025 requirements.

Your file and folder ACLs are stored on the Unity filesystem as Security Identifiers (SIDs), not as plain-text usernames. Even if the domain trust is temporarily disrupted during the restart process, the underlying SIDs remain intact on disk. Once the trust is re-established, Windows will resolve all SIDs back to the correct user and group names. No data migration or ACL recreation is required.

Let us know if there is anything else we can assist you with.

Thanks,

Josh

Did I answer your query? Please click on ‘Mark as Accepted Answer’. ‘Thumbs up’ the posts you like!

#Iwork4Dell

cristiano corsani · Answer

Dear Josh, many thanks for your help. I opened a ticket with DELL support yesterday, this evening they will re-join the domain (de-join an join again). Do you think is the best way? Or better only to restart only CIFS service without re-join? Do we need to phisically restart the NAS or is there a way to restart CIFS softly?

Regards.

DELL-Josh Cr · Answer

Plan for the whole thing to be restarted.

cristiano corsani · Answer

We recently upgrade the firmware as suggested from the DELL assistance. Now the system is a 5.5.3.0.5.057 version.

Unfortunately the error remain, different, but we still have problems connection to our 2025 DC.

"For the NAS server XXXXXX in the domain YYYY, the DC ZZZZ has the following error: compname XXXXXX DC=ZZZZ Step='Open NETLOGON Secure Channel' 'NETLOGON' ' Action failed with status=PIPE_DISCONNECTED'."

That seems to be related to the presence of an old DC name in the DNS list. We already tried to re-join, but UNITY could not de-join, due to the absence of the old DC ZZZZZ. So DELL decided to upgrade all. After upgrade we still have problem. I think that UNITY has been joined on the old DC ZZZZ, now it still trying to contact ZZZZ and that is the problem. I think we need to "force" de-join and then re-join without ZZZZ

DELL-Josh Cr · Answer

The Unity NAS server caches DC bindings. If the system is stuck trying to contact the offline DC. and the GUI fails to unjoin, you can use the Unity Service CLI (via SSH as the service user) to override it.

View Cached DCs: Run the following command to see exactly which DCs the NAS server is actively querying or caching:
svc_cifssupport <NAS_server_name> -pdcdump
Force Unjoin via CLI: You can forcefully unjoin the NAS server from the domain using the CLI, which often succeeds where the Unisphere GUI hangs:
svc_cifssupport <NAS_server_name> -Unjoin -compname <NAS_Computer_Name> -domain <full_domain_name> -admin <Domain_Admin_User>
DNS Check: Ensure that the old DC (ZZZZ) has its A records and _msdcs SRV records completely removed from your DNS servers. If the Unity queries DNS and still receives the IP for ZZZZ, it will repeatedly fail the Netlogon secure channel setup.
Clean up any stale DNS records for DC ZZZZ (both A records and _msdcs SRV records).
During a maintenance window, execute svc_nas <NAS_server_name> -restart to flush the DC cache and apply the pending SMB signing requirement.
If it still fails to connect to the new DCs after the restart, use svc_cifssupport -Unjoin via CLI to force the unjoin, and then rejoin the NAS server to the domain.

Unity

Dell Unity 480 (v5.3) - SMB Issues with Windows Server 2025 Domain Controllers

Was this post helpful?