Hi Wale.  When you replicate an element from one DataMiner System to another, it essentially forwards the raw values of the metrics of the element from the source to the destination DataMiner System.  For that reason you indeed also have to have the matching driver on the destination system (because that contains the entire model of the element where the data needs to be mapped onto).

Considering that, I would not expect the presets to work, because that is a core software functionality for a spectrum analyzer element (i.e. this is not a metric of the element itself).  The presets therefore exist on the source DataMiner System but not on the destination DataMiner System (for the same reason if you replicate an element, you will not find the alarm templates for that element that you made on source DataMiner System when you open the replicated element on the destination DataMiner System).

The trace however one could expect to see, in the sense that it is (although a special one) a metric of the element object (and those raw data values are pushed across the replication link).

But there is a problem here, which I believe prevents you from seeing a trace in the replicated element. Spectrum analyzers run in parallel sessions for different simultaneous users.  Meaning, that if we both work on the same spectrum analyzer element in DataMiner, we both can do our own settings (such as RBW, VF, start & stop frequency, etc.) and we will each receive our own spectrum traces (i.e. DataMiner is transparently time mux'ing the use of the analyzer between the two of us).

So the fact that you do not see a trace on your replicated element has probably to do with that specific aspect of this type of element.   And considering what replication does (i.e. transfer bare bone data values), I would say that it is not really designed to support spectrum elements.