You would have to read the DirXML-DriverConfig attribute from the Driver object (Use the auto GCV to get the DN).  May have to B64 decode it.  You coudl use the Document token but I find it just as easy to use Source Attribute.

Then XPATH out the item you want.

No tokens.

Interestingly enough in a driver shim, the built in classes support easily reading driver parameters but not GCVs.  Which is why the gcv-ref Syntax type exists for GCV/Driver Settings I think.  You specify it once, as a Driver Config, then in the GCV you point at that, so change it once, changes it in two places so to speak.  Then it is easy to read in either place.

Thanks for the great explanation!  May be more hassle then it's worth for what I wanted to do.

Also thanks for the gcv-ref explanation.  I often wondered why the heck sometimes the values would be in two places.  I didn't understand what the purpose was!

Matt

I have made great use of gcv-ref in many drivers I have worked on in the past.

One driver that really suits gcv-ref is the scripting driver, where so much of the logic can potentially be handled in the "custom shim" that one has to write scripts to handle. I found myself often requiring contextual information in said scripts that might need to change depending on the environment. So I made GCVs for these parameters, referenced them as gcv-ref in driver params and then could easily access the same info from within the scripts I wrote.

In more recent times, the scripting driver incorporated the ability for scripts to "query back" to the IDVault and read GCVs directly, but that is slower than accessing the same information that the scripting driver automatically caches locally during driver startup.

gcv-refs can be a bit tricky if using driver packages though.

Can you clarify the packaging issues please?

Has been many years since I dabbled in that specific space, had sort of hoped that it had been solved in the intervening years.

Relates back to the issue of properly implemented base packages and the necessity of keeping them as streamlined as possible.

Cannot recall all the details but there were challenges with the way the package stylesheets worked, either prompts or upgrades.

My plan was to have a series of add-on packages that each included the GCV and also updated the Driver Parameters with a matching gcv-ref entry.

Discovered that this was far trickier than I thought it would be. That updating driver parameters was only possible using the package prompt stylesheets from the base driver package.

So, every time one wanted to add a new GCV and gcv-ref pair, for say a new optional feature, one had to issue a corresponding base package update also.

I believe a real world example of this kind of issue is mentioned here in this thread.
Azure AD Driver error Global Configuration Value 'drv.team.user.owner' not found

Another bug I vaguely recall was that the base package stylesheet kept on adding the same GCV ref entry to the driver parameters on every upgrade.

That makes sense that to update the driver config, you need a base package, and a prompt resource. Annoying I agree.  BUt not fixed as far as I know.

That makes sense that to update the driver config, you need a base package, and a prompt resource. Annoying I agree.  BUt not fixed as far as I know.