I am trying to figure out the best way to handle the deployment of the Windows Agent and while I think I have it working farely well, I have one issue that I would like to get an opinion or help on.
I have import and sync configured to automatically add hosts from AD. This works fine.
I have the Windows Agent being deployed via SCCM using the Powershell module and the Director Self-Service API. This is also working fine with a couple of minor issues:
When the host object is imported from AD I have it configured to make the address field the fqdn. I like this because I prefer the fqdn over the IP address. When I deploy a Windows Agent with the Powershell module, it works fine… but it changes the address field to be the ipaddress instead of the fqdn.
This causes Director to see a change and require manual deployment. When the next scheduled sync/import jobs run, they see the ipaddress in the address field and automatically change it back to the fqdn, requiring another manual deployment of the config because of the change.
I would like to have it work so that the address field stays the fqdn but I cannot figure out how to make the agent use the fqdn for the address field instead of the ipaddress.
I could stop setting the address field in the import/sync to the fqdn but at the end of the day I would prefer it to be the fqdn.
I’m trying to automate as much as possible without my interaction and this seems to be my last issue.
Any suggestions? I tried using json in the Powershell module but it sounds like it will require using the username and password and director url in the script to accomplish it… I’m not OK with that.
I don’t know much about the internals of the mentioned PS script … maybe you can modify it or discuss the change upstream on GitHub? @cstein may know more.
The hope was to save time by using the Powershell script as opposed to contributing time to improve upon it
I am reluctantly leaning towards changing the import filter to not populate the address field (unless it is required to create a host, I am not sure about that.) This way the address field would be blank, then the agent gets installed and checks in populating the address field with the ip address… though that will likely be seen as a change also and will require deployment of the config again.
I am trying to avoid the manual deployment of the config here so I can have a fully automated Windows monitoring solution.
I have things working just fine now. I have accepted the fact that their will be config changes after the agent is installed and checks in because of the differences in the address field with the AD imported hosts.
To deal with this I have just created a job to deploy the config on a schedule.
This combined with service sets, templates, etc… and a mass deployment tool like SCCM allows me to have all servers that exist in AD auto imported to Icinga2, the Icinga2 agent auto deployed as soon as a server shows up in SCCM (which also syncs with AD) and the config changes automatically deployed when the address field differences are sorted out.
So in one fell swoop I can pretty much start monitoring every windows server for all common services with almost no effort on my part. Going forward, as new servers are added to AD they will automatically import to Icinga2, they will automatically go to SCCM which will automatically deploy the agent, and then the config changes will automatically deploy all without my involvement.
@csmall Very impressed by what you were able to accomplish
I have been using Icinga2 with Director for a couple in a Windows Environment with about 80 hosts. Just like you I use the AD import Sync to import all my Windows Server objects on a scheduled basis. Although the icinga project has extensive documentation , I haven’t found anything that is comprehensive for how to quickly integrate into a Windows Environment and hit the ground running.
My setup is working well and I’d like to expand my single master node to a distributed setup in the future. I also have been testing out the PowerShell Module to deploy the Windows Agent (it definitely works) and my next step is to automate with SCCM the deployment.
I would be one of the first to read a #howto if you wrote one and would be more than happy to contribute to anything you were to publish
