Hello, This is a bug, in that PSVerify shouldn't show up on the statement list. Instead, your scripts should, in a manner like this, with a Script Execution mode: [image: 1614579688039-f659bdca-9a55-4b9c-81bb-77ee357e8e66-image.png] Then, they'll look in Otter like this: PSVerify VerifyFreeSpace ( MinimumFreeGB: 24, DriveToVerify: C ); Here's how this script works behind the scenes... <# .DESCRIPTION Verifies that an hdars server has the required and expected configuration .AHDESIREDVALUE True .AHCURRENTVALUE $AmpleFreeSpace .PARAMETER DriveToVerify The drive letter (such as "C") for what to verify .PARAMETER MinimumFreeGB The minimum free space required on the drive, in gigabytes #> param ([int]$MinimumFreeGB = 20, [string]$DriveToVerify = "C") $ActualFreeGB = [int]((Get-PSDrive $DriveToVerify).Free / (1024 * 1024 * 1024)) $AmpleFreeSpace = $ActualFreeGB -gt $MinimumFreeGB And for reference, the additional help parameter descriptions... .AHDESIREDVALUE This is what you wish the configuration value to be. When not specified, the value of $true is assumed. .AHCURRENTVALUE This is the actual value of the configuration. When not specified, script's output is used. .AHCONFIGKEY This is the "configuration key" used by the script, which is a string that uniquely identifies configuration on a server. It's like a file on disk (a file is uniquely identified by its name), or the name of an IIS Application pool (an application pool is unqiuely identified by its name). Optional. When not specified, the name of the script is used. .AHVALUEDRIFTED This is an indicator as to whether the value is considered drifted. When not specified, it's a string comparison of the desired and current value. .AHEXECMODE This is either "Collect" or "Configure", and is only used on PSEnsure operations; it will be ignored (or set to Collect, depending on what's easier to code) on PSVerify. Using a PSEnsure without a .AHEXECMODE will cause an error. The Additional Help items can be specified as a value or a variable; variables will simply start with a $.

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!