Having just covered the methods to discover the metadata for a deployed session including the details about the session settings, events, actions, and predicates, I am nearly finished with the session metadata. All that remains is to dive into the metadata for Targets.
Through the articles thus far, I have shown some of the nuances in dealing with PowerShell to retrieve this metadata and how it differs a bit from performing the same inquiries via TSQL. PowerShell exposes Extended Events differently than what one would expect due to familiarity with Extended Events through the catalog views and the DMVs I have previously discussed.
Along with the nuances associated with accessing this metadata via PoSH, I have also showed how some of this metadata is different. The dive into the metadata about Targets will continue to reinforce and embrace these differences.
Regrouping
Picking up from where I left off, and following the same pattern as has already been 
established, it is time to dive into the metadata for the Predicates and Actions that are tied to an Event deployed with a session using PowerShell. This means that I will need to ensure I have a session established that has the SQLPS module loaded. Then I need to ensure I browse back to the sessions folder.
Just in case, here is the working directory for the sessions out of the default instance.
cd XEvent$env:computernamedefaultsessions
Also, from this point, I will go ahead and load the “demosession” session into an object again for demonstration purposes throughout the remainder of this article.
$sessionobj = dir | Where-Object {$_.name -eq 'demosession'}With that loaded, I just need to remember to reference the Events object (as was introduced in the prior article).
Targets
While the Actions, Predicates, and Events are all tied tightly together (Actions and Predicates have to be attached to an Event), Targets are somewhat independent. The Target is directly attached to the Session in the same way that an Event would be tied directly to the session. Looking at the Metadata for the Session attached to an object, it will show the Targets object being similar to the Events object. Let’s see that in action:
$sessionobj.Metadata
That script will produce the following:
Reverting back to the patterns used so far through this series of posts, I will explore what is available to me for the Targets that may be deployed to the session of interest. The following query would be the first step:
$sessionobj.Targets
This query will result in the following:
Following the established patterns and results, I can see some very common ground here. The results of this query are strikingly similar to the results seen when querying Actions and Events where I would also see the “name”, package and a description. This is a pretty basic demonstration into viewing the targets tied to a session. To get a better view of the Targets attached to a session, I need to dig a little bit deeper.
$sessionobj.Targets | gm
This will produce the following useful information:
From those results, I can see that I would immediately be interested in the TargetFields (recall the similar property from the Events) and the Properties property. The first of these that I want to explore is the Properties property.
$sessionobj.Targets.Properties | ft Name,Value
Note the trick I am using again to dump the results into a quasi-table format. And the results will look like this:
Once again, the results should seem somewhat familiar. These properties underscore one of the nuances being the EAV model with how PoSH accesses the Extended Event properties. With this kind of query, I can see what kind of targets have been deployed to the Session and get a little bit of information as to the type(s) of target(s) they are.
This is all really cool. The real meat of the metadata for Targets is in the “Set” options that have been configured. The “Set” options are the configurations that are exposed via the TargetFields property previously seen. With that said, it is time to dive into these configuration options.
$sessionobj.Targets.TargetFields
This query returns this rather useful data:
And to make this slightly more useful and more valuable, I need to know which target has which setting. For a more usable query, I can resort back to the table output. Instead of just using the data directly accessible from the previous query, I will use the Parent property to get the name of the Target.
$sessionobj.Targets.TargetFields | ft Name, Value, Parent
And now I will get something like this:
This is good and useful information. Being able to tie the target type to the specific setting is crucial to better understanding how the metadata is interrelated. This is also something pretty easy to do via TSQL as I demonstrated in this article.
In this article I have covered the core concept of Targets. I showed how to access the Target metadata which includes the “Set” operations for each of the Targets. This is the last of the core concepts to discuss the means to access the metadata via PowerShell. I do have one more item I wish to discuss via the means of PowerShell and I will be discussing that in the next article.
Stay tuned as I continue to work through another trick that can be done via PowerShell in the next article. To recap the series, please visit the table of contents.
