I cheated and did it in SQL, been digging a little bit into your database anyways. DECLARE @DefaultRaftId INT SELECT TOP 1 @DefaultRaftId = Raft_Id FROM Rafts WHERE Raft_Name = 'Default' UPDATE [Servers] SET Raft_Id = @DefaultRaftId UPDATE [ServerRoles] SET Raft_Id = @DefaultRaftId

Thank you Alana, this makes sense. I was trying to use a NuGet feed type. This answers my question.

In case you didn't see the email, we were able to reproduce this with your repository and will be fixing this in the next maintenance release! Thanks

This is, unfortunately, a new glitch related to the call template statement in the visual editor. We'll be fixing it in next maintenance release. FWIW - we're also looking to add a "undo" mechanic that should, at the very least, allow for recovery to previous states when the visual editor creates an invalid model of a plan/OtterScript.

I'm afraid the Ensure operations are a bit trickier to write, mostly because they require the definition of a configuration template... The EnsureOperation<TConfig> class is designed to help make it simpler to write these... but we don't have a tutorial for those just yet. In the mean time, I've emailed you the source code of all of the built-in Operations and Configurations, so I hope that might be of some assistance.

Thanks, we've identified this as a bug with template variable processing, and will have this fixed in the next version of Otter (coming in a day or two).

We'll be fixing some of the bugs in the visual editor with regards to template arguments in a future maintenance release (hopefully 1.1.3); we've already made the changes in BuildMaster v5's editor, just need to bring them over.

This appears to be a bug in the visual editor regarding templates... but if you switch to text-mode it should work. template my_template<$arg1,@arg2,out $arg3>{ ... blocks and content here ... }

Hmm, I wonder if it's related to Powershell Execution Policy? I'm not terribly familiar myself, but I know I've had to fiddle with that a bit to get things working... 15 Ways to Bypass the PowerShell Execution Policy

The easiest workaround is to declare the variable at the top of your plan. set @WebServerFeatures = @(...) Otherwise we will get this shipped by end of day!

Yes; the JSON-based REST API allows you to do everything you can from the website, and there's also a simplified job trigger endpoint, where you can do something like POST /api/jobs/trigger/mytemplatname?key=secret123 to trigger a new job. These particular bits aren't fully documented (or implemented in current the v1.0 release) yet, but will be in just a day or so.

FYI one of our developers posted an answer on the linked question.

Although we do not provide a reseller discount, we do work with quite a few software resellers who purchase on behalf of their clients, as those clients prefer to have a single source for all procurement. If, as a reseller, you purchase directly from the MyInedo portal, just contact us with the end-user information, and we will update the licensing information. You can also submit a quote request as needed.

Ah, yes... definitely a bug. Seems to be related to some unanticipated changes in the latest WMF preview, but easy for us to fix. Can you please try upgrading to v1.0.3? Also please note that, due to a bug in the latest WMF5, it now appears you may need to specify a module name for some non-built in resources; it's supposed to be optional, and search all installed modules if not specified. We don't know when Microsoft will fix this, but the work-around is fairly simple: PSDsc xWebAdministration::xWebAppPool ( Name: AccountsAppPool, Ensure: present );