you can use Invoke-NaSsh to pull it for each volume. i happened to be working on a function with a similar structure so i just changed the lines to pull the volume FSIDs and it worked against the 8.1.3 controller i tested it against.
YMMV - this structure makes several assumptions like RPC access from the account your are running the function under and that you have keyless SSH setup - plus a complete lack of error handling but it is a starting point.
save as Get-NaVolFSID.ps1, edit $keyfile and dot source it (. .\Get-NaVolFSID.ps1) then you can run $FSID = Get-NaVolFSID <controller> or pipe a list of controllers to it like: $FSID = gc .\filerlist.txt | Get-NaVolFSID
Why do you say out-null is the proper way? There are many ways to do almost anything in powershell, so what makes out-null better?
I prefer RPC over https because in my testing (and maybe it is just my environment) it is many times faster than https. It also allows me to schedule my scripts using our scripting account and not have to deal with the credential cache.
As for the script above, it is using RPC to get the volume list but invoke-nassh is run using -privatekeyfile since invoke-nassh doesn't support RPC.
Thanks, this helps a lot to read out the data. And I think invoke-nassh should also do make it possible to "rewrite" FSID's.
But can an aggregate's FSID be changed while volumes are living on that aggr? Does it need to be offline to change it?
The idea is to get an exact 1:1 copy of and "old" filer aggregate / volume structure to a "new" filer using snapmirror - keeping all FSID's so that OnCommand UM is happy afterwards (does not notice the change) and all datasets/relationships stay intact after a filer migration...
unfortunately, this isn't something i have any experience doing.
given that you are doing a migration, i would probably attack the problem from the other end and script the changes in OnCommand instead of changing the aggregrates/volumes - but i don't use OnCommand for managing Snapmirror/Snapvault relationships, so that is a naive statement on my part.