There are tons of ways to automate an Exchange Server 2016 deployment process, and the product itself has a command line interface where the administrator can pass a lot of default settings during the installation process.
However, that is just the beginning. In some environments, we may be asked to build several servers and the goal is to make them the same -- after all, consistency is the key. Since I hate doing repetitive work and I had to build a DAG with 12 nodes, I decided to create a simple script to do it. I’ve been using that script for ages, but it was a bunch of scripts together that I’m used to running all the time. Any other administrator would need a few minutes to understand the logic behind it.
In my last engagement in my consulting services, the customer asked me to create a checklist and document the tasks to pass on to his operations team to prepare the environment. I could’ve created an extensive document showing all the steps, but it would require a second person to double-check the tasks and see if they were done exactly as described in the document.
I’m not a developer, and you will find that my code requires fine tuning. In this article, we are going over the steps and configuration that I put on practice for the script to work, and you can contribute to the script using GitHub.
Another comment before diving into the script: We have several similar scripts on the Internet to do the same thing. I’m using the code that I required to finish my tasks, and you can use it, too. If you improve it, please let me know. And feel free to research the Internet to find other and better ways to perform similar tasks.
Since I was going to make something easy to run for a non-Exchange administrator, my thought was to create a simple step-by-step guide that would configure not just Exchange Server but also prepare the server settings and the initial settings after the Exchange Server deployment. Because my goal was to create something that is bulletproof, I decided to find a way to define server names and main configuration during the design phase, so I would give to the customer just an answer file to execute on their servers.
To keep things easy, the script shown in the image below is the step-by-step guide that the operator has to follow to complete the preparation of the server and Exchange Server 2016 installation.
Before running the script, here are the requirements:
My first thought when creating this script was that I would like to control if the operations team was executing the script on the right server.
Based on that requirement, I used a file called server.info, which contains specific settings that we want to apply on any given server. For starters, we are defining these following items for each server:
After configuring the server, my goal for this customer was to configure the autodiscover, web services and license information. For that, I created a customer.info file with all the variables that I need to configure the environment.
The good thing about this format is that down the road you can add more columns to the file and use that information on new routines in your main script. I’ve done my best to always use the information coming from the files to make sure that the script is applicable to any new Exchange Server, and it does not have any static configuration on it.
The first block of the script is to retrieve the information from the files that we created previously, and we are going to store that information in two variables: $vinfo and $vserver. We are also getting the current server name in the $vhost variable and finally defining the path for the script.
After that we have the menu being printed on the screen. Nothing fancy, just displaying the information and reading the option from the console on the variable $opt.
Last but not least, we validate and create the C:\Temp folder on the server where the script is being executed.
In the first option, which is 1 – Network adjustments, our script will check if all network adapters were labeled correctly, and if they were, then a series of tasks will be applied to these additional network cards (Replication01, Replication02 and SMTP), as follows:
In this article -- which is the first of a series -- we went through the logic behind of the script, the configuration files, and how we configure the network portion of our Exchange Servers.
As I said earlier, I’m not a developer, so there is always room for improvements, and during the writing of this article I could identify at least four things that I could have done differently:
In the next article of this series, we will go over the other tasks of this script.
Photo credit: Flickr / Dan Pupek
What will be in your living room or on your wrist this year? It may very likely be one of…
As virtualization becomes a major part of organizations’ infrastructure, these SD-WAN technologies provide faster and more reliable networking solutions.
In this blog post, we are going over a simple script that can be used as an Azure runbook to…
On-premises backup is a down-to-earth solution for backing up your cloud data – especially for those with a healthy paranoia…