The person who initiated the executions is would be recorded in both versions (if not, a bug for sure), but in the free version, since everyone is effectively the same user, it's all recorded under "Admin" user (by design).

There hasn't been a huge demand for Native TFS Repositories, so we haven't prioritized it. We don't have a ETA, since everyone who has asked for it just ended up using Git in TFS.

Can you provide a example for this not working? The Add-Member cmdlet interacts with PSObjects, but the OUt-String does interact with the host (which, is different than an output stream... and has some strange handling sometimes).

Further troubleshooting seems to have helped. I rebuilt everything on SQL Express 16 instead of the included version 5 included with the installer and everything appears blazing fast at the moment with the more complex setup in place. I'll keep toying with it, but any insight you may have is appreciated. Thanks!

Thanks Tod, I guess I was overly enthusiastic for this feature ;)

The problem here is that there is not exactly 1 environment in context. I'm guessing this is an orchestration plan? Configuration plans will already bring in the environment context if there is exactly one environment. The way this will be solved (targeted for v1.6, but may appear earlier in a v1.5.X maintenance release) is by the following rules: Context will solely be determined from environment associations of servers (this changes the current behavior which relies on orchestration jobs being targeted at an environment in order to bring the environment into context) Parent environments will only be considered for user permissions and variable resolution If there is not exactly 1 environment applicable to the current server in context, $EnvironmentName will result in an empty string (so the same as you're seeing now) We will add @EnvironmentNames which will resolve to a list of all environment names in context (including an optional parameter for including/ignoring parent environments)

Thank you for the report, we are in the process of releasing a hotfix (v1.5.5). It should be released within the hour.

The environment on a raft affects who can access it, but not which raft is accessed. Asset names with no RaftName::part always use the Default raft. There's a bug in the implementation of OtterScript in the current version of Otter that makes it unable to call templates from a non-Default raft. Running a plan from a non-Default raft is also slightly broken in that it brings up the wrong preselected plan, but selecting the correct plan afterwards works.

Thanks Phillipe, we've identified the bug and will fix it in next maintence release as [OTTER-133]

Just as a follow-up, we are going to clarify this behavior and "fix" it to be more like your use-case, see: http://inedo.com/support/questions/6290#inline-post-6291

Just a quick update... Upon researching it further, it seems that modifying PSCall in this manner might be quite a bit complicated; not so much technically, but we'd have to balance with how PSExec works as well. Definitely something for us to consider as we work towards getting closer with PowerShell/DSC in the coming versions. The current thought is to add a new variatic variable function: PSEvalAsset(OptionalRaftName::AssetName[, arg.1..n]) This could return a scalar ($), vector (@), or map (@). Unfortunately there are no named arguments in OtterScript variable functions (unlike operations), but I think that's OK... hopefully assets will be very simple and not have a lot of arguments.

There was a regression for the PowerShell agents that caused this to behave like this in some cases, but it was fixed in Otter 2.2.5 (released today). I should be fixed Let me know if this resolves your issue!

Well... the error is a bit strange, because EnumerateFileSystemInfos is in fact a method on System.IO.DirectoryInfo. It's a core .NET class, so this error is "impossible" then... I'm wondering if there's an older version of powershell or .net on the server? There has to be some other difference between the servers I would think... You can trigger the RoutineServerChecker under Admin > Service. Hopefully you'll find some clues by running it repeatedly...

It is working :) Thank you Have a nice week-end Regards Philippe

Great questions. a second Raft, that uses the same Git repo but a different branch? This was definitely something we considered when designing rafts... i.e. the ability to "promote" changes between environments. This is somewhat common in other IaC tools, such as Chef, where a cookbook is tied to a git repository. Some folks will use branches in this "promotion" manner. I was also thinking of having a second Otter Server instance for the pre-production environment This is fine; actually, our licensing model is designed for this. One instance of Otter managing pre-production servers (typically free), then the other instance managing production servers. Obviously you loose the unified visualization, but a lot of folks prefer having two totally different dashboards anyway. A lot of folks will also set up a second instance of Otter as more of a "Sandbox". It isn't to "test" the configuration plans, but more to test extensions, play around, try upgrades, etc. hope that helps.

Thank you for the report. This will be resolved in the next maintenance release as issue OTTER-130.

Sure, that would solve the issue.

Awesome Dean. Thanks for taking a look.

Pb solved with the 1.5.2

Pb solved with the 1.5.2