Just migrated vault store group, but what about hidden shares ($) on ptn folders?

[RhoSysAdmin]

I'm running EV 9.0.4 R1.  I just successfully migrated the vault store group associated with our Exchange public folders to a CIFS share.  While looking back at the logs to make sure everything is ok (which it seems to be), I noticed there are hidden shares associated with each partition.  Only the vault admin account has share permissions.  The shares associated with the partitions I moved tonight are still pointing to the original location.  The share names have long random numbers in the name, so I'm not sure when they were created. 

Do they serve any purpose?  I've not seen anyone mention them in other forums that have discussed moving vault store groups.  I did make the changes in SQL, so the properties of the partitions in the VAC show the NEW location.

Here's a sample share name which is still pointing to the original location of the partition I just moved: EVPartition01c9b7a914864670$

Could this be related to Discovery Accelerator?  We have it licensed and it is installed, but we've not ever fully implemented it.

[JesusWept3]

The hidden shares will get created automatically by the storage service if they're deleted It's used for the OSIS, so one EV server can access another's vault store to get files such as dvssp or dvscc etc

[RhoSysAdmin]

So I moved my partitions to a CIFS share on a NetApp.  If I delete these shares on my EV server, will they be recreated on the NetApp?  My vault service account is a member of the local administrators group on the NetApp already. 

Since I only have one EV server, are these shares necessary if they don't get (re)created on the NetApp?

[JesusWept3 · Accepted solution]

When you move the partitions and update the partition entry table to show it's new location, the storage service will update the hidden share, it doesn't matter what the old partition is doing or whether you delete it's hidden share etc

[RhoSysAdmin]

So the fact that I see my CIFS UNC pathname in the RemotePartitionRootPath column in the PartitionEntry table explains why I don't see a new hidden share created anywhere, right?  That must be the table entry that was updated automatically when I changed the PartitionRootPath values and restarted the Storage Service. 

I just want to make sure I understand correctly.