I'm starting a blog about my experiences and training/how to with using Salt for configuration management on Windows and Linux. I'm kind of worried about being coherent (especially with my first post that I've just created since it is a bit of a wall of text)
Anyways, I'd be interested in hearing any criticism - something that didn't make sense, anywhere I've given TMI, something I didn't even enough attention, or even if you don't agree with something I've said.
Anyways, here it the blog with my first post, which is supposed to just be an intro
https://saltyourwindows.blogspot.ca/
Why Salt?
Typically in an SMB Group Policy is used to centrally manage Windows computers, and it's relied on so much by IT professionals that not having full Group Policy in Azure Active Directory is a major deterrent to adopting it and decommissioning onsite Domain Controllers. But in reality, Group Policy isn't a great tool for configuration management.
Software deployment
We should just forget that Group Policy 'sort of' has this feature. It's hard to use, slow, and only works with MSI files. Just installing software using scripts works better, but that's not really a software deployment solutions and doesn't scale well. A lot of organizations use a third-party tool for software deployment because Group Policy is not the right tool for the job.
Documentation
It is possible to but comments in some places in a GPO, but it's hardly ever used and not easy to get too. Wouldn't it be nice to put comments where every you want and create documentation as you go? To effectively document group policy you pretty much have to be diligent in creating separate documentation, and when you're dealing with GUIs usually that means a lot more typing to explain what you mean, screenshots, etc. I create a lot of documentation, but my Group Policy documentation is lacking, I think it's because you can kind of figure it out just by through Group Policy, but the problem is that it is slow and connections between why your doing things a certain way might not be readily apparent.
Reporting
If you wanted to get reports of whether or not a GPO successfully applied to computers, you would have to collect the event logs from all the computers. Some organizations might be doing this, but I'm sure a lot aren't. Wouldn't it be nice if they just reported back automatically?
Using Complicated solutions
WMI filters, client-side targeting, etc. You could actually do a fair bit with these things, but a lot of techs don't unless they have to. Sometimes it is for performance reasons, and other times is is because things start looking messy.
What really pressed me to switch over to a new solution was for software deployment. I wasn't using GPO for software deployment anymore, I was deploying software through WSUS using WSUS Package Publisher, but I still found it cumbersome. I had some software I needed to deploy that actually required three different packages, and an extra package if the OS was Windows 10, and I wanted a clean way to do it. And so I turned to Google.
I already knew about the big configuration management players (well, at least I already knew their names) Chef, Puppet, Ansible, SaltStack. I ruled out Chef pretty early, it seems the consensus is that it is more tailored for developers, I'm sure that's an oversimplification but simplifying things can be useful. I also didn't look too far into Ansible, it seems their commercial version is pushed a lot and I actually prefer a client rather than clientless. I was looking at things those the lens of Windows, so I was specifically looking for examples of use with Windows and some kind of indications of Windows support. So I went with the tools I felt best about. There was a Windows specific channel in their Slack community. I was able to find specific Windows software deployment examples and it looked nice and simple. There were discussions about using it with Windows and lots of community modules that were easy to find. And so I chose Puppet.
It was about a week before I finished the training for Puppet (I used the Learning VM) but it seemed like exactly what I was looking for. I deployed my clients, created my puppet code for the software installation and organized things using Roles and Profiles. The software deployment worked great, I was very satisfied.
Now I was ready to translate my GPOs into Puppet code, so naturally I started with the hardest one, Folder Redirection. I knew this would be hard, since all the Configuration Management tools I looked at were designed for computer configuration and not user configuration. Folder Redirection is literally the only user configuration GPO I am currently using, and it is something I would really like a better solution for. However I quickly become out of my depth. I found myself having to write code in Ruby, and other things felt a bit hacky and like I was doing things against how I should be. How Puppet works is that the node gathers information about itself (Facts) and sends the information to the Puppet Master. The Puppet Master then compiles a configuration catalog and sends it to the node for it to apply. One limitation with this is that Facts are the preferred way to get any information about the client. The Puppet Code does not run on the client, so any code should use information that the Master has already received from the client. There are ways around this (since the code is evaluated on the client), but it isn't the natural way to do things.
I decided to look into Salt, since it has a client and because it uses Python, which I know. It turns out that Salt does have extensive support for Windows, it's all there in the docs, they just don't advertise it specifically. I also found Salt to be very flexible. If you want Salt to function like Puppet, it can. If you want to go agentless, you can. Salt was built on remote execute and maintains a persistent connection between the master and client, which means you can do some really cool things. You can do remote execute while you're applying a configuration, so you are not limited to by the grains (Salt's version of facts) already collected. A client can also trigger an event to happen based on something that happens on it. All this and more makes Salt very flexible, and is why I chose it for my configuration management tool.
I'm not a Salt expert. I dive deeper into it everyday, but I still have a long way to go. I created this blog because I wanted to show examples of it's use on Windows, which is what I was looking for when researching CM tools. So I welcome you to follow me on my journey with Salt, and if you have a suggest about a better way to configure something, let me know! I'm always looking to improve.
Anyways, I'd be interested in hearing any criticism - something that didn't make sense, anywhere I've given TMI, something I didn't even enough attention, or even if you don't agree with something I've said.
Anyways, here it the blog with my first post, which is supposed to just be an intro
https://saltyourwindows.blogspot.ca/
Why Salt?
Typically in an SMB Group Policy is used to centrally manage Windows computers, and it's relied on so much by IT professionals that not having full Group Policy in Azure Active Directory is a major deterrent to adopting it and decommissioning onsite Domain Controllers. But in reality, Group Policy isn't a great tool for configuration management.
Software deployment
We should just forget that Group Policy 'sort of' has this feature. It's hard to use, slow, and only works with MSI files. Just installing software using scripts works better, but that's not really a software deployment solutions and doesn't scale well. A lot of organizations use a third-party tool for software deployment because Group Policy is not the right tool for the job.
Documentation
It is possible to but comments in some places in a GPO, but it's hardly ever used and not easy to get too. Wouldn't it be nice to put comments where every you want and create documentation as you go? To effectively document group policy you pretty much have to be diligent in creating separate documentation, and when you're dealing with GUIs usually that means a lot more typing to explain what you mean, screenshots, etc. I create a lot of documentation, but my Group Policy documentation is lacking, I think it's because you can kind of figure it out just by through Group Policy, but the problem is that it is slow and connections between why your doing things a certain way might not be readily apparent.
Reporting
If you wanted to get reports of whether or not a GPO successfully applied to computers, you would have to collect the event logs from all the computers. Some organizations might be doing this, but I'm sure a lot aren't. Wouldn't it be nice if they just reported back automatically?
Using Complicated solutions
WMI filters, client-side targeting, etc. You could actually do a fair bit with these things, but a lot of techs don't unless they have to. Sometimes it is for performance reasons, and other times is is because things start looking messy.
What really pressed me to switch over to a new solution was for software deployment. I wasn't using GPO for software deployment anymore, I was deploying software through WSUS using WSUS Package Publisher, but I still found it cumbersome. I had some software I needed to deploy that actually required three different packages, and an extra package if the OS was Windows 10, and I wanted a clean way to do it. And so I turned to Google.
I already knew about the big configuration management players (well, at least I already knew their names) Chef, Puppet, Ansible, SaltStack. I ruled out Chef pretty early, it seems the consensus is that it is more tailored for developers, I'm sure that's an oversimplification but simplifying things can be useful. I also didn't look too far into Ansible, it seems their commercial version is pushed a lot and I actually prefer a client rather than clientless. I was looking at things those the lens of Windows, so I was specifically looking for examples of use with Windows and some kind of indications of Windows support. So I went with the tools I felt best about. There was a Windows specific channel in their Slack community. I was able to find specific Windows software deployment examples and it looked nice and simple. There were discussions about using it with Windows and lots of community modules that were easy to find. And so I chose Puppet.
It was about a week before I finished the training for Puppet (I used the Learning VM) but it seemed like exactly what I was looking for. I deployed my clients, created my puppet code for the software installation and organized things using Roles and Profiles. The software deployment worked great, I was very satisfied.
Now I was ready to translate my GPOs into Puppet code, so naturally I started with the hardest one, Folder Redirection. I knew this would be hard, since all the Configuration Management tools I looked at were designed for computer configuration and not user configuration. Folder Redirection is literally the only user configuration GPO I am currently using, and it is something I would really like a better solution for. However I quickly become out of my depth. I found myself having to write code in Ruby, and other things felt a bit hacky and like I was doing things against how I should be. How Puppet works is that the node gathers information about itself (Facts) and sends the information to the Puppet Master. The Puppet Master then compiles a configuration catalog and sends it to the node for it to apply. One limitation with this is that Facts are the preferred way to get any information about the client. The Puppet Code does not run on the client, so any code should use information that the Master has already received from the client. There are ways around this (since the code is evaluated on the client), but it isn't the natural way to do things.
I decided to look into Salt, since it has a client and because it uses Python, which I know. It turns out that Salt does have extensive support for Windows, it's all there in the docs, they just don't advertise it specifically. I also found Salt to be very flexible. If you want Salt to function like Puppet, it can. If you want to go agentless, you can. Salt was built on remote execute and maintains a persistent connection between the master and client, which means you can do some really cool things. You can do remote execute while you're applying a configuration, so you are not limited to by the grains (Salt's version of facts) already collected. A client can also trigger an event to happen based on something that happens on it. All this and more makes Salt very flexible, and is why I chose it for my configuration management tool.
I'm not a Salt expert. I dive deeper into it everyday, but I still have a long way to go. I created this blog because I wanted to show examples of it's use on Windows, which is what I was looking for when researching CM tools. So I welcome you to follow me on my journey with Salt, and if you have a suggest about a better way to configure something, let me know! I'm always looking to improve.
