# Understanding (Windows PS) Plugins, Icinga2Agent and Director

**URL:** <https://community.icinga.com/t/understanding-windows-ps-plugins-icinga2agent-and-director/705>\
**Category:** Icinga Director\
**Created:** [March 25, 2019, 12:23pm UTC](https://community.icinga.com/t/understanding-windows-ps-plugins-icinga2agent-and-director/705 "2019-03-25T12:23:28Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\
**Post date:** [March 25, 2019, 3:25pm UTC](https://community.icinga.com/t/understanding-windows-ps-plugins-icinga2agent-and-director/705/4 "2019-03-25T15:25:53Z")

</div>

Interesting, I thought we’ve migrated all howtos. Obviously not, it is now located here: [Windows PowerShell Checks with Icinga2](https://community.icinga.com/t/windows-powershell-checks-with-icinga2/712)

Since the question targets the Director, you’ll need to figure out the command parameters first, e.g. by calling it on the command line. Once you’ve extracted such, you can start with the `Commands` tab inside the Director.

Add a new “plugin check command”, give it a name, and set the command to powershell.exe including its path, similar to what [https://github.com/NETWAYS/check\_exchange\_powershell/blob/master/icinga2-commands.conf](https://github.com/NETWAYS/check_exchange_powershell/blob/master/icinga2-commands.conf) describes (you of course include this once in your icinga2.conf, restart icinga2, and let the Director treat this as external command - the better way is to integrate it into the Director natively).

 ![22](https://community.icinga.com/uploads/default/original/1X/e87fc9684ca9205730672a94a1c6aa9356bf18c3.png)

Then put that command in the `global-templates` cluster zone.

 ![32](https://community.icinga.com/uploads/default/original/1X/4c9f5620a34930bdde2acac4194d1101e1a44116.png)

The `arguments` tab now appears, and you can start adding the arguments as key-value pairs following the model here: [https://github.com/NETWAYS/check\_exchange\_powershell/blob/master/icinga2-commands.conf#L10](https://github.com/NETWAYS/check_exchange_powershell/blob/master/icinga2-commands.conf#L10)

 ![26](https://community.icinga.com/uploads/default/original/1X/35f0ea77f317a705ac7b44056804b5f77b87159d.png)  
 ![03](https://community.icinga.com/uploads/default/original/1X/01b0c74b99b8ee0fa177a01230bd98884d91e235.png)  
 ![29](https://community.icinga.com/uploads/default/original/1X/88c1bd47d262d00e2157cb2b372206181065e567.png)

Change into the `Fields` tab and make the script parameter mandatory.

 ![17](https://community.icinga.com/uploads/default/original/1X/6f49b8cc2c5048c291410fe6a772160d89cd0702.png)

That’s the base powershell command, now you’ll need to put in the script actually being executed. You can do so either by setting `powershell_script` as data field (needs to be defined first) in your services, or you’ll create a new CheckCommand object which imports this one, and sets this parameter (preferred).

Add a new CheckCommand, import the existing one and set `powershell_script` to a default value.

 ![24](https://community.icinga.com/uploads/default/original/1X/fc713fec186c50399a302d4283eeba8de3763235.png)

Then hit deploy, to see that the configuration is actually rendered.

Next up, define a new service which uses the powershell plugin (and set the correct path of course).

First, go to “Define data fields” and verify that `powershell_script` is defined there.  
Second, define a service template which uses the check\_command and may override the custom properties for `powershell_script`.

The task left for you is to actually create the service apply rule / set then and see this working 🙂

Cheers,  
Michael

PS: The steps I’ve done here are reproducible with the standalone Vagrant box.

---

_[View the full topic](https://community.icinga.com/t/understanding-windows-ps-plugins-icinga2agent-and-director/705)._