As the NW server today has a lot of administrative/reporting tasks to fulfill, it is in fact best practice to associate DDBoost devices with the remote storage node(s). The only rule you have to follow is that the backups of the NW internal databases (especially the bootstrap) must be lead to a local device at the NW server. This is the most obvious reason for your error messages. A second criteria is that you may have associated devices to certain pools (probably from an older installation). This is possible but normally unnecessary if you ensure that the volumes have been labeled to the correct pools. Selecting more criteria than necessary is most likely the reason that the filter (in fact you set up such one) is to narrow so that not all criteria are matching properly.   BTW - if you are backing up the bootstrap to a DDBoost device, may I suggest that you clone the most recent version to a local File Type Device (FTD). This is much easier to configure whenever you must run a disaster recovery of your NW server and you do not have to care about all the connection attributes.    
In our Networker environment, we have one Networker server, two storage nodes at two sites and two Data Domain systems at two sites. When creating DDBoost devices in the Data Domain devices, which storage node, the Networker server which is also a storage node, the storage node at the same site or the storage node at the remote site, should be associated to the new DDBoost device? According to Networker on-line help, “By default, Networker associates all devices with the Networker server.” But based on a consideration of workload balancing and a possible DR situation, we usually associate the storage node server at the same site to a new DDBoost device. This setting works without any issue until we want to migrate the savesets by using ‘nsrstage’ from one volume on a DDBoost device to another volume on another DDBoost device of the same pool or a different pool. Strange thing happens, the migration works if the destination volume device is associated with the Networker server or one of the two storage nodes. But if the destination volume device is associated with another storage node, the staging operation failed with the error messages: 175297:nsrstage: Unable to set up the direct save with server 'NetworkerServer': no matching devices for save of client `NetworkerServer'; check storage nodes, devices or pools. 11390:nsrd: no matching devices for save of client `NetworkerServer'; check storage nodes, devices or pools So is it a good practice to associate a storage node, instead of the Networker server, to a DDBoost device? BTW, we considered the option of temporarily changing the associated storage node of the volume device just for the staging, and found a threat of changing storage node in this forum ([URL]#M61611). But I am not sure I fully understand the change process and I don’t know if it is safe to do so.
When creating a DDBoost device, which storage node should be associated with 
the new device?