Solving the ViewEntireForest problem

In this recent post, I blogged about Scope and the ViewEntireForest property of $AdminSessionADSettings variable. In particular, one thing I said in passing bears a bit more explanation:

When you're in Forest scope, the admin session talks to a GC for all reads (to get the whole forest view), but does any writes back to a DC in the appropriate domain. This is great because it means it's possible to get a view of all mailboxes in the whole forest, for instance. But it's also bad, because when you're in this mode, replication latency can make things in your view be out of date -- since you're reading from a GC and writing to a DC in the object's domain, it's quite possible you won't read the latest data if it's just been changed.

What does this really mean? If we are always reading from a GC (which may be out of date due to replication latency), it means we stand a chance of getting back stale data. For the shell where we don't maintain object context -- and worse, let you click on it with the mouse and take some action on the selected object -- it's generally not a huge impediment. And stay tuned for how to handle the times when you find that it IS an impediment.

In general, where this really becomes a problem is in the GUI. The way the GUI works in most cases relating to AD, a selection of objects are read from whatever GC (ForestScope) or DC (DomainScope) the AdminSession is currently connected to. These objects are then displayed in a result-pane table. Once this is done, they linger around as objects that you can select and take action on.... for instance, double-clicking to pull up the property page.

Well, if we're doing all the reads from a GC (which is out of date due to replication latency), you'll get back a property page with stale info. This would be a huge hassle. And it's totally preventable since we know we can always find the DC from a domain where the object is most current, even when we're configured to forest mode.

And that's what the "-ReadFromDomainController" switch does. When you're in ViewEntireForest mode and you "Get" some object by identity, we (by default) will still read this object from the GC being used for ForestScope. But if you specify the "-ReadFromDomainController" override switch, we'll make a special trip to a DC in the recipient object's home domain to read the object from there.

This is the way GUI operates on recipient objects in ForestScope when we do any identity-based reads (ie - anytime you take action on the context of a single recipient object and not just filling result-pane tables). It's also a trick you can use to ensure you're getting the freshest data in the shell when doing identity-based reads in ForestScope.