You're almost there.  See [commit 157a4833 in my fork](https://github.com/olivierdagenais/tfs-plugin/commit/157a4833a7b2ca62cf75a128dafc4423ceddc916) for what I wanted you to do:  call `Util.replaceMacro()` (instead of re-implementing part of it yourself) with a `VariableResolver` that can determine both build parameters and environment variables.

I tested this by configuring your post-build step with the following expression:

    Build: ${JOB_NAME} Environment: $TEMP

...to make sure I could expand both a build variable and an environment variable as well as with both types of variable specification (with curly braces and without).  The expansion worked, as the plugin tried to execute the following:

    tf label "Build: SampleProject Environment: C:\Windows\TEMP" (...)

...but the command failed as follows:

> TF10159: The label name 'Build: SampleProject Environment: C:\Windows\TEMP' is not supported. It must be less than 64 characters, cannot end with a space, and cannot contain any of the following characters: "/:<>\|*?@

...which is fine, because I was just testing the expansion.

You ought to be able to import commit 157a4833a7b2ca62cf75a128dafc4423ceddc916 from my fork using:

    git pull https://github.com/olivierdagenais/tfs-plugin.git simplerDynamicValue

...although if that doesn't work, you could always copy-paste my changes and commit them that way.

The only thing about all of this that I'm not sure of is if our union of the two `VariableResolver` implementations is needed at all, since the `hudson.plugins.tfs.util.BuildVariableResolver` appears to already resolve environment variables if the `computer` constructor parameter is used.  Can you look into this and re-run your tests if you end up using that resolver only?

Thanks!