Hi Jay -

As you probably noticed, the get-bootpolicy cmdlet doesn't exactly do what you want. We're working on a better way to show that information. In the meantime, its super easy to do via invoke-xmlcommand. Try this, assuming you've already made a connection to UCSM via PowerShell:



and



If you have a primary and secondary path assigned for each target (primary and secondary), you'll see two dn's returned. Each of those will return a property called wwn that represents the WWPN of the SAN target you're booting off of. There's also a lun property that designates the target lun number.

In the above example, ls-HyperV-Template would be the name of your Service Profile (don't forget to prepend with ls-. That would do the trick for a boot-policy that's local to a Service Profile or SP Template. If you wanted to get the info for a stand-alone boot-policy, you just need to change the Dn:



Similar comments as above to primary and secondary targets and paths, respectively.

Hope that helps!
Josh

For the first part of your question...can you send the syntax you're using to query the Service Profile boot policy? Not sure why that wouldn't work. That's actually the example that I used in my first reply, so it definitely should work. My only guess is that your service profile is using a boot-policy (a boot policy that was setup 'globally', not specific to a single SP). In that case, you need to look for it as a standalone boot policy - not a member of an SP. If the boot policy was created especially for the SP, then you can look at it within the context of the SP itself.

I also saw you ask about how to parse between the primary and secondary entries when both are returned....since multiple objects are being returned (a primary and a secondary path entry, each with a wwn property entry), you need to refer to them as members of an array. After the variable assignment, look at the values like this: $xmlout[0].wwn and $xmlout[1].wwn (where $xmlout is the variable you assigned-to). [0] will be the primary path, and [1] the secondary.

Alternatively, you could specifically query for the primary and secondary paths using the configResolveDn method:



Only difference is that you're running two queries against UCS instead of only one.