Figure 2, page 14, shows that the LissWare.Net domain has two trust relationships: an intraforest transitive trust with the Emea.LissWare.Net domain and an interforest trust with the ForeignForest.Com domain. In the latter trust relationship, LissWare.Net is the trusted (aka account) forest and ForeignForest.Com is the trusting (aka resource) forest. If I run WMITrust with the /Check switch on a DC in the LissWare.Net domain, I see the results that Figure 3 shows. Note that the script lists all LissWare.Net domain trusts. You can see that the LissWare.Net domain has a bidirectional trust with the Emea.LissWare.Net domain and an inbound trust with the ForeignForest.Com domain.
When you use the /Check switch, you can also update the Microsoft_
TrustProvider instance property values by using the /StatusLifeTime switch (which updates the TrustStatusLifetime property), the /ListLifeTime switch (which updates the TrustListLifetime property), and the /TrustedOnly switch (which updates the ReturnAll property). A sample command is
WMITrust /Check:EnumOnly
/StatusLifeTime:6
/ListLifeTime:40 /TrustedOnly-
After changing the values, you must restart the WMI service if you want the new values to take effect immediately.
The code at callout B in Listing 1 handles the Microsoft_TrustProvider class. The script first retrieves the Microsoft_TrustProvider singleton class instance. If you specified on the command line any of the switches that update Microsoft_TrustProvider, the script assigns the specified values to the respective Microsoft_TrustProvider properties. If you turned on the /TrustedOnly switch (/TrustedOnly+), a logical Not operation sets the Return- All property to False to tell the WMI provider to return only the trusted domains (and not the trusting domains). Next, the script saves the Microsoft_TrustProvider instance back to the system by using the Put_ method exposed by the SWbemObject object that represents the Microsoft_TrustProvider instance. (For more information about the SWbemObject object, see "SWbemObject" at http://msdn.microsoft.com/library/en-us/wmisdk/wmi/swbemobject.asp.)
After the update process, the code at callout C enumerates the list of trusts. To do so, the script retrieves a collection of Microsoft_DomainTrustStatus class instances. If the collection contains at least one instance, the script enumerates and displays the instance's properties. A Select Case statement handles the necessary decoding functions based on the property name.
Monitoring Windows 2003 Trusts
The WMITrust script retrieves information about trusts and can change the Trustmon provider properties, but it doesn't monitor trust status. To detect a trust status change, you can use a WQL event query such as
Select * FROM
__InstanceModificationEvent
Within 5
Where TargetInstance ISA
'Microsoft_DomainTrustStatus'
To submit this query, you can use GenericEventAsyncConsumer.wsf, a script that I wrote expressly for the purpose of submitting such queries. For more information about how GenericEventAsyncConsumer submits an event query, see "Exchange 2000 SP2 WMI Updates," January 2003, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 27211. With the help of this script, a WQL event query detecting a trust status change would generate the output that Figure 4 shows. (I've edited the output to show only the relevant information.) GenericEventAsyncConsumer displays the Microsoft_DomainTrustStatus instance before and after a DC had disappeared because of a shutdown or crash. The second set of TrustIsOk, TrustStatus, and TrustStatusString property values show that the trust is broken.
Improved Management
Windows 2003 dramatically improves the OS's management capabilities, including bumping up the number of WMI providers to 80 (from 29 in Windows 2000 Server). The Trustmon WMI provider is just one of these providers, but it's an important one. Windows 2003 has new trust features to support multiforest environments, making it a key area to manage, and the new ability to monitor trusts is a great asset for systems administrators.