Automating Exchange Server 2016 deployment: Configure the network portion

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:

  • Server must be joined to the domain.
  • Server must have all Windows Update in place (we could add that to the script).
  • Network adapters must be renamed to MAPI, Replication01, Replication02, and SMTP.

Script logic and general settings

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:

  • Time zone.
  • IP Address for the first replication network adapter (NICRep01).
  • IP Address for the second replication network adapter (NICRep02).
  • IP Address for the SMTP network adapter (SMTP).

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.

OS settings

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:

  • Configure the IPs based on the server.info configuration file.
  • Disable DNS registration.
  • Disable NetBIOS.
  • Disable Client for Microsoft Networks.
  • Disable File and Printer Sharing for Microsoft Networks.

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:

  • We could use a loop (Do-While statement) for the main menu
  • The adapter names could come from the configuration file instead of static information.
  • The 24 prefix on the network adapter could come from the configuration files as well.
  • I could’ve used the switch statement instead of if,

In the next article of this series, we will go over the other tasks of this script.

Photo credit: Flickr / Dan Pupek

Anderson Patricio

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange, CISSP and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at Techgenix.com, MSExchange.org, ITPROCentral.com and Anderson Patricio.org (Portuguese).

Share
Published by
Anderson Patricio

Recent Posts

IFA 2019: Smart TVs and even smarter wearables unveiled

What will be in your living room or on your wrist this year? It may very likely be one of…

3 hours ago

Consider these SD-WAN technologies for faster, more reliable networking

As virtualization becomes a major part of organizations’ infrastructure, these SD-WAN technologies provide faster and more reliable networking solutions.

6 hours ago

An overview of PCI DSS and a guide to compliance

PCI DSS is the globally recognized security standard for any business that processes credit card payments. Are you in compliance…

22 hours ago

Quick tip: Runbook script to start and stop your Azure Firewall

In this blog post, we are going over a simple script that can be used as an Azure runbook to…

1 day ago

Private 5G networks: Everything you need to know

We are on the verge of the rollout of public 5G networks. And following close behind is the reality of…

1 day ago

On-premises backup for cloud data and cloud infrastructure protection

On-premises backup is a down-to-earth solution for backing up your cloud data – especially for those with a healthy paranoia…

2 days ago