Anybody been able to setup a Powershell script to unlock files? I'm thinking something that a user could run to unlock files that are locked under that user's username. We use Citrix, and sometimes a user will lose connection to a session, then not be able to get back to it -- some files are locked open in that other session, and, rather than calling the Helpdesk, etc., it would be useful for that user to unlock certain files just by running a script (e.g., a ~notes.lck file). Thanks.
Actually I'm working on a solution to do this right...there appears to be a cmdlet to unlock NFS locks but no CIFS??? If you want to provide standard users with the ability to do this then you will probably need to have a service account run the script as a scheduled task or use an orchestration tool like NetApp WFA product to build a workflow that accepts the UNC path of the file to close. At a first glance it will probably require a few cmdlet's to translate the UNC path to mount point and find out who has the file locked
Sounds great! I'll check out NetApp WFA and will keep an eye on this space.
Would the service account need to have root / administrator access on the filer? That's another, related issue that I've been trying to solve -- provide the permission to unlock files, but not provide full admin. This would be especially important if running a script, but your "scheduled task" idea sounds good -- just allow users the ability to start the task, which itself runs under admin credentials.
So it appears that there is a known problem with the powershell toolkit when you execute the "invoke-nassh" cmdlet using the "lock break -f" command. The ZAPI command on the controller prompts for confirmation and there is not currently a workaround for this issue with the "invoke-nassh" cmdlet...however you can use a combination of Get-NaCifsShare and Get-NaLockStatus with the psfile.exe utility from system internals to close the file. Here is the syntax (assumes it is executed with an account with admin privellages on the filer...i think this may be delegated to a member of Power Users)
It might help if I used the correct path.... Email had been upgraded recently, and I forgot that the path to the ~notes.lck file is different. After using the correct path, I was able to close the files with psfile as my non-admin user. I confirmed, though, that at least Power Users privileges on the filer are required. Rather than making all users part of the Power Users group on the filer, I'll likely create a local user on the filer specifically for the purpose of running my psfile script.