Creating servers and keeping basic configuration consistent and compliant

I am a strong believer that whatever you develop should be, if possible, easily usable by any administrator with sufficient access rights. Hence, maybe not everyone will be involved thinking about better ways of deploying servers and services (in this case), but I do think that everyone with sufficient rights should be able to use whatever automation developers create and should be able to apply those automation rules easily to any server. I believe in innovation and sharing innovation with colleagues.

So here is something I am testing in DEV something that is not hard to maintain once it has been setup and where parameters and servers can easily be changed by everyone with of course the necessary access rights.

Creating servers with the same configuration over and over is not that difficult, templates can take care of that very easily. But a lot of the steps which you need to take as an administrator are easier handled by using a tool such as VMware vRealize Orchestrator: Adding and changing RAM and CPU, selecting the correct datastore and such.

However to make sure that servers have a build which remains consistent can be more of a challenge. Here is an example: Administrator X might want .NET version 3.5 enabled and security might want to have this disabled. After a while, you will notice that services and features which are installed and enabled on servers are not always those services and features which are signed off on. Microsoft’s Desired State Configuration can be handy here. See my post here: DSC

So this is what you need:

1. Creating servers is handled by VMware vRealize Orchestrator. Anyone can run a created workflow without any formal training.

2. Keeping server configurations consistent (services, features, etc..) is being handled using DSC. DSC can make use of CSV files, these CSV files would contain the ‘specific servers’ to which a certain configuration file applies, or a list of services and features which should at all times be enabled for for example ‘database servers’.

Whether you want to use this as DEV or as Production, the methodology to create servers can be identical: Orchestrator creates the server and DSC makes sure each server remains compliant. The  Orchestrator workflows and the process to get DSC configurations approved, will most likely be different between Production and Dev.