Hello, the configuration plans can do a ton of great things, but they're a bit confusing -- and a big thing we want to be improving in the next year, with both software and documentation changes. But I'll explain a couple things you might already know, for the sake of helping someone who might read this in future. Using your first script (without the execution policy): The OtterScript is executed twice in a row; first in "Collect" mode then "Ensure" mode if it Ensure-File always executes in Collect (and it records whether the file exists), and it may execute in the "Ensure" run (where it would create/overwrite) if it reported drift Start-Service never executes in Collect, but may run in "Ensure" mode... but may executes if another operation in the block reported drift (i.e. if Ensure-File reported drift) Post-Http never executes in Collect mode, and it never executes or Ensure modes, because it's the only statement in a block The with executionPolicy=always policy changes this, and it's the intended use of this execution directive. But... it's an editor bug, so we'll fix it. So... all that said... I don't think I'd recommend doing an error handling in a Configuration plan like this; it feels more appropriate for an Orchestration plan that you run for a purpose, to like provision or set-up a server. Otter will perform a routine configuration scan at least every hour, so there's a good chance this will just end up sending the same error message over and over: Drift is a detected Configuration FAILS to change Error notice is sent This isn't all that helpful, and is more of an indication of an outage more than anything else. And this isn't a great way to detect an outage. Instead, you can check the status of the server; if there is a failure during a Configuration execution, the server status becomes Error, and it can then be investigated about the details.

Thank you for your reply. That's great news, I'm really looking forward to the new version.

You're welcome

Hi Phillipe, I created an issue on GitHub, #8, to track adding this to the extension. I'll reply back once there is a CI version released of the extension. Thanks, Rich

@gdivis

@rhessinger Thanks a lot. I will try it.

@atripp Thank you Just one small quesiton: When do you plan to make the UPack raft available for both BuildMaster and Otter ?

@rhessinger Good news thank you

thanks!! Very interesting to see.

Hello; For this, we recommend just doing a Backup and Restore. Of course, the Detatch/Reattach is effectively the same thing, but don't forget the config. For the Git-based raft, the Database just contains the connection information to the Bitbucket repository... so it will just come over with the database.

Alright, fair enough. As I use Otter almost exclusively for checking for compliance, I will look forward to this. Nontrivial asks are always the best ones, right? :D

I'll see if we can get a new version built that includes an option to output the full log to the console after a job completes. In the meantime, you could call romp with a simple batch script like: romp install %1 romp jobs logs Then invoke it with: romp.bat <packageName> Let me know if that's helpful!

Hi Philippe, Thank you for the report, this has been fixed internally and will be released in the next maintenance release on Dec. 6. The associated issue is here: https://inedo.myjetbrains.com/youtrack/issue/OT-360 Thanks, -John

We definitely want to add these as first-class Operations in our Windows extensions, but in the mean time the best route is to use the PSDsc Operation to invoke the Windows Feature DSC Resource PSDSC WindowsFeature ( Name: Web-Server, Ensure: present ); Hope that helps!

We recently moved our documentation; do you know where you found those 404s? We're also monitoring via Analytics Tools as well, but finding sooner is better :) Anyways PSCall is good in Orchestration Plans (can be done in a Configuration Plan, under some conditions), and PSEnsure is best for Configuration Plans. Explaining Ensure vs Execute can be tricky, but I'd recommend checking out our ebook, called Windows-first Guide to Infrastructure as Code and Continuous Configuration Automation :)

Thanks for tracking those down, I updated owner on them :)

We hope to include this ability in a future release, but it's a bit more complicated to get the details worked out. For now, just uninstall, then reinstall (pick version you want) will work.

Thanks Philipe; all operation documentation is automatically updated within the software once the latest version of the relevant extension is installed (i.e. the Windows extension in this case). The documentation on the website will also get updated with any minor version of the software is released, or the Inedo.SDK is updated. Hope this helps, -Tod

So I looked over OT-331, and while close, I am looking for each role to report the status of each server that has that role assigned to it, and whether it has drifted or is current. Thanks!

Alright, I have my one token agent I had to update. Thanks!