In the Configuration management There are different approaches and needs, which is why there are a lot of products that can be combined with each other in some places.
As an example, the iTop from Combodo, which has more of a documentation approach. It supports problem, incident and change management as well as helpdesk according to ITIL with the CMDB (Configuration Management Database) as a basis and workflows for tickets.
On the other hand, there are, for example, “Puppet” or “Ansible”, which tend to support active administration through (partially) automated rolling out of a centrally specified configuration. The tools can then be used to implement the baseline defined in the CMDB fully automatically on all systems, which must be added to the assets after evaluation in the configuration management database.
Both types of CM should be used, documentation and automatic configuration, some of which are also available from a manufacturer as a complete package.
So that new employees can be integrated into IT administration more quickly and easily, it makes sense to have a template for most things. Examples include permissions on file systems for special user groups or security measures for web services with a Web application firewall.
Rule sets for firewalls can also be converted into templates. These must be documented with the appropriate note with which baseline they work on which product.
The history of a product or system is just as important as the template from which the corresponding configuration came.
Based on the life cycle of the system, improvements can be recorded via CSI (Continual Service Improvement / Continuous Improvement Program) for the subsequent product generation.
Known previous problems (issue/incident) can also be summarized in problem management and helps to avoid or detect and correct possible production or configuration errors.
If the configuration worked as desired on a test system, it can be applied to the same systems. This should be done automatically in order to keep possible sources of (human) error as low as possible.
Security measures (e.g. patches or firewall configurations) can be checked in small test environments without exposing the entire network to possible danger or failure due to incompatibility.
The documentation should include all configuration options so that it is not just a Windows Server 2019, but a VM on an ESXi 7.0 with compatibility level 6.7, etc. Everything that can be changed should be documented so that the same systems can be identified and uniform procedures are described can.