topic Re: SnapDrive Transport Protocol Password Change in Data Protection

SnapDrive Transport Protocol Password Change

TMADOCTHOMAS — Wed, 04 Jun 2025 10:34:08 GMT

I am resetting all local NetApp cluster passwords to upgrade the hash from MD5 to SHA512 and I am down to my last one - the local service account used by SnapDrive for the Transport Protocol Settings. We only have SnapDrive running on Windows Failover Clusters, and only for LUN management (due to a SnapCenter bug I'm awaiting a fix on). We use SnapCenter on all systems, including the ones with SnapDrive, for backups.

Within this context, is there any risk to changing the password for the service account used in the Transport Protocol Settings dialog box, and then going one system at a time to update the new password in the dialog box? I don't want to get in a situation where (a) SnapDrive tries to connect and it affects LUN functionality, and/or (b) SnapDrive tries to connect from systems I haven't updated the password for yet, and it locks out the service account.

Any recommendations?

Re: SnapDrive Transport Protocol Password Change

GidonMarcus — Mon, 22 Feb 2021 22:26:26 GMT

Hi. SDW or it's account not required for LUN connectivity (also in a case of a reboot / failovers etc). It's only required for mounting new LUNs, removing them, and for backup operations running via SDW.

In case it stops working (for whatever reason I can't think of), you also do the add/remove LUNs directly from ONTAP, then format and add these to the cluster manually. With similar process from removing LUNs. And you can also still take non-OS/application consistent snapshots that will still be usable for 99% of the scenarios.

Re: SnapDrive Transport Protocol Password Change

TMADOCTHOMAS — Tue, 23 Feb 2021 14:02:45 GMT

Thank you @GidonMarcus ! Very helpful. So if I change the password on the NetApp cluster and then go system by system to change it in SnapDrive, I should be fine as long as I don't use SnapDrive until after I've entered the new password?

Re: SnapDrive Transport Protocol Password Change

GidonMarcus — Tue, 23 Feb 2021 20:13:38 GMT

Correct, but if you don't do it fast enough the user can get locked. if you encounter issues - consider stopping the service before the change.

Re: SnapDrive Transport Protocol Password Change

TMADOCTHOMAS — Tue, 23 Feb 2021 20:23:39 GMT

Ahh, great idea. Thank you @GidonMarcus ! I will do that.

Re: SnapDrive Transport Protocol Password Change

TMADOCTHOMAS — Thu, 25 Feb 2021 15:10:02 GMT

@GidonMarcus (or anyone who sees this),

Am curious if you've encountered this issue. I'm testing the change on a test SVM and two test SQL Servers with SnapDrive still installed. I changed the password for the service account using the security login password command, then opened SnapDrive on each server as Administrator, opened Transport Protocol Settings, clicked Default, then Manage, pasted in the new password, and clicked OK on each dialog. The password change didn't take! It took me awhile to realize but I couldn't see disks in SnapDrive anymore and saw errors in the Event Log. When I opened the dialog and looked at the password, the # of characters were the same as what they had been previous to the change. It's like it ignored the change. I tried this multiple times, restarting all 3 SD services before and after the change, and it never 'took'. I even tried it with sdcli instead, and got the same results. VERY STRANGE! Any ideas?

Re: SnapDrive Transport Protocol Password Change

GidonMarcus — Thu, 25 Feb 2021 22:25:16 GMT

To be honest I didn't. Worth opening new thread for visibility or open a support case.

This TR does say "Note:SnapDrive might cache credentials; therefore, if an incorrect set of credentials is entered, adding correct credentials might fail. To correct this issue, restart the SnapDrive service to clear the credential cache"

http://doc.agrarix.net/netapp/tr/tr-4228.pdf

but you mentioned you did restart them - so I'm out of ideas

Re: SnapDrive Transport Protocol Password Change

TMADOCTHOMAS — Fri, 26 Feb 2021 13:43:10 GMT

Ok thanks @GidonMarcus , I will likely open a case.