Install and Configure pfBlockerNg for DNS Black Listing in pfSense FirewallDownload Your Free eBooks NOW – 10 Free Linux eBooks for Administrators | 4 Free Shell Scripting eBooks
In an earlier article the installation of a powerful FreeBSD based firewall solution known as pfSense was discussed. pfSense, as mentioned in the earlier article, is a very powerful and flexible firewall solution that can make use of an old computer that may be laying around not doing much.
This article is going to talk about a wonderful add-on package for pfsense called pfBlockerNG.
pfBlockerNG is a package that can be installed in pfSense to provide the firewall administrator with the ability to extend the firewall’s capabilities beyond the traditional stateful L2/L3/L4 firewall.
As the capabilities of attackers and cyber criminals continues to advance, so must the defenses that are put in place to thwart their efforts. As with anything in the computing world, there isn’t a one solution fixes all product out there.
pfBlockerNG provides pfSense with the ability for the firewall to make allow/deny decisions based items such as the geolocation of an IP address, the domain name of a resource, or the Alexa ratings of particular websites.
The ability to restrict on items such as domain names is very advantageous as it allows administrators to thwart attempts of internal machines attempting to connect out to known bad domains ( in other words, domains that may be known to have malware, illegal content, or other insidious pieces of data).
This guide will walk through configuring a pfSense firewall device to use the pfBlockerNG package as well as some basic examples of domain block lists that can be added/configured into the pfBlockerNG tool.
This article will make a couple of assumptions and will build off of the prior installation article about pfSense. The assumptions will be as follows:
- pfSense is already installed and has no rules currently configured (clean slate).
- The firewall only has a WAN and a LAN port (2 ports).
- The IP scheme being used on the LAN side is 192.168.0.0/24.
It should be noted that pfBlockerNG can be configured on an already running/configured pfSense firewall. The reason for these assumptions here is simply for sanity’s sake and many of the tasks that will be completed, can still be done on a non-clean slate pfSense box.
The image below is the lab diagram for the pfSense environment that will be used in this article.
Install pfBlockerNG for pfSense
With the lab ready to go, it is time to begin! The first step is to connect to the web interface for the pfSense firewall. Again this lab environment is using the 192.168.0.0/24 network with the firewall acting as the gateway with an address of 192.168.0.1. Using a web browser and navigating to ‘https://192.168.0.1’ will display the pfSense login page.
Some browsers may complain about the SSL certificate, this is normal since the certificate is self signed by the pfSense firewall. You can safely accept the warning message and if desired, a valid certificate signed by a legitimate CA can be installed but is beyond the scope of this article.
After successfully clicking ‘Advanced’ and then ‘Add Exception…’, click to confirm the security exception. The pfSense login page will then display and allow for the administrator to log in to the firewall appliance.
Once logged in to the main pfSense page, click on the ‘System’ drop down and then select ‘Package Manager’.
Clicking this link will change to the package manager window. The first page to load will be all the currently installed packages and will be blank (again this guide is assuming a clean pfSense install). Click on the text ‘Available Packages’ to be provided a list of installable packages for pfSense.
Once the ‘Available Packages’ page loads, type ‘pfblocker’ into the ‘Search term’ box and click the ‘Search’. The first item that is returned should be pfBlockerNG. Locate the ‘Install’ button to the right of the pfBlockerNG description and click the
‘+’to install the package.
The page will reload and request the administrator confirm the installation by clicking ‘Confirm’.
Once confirmed, pfSense will begin to install pfBlockerNG. Do not navigate away from the installer page! Wait until the page displays successful installation.
Once the installation has been completed, the pfBlockerNG configuration can begin. The first task that needs to be completed though is some explanations on what is going to happen once pfBlockerNG is configured properly.
Once pfBlockerNG is configured, DNS requests for websites should be intercepted by the pfSense firewall running the pfBlockerNG software. pfBlockerNG will then have updated lists of known bad domains that are mapped to a bad IP address.
The pfSense firewall needs to intercept DNS requests in order to be able to filter out bad domains and will use a local DNS resolver known as UnBound. This means clients on the LAN interface need to use the pfSense firewall as the DNS resolver.
If the client requests a domain that is on pfBlockerNG’s block lists, then pfBlockerNG will return a false ip address for the domain. Let’s begin the process!
pfBlockerNG Configuration for pfSense
The first step is to enable the UnBound DNS resolver on the pfSense firewall. To do this, click on the ‘Services’ drop down menu and then select ‘DNS Resolver’.
When the page reloads, the DNS resolver general settings will be configurable. This first option that needs to be configured is the checkbox for ‘Enable DNS Resolver’.
The next settings are to set the DNS listening port (normally port 53), setting the network interfaces that the DNS resolver should listen on (in this configuration, it should be the LAN port and Localhost), and then setting the egress port (should be WAN in this configuration).
Once the selections have been made, be sure to click ‘Save’ at the bottom of the page and then click the ‘Apply Changes’ button that will appear at the top of the page.
The next step is the first step in configuration of pfBlockerNG specifically. Navigate to the pfBlockerNG configuration page under the ‘Firewall’ menu and then click on ‘pfBlockerNG’.
Once pfBlockerNG has loaded, click on the ‘DNSBL’ tab first to begin setting up the DNS lists before activating pfBlockerNG.
When the ‘DNSBL’ page loads, there will be a new set of menus beneath the pfBlockerNG menus (highlighted in green below). The first item that needs to be addressed is the ‘Enable DNSBL’ check box (highlighted in green below).
This check box will require the UnBound DNS resolver be used on the pfSense box in order to inspect dns requests from LAN clients. Don’t worry UnBound was configured earlier but this box will need to be checked! The other item that needs to be filled in on this screen is the ‘DNSBL Virtual IP’.
This IP needs to be in the private network range and not a valid IP on the network in which pfSense is being used. For example, a LAN network on 192.168.0.0/24 could use an IP of 10.0.0.1 as it is a private IP and isn’t part of the LAN network.
This IP will be used to gather statistics as well as monitor domains that are being rejected by pfBlockerNG.
Scrolling down the page, there are a few more settings worth mentioning. The first is the ’DNSBL Listening Interface’. For this setup, and most setups, this setting should be set to ‘LAN’.
The other setting is ‘List Action’ under ‘DNSBL IP Firewall Settings’. This setting determines what should happen when a DNSBL feed provides IP addresses.
The pfBlockerNG rules can be setup to do any number of actions but most likely ‘Deny Both’ will be the desired option. This will prevent inbound and outbound connections to the IP/domain on the DNSBL feed.
Once the items have been selected, scroll to the bottom of the page and click the ‘Save’ button. Once the page reloads, it is time to configure the DNS Block Lists that should be used.
pfBlockerNG provides the administrator with two options that can be configured independently or together depending on the administrator’s preference. The two options are manual feeds from other web pages or EasyLists.
To read more about the different EasyLists, please visit the project’s homepage: https://easylist.to/
Configure pfBlockerNG EasyList
Let’s discuss and configure the EasyLists first. Most home user’s will find these lists to be sufficient as well as the least administratively burdensome.
The two EasyLists available in pfBlockerNG are ‘EasyList w/o Element Hiding’ and ‘EasyPrivacy’. To use one of these lists, first click on the ‘DNSBL EasyList’ at the top of the page.
Once the page reloads, the EasyList configuration section will be made available. The following settings will need to be configured:
- DNS Group Name – User’s choice but no special characters
- Description – User’s choice, special characters allowed
- EasyList Feeds State – Whether the configured list is used
- EasyList Feed – Which list to use (EasyList or EasyPrivacy) both can be added
- Header/Label – User choice but no special characters
The next section is used to determine which parts of the lists will be blocked. Again these are all user preference and multiple can be selected if desired. The important settings in the ‘DNSBL – EasyList Settings’ are as follows:
- Categories – User preference and multiple can be selected
- List Action – Needs to be set to ‘Unbound’ in order to inspect DNS requests
- Update Frequency – How often pfSense will update the list of bad sites
When the EasyList settings are configured to the user’s preferences, be sure to scroll to the bottom of the page and click the ‘Save’ button. Once the page reloads, scroll to the top of the page and click on the ‘Update’ tab.
Once on the update tab, check the radio button for ‘Reload’ and then check the radio button for ‘All’. This will run through a series of web downloads to obtain the block lists selected on the EasyList configuration page earlier.
This must be done manually otherwise lists won’t be downloaded until the scheduled cron task. Anytime changes are made (lists added or removed) be sure to run this step.
Watch the log window below for any errors. If everything went to plan, client machines on the LAN side of the firewall should be able to query the pfSense firewall for known bad sites and receive bad ip addresses in return. Again the client machines must be set to use the pfsense box as their DNS resolver though!
Notice in the nslookup above that the url returns the false IP configured earlier in the pfBlockerNG configurations. This is the desired outcome. This would result in any request to the URL ‘100pour.com’ being directed to the false IP address of 10.0.0.1.
Configure DNSBL Feeds for pfSense
In contrast to the AdBlock EasyLists, there is also the ability to use other DNS Black Lists within pfBlockerNG. There are hundreds of lists that are used to track malware command and control, spyware, adware, tor nodes, and all sorts of other useful lists.
These lists can often be pulled into pfBlockerNG and also used as further DNS Black Lists. There are quite a few resources that provide useful lists:
The links above provide threads on pfSense’s forum where members have posted a large collection of the list’s they use. Some of the author’s favorite lists include the following:
Again there are tons of other lists and the author strongly encourages that individuals seek out more/other lists. Let’s continue with the configuration tasks though.
The first step is to go into pfBlockerNG’s configuration menu again through ‘Firewall’ -> ‘pfBlockerNG’ -> ’DSNBL’.
Once on the DNSBL configuration page again, click on the ‘DNSBL Feeds’ text and then click on the ‘Add’ button once the page refreshes.
The add button will allow the administrator to add more lists of bad IP addresses or DNS names to the pfBlockerNG software (the two items already in the list are the author’s from testing). The add button brings the administrator to a page where DNSBL lists can be added to the firewall.
The important settings in this output are the following:
- DNS Group Name – User chosen
- Description – Useful for keeping groups organized
- DNSBL Settings – These are the actual lists
- State – Whether that source is used or not and how it is obtained
- Source – The link/source of the DNS Black List
- Header/Label – User choice; no special characters
- List Action – Set to Unbound
- Update Frequency – How often the list should be updated
Once these settings have been set, click the save button down at the bottom of the page. As with any changes to pfBlockerNG, the changes will take effect on the next scheduled cron interval or the administrator can manually force a reload by navigating to the ‘Update’ tab, click the ‘Reload’ radio button, and then click the ‘All’ radio button. Once those are selected, click the ‘Run’ button.
Watch the log window below for any errors. If everything went to plan, test that the lists are working by simply attempting to do an nslookup from a client on the lan side to one of the domains listed in one of the text files used in the DNSBL configuration.
As can be seen in the output above, the pfSense device is returning the virtual IP address that was configured in pfBlockerNG as the bad IP for the black list domains.
At this point the administrator could continue tuning the lists by adding more lists or creating custom domain/IP lists. pfBlockerNG will continue to redirect these restricted domains to a fake IP address.
A virtual private network (VPN) is one of the most popular methods to access files and resources, such as apps, intranet websites, and printers using an encrypted connection from a remote location and through the internet.
Often companies use VPN to extend their private network to allow employees access resources through a public network as if they were directly connected into the company’s network.
Windows 10 like other versions of the OS has a feature called “Incoming Connection” that enables you to set up a VPN server to connect remotely to your home network to access your computer’s files and peripherals, and even other computers in the network.
In this guide, you’ll learn how to set up a VPN server on your Windows 10 computer without the need of extra software on the Home or Pro version of the OS.
- How to find your IP address information
- How to set up port forwarding on your router
- How to set up a VPN server on Windows 10
- How to allow VPN connections through the firewall
- How to set up a VPN connection on Windows 10
How to find your IP address information
Before diving into the instructions, the first thing you need to know is your public IP address that has been assigned to you by your Internet Service Provider (ISP). You will need this information in order to contact your VPN server remotely.
To know your current public IP address, open your web browser, and using any search engine, do a search for “What’s my IP”, and your information should be listed in the first result.
If you’re setting up Incoming Connection in your home computer, you probably have a dynamic public IP address, which can change at any time. If this is the case, you’ll need to configure DDNS (Dynamic Domain Name System) in your router to avoid having to configure the VPN setup every time your public IP address changes.
Here are the instructions that will help you set up DDNS on your router. Remember that you can visit your router’s manufacturer website for more assistance to configure DDNS.
How to set up port forwarding on your router
To be able to connect through a public network, such as the internet, to your home VPN server, you’ll need to forward port 1723 (Point to Point Tunneling Protocol (PPTP)) to allow VPN connections.
Here are the instructions that will help you set up port forwarding on your router. Remember that you can visit your router’s manufacturer website for more assistance to configure Port Forwarding.
How to set up a VPN server on Windows 10
Once you have set up DDNS to use a domain name instead of a complicated IP address, and you forwarded port 1723, now you are ready to set up a VPN server on your device:
Use these steps to create a VPN server on Windows 10:
- Open Control Panel.
- Click on Network and Sharing Center.
- Using the left pane, click the Change adapter settings link.
- On “Network Connections,” open the File menu pressing the Alt key, and select the New Incoming Connection option.
- Check the users you want to VPN access to your computer, and click the Next button.
Alternatively, you can click the Add someone button to create a new VPN user:
- Check the Through the Internet option.
- Click the Next button.
- In the networking software page, select Internet Protocol Version 4 (TCP/IPv4) option.
- Click the Properties button.
- Check the Allow callers to access my local area network option.
- Under “IP address assignment,” click Specify IP addresses, and specify the number of clients allowed to access using a VPN connection. (You will do this by specifying an IP address range, and it’s recommended that you use high-order range of IP addresses to help avoid conflicts in the network with the IPs distributed by your router.)
Quick Tip: To find out the range of IP addresses you can use, navigate to your router’s settings page, and look for the DHCP settings.
- Click the OK button.
- Click the Allow access button.
- Click the Close button to complete setting up the VPN server on Windows 10.
How to allow VPN connections through the firewall
While configuring the Incoming Connection feature on Windows 10 should automatically open the necessary Windows Firewall ports, you want to make sure the firewall is properly configured.
Use these steps to allow VPN connections through the firewall on Windows 10:
- Open Start.
- Search for Allow an app through Windows Firewall, and click the top result to open the experience.
- Click the Change settings button.
- Scroll down and make sure Routing and Remote Access is allowed on Private and Public.
- click the OK button.
How to set up a VPN connection on Windows 10
After completing setting up the Windows 10 as a VPN server, you’ll need to configure the devices that will be accessing your local network remotely. You can set up any device, including your desktop, laptop, tablet, and even phone (e.g., Android and iPhone).
Here are the instructions to set up a VPN connection on Windows 10.
Once you set up a VPN connection on your computer, you’ll need to adjust the settings with these steps:
- Open Control Panel.
- Click on Network & Internet.
- Click on Network and Sharing Center.
- On the left pane, click the Change adapter settings link.
- Right-click the VPN adapter and select Properties.
- In the General tab, make sure you’re using the correct domain you created while configuring DDNS — or at least you’re using the correct public IP address.
- Click on the Security tab.
- Under “Type of VPN,” select the Point to Point Tunneling Protocol (PPTP) option.
- Under “Data encryption,” select the Maximum strength encryption (disconnect if server declines) option.
- Click the OK button.
- Click on the Networking tab.
- Uncheck the Internet Protocol Version 6 (TCP/IPv6) option.
- Check the Internet Protocol Version 4 (TCP/IPv4) option.
- Select the Internet Protocol Version 4 (TCP/IPv4) option.
- Click the Properties button.
- Click the Advanced button.
- Clear the Use default gateway on remote network option.
Important: We’re disabling this option to prevent your web traffic to go through the remote connection, which can dramatically slow down your internet connection. However, if you’re looking to access the internet through a VPN connection, then don’t change this last setting.
- Click the OK button.
- Click the OK button again.
- Click the OK button once more.
- Open Settings.
- Click on Network & Internet.
- Click on VPN.
- Select the VPN connection option and click the Connect button.
While there are many solutions to allow users to connect remotely to a private network using a VPN connection, you can set up your own server with the tools built within Windows 10 without the need of extra software.
In addition, one of the best benefits of setting up a VPN server on your Windows 10 PC is that it’s not only secure and reliable, but it’s a great alternative for users who are still skeptical about cloud services to store their data. Even more, through a virtual private network, you can even access your device using remote desktop.
If you’re dual booting Windows and Linux, you’ll probably want to access files on your Linux system from Windows at some point. Linux has built-in support for Windows NTFS partitions, but Windows can’t read Linux partitions without third-party software.
So we’ve rounded up some third-party software to help. This list is focused on applications that support the Ext4 file system, which most new Linux distributions use by default. These applications all support Ext2 and Ext3, too—and one of them even supports ReiserFS.
Ext2Fsd is a Windows file system driver for the Ext2, Ext3, and Ext4 file systems. It allows Windows to read Linux file systems natively, providing access to the file system via a drive letter that any program can access.
You can have Ext2Fsd launch at every boot or only open it when you need it. While you can theoretically enable support for writing to Linux partitions, I haven’t tested this. I’d be worried about this option, myself—a lot can go wrong. Read-only support is fine, though, and doesn’t carry a risk of messing anything up.
The Ext2 Volume Manager application allows you to define mount points for your Linux partitions and change Ext2Fsd’s settings.
If you didn’t set Ext2Fsd to autostart at boot, you’ll have to go into Tools > Service Management and start the Ext2Fsd service before you can access your Linux files. By default, the driver automatically mounts and assigns drive letters to your Linux partitions, so you don’t have to do anything extra.
You’ll find your Linux partitions mounted at their own drive letters in Windows Explorer. You can access the files on them from any application, without the hassle of copying files to your Windows partition before accessing them.
This partition’s file system as actually EXT4, but Ext2Fsd can read it fine, anyway. If you’re looking for your personal files, you’ll find them in your /home/NAME directory.
DiskInternals Linux Reader
Linux Reader is a freeware application from DiskInternals, developers of data recovery software. In addition to the Ext file systems, Linux Reader also supports ReiserFS and Apple’s HFS and HFS+ file systems. It’s read-only, so it can’t damage your Linux file system.
Linux Reader doesn’t provide access via a drive letter—instead, it’s a separate application you launch to browse your Linux partitions.
Linux Reader shows previews of your files, making it easy to find the right one.
If you want to work with a file in Windows, you’ll have to save the file from your Linux partition to your Windows file system with the Save option. You can also save entire directories of files.
We’ve covered Ext2explore in the past. It’s an open-source application that works similarly to DiskInternals Linux Reader—but only for Ext4, Ext3, and Ext2 partitions. It also lacks file previews, but it has one advantage: it doesn’t have to be installed; you can just download the .exe and run it.
The Ext2explore.exe program must be run as administrator, though, or you’ll get an error. You can do this from the right-click menu.
To save some time in the future, go into the file’s properties window and enable the “Run this program as an administrator” option on the Compatibility tab.
As with Linux Reader, you’ll have to save a file or directory to your Windows system before you can open it in other programs.
With the end of life of Windows 2003, Windows 2003 domain controllers (DCs) need to be updated to Windows Server 2008, 2012 or 2016. As a result, any domain controller that runs Windows Server 2003 should be removed from the domain. The domain and forest functional level should be raised to at least Windows Server 2008 to prevent a domain controller that runs an earlier version of Windows Server from being added to the environment.
We recommend that customers update their domain functional level (DFL) and forest functional level (FFL) as part of this, since the 2003 DFL and FFL have been deprecated in Windows Server 2016 and they will no longer be supported in future releases.
For customers who need additional time to evaluate moving their DFL & FFL from 2003, the 2003 DFL and FFL will continue to be supported with Windows 10 and Windows Server 2016 provided all domain controllers in the domain and forest are either on Windows Server 2008, 2008R2, 2012, 2012R2, or 2016.
At the Windows Server 2008 and higher domain functional levels, Distributed File Service (DFS) Replication is used to replicate SYSVOL folder contents between domain controllers. If you create a new domain at the Windows Server 2008 domain functional level or higher, DFS Replication is automatically used to replicate SYSVOL. If you created the domain at a lower functional level, you will need to migrate from using FRS to DFS replication for SYSVOL. For migration steps, you can either follow the procedures on TechNet or you can refer to the streamlined set of steps on the Storage Team File Cabinet blog.
The Windows Server 2003 domain and forest functional levels continue to be supported, but organizations should raise the functional level to Windows Server 2008 (or higher if possible) to ensure SYSVOL replication compatibility and support in the future. In addition, there are many other benefits and features available at the higher functional levels higher. See the following resources for more information:
Windows Server 2016
Supported Domain Controller Operating System:
- Windows Server 2016
Windows Server 2016 forest functional level features
- All of the features that are available at the Windows Server 2012R2 forest functional level, and the following features, are available:
Windows Server 2016 domain functional level features
- All default Active Directory features, all features from the Windows Server 2012R2 domain functional level, plus the following features:
- DCs can support rolling a public key only user’s NTLM secrets.
- DCs can support allowing network NTLM when a user is restricted to specific domain-joined devices.
- Kerberos clients successfully authenticating with the PKInit Freshness Extension will get the fresh public key identity SID.
Windows Server 2012R2
Supported Domain Controller Operating System:
- Windows Server 2016
- Windows Server 2012 R2
Windows Server 2012R2 forest functional level features
- All of the features that are available at the Windows Server 2012 forest functional level, but no additional features.
Windows Server 2012R2 domain functional level features
- All default Active Directory features, all features from the Windows Server 2012 domain functional level, plus the following features:
- DC-side protections for Protected Users. Protected Users authenticating to a Windows Server 2012 R2 domain can no longer:
- Authenticate with NTLM authentication
- Use DES or RC4 cipher suites in Kerberos pre-authentication
- Be delegated with unconstrained or constrained delegation
- Renew user tickets (TGTs) beyond the initial 4 hour lifetime
- Authentication Policies
- New forest-based Active Directory policies which can be applied to accounts in Windows Server 2012 R2 domains to control which hosts an account can sign-on from and apply access control conditions for authentication to services running as an account.
- Authentication Policy Silos
- New forest-based Active Directory object, which can create a relationship between user, managed service and computer, accounts to be used to classify accounts for authentication policies or for authentication isolation.
- DC-side protections for Protected Users. Protected Users authenticating to a Windows Server 2012 R2 domain can no longer:
Windows Server 2012
Supported Domain Controller Operating System:
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
Windows Server 2012 forest functional level features
- All of the features that are available at the Windows Server 2008 R2 forest functional level, but no additional features.
Windows Server 2012 domain functional level features
- All default Active Directory features, all features from the Windows Server 2008R2 domain functional level, plus the following features:
- The KDC support for claims, compound authentication, and Kerberos armoring KDC administrative template policy has two settings (Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012 domain functional level. For more information, see What’s New in Kerberos Authentication
Windows Server 2008R2
Supported Domain Controller Operating System:
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
Windows Server 2008R2 forest functional level features
- All of the features that are available at the Windows Server 2003 forest functional level, plus the following features:
- Active Directory Recycle Bin, which provides the ability to restore deleted objects in their entirety while AD DS is running.
Windows Server 2008R2 domain functional level features
- All default Active Directory features, all features from the Windows Server 2008 domain functional level, plus the following features:
- Authentication mechanism assurance, which packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos token. When this feature is enabled in a network environment that has deployed a federated identity management infrastructure, such as Active Directory Federation Services (AD FS), the information in the token can then be extracted whenever a user attempts to access any claims-aware application that has been developed to determine authorization based on a user’s logon method.
- Automatic SPN management for services running on a particular computer under the context of a Managed Service Account when the name or DNS host name of the machine account changes. For more information about Managed Service Accounts, see Service Accounts Step-by-Step Guide.
Windows Server 2008
Supported Domain Controller Operating System:
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
- Windows Server 2008
Windows Server 2008 forest functional level features
- All of the features that are available at the Windows Server 2003 forest functional level, but no additional features are available.
Windows Server 2008 domain functional level features
- All of the default AD DS features, all of the features from the Windows Server 2003 domain functional level, and the following features are available:
- Distributed File System (DFS) replication support for the Windows Server 2003 System Volume (SYSVOL)
- DFS replication support provides more robust and detailed replication of SYSVOL contents. [!NOTE]> >Beginning with Windows Server 2012 R2, File Replication Service (FRS) is deprecated. A new domain that is created on a domain controller that runs at least Windows Server 2012 R2 must be set to the Windows Server 2008 domain functional level or higher.
- Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability. Domain-based namespaces in Windows Server 2008 mode also require the forest to use the Windows Server 2003 forest functional level. For more information, see Choose a Namespace Type.
- Advanced Encryption Standard (AES 128 and AES 256) support for the Kerberos protocol. In order for TGTs to be issued using AES, the domain functional level must be Windows Server 2008 or higher and the domain password needs to be changed.
- For more information, see Kerberos Enhancements. [!NOTE]> >Authentication errors may occur on a domain controller after the domain functional level is raised to Windows Server 2008 or higher if the domain controller has already replicated the DFL change but has not yet refreshed the krbtgt password. In this case, a restart of the KDC service on the domain controller will trigger an in-memory refresh of the new krbtgt password and resolve related authentication errors.
- Last Interactive Logon Information displays the following information:
- The total number of failed logon attempts at a domain-joined Windows Server 2008 server or a Windows Vista workstation
- The total number of failed logon attempts after a successful logon to a Windows Server 2008 server or a Windows Vista workstation
- The time of the last failed logon attempt at a Windows Server 2008 or a Windows Vista workstation
- The time of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation
- Fine-grained password policies make it possible for you to specify password and account lockout policies for users and global security groups in a domain. For more information, see Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration.
- Personal Virtual Desktops
- To use the added functionality provided by the Personal Virtual Desktop tab in the User Account Properties dialog box in Active Directory Users and Computers, your AD DS schema must be extended for Windows Server 2008 R2 (schema object version = 47). For more information, see Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide.
- Distributed File System (DFS) replication support for the Windows Server 2003 System Volume (SYSVOL)
Windows Server 2003
Supported Domain Controller Operating System:
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
- Windows Server 2008
- Windows Server 2003
Windows Server 2003 forest functional level features
- All of the default AD DS features, and the following features, are available:
- Forest trust
- Domain rename
- Linked-value replication
- Linked-value replication makes it possible for you to change group membership to store and replicate values for individual members instead of replicating the entire membership as a single unit. Storing and replicating the values of individual members uses less network bandwidth and fewer processor cycles during replication, and prevents you from losing updates when you add or remove multiple members concurrently at different domain controllers.
- The ability to deploy a read-only domain controller (RODC)
- Improved Knowledge Consistency Checker (KCC) algorithms and scalability
- The intersite topology generator (ISTG) uses improved algorithms that scale to support forests with a greater number of sites than AD DS can support at the Windows 2000 forest functional level. The improved ISTG election algorithm is a less-intrusive mechanism for choosing the ISTG at the Windows 2000 forest functional level.
- The ability to create instances of the dynamic auxiliary class named dynamicObject in a domain directory partition
- The ability to convert an inetOrgPerson object instance into a User object instance, and to complete the conversion in the opposite direction
- The ability to create instances of new group types to support role-based authorization.
- These types are called application basic groups and LDAP query groups.
- Deactivation and redefinition of attributes and classes in the schema. The following attributes can be reused: ldapDisplayName, schemaIdGuid, OID, and mapiID.
- Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability. For more information, see Choose a Namespace Type.
Windows Server 2003 domain functional level features
- All the default AD DS features, all the features that are available at the Windows 2000 native domain functional level, and the following features are available:
- The domain management tool, Netdom.exe, which makes it possible for you to rename domain controllers
- Logon time stamp updates
- The lastLogonTimestamp attribute is updated with the last logon time of the user or computer. This attribute is replicated within the domain.
- The ability to set the userPassword attribute as the effective password on inetOrgPerson and user objects
- The ability to redirect Users and Computers containers
- By default, two well-known containers are provided for housing computer and user accounts, namely, cn=Computers, and cn=Users,. This feature allows the definition of a new, well-known location for these accounts.
- The ability for Authorization Manager to store its authorization policies in AD DS
- Constrained delegation
- Constrained delegation makes it possible for applications to take advantage of the secure delegation of user credentials by means of Kerberos-based authentication.
- You can restrict delegation to specific destination services only.
- Selective authentication
- Selective authentication makes it is possible for you to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest.
Supported Domain Controller Operating System:
- Windows Server 2008 R2
- Windows Server 2008
- Windows Server 2003
- Windows 2000
Windows 2000 native forest functional level features
- All of the default AD DS features are available.
Windows 2000 native domain functional level features
- All of the default AD DS features and the following directory features are available including:
- Universal groups for both distribution and security groups.
- Group nesting
- Group conversion, which allows conversion between security and distribution groups
- Security identifier (SID) history
Every new version of Windows Server adds more features. Active Directory domain and forest functional levels determine the features that can be used within the system. You can check domain and forest functional levels using these steps.
- From the “Administrative Tools” menu, select “Active Directory Domains and Trusts“.
- Right-click the root domain, then select “Properties“.
- Under the “General” tab, the “Domain functional level” and “Forest functional level” is displayed on the screen.
You can also use steps 2 and 3 from within the Active Directory Users and Computers snap-in to see the same screen.
The forest functional level can be changed by right-clicking Active Directory Domains and Trusts and selecting Raise Forest Functional Level… Before doing this step, you must ensure that all domains in the forest are at the level required for the change.
The domain functional level can be changed by right-clicking the domain and selecting Raise Domain Functional Level… Before doing this step, you must ensure that all domain controllers are running the version(s) of windows that allow for the change. For more information on raising domain and forest functional levels, visit the Microsoft page – How to raise Active Directory domain and forest functional levels.
You can also grab information via a command line or PowerShell if you’d like to go that route.
Frequently in support, we encounter several backup related calls for Exchange 2010 databases. A sample of common issues we hear from our customers are:
- “My backup software is not able to take a successful snapshot of the databases”
- “My backups have been failing for quite a while. I have several thousand log files consuming disk space and I will eventually run out of disk space”
- “My backup software indicates that the backup is successful but at the end of my backup, logs do not truncate”
- “The Exchange Writer /VSS writer is not in a stable state (state is listed as ‘Retryable‘, ’Waiting for completion‘ or ’Failed’)”
- “We suspect that the Volume Shadow Copy Service (VSS) is failing on the server and hence there are no successful backups”
It is critical to understand how backups and log truncation work in Exchange 2010. If you haven’t already done so, check out our three-part blog series by Jesse Tedoff on backups and log truncation in Exchange 2010, Everything You Need to Know About Exchange Backups*.
When troubleshooting backups in Exchange 2010 we are interested in two writers – the Exchange Information Store Writer (utilized for active copy backups) and the Exchange Replica Writer (utilized for passive copy backups). The writers are responsible for providing the metadata information for databases to the VSS Requestor (aka the backup software). The VSS Provider is the component that creates and maintains shadow copies. At the end of successful backups, when the Volume Shadow Copy Service signals backup is complete, the writers initiate post-backup steps which include updating the database header and performing log truncation. (For more details, see Exchange VSS Writers on MSDN.)
As explained above, it is the responsibility of the VSS Requestor to get metadata information from Exchange writers and at the end of successful backup, VSS service signals backup complete to the Exchange writers so the writers can perform post-backup operations.
The purpose of this blog is to discuss the VSSTester script, its functionality and how it can help diagnose backup problems.
What does the script to?
The script has two major functions:
- Perform Diskshadow backup of a selected Exchange database so we can exercise the VSS framework in the system, so at the end of a successful snapshot, database header is updated and log files are truncated. We will discuss in detail what Diskshadow is and what it does.
- The second function of this script is to collect diagnostic data. For backup cases, there is a lot of data that needs to be collected. To get the diagnostic data you may have to manually go to different places in the Exchange server and turn on logging. If that is not done correctly, we will miss getting crucial logs during the time of the issue. The script makes the data collection process much easier.
- The current version of the script works only on Exchange 2010 servers.
- The script needs to be run on the Exchange server that is experiencing backup issues. If you are having issues with passive copy backups, please go to the appropriate node in the DAG and run the script. For example: You may have Database A having copies on Server1, Server2 and Server3. Server1 hosts the active copy of the database. If backups of the active copy have previously failed run the script on Server1. Otherwise run script on whichever of the remaining servers has failed previously when backing up the passive copy.
- Please ensure that you have enough space on the drive you save the configuration and output files. Exchange and VSS traces, Diagnostic logs can occupy up to several GBs of drive space depending on the time taken for taking backup. For example: Running the script in a lab environment consumed close to 25MB of drive space a minute.
- The script is unsigned. On the server where you run the script you will have to set the execution policy to allow unsigned PowerShell scripts. Please see this for how to do this.
The script can be run on any DAG configuration. You can use this to troubleshoot Mailbox and Public folder database backup issues. Databases and log files can be on regular drives or mount points. Mix and match of the two will also work!
Let us discuss in detail the two main functionalities of the script.
Diskshadow functionality and how the script uses it
What is Diskshadow and why do we utilize it in VSSTester script?
Diskshadow.exe is a command line tool built in to Windows Server 2008 operating system family as well as Windows Server 2012. Diskshadow is an in-box VSS requestor. It is utilized to test the functionality provided by the Volume Shadow Copy Service (VSS). For more details on Diskshadow please visit:
The best part about Diskshadow is that it includes a script mode for automating tasks. This feature of Diskshadow is utilized in the VSSTester. The shadow copy done by Diskshadow is a snapshot of the entire volume at a given point in time. This copy is read-only.
More details on how a shadow copy is created, please visit the following link: http://technet.microsoft.com/en-us/library/ee923636(v=ws.10).aspx
During the course of the blog post, I will be mentioning the term “Diskshadow backup”. It is very important to understand that the term “backup” is relative here. Diskshadow uses the VSS service and gets the appropriate writer to be utilized for the snapshot. The writer will provide the metadata information of database /log files to the Diskshadow. After which Diskshadow utilizes the VSS Provider to create a shadow copy.
After a successful shadow copy /snapshot of databases and log files, the VSS Provider signals an end-backup to Exchange writers. To Exchange this looks like a full backup has been performed on the database. The key to understand here is NO data is actually transferred to a device, tape etc. This is only a test! You will see events in the application logs that usually show up when you take a regular backup, but NO data is actually backed up. Diskshadow has simply run all the backup APIs through the backup process without transferring any data.
The VSS Provider will take a snapshot of all the databases and logs (if present) on the volume. We will be doing a mirrored snapshot of the entire volume at the point in time when Diskshadow was run. Anything that is on the volume will be part of the snapshot. During the Diskshadow backup, we will be utilizing either the Information store writer (for active copy backup) or the Replica Writer (Passive copy backup) to provide the metadata information for the database.
When you use the VSSTester script, it prompts you for a database to be selected to perform the Diskshadow backup. When we take a snapshot of the volume all other databases (if present on the same drive) will be part of the snapshot, but post-backup operations will happen only on the selected database. This is because we will be utilizing either the Information store Writer (Active Copy Backup) or the Replica Writer (Passive copy backup) that is associated with the selected database. DB headers get updated based on VSS Requestor interaction with the Exchange writer that was utilized, which in turn leads to log truncation. Hence the header of the selected database will be only updated and logs will be purged (only for that the selected database) without being backed up.
When would you be interested in utilizing this Diskshadow functionality of the script?
You would be interested to utilize this functionality in almost all scenarios that I discussed at the start of this blog post. In addition to those scenarios another one that is not related to backups sometimes arises:
- “I had an unexpected high transactional log growth issue in my exchange 2010 environment and now I am on the verge of losing all disk space in the logs directory. I do not have the time to perform a backup to truncate logs and my goal is to safely remove all the log files”
In the scenario mentioned above (and, by the way, if you have that problem, please go here), Exchange administrators would like to avoid causing a service outage by dismounting the database, removing log files and remounting the database. Another downside to manually removing the log files is breaking replication if the database has replicas across Database Availability Group members.
If you are willing to forgo a backup of the log files you can use the Diskshadow functionality of the script to trigger the backup APIs and tell Exchange to truncate the log files. The truncation commands will replicate to the other database copies and purge log files there as well. If successful, the net result is that the database will not go offline for lack of disk space on the log drive, but you will not have the security of retaining those log files for a future restore.
A sample run of the VSSTester script (with Diskshadow functionality)
Let me demonstrate the Diskshadow functionality of the script.
The Script can be downloaded from here.
The script initializes and gives us the following options.
We select the option 1 to test backup using the built-in Diskshadow function.
If the path does not exist, the script will create the folder for you.
We gather the server name and verify it is an Exchange 2010 server. The script will check for the VSS writer status on the local machine. If we detect, any of the writers are not in a “Stable” state, the script will exit. You will need to restart the service associated with the writer to get the writers to a stable state (The Replication service for the Replica Writer or the Information Store service for the Exchange Writer).
The script then gets a list of databases present on the local server and displays the database name, if database is mounted or not and what is the server that holds the active copy of the database. You will have to select the number of the database.
Note: If the user does not provide an input, the script will automatically select the last database in the list.
In my case, I selected database mdb5. The number to enter would be 8.
The next important check is ensuring that the database’s replicas (if present) are healthy. If we detect that one of the copies is not healthy, the script will exit mentioning that the database copies need to be in healthy status before running the script.
The script next detects the location of the database file and log files. We create the Diskshadow configuration file on the fly every time a database is selected. This configuration file is also saved to the location you had specified earlier (in the example screenshots of this blog c:\vsstesterlogs) to save the configuration and output files. In this case the log files are in a mount point and the database file is on a regular volume. The script will add the appropriate volumes to the disk shadow file.
The script will then prompt you to provide the drive letters to expose the snapshots. A common question that arises is, do I need to initialize the drive before I specify a drive letter? The answer is no!
You will be specifying a drive letter that is currently not in use, so Diskshadow will create a virtual drive and expose the snapshot. Remember, the virtual drive that exposes the shadow copy is a read-only volume. The shadow copy is a read only copy .If the database and logs are in the same mount point / drive only, one drive letter is required to expose the snapshot, otherwise you will need to provide two different drive letters. One for exposing database snapshot and another for log files.
When you select the option to perform the Diskshadow backup, the script will automatically collect Diagnostic logs, ExTRA traces and VSS traces. Also verbose logging is turned on for Diskshadow. Whatever activity the script does is also logged in to transcript log and saved in the output files directory (c:\vsstesterlogs in this example).
Note: If you are performing a passive copy backup, ExTRA tracing will also be turned on in the active node. At the end of the script, we turn off ExTRA tracing in the active node and it will be automatically moved to the passive node. The active node ETL will be placed in the logs folder you had specified at the start of the script. .
Now, the main Diskshadow function will execute.
In the screenshots below we have excluded all other writers on the system that are associated with all other databases on the node (that are mounted or be replicas) and we are ONLY utilizing the writer associated with the selected database. This node hosts the passive copy of the database MDB5. Hence, the writer utilized will be associated with the Replication service aka the Microsoft Exchange Replica Writer.
From the screen shot below, you can see that VSS Provider has taken a successful snapshot of the database and signaled end backup to the replica writer.
Now that we performed a successful snapshot of the database and log files, all the logging that was turned on will be turned off. The log files will be consolidated in the logs folder that you specified earlier at the start of the script. The script checks the VSS writer status after the backup is complete.
When the snapshot operation is complete, you will be prompted for an option to either remove the snapshot or leave the snapshots exposed in Windows Explorer.
I selected the option to remove the snapshot; hence we will be invoking Diskshadow again to delete the snapshot created earlier.
Let us discuss in detail exposing and removing snapshot functionality:
- Remove snapshots – The snapshots that were taken earlier (database or log files) will be exposed in the Windows explorer, if the snapshot operation was successful. In this script we expose the snapshots as a drive letter (that you had specified earlier). If you do not want to have a copy of the log files, you may chose this option and the snapshot will be deleted. All the logs that got purged after post-backup will be present in this read only volume and when this volume is removed they will be deleted forever.
- Expose Snapshots – You may choose to have the snapshots exposed. Later, if you want to delete the snapshot, please do the following
- Open Command prompt
- Type in Diskshadow
- Delete shadows exposed <volume>
Note: It is highly recommended to take a full backup of the database using your regular backup software after utilizing Diskshadow.
After this, the script collects the application and system logs. The script filters them to cover only the period you started the script to the present. The transcript log is also stopped. The logs will be saved as a text file and saved in the output folder you had specified earlier (c:\vsstesterlogs in this example).
The most reliable method to verify log truncation takes place is to get the log sequence before and after the backup. Hence, before running the script I ran eseutil/ml ENN (the log generation prefix associated with database).
Post-backup, when I ran the same command, and can see:
We can clearly see a difference in the start of the sequence, meaning log truncation has occurred for the database. One more verification that can be done is to check the database header. We can see that the database header got updated to the most recent time, where Diskshadow was run.
I ran the script; what have I accomplished?
If the script finished successfully:
- We were able to successfully test and exercise the underlying VSS framework in the server. Volume Shadow Copy service was able to successfully identify and utilize the Exchange writers in the box
- The Exchange writers are able to provide the metadata information to the VSS Requestor (Diskshadow)
- VSS Provider was able to successfully create a snapshot /shadow copy
- VSS successfully signaled the Exchange writers on backup complete
- The Exchange writers were able to perform the post snapshot operations which included log truncation.
Let us now look in to the other major functionality of the script.
Enable logging to troubleshoot backup issues
Use this if you do not want to test backup using Diskshadow and you just want to collect diagnostic logs for troubleshooting backup issues.
You may collect the diagnostic logs and have them handy before calling Microsoft Support saving a lot of time in the support incident because you can provide the files at the beginning of the case.
This time we will be selecting option 2 to enable logging.
Selecting this option does the majority of the things that the script did earlier, EXCEPT Diskshadow of course!
After checking the writer status, you can select the database to backup. We will be enabling all the logging like before (Diagnostic Logging, ExTRA, VSS tracing). Remember that, even though you would still be selecting one database – diagnostic logging, ExTRA tracing, VSS tracing are not database specific and are turned on at the server level. When you are utilizing the script to troubleshoot backup issues you can select any one database on the server and it will turn on appropriate logging on the server.
After the logging is turned on and traces enabled, you will see:
Now you will need to start your regular backup. After the backup completes/fails, you will need to come back to the PowerShell window where you are running the script and use the “ENTER” key to terminate the data collection. The script then disables diagnostic logging and tracing that was turned up earlier. If needed it will copy diagnostic logs from the active node for that database copy as well.
The script will again check for writer status after the backup then collect the application and system logs. It will stop the transcript log as well.
At this point, in order to troubleshoot the issue, you can open a case with Microsoft Support and upload the logs.
I hope this script helps you in better understanding the core concepts in Exchange 2010 backups, thus helping you troubleshoot backup issues! You can utilize Diskshadow to test Volume Shadow Copy Service and also check if the Exchange writers are performing as intended. If Diskshadow completes successfully without any error and you are still experiencing issues with backup software, you may need to contact the backup vendor to further troubleshoot the issue.
This article suggests that you cannot sustain downtime or interruption for your users while battling with deleting log files or restoring your working backup solution. If you can sustain a downtime (should be around minutes or so) the easiest method will be to enable Circular Logging on your database / storage group – see more here – http://technet.microsoft.com/en-us/library/bb331958%28v=exchg.141%29.aspx#UTL
The exchange team has written a script which helps troubleshoot and identity issues with Backups etc.. The script use the DiskShadow utility as well ! check it out @ http://blogs.technet.com/b/exchange/archive/2013/04/29/troubleshoot-your-exchange-2010-database-backup-functionality-with-vsstester-script.aspx
Hi Again !
I often get calls and questions regarding backups and Exchange Server, since ever this issue is not always working as required or as you would expect, but that’s off-topic
One of the most common stories is that without a working Exchange Server backup when you perform massive mailbox moves, transaction logs will get piled and fill up the volume or disk that they reside in. and then panic starts, “hey my databases were dismounted…” then of course the administrator realizes that the space on the log drive or volume has indeed ran out and now he needs to figure out what to delete.. and here’s where this post comes in…
So how can you delete or purge Exchange server logs without any risk ? well, in simple – you cannot, because the whole idea of restoring an Exchange or for this matter any transactional database requires you to have a first – “full” backup of the database itself and all transaction logs that were generated since the the date of the database creation date, or the last “successful” “full backup”.
Now here’s a nice method to “fake” a “full backup” or an on-demand transaction logs purge when you see you will be soon out of space, using the Exchange VSS writers and the diskshadow utility (available with Server 2008 or 2008 R2) . This procedure also “proves” that a VSS backup for your Exchange Server will work fine.
note: This method was tested on an Exchange server with Locally Attached Disks, not storage attached LUNs.
Use this method on on your risk. You should preform a “Full Backup” right after this process is done.
This example will show you how to purge the logs for a database that is located on Drive D, the log files of the databases are also located in Drive D. we will “fake backup” drive D and this will trigger the logs to be purged.
Note: If you have separated your log files and database file in different drives, or you want to include additional databases in the “backup” you must include the additional drives in the process, so in the example below, you will “Add volume e:” after “Add volume drive d:” and so on…
- Open Command prompt
- Launch Diskshadow
- Add volume d:
- (optional, add one line for each additional drive to include) Add volume X:
- Begin Backup
- End Backup
- At this step you should notice the following events in the application log indicating that the backup was indeed successful and logs will now be deleted.
Here’s some screenshots from the process:
The Diskshadow example screenshot.
ESE – Event ID 2005 – Starting a Full Shadow Copy Backup
MSexchangeIS – Exchange VSS Writer preparation.
ESE Event ID 224 – Logs are now purged
MSExchangeIS Event ID 9780 – Backup is now complete.
side note: although this example was tested against Exchange 2010, it should work just as fine with Exchange 2013 & 2007
ORIGINAL SOURCE OF THIS ARTICLE.
Microsoft Exchange 2016 is exciting as it comes with a host of cool features such as cloud deployments, improved reliability, and a new architecture that is much more conducive for today’s business environment.
If you haven’t done it already, it’s probably time to consider migrating your mail server from Exchange 2010 to 2016 because it is more convenient and lays the foundation for future progress.
So, what’s new in Exchange 2016 that makes it so exciting for system administrators world over?
Let’s briefly look at some of the key changes in 2016 that were not available in the 2010 version. Also, if you don’t want to miss my future Exchange configuration guides and best practices articles, sign up for updates here!
Exchange 2010 had separate components such as Mailbox, Hub Transport, Unified Messaging, and Client Access for performing separate roles in the server. In 2016, all of these components have been combined into a single component called Mailbox, and this component performs the combined role of other components.
Exchange Admin Center
Exchange Admin Center (EAC) has been greatly enhanced to help you connect from anywhere using a web browser. It acts as a single point of control for all operations and is optimized for on-premise, online, and hybrid Exchange deployments. Due to this enhanced EAC, Exchange Management Console (EMC) of 2010 has taken a back seat. Microsoft observed delayed updates in EMC, and this is why it decided to limit its scope in 2016.
Hybrid Configuration Wizard (HCW)
Exchange 2016 has a cloud-based application called Hybrid Configuration Wizard (HCW) that helps to connect with other Microsoft tools like Office 365 in real-time. Improved diagnostics and troubleshooting make it ideal for hybrid deployments.
MAPI over HTTP
MAPI over HTTP is the default protocol in Exchange 2016, as it is more reliable and stable than the RPC over HTTP protocol of Exchange 2010. Also, this protocol allows Outlook to pause a connection, change networks, and resume hibernation, things that were difficult to implement in Exchange 2010.
In 2010, you had to install certificate for every server through EMC, while in 2016, you can install certificates across multiple servers at the same time through EAC. You can also see the expiry details in EAC.
Now that you know why Exchange 2016 is better, let’s see how to migrate from version 2010 to 2016.
Update the existing environment
If you unsure of the version you’re using, open the Exchange Management Shell and run this command:
Get-ExchangeServer : Format-List Name, Edition, AdminDisplayVersion
This should bring up the current version you’re using. Make sure it says Exchange 2010.
The first step is to update the existing environment to make the 2010 version suitable for upgrading to 2016. To do that, install Exchange 2010 Service Pack 3 and Exchange 2010 SP3 Update Rollup 11. These are the minimum supported patch level updates for 2010, and the installation process is fairly self-explanatory.
The next step is to consider updating the Directory Service Requirement and Outlook Client. For Exchange 2016, the minimum Directory Service Requirement is AD Functional Level 2008, and for Outlook Client, it is Exchange 2016 Support Outlook 2010 and above on Windows and Mac Outlook 2011 and above on Mac. You should update clients to this minimum supported version before implementing Exchange 2016.
Prepare the System for Exchange Server 2016
Do you have the system requirements needed to support Exchange 2016? Let’s double check the below requirements again, as Exchange Server 2016 supports only the following:
- Windows Server 2012 / 2012 R2
- Minimum memory requirement for Mailbox server role is 8GB plus an additional minimum requirement of 4GB for edge transport
- Paging file size should be set to physical RAM, and an additional 10MB to 32788MB, depending on the size of the RAM. If you’re using 32GB of RAM, then go for the maximum of 32788MB
- Disk space of at least 30GB on the drive on which you plan to install Exchange. Also, an additional 500MB is needed for every Unified Messaging (UM) language pack that you want to install. Additionally, you need 200MB of available disk space on the system drive, and a hard disk of a minimum of 500MB of free space for message queue database
- A screen resolution of 1024 X 768 pixels.
- Disk partitions that are formatted on the NTFS file system
- .NET framework and UCS API should be installed before installing Exchange 2016. You can download both from Microsoft website and install it in your system.
Make sure your system meets all these prerequisites before installing Exchange 2016.
Next, you have to prepare the schema update. This step is irreversible, so make sure you have a full backup of Active Directory before proceeding.
A good part about this migration is you don’t have to worry much about changing HTTPS names for OWA as both the versions support the same set of naming services and active sync directories.
Install Active Directory for Exchange 2016
Next, run the Exchange 2016 setup. Choose a specific directory to extract all the files of this setup. Once the extraction is complete, run the following commands, one after the other. Open the command prompt and go to the directory where you have extracted the files.
The first command is to prepare the schema, which is, setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Now your schema is prepared, so move on to the next command, which is, setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms. Once that’s done, prepare your domain with the command setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms. With this, we have completed the Active Directory installation for Exchange 2016.
Install Exchange 2016
Now that you have the environment set up, it’s time to do what you’ve come for, which is installing Exchange 2016. Fortunately, this is also the easiest step in the migration process as the configuration wizard takes care of most things for you!
Browse through the setup directory, and run the file called Setup.exe.
During the installation, you’ll be prompted to choose the server role selection. Choose « Mailbox role, » and the other options will automatically be deactivated because Mailbox and Edge Transport cannot coexist in the same machine.
Installation will complete within the next few minutes.
Once the installation is complete, click on the Finish button. This will load the Exchange Admin Center on the browser.
Exchange management console in 2010 is replaced with a web-based Exchange Admin Center in 2016. This is the place where you can have greater control over all operations.
After installing Exchange 2016 successfully, update the Service Connection Point for AutoDiscover. To do this, use the Set-ClientAccess command from Exchange Management Shell.
Go to the Exchange Management Shell, and type this command:
Set-ClientAccessService -Identity E2016 -AutoDiscoverServiceInternalURI https://autodiscover.yourURL.com/Autodiscover/Autodiscover.xml
Next, update the settings of Outlook Anywhere. To do this, go to EAC, and click on servers on the left hand side. This will open up the list of servers. Click the Edit icon and a pop-up will open. Choose the Outlook Anywhere option, and update the DNS lookup and IMAP4 settings with the name of your new server.
Once you’ve configured the settings, run IIS RESET. To do this, go to your command prompt and run the command iisreset. This will stop and restart IIS services.
The next step is to configure your Receive Connector to relay email applications. To configure this, go to the mail flow option in your EAC, click on a connector, and edit it.
Next up is your Mail Database installation. When you install 2016, a default database is created. You can rename this database and move it from C Drive to another drive. Open the EMC shell and run these commands to rename and move your database.
Get-MailboxDatabase -Server E2016 : Set-MailboxDatabase -Name DBExchange2016
Move-DatabasePath -Identity DB01 -EdbFilePath E:\Database\DB01\DBExchange2016.EDB. -LogFolderPath E:\Database\DBExchange2016_Log
Once that’s done, update the OWA directory. Exchange 2016 supports acting-as-a-proxy for 2010, so both the versions can coexist using the same URLs. Now, change the OWA and autodiscover URL to Exchange 2016, to ensure all URLs go through Exchange 2016. You can use the below script to do that.
$Server = « E2010 »
$HTTPS_FQDN = your_URL
Get -OWAVirtualDirectory -Server $Server | Set -OWAVirtualDirectory -ExternalURL $null
Get -ECPVirtualDirectory -Server $Server | Set -ECPVirtualDirectory -ExternalURL $null
Get -OABVirtualDirectory -Server $Server | Set -OABVirtualDirectory -ExternalURL $null
Get -ActiveSyncVirtualDirectory -Server $Server | Set -ActiveSyncVirtualDirectory -ExternalURL $null
Get -WebServicesVirtualDirectory -Server $Server | Set -WebServicesVirtualDirectory -ExternalURL $null
Enable -OutlookAnywhere -Server $Server -ClientAuthenticationMethod Basic -SSLOffloading $False -ExternalHostName $HTTPS_FQDN
Lastly, update the DNS, so it points to autodiscover and OWA. To do that, open your Accu Directory Domain Controller Machine. Open the DNS Manager, and change the record to ensure that it points to the new server.
Whew! With this, you’re almost done with the migration.
Test your configuration
Finally, it’s time to test if your configurations work. It’s best to create a new user to login and test the account functionality. To create a new user, open EAC and click on Recipients. From here, add a new user and check if everything is working fine.
If all is good, migrate all users from the Exchange 2010 to the Exchange 2016 database.
And that’s a wrap!
In short, much has changed between Exchange 2010 and Exchange 2016, so it’s best you migrate to the latest version to make the most of the new functionalities. Migrating to 2016 is not so difficult when you follow the aforementioned steps.
Do the migration right away to enjoy the new functionalities of Exchange 2016, not to mention the reduced workload of mundane tasks. With all Exchange has to offer, you best prepare to upgrade to appreciate the benefits. (Remember, an upgrade is usually one-time only!)
Learn why Exchange 2016 is better than Exchange 2010–and how to take the plunge to migrate your Microsoft server to the latest version.
The latest version of Exchange Server brings the latest cloud-based developments and reliability improvements to on-premises Exchange. In this series we will walk through the steps required to implement Exchange 2016 into your current Exchange 2010 organization and migrate mailboxes across.
Planning for Deployment
In this short series we’ll be focusing on the implementation and migration steps to move from Exchange 2010 to Exchange 2016, rather than implementing features like Database Availability Groups or configuring load balancing. Therefore, we’ll focus on a smaller organization with a relatively simple deployment.
Before you begin it’s important to understand that a key architectural change has been made in Exchange 2016. Exchange 2010 had a number of separate roles; Client Access, Hub Transport, Mailbox and Unified Messaging.
In Exchange 2016 only a single role is used, the Mailbox role. This contains all necessary components required.
Our example organization is Goodman Industries, who have a single Exchange 2010 multi-role server and will migrate over to a single Exchange 2016 mailbox server.
Figure 1: An overview of our topology
In the example above, you’ll see our source server EX1401 running Exchange 2010. Our target server will be EX1601. In a larger organization this would most likely be highly available, so we’d have multiple domain controllers (rather than just AD01) and use Database Availability Groups on the source and target.
Naming and Services
Our first step is to define names used by clients to access Exchange. Co-existence with Exchange 2010, 2013 and 2016 allows sharing of the same HTTPS names for Autodiscover, OWA, ActiveSync and other services, making it easy to transition across and reduce the risk of implementing co-existence.
|Old Exchange 2010 Namespaces||New Exchange 2016 Namespaces|
Exchange Server Sizing
The environment we’ll be implementing Exchange 2016 on is virtualised, running Hyper-V in our example.
|CPUs||Cores||SPECint_rate2006 score||Host RAM||Disks Available|
|2 x Intel Xeon||12||367||256GB||24 x 4TB 3.5” 7.2K RPM SAS (RAID 10)|
We have also collected statistics from the existing environment:
|Number of mailboxes||Average Message Size||Average Received||Average Sent||Average Mailbox Size|
To calculate the requirements, we’ll use version 7.8 or higher of the Exchange Server Role Requirements Calculator. This supports both Exchange 2013 and Exchange 2016, so be sure to select the correct version when using the tool.
When sizing the solution two important factors will form design constraints:
- The solution will not have high availability and instead will use Hyper-V for high availability.
- The Exchange 2016 environment will provide quota limits of 5GB per user.
- We’ll configure the maximum number of databases to be 5.
- We’ll use a VSS-based backup solution rather than Exchange Native Protection – simply because it’s a non-HA simple environment.
Our output from the role requirements calculator results in the following server specification:
|Hostname||Virtual CPU||RAM||OS Disk||Page file Disk||Physical disks required||Database virtual disks||Log virtual disks||Restore LUN|
|EX1601||1 x vCPU||16GB||100GB||20GB||4 x 4TB||5 x 291GB||5 x 5GB||1 x 213GB|
The Virtual CPU specifies how many CPU cores should be assigned to the Virtual Machine used, as does the RAM. The OS disk will hold both Operating System Exchange install and transport databases.
The Physical Disks represents how many of the available physical disks are needed to actually support the deployment and meet requirements for performance and space. In the virtual environment, these will be presented as virtual disks and will be used for database and log files respectively.
You’ll note that we’re still splitting databases and logs. For an implementation making use of Exchange Native Protection we wouldn’t look to do this, but for an implementation in a virtual environment that takes advantage of backups this is still required. We’ve also included an additional virtual disk to use as a restore LUN.
Splitting Databases from logs ensure that in the scenario of a log disk filling up, databases will not be corrupted. We also ensure that losing or the corruption of a virtual disk doesn’t result in a full restore of Exchange.
Updating the environment
Updating Exchange Server 2010
The minimum supported patch level for Exchange Server 2010 is Service Pack three with Update Rollup 11.
Exchange 2010 Service Pack 3 is available here.
Exchange 2010 SP3 Update Rollup 11 is available here. Install it, or a newer version if it is available.
Directory Service Requirements
The last few versions of Exchange had reasonably light requirements on AD functional levels. Now Windows 2003 R2 has finally went out of support the minimum Forest Functional Level and Domain Functional Level has been changed from 2003 and above. The minimum support FFL/DFL is now a minimum of Windows 2008 or above.
Updating Outlook Clients
Exchange 2016 supports Outlook 2010 and above on Windows, and on the Mac Outlook 2011 and higher. Outlook 2007 is no longer supported, but may work.
All versions of Outlook 2016 and Outlook 2013 are supported. Outlook 2010 is supported with the April 2015 update (KB2965295).
Update clients to the minimum supported version required before implementing Exchange 2016. Newer versions of Outlook will work with Exchange 2010 without issue.
Preparing the server for Exchange 2016
Exchange 2016 supports Windows 2012 and Windows 2012 R2. In our series we’ll use Windows 2012 R2.
We’ll be using physical disks to support Exchange 2016 and then creating virtual disks atop our Hyper-V environment. In Hyper-V, our new VM looks like this:
Figure 2: Hyper-V Configuration for our Virtual Machine
We’ll then proceed and install Windows Server 2012 R2 on the virtual machine used for Exchange 2016, then configure it with correct network settings, install the latest Windows updates and join it to our domain.
Exchange Server 2016 supports NTFS and ReFS for Exchange databases and log files, and supports NTFS for operating system and Exchange binaries.
ReFS is recommended, with data integrity features switched off; therefore, we’ll format all Exchange database and log disks using this filesystem.
In addition to making sure we’re using the recommended filesystem, we will create mount points to represent the disks and their purpose:
|Database 1 Log||C:\ExchangeDatabases\DB01_Log|
|Database 2 Log||C:\ExchangeDatabases\DB02_Log|
|Database 3 Log||C:\ExchangeDatabases\DB03_Log|
|Database 4 Log||C:\ExchangeDatabases\DB04_Log|
We will then bring storage online, initialize and then format and mount the storage. Launch Disk Management by right-clicking the Start Button:
Figure 3: Opening Disk Management
Within Server Manager, navigate to Disk Management. We will see in the upper panel the system disk, C: and the System Reserved Partition. These also display in the lower page, contained as partitions within the primary disk.
All newly added disks will typically be shown as offline. We’ll need to first change each of these disks to an online state before we prepare them. This is accomplished by right clicking each disk and simply choosing online. Perform this step, as shown below, across all new disks before proceeding:
Figure 4: Using Disk Management to bring a disk online
After bringing the disks online, we will now select one of the disks, right click and choose Initialize Disk:
Figure 5: Initializing disks for Exchange use
This will allow us to initialize all new disks in a single operation. We’ll ensure all disks are selected (in our case all 12 additional disks), then select GPT (GUID Partition Table), which is recommended for Exchange and supports disk sizes over 2TB, should they be required:
Figure 6: Selecting the GPT partition type
In part one of this series we have planned our simple deployment, ensured our Exchange environment and clients are up to date and started the preparation of the virtual machine for Exchange 2016. In the next part of this series, we will complete the virtual machine configuration and install Exchange 2016.
Preparing the server for Exchange 2016
We’ll now create our first volume for the Page File. In our design, this is not to be located on a mount point, so we don’t need to create a folder structure to support it. We can simple right click and choose New Simple Volume:
Figure 1: Creating a new volume for the page file
The New Simple Volume Wizard will launch. We’ll be provided with the opportunity to assign our drive letter, mount in an empty folder (which we will use for the database and log volumes) or not to assign a drive letter or path. We’ll choose a drive letter, in this case, D:
Figure 2: Assigning a drive letter to our page file disk
After choosing the drive letter, we’ll then move on to formatting our first disk.
Figure 3: Formatting our page file disk
After formatting the page file volume, we will format and mount our database and log volumes.
The process to create the ReFS volume with the correct settings requires PowerShell.
An example function is shown below that we will use to create the mount point, create a partition and format the volume with the right setting.
param($Disk, $Label, $BaseDirectory= »C:\ExchangeDatabases »)
New-Item -ItemType Directory -Path « $($BaseDirectory)\$($Label) »
$Partition = Get-Disk -Number $Disk | New-Partition -UseMaximumSize
$Partition | Format-Volume -FileSystem ReFS -NewFileSystemLabel $Label -SetIntegrityStreams:$False
$Partition | Add-PartitionAccessPath -AccessPath « $($BaseDirectory)\$($Label) »
Check and alter the script for your needs. To use the function, paste the script into a PowerShell prompt. The new function will be available as a cmdlet, Format-ExchangeDisk.
Before using the script we need to know which disks to format. In Disk Management examine the list of disks. We’ll see the first one to format as ReFS is Disk 2:
Figure 4: Checking the first disk number to use for Exchange data
Format the disk using the PowerShell function we’ve created above:
Figure 5: Formatting an Exchange data disk using ReFS
After formatting all disks, they should show with correct corresponding labels:
Figure 6: Viewing disks after formatting as ReFS
Configuring Page file sizes
Page file sizes for each Exchange Server must be configured correctly. Each server should have the page file configured to be the amount of RAM, plus 10MB, up to a maximum of 32GB + 10MB.
To configure the Page file size, right click on the Start Menu and choose System:
Figure 7: Accessing system settings
The system information window should open within the control panel. Choose Advanced system settings, as shown below:
Figure 8: Navigating to Advanced system settings
Next, the System Properties window will appear with the Advanced tab selected. Within Performance, choose Settings:
Figure 9: Opening Performance settings
We will then adjust the Virtual Memory settings and perform the following actions:
- Unselect Automatically manage paging file size for all drives
- Set a page file size to match the current virtual machine RAM, plus 10MB, for example:
- 8GB RAM = 8192MB RAM = 8202MB page file
- 16GB RAM = 16384MB RAM = 16394MB page file
You’ll see the result of this for our virtual machine illustrated below:
Figure 10: Configuring the page file size
After making this change you may be asked to reboot.
You don’t need to do so at this stage as we will be installing some pre-requisites to support the Exchange installation.
Configuring Exchange 2016 prerequisites
To install the pre-requisites, launch an elevated PowerShell prompt, and execute the following command:
|Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS|
After installation of the components a reboot is required before we can install the other pre-requisites needed for Exchange 2016 installation.
First we’ll install the .Net Framework 4.5.2.
Figure 11: Installing .Net Framework 4.5.2
Next, install the Microsoft Unified Communications Managed API Core Runtime, version 4.0.
After download, launch the installer. After copying a number of files required, the installer provides information about the components it will install as part of the Core Runtime setup:
Figure 12: Installing the Unified Comms Managed API
No special configuration is needed after install as it’s a supporting component used by Unified Messaging.
Our final pre-requisite is to download and extract the Exchange 2016 installation files themselves.
At the time of writing, the latest version of Exchange 2016 is the RTM version.
Note that because each Cumulative Update and Service Pack for Exchange 2016, you do not need to install the RTM version and update if a CU/SP has been released. Download the latest version available.
After download, run the self-extracting executable and choose an appropriate location to extract files to:
Figure 13: Extracting the files for Exchange 2016
Installing Exchange Server 2016
We will install Exchange Server 2016 via the command line. It’s also possible to perform the setup using the GUI, however the command line options allow us to perform each critical component, such as schema updates, step-by-step.
As recommended by the Exchange 2016 Role Requirements Calculator, we will be placing the Transport Database – the part of Exchange that temporarily stores in-transit messages – on the system drive, therefore it makes a lot of sense to use the default locations for Exchange installation.
The default installation location for Exchange 2016 is within C:\Program Files\Microsoft\Exchange Server\V15.
Preparing Active Directory
Our first part of the Exchange 2016 installation is to perform the Schema update. This step is irreversible; therefore, it is essential that a full backup of Active Directory is performed before we perform this step.
While logged on as a domain user that’s a member of the Enterprise Admins and Schema Admins, launch an elevated command prompt and change directory into the location we’ve extracted the Exchange setup files, C:\Exchange2016.
Execute setup.exe with the following switches to prepare the Active Directory schema:
|setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms|
Figure 14: Preparing the schema for Exchange 2016
Expect the schema update to take between 5 and 15 minutes to execute.
Next prepare Active Directory. This will prepare the Configuration Container of our Active Directory forest, upgrading the AD objects that support the Exchange Organization. We’ll perform this preparation using the following command:
|setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms|
Figure 15: Preparing Active Directory for Exchange 2016
Our final step to prepare Active Directory is to run the domain preparation.
Our smaller organization is comprised of a single domain, and therefore we can run the following command:
|setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms|
Figure 16: Preparing the domain for Exchange 2016
If you have more than one domain within the same Active Directory forest with mail-enabled users, then you will need to prepare each domain. The easiest way to prepare multiple domains is to replace the /PrepareDomain switch with /PrepareAllDomains.
Performing Exchange 2016 Setup
To install Exchange 2016 via setup.exe we will use the /Mode switch to specify that we will be performing an Install.
In addition to the /Mode switch we need to specify the role that we’ll install, the Mailbox role.
|setup.exe /Mode:Install /Roles:Mailbox /IAcceptExchangeServerLicenseTerms|
Figure 17: Installing Exchange 2016 server
After a successful installation, reboot the server.
In part two of this series we have completed the server preparation and then installed Exchange Server 2016. In the next part of this series we will perform post installation checks and configuration.
Post-Installation Configuration Changes
Checking Exchange After Installation
After installation completes we will ensure that the new Exchange Server is available.
Choose Start and launch the Exchange Administrative Center from the menu, or navigate using Internet Explorer to https://servername/ecp/?ClientVersion=15:
Figure 1: Launching the EAC
When launching via a localhost URL and because we haven’t installed the real SSL certificate we will see a certificate warning, as shown below. Click Continue to this website to access the EAC login form:
Figure 2: First login to the EAC
You should see the Exchange Admin Center login form. Login using an organization admin credentials:
Figure 3: Login as an Admin to the EAC
After you successfully login, take a moment to navigate around each section of the EAC to familiarise yourself with the new interface.
Figure 4: Exploring the Exchange 2016 EAC
You’ll notice that the EAC is very different in layout to Exchange Server 2010’s Exchange Management Console. In Exchange 2010 and 2007, the focus was based on the organization, servers and recipients with distinct sections for each. Exchange 2013 and 2016 move to a more task-oriented view. For example, Send and Receive connectors are both managed from the Mail Flow section rather than hidden within respective Organization and Server sections.
However even with those changes, very similar commands are used within the Exchange Management Shell and you will be able to re-purpose any Exchange 2010 PowerShell skills learnt.
Updating the Service Connection Point for Autodiscover
After successfully installing Exchange Server 2016, a change worth making is to update the Service Connection Point (SCP).
The SCP is registered in Active Directory and used, alongside the Exchange 2010 SCP, as a location Domain-Joined clients can utilize to find their mailbox on the Exchange Server.
By default, the SCP will be in the form https://ServerFQDN /Autodiscover/Autodiscover.xml; for example https://EX1601.goodmanindustries.com/Autodiscover/Autodiscover.xml.
The name above however won’t be suitable for two reasons – firstly, no trusted SSL certificate is currently installed on the new Exchange 2016 server, and the SSL certificate we’ll replace it with in the next section won’t have the actual full name of the server.
This can cause certificate errors on domain-joined clients, most commonly with Outlook showing the end user a certificate warning shortly after you install a new Exchange Server.
Therefore, we will update the Service Connection Point to use the same name as the Exchange 2010 uses for its Service Connection Point. This is also the same name we’ll move across to Exchange 2016 later on.
To accomplish this, launch the Exchange Management Shell from the Start Menu on the Exchange 2016 server:
Figure 5: Launch the EMS
To update the Service Connection Point, we’ll use the Set-ClientAccessService cmdlet from the Exchange Server 2016 Management Shell, using the AutodiscoverServiceInternalURI parameter to update the actual SCP within Active Directory:
|Set-ClientAccessService -Identity EX1601 -AutodiscoverServiceInternalURI https://autodiscover.goodmanindustries.com/Autodiscover/Autodiscover.xml|
Figure 6: Updating the SCP
After making this change, any clients attempting to use the Exchange 2016 Service Connection Point before we implement co-existence will be directed to use Exchange 2010.
Exporting the certificate as PFX format from Exchange 2010
Because we will migrate the HTTPS name from Exchange 2010 to Exchange 2016 we can re-use the same SSL certificate by exporting it from the existing Exchange server.
To perform this step, log in to the Exchange 2010 server and launch the Exchange Admin Console. Navigate to Server Configuration in the Exchange Management Console, select the valid SSL certificate with the correct name, then select Export Exchange Certificate from the Actions pane on the right hand side.
Figure 7: Exporting the Exchange 2010 SSL cert
The Export Exchange Certificate wizard should open. Select a location to save the Personal Information Exchange (PFX) file and an appropriate strong password, then choose Export:
Figure 8: Specifying an export directory and password
Make a note of this location, as we’ll use it in the next step.
Importing the Certificate PFX File
Back over on the Exchange 2016 server, open the Exchange Admin Center and navigate to Servers>Certificates. Within the more (…) menu choose Import Exchange Certificate:
Figure 9: Importing the SSL certificate to Exchange 2016
In the Import Exchange Certificate wizard we’ll now need to enter a full UNC path to the location of the exported PFX file, along with the correct password used when exporting the certificate from Exchange 2010:
Figure 10: Specifying the path to the Exchange 2010 server
After entering the location and password, we’ll then choose Add (+) to select our Exchange 2016 server, EX1601, as the server to apply this certificate to. We’ll then choose Finish to import the certificate:
Figure 11: Selecting appropriate servers to import the certificate to
Assigning the SSL certificate to services
Although we now have the SAN SSL certificate installed on the Exchange 2016 server it is not automatically used by services such as IIS, SMTP, POP/IMAP or Unified Messaging. We’ll need to specify which services we want to allow it to be used with.
To perform this step, within Certificates select the certificate and then choose Edit:
Figure 12: Assigning SSL certificates for use
Next, choose the Services tab in the Exchange Certificate window and select the same services chosen for Exchange 2010. In this example, we’re only enabling the SSL certificate for IIS (Internet Information Services):
Figure 13: Selecting services to assign the SSL cert to
After the certificate is assigned, ensure it is applied to IIS by running the following command:
Configuring Exchange URLs using the Exchange Management Shell
The Exchange Management Shell also provides the functionality to change the Exchange URLs for each virtual directory, however unless you know the syntax it can be a little intimidating – and even if you do know the relevant syntax, typing each URL can be a little time consuming too.
We can use a PowerShell script to make this process simpler.
The first two lines of the script are used to specify the name of the Exchange 2016 server, in the $Server variable, and the HTTPS name used across all services in the $HTTPS_FQDN variable.
The subsequent lines use this information to correctly set the Internal and External URLs for each virtual directory:
|$Server = « ServerName »$HTTPS_FQDN = « mail.domain.com »
Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -InternalURL « https://$($HTTPS_FQDN)/owa » -ExternalURL « https://$($HTTPS_FQDN)/owa »
Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -InternalURL « https://$($HTTPS_FQDN)/ecp » -ExternalURL « https://$($HTTPS_FQDN)/ecp »
Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -InternalURL « https://$($HTTPS_FQDN)/oab » -ExternalURL « https://$($HTTPS_FQDN)/oab »
Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory -InternalURL « https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync » -ExternalURL « https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync »
Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory -InternalURL « https://$($HTTPS_FQDN)/EWS/Exchange.asmx » -ExternalURL « https://$($HTTPS_FQDN)/EWS/Exchange.asmx »
Get-MapiVirtualDirectory -Server $Server | Set-MapiVirtualDirectory -InternalURL « https://$($HTTPS_FQDN)/mapi » -ExternalURL https://$($HTTPS_FQDN)/mapi
In the example below, we’ve specified both our server name EX1601 and HTTPS name mail.goodmanindustries.com and then updated each Virtual Directory accordingly:
Figure 14: Updating URL values
Configuring Outlook Anywhere
After updating the Virtual Directories for Exchange, we’ll also update the HTTPS name and authentication method specified for Outlook Anywhere.
As Outlook Anywhere is the protocol Outlook clients will use by default to communicate with Exchange Server 2016, replacing MAPI/RPC within the LAN, it’s important that these settings are correct – even if you are not publishing Outlook Anywhere externally.
During co-existence it’s also important to ensure that the default Authentication Method, Negotiate, is updated to NTLM to ensure client compatibility when Exchange 2016 proxies Outlook Anywhere connections to the Exchange 2010 server.
To update these values, navigate to Servers and then choose Edit against the Exchange 2016 server:
Figure 15: Locating Outlook Anywhere settings
In the Exchange Server properties window choose the Outlook Anywhere tab. Update the External Host Name, Internal Host Name and Authentication Method as shown below:
Figure 16: Updating Outlook Anywhere configuration
Naturally you can also accomplish this with PowerShell, however it’s just as quick to use the Exchange Admin Center for a single server.
With these settings configured, along with iisreset /noforce to ensure configured is re-loaded into IIS we could in theory move client access across from Exchange 2010 to Exchange 2016. Before we do that we will first make some additional configuration changes.
In part three of this series, we’ve performed the first basic configuration required for our Exchange 2016 server post-installation. In part four we will complete the post-installation configuration and begin preparation for migration.
Completing Post Installation Configuration
Configuring Receive Connectors
We’ll need to ensure that the same settings are applied to Receive Connectors on Exchange 2016 as per Exchange 2010. Default and Client connectors are already created and do not typically need to be altered. The defaults for Exchange Server 2016 allow email from the internet or spam filter to be delivered without adding an additional permission.
Many organizations do allow users to relay mail through Exchange from application servers, so we will use this as an example to illustrate how the process is slightly different when compared to Exchange 2010.
To begin, launch the Exchange Admin Center and navigate to Mail Flow>Receive Connectors and after selecting the Exchange 2016 server from the list, then choose Add (+) to create a new Receive Connector:
Figure 1: Creating a new Receive Connector
On the first page of the wizard, enter the name for the receive connector. For consistency we’ve specified the server name after entering Anonymous Relay.
Select Frontend Transport as the role and choose Custom as the type:
Figure 2: Naming the connector and specifying core options
On the next page, we’ll be provided with the opportunity to specify Network Adapter Bindings – the IP address and TCP/IP port that the receive connector will listen on. Our example receive connector will listen on the standard port for SMTP, port 25:
Figure 3: Leaving TCP/IP listener settings as default
On the final page of the wizard, we’ll choose which IP addresses that the receive connector will accept mail for.
This allows multiple receive connectors to listen on the same TCP/IP port and IP address and perform an action depending on the remote IP address of a client.
As an example, if our anonymous connector on Exchange 2010 only allowed mail relay from the IP addresses 192.168.15.1-20, we’ll specify that range here:
Figure 4: Specifying IP addresses that can use this connector
After completing the wizard, we will then open the new Receive Connector’s properties page by selecting it from the list, then choosing Edit, as shown below:
Figure 5: Editing connector settings after creation
In the Exchange Receive Connector window, select the Security tab. Then within the Authentication section select Externally secured to indicate our anonymous relay is from secure IPs; then under Permission Groups, choose Exchange Servers and Anonymous users:
Figure 6: Allowing anonymous relay
Moving Default Mailbox Databases
We will move the initial database created by Exchange Server 2016 setup and make it our first Mailbox Database.
To perform this action, we will perform a two-step process using the Exchange Management Shell.
First, launch the Exchange Management Shell and use the following command to rename the database to DB01:
Get-MailboxDatabase -Server <Server> | Set-MailboxDatabase -Name DB01
Figure 7: Renaming the default database
In the example above you’ll see that by executing the Get-MailboxDatabase cmdlet before making the change we see its default name – “Mailbox Database” with a random suffix. After making the change, the name is changed to something more appropriate.
With the database name changed, it still remains in the same location. Move both the Database file and the associated log files to their respective final destinations using the Move-DatabasePath cmdlet with the -EdbFilePath and -LogFolderPath parameters:
Move-DatabasePath -Identity DB01 -EdbFilePath C:\ExchangeDatabases\DB01\DB01.EDB -LogFolderPath C:\ExchangeDatabases\DB01_Log
Figure 8: Moving the default database path
When moving the database, it will be dismounted. The files will then be moved to the new location and the database and log locations updated in Active Directory. Finally the database will be re-mounted.
Creating Additional Mailbox Databases
Next, create additional Mailbox Databases to match our design specifications. We can create the mailbox databases using either the Exchange Admin Center or the Exchange Management Shell.
In this example we will use the Exchange Management Shell, which for a larger number of databases will be faster and more accurate.
The cmdlets used are New-MailboxDatabase, Restart-Service, Get-MailboxDatabase and Mount-Database.
In the example shown below we will use the first cmdlet to create the databases, restart the Information Store to ensure it allocates the correct amount of RAM, then after retrieving a list of all databases we will ensure they are mounted:
New-MailboxDatabase -Name DB02 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB02\DB02.EDB -LogFolderPath C:\ExchangeDatabases\DB02_Log
New-MailboxDatabase -Name DB03 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB03\DB03.EDB -LogFolderPath C:\ExchangeDatabases\DB03_Log
New-MailboxDatabase -Name DB04 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB04\DB04.EDB -LogFolderPath C:\ExchangeDatabases\DB04_Log
Get-MailboxDatabase -Server <Server>| Mount-Database
Figure 9: Creating additional databases
Configuring Mailbox Database Settings
After we have moved our first Mailbox Database and created our additional mailbox databases, we will now need to configure each database with the correct limits.
The limits chosen for our example environment are shown below, along with retention settings for mailboxes:
Warning Limit – 4.8GB
Prohibit Send Limit – 4.9GB
Prohibit Send/Receive Limit – 5GB
Keep Deleted Items for (days) – 14
Keep Deleted Mailboxes for (days) – 30
It’s possible to configure this using the Exchange Admin Center, but for multiple databases, use Exchange Management Shell to ensure consistency. Using a combination of the Get-MailboxDatabase cmdlet and Set-MailboxDatabase cmdlet make the changes, using the values from the table above:
Get-MailboxDatabase -Server <Server> | Set-MailboxDatabase -IssueWarningQuota 4.8GB -ProhibitSendQuota 4.9GB -ProhibitSendReceiveQuota 5GB -DeletedItemRetention « 14:00:00 » -MailboxRetention « 30:00:00 »
Figure 10: Updating mailbox database settings
Preparing for Exchange 2016 Migration
Testing base functionality
Before we can move namespaces and mailboxes across to Exchange Server 2016 we need to test that the new server is fully functional.
We’ll start by creating a test mailbox to use on Exchange 2016. To do this, navigate to the Exchange Admin Center and within Recipients choose Add, then User Mailbox:
Figure 11: Creating a test mailbox
There is no prescriptive name for a basic test account, so enter suitable unique and identifiable details:
Figure 12: Specifying test mailbox settings
After creating our test mailbox we’ll now need to test that they are functional from a client perspective.
Navigate to OWA via the server’s name. As a minimum test mail flow works correctly between our new Exchange 2016 test user and existing Exchange 2010 users.
Figure 13: Testing OWA and other services
Updating Exchange 2010 Virtual Directory URLs
Exchange 2016 supports acting as a proxy for Exchange 2010 services. This means that it is easy to allow Exchange 2010 and Exchange 2016 to co-exist using the same URLs.
We decided earlier in this guide that we would use the same names for both Exchange 2016 and 2010.
It is now time to move the autodiscover.goodmanindustries.com and mail.goodmanindustries.com names across from Exchange 2010 to Exchange 2016.
This, along with the respective DNS / firewall changes, will result in HTTPS client traffic for Exchange 2010 going via the Exchange 2016 server.
We will update our core URLs for Exchange 2010 to remove the ExternalURL value. We’ll also enable Outlook Anywhere, configuring it with the HTTPS name that will move to Exchange 2016.
To do this we will login to the Exchange 2010 server and launch the Exchange Management Shell. Enter the following PowerShell commands, substituting the $Server and $HTTPS_FQDN variables for appropriate values.
$Server = « EX1401 »
$HTTPS_FQDN = « mail.goodmanindustries.com »
Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -ExternalURL $null
Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -ExternalURL $null
Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -ExternalURL $null
Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory -ExternalURL $null
Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory -ExternalURL $null
Enable-OutlookAnywhere -Server $Server -ClientAuthenticationMethod Basic -SSLOffloading $False -ExternalHostName $HTTPS_FQDN -IISAuthenticationMethods NTLM, Basic
Figure 14: Updating Exchange 2010 URL and Outlook Anywhere configuration
From a client perspective this should not have any immediate effect. The Exchange 2016 server will provide External URL values via Autodiscover, but in the meantime client traffic will still be directed at the Exchange 2010 staging server.
Updating Internal DNS records and switching external HTTPS connectivity
To direct traffic internally at the Exchange 2016 server we need to change internal DNS records so that both the Autodiscover name and HTTPS namespace (in our case, mail.goodmanindustries.com) are configured with the IP address of the new Exchange 2016 server.
On a server with access to DNS Manager, such as an Active Directory domain controller, update both records from the IP address of the Exchange 2010 server to the Exchange 2016 server:
Figure 15: Updating internal DNS entries
Clients will not be immediately redirected to use the Exchange 2016 server as the proxy for client access, and instead will do so once their cached records expire. As soon as clients can access the server retry login and client access to ensure no issues exist.
If internal access works without issue, update the external HTTPS publishing – which in our example organization is a NAT rule configured via the router.
In part four of this series, we’ve completed the post-install configuration and began preparation for the migration. Base functionality has been tested and we have updated records to direct client access to the server. In the next part of this series we’ll begin by updating mail flow.
Introduction – Last Part
During the last part in this series we completed the post installation configuration of Exchange Server 2016 and configured it as per our basic design, then performed some basic tests to ensure it functions correctly. We’re now ready to update the mail routing to the Exchange 2016 server in preparation for the migration. We’ll also integrate with an Office Online Server as an optional step before migration to allow documents to be previewed within Outlook Web App.
Migrating Mail Routing
Updating Inbound Mail Routing
In the previous article, we tested to ensure that our Exchange 2016 server can receive mail and deliver it to Exchange 2010 users. By default, Exchange Server 2016 is already configured to receive email from the Internet using Anonymous permissions on the default receive connector.
If this hasn’t been changed from the defaults, update either firewall rules to direct traffic on SMTP port 25 to the Exchange 2016 server, or update your spam filter appliance to do so.
After this change has been applied ensure that inbound mail flow is not interrupted before moving on to migrating outbound mail flow.
Updating Outbound Mail Routing
With incoming mail now flowing through Exchange 2016, our next step is to make the changes required to allow and then reconfigure Exchange Server 2016 to be responsible for outbound mail flow rather than via the Exchange 2010 server.
In our example environment our mail flow is direct to the Internet, but in your organization you might use a spam filter appliance. Therefore, make sure if you use a smart host for relay, ensure the IP address of the new Exchange 2016 server is added as a server allowed to relay outbound messages.
Likewise, if you email direct to recipients then ensure the Firewall rules allow the Exchange 2016 server IP address to initiate connections to Internet hosts on TCP port 25 without tampering (such as SMTP Fixup).
After ensuring that the Exchange 2016 server is allowed to relay outbound mail, we are ready to update the Send Connector. To perform this step, open the Exchange Admin Center and navigate to Mail Flow and then choose Send Connectors. You should see the Send Connector used for outbound mail flow within the list:
Figure 1: Locating the primary Send Connector for outbound email
Open the properties for the Send Connector used for outbound mail flow.
Navigate to the Scoping tab and locate the Source server section. The Exchange 2010 server should be listed. Choose Add (+) and select the Exchange 2016 server, then select the Exchange 2010 and choose Remove (-); leaving only the Exchange 2016 server within the server list:
Figure 2: Updating send connector settings
After verifying both the server IP address is listed as able to relay, and that the correct Exchange 2016 server has been selected, choose Save to apply the configuration.
As with updating inbound mail routing, ensure you test outbound mail flow is unaffected before continuing.
Installing Office Online Server
Optionally, before migrating mailboxes we can install Office Online Server. At the time of writing, this is still in preview and is expected to reach general availability (GA) around the same time SharePoint Server 2016 is launched.
The Office Online Server is required for viewing and editing attachments within a web browser, so for our small organization we will walk through the installation of a single server farm. For larger organizations, high availability may be required.
Installation of Office Online Server
The current version of Office Online Server, the preview version, can be downloaded from this Microsoft link.
This must be installed on a standalone Windows 2012 R2 virtual machine or server. Before commencing the install we must also install a number of pre-requisites. First install the Visual Studio 2015 runtime from this link.
Next, install the .Net Framework 4.5.2, then install all available Windows Updates.
Finally, before commencing the installation, use the following PowerShell script to install all required pre-requisites, as shown below:
|Install-WindowsFeature Web-Server, Web-Mgmt-Tools, Web-Mgmt-Console, Web-WebServer, Web-Common-Http, Web-Default-Doc, Web-Static-Content, Web-Performance, Web-Stat-Compression, Web-Dyn-Compression, Web-Security, Web-Filtering, Web-Windows-Auth, Web-App-Dev, Web-Net-Ext45, Web-Asp-Net45, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Includes, InkandHandwritingServices|
Figure 3: Installing OOS server pre-requisites
After installation of pre-requisites, perform a re-boot.
Next, mount the ISO image downloaded for installing Office Online Server and then start setup. For our installation, we’ll leave all defaults as-is. In the preview you will note that the version of Office Online Server is 2013. This is expected:
Figure 4: Installing Office Online Server.
Configuration of Office Online Server
After installation completes, Office Online Server will not be available for use. To make it available for use with Exchange Server 2016 we must install a new Office Online Farm.
Before we do that, we’ll need to install a valid SSL certificate and configure a DNS name.
The standard naming for Office Online Server is oos.domain.com. We will choose to use oos.stevieg.org for both the internal and external URLs for our simple farm.
We’ll use the Manage Computer Certificates management snap-in to import the SSL certificate and check the certificate Friendly Name. Search in the Windows 2012 R2 Start Menu, then launch the snap-in:
Figure 5: Locating Computer Certificates
You should see Certificate – Local Computer launch. Navigate to Personal and right-click Certificates. Choose All Tasks>Import… and import your certificate.
Figure 6: Importing an existing SSL certificate
In our example we’ve imported an example Wildcard certificate. We’ll navigate to Certificates and record its Friendly Name from the list.
Figure 7: Checking the Friendly Name of the SSL certificate
You’ll note from the command below that we specifically need to enable editing of documents when creating the farm. This is dependent on whether or not you have appropriate Office licensing. We are choosing to enable it in the example below:
|New-OfficeWebAppsFarm -InternalURL « https://<OOS FQDN> » -ExternalURL « https://<OOS FQDN> » » -CertificateName « <Certificate Name> » -EditingEnabled|
Figure 8: Creating a new Office Online Server Farm
Configuration of Exchange 2016
To ensure that Exchange Server 2016 can utilize our new Office Online Server farm we must configure the discovery endpoint using PowerShell. This can be configured at the Mailbox server level, or the organization level. It is useful to configure at the mailbox level if you need to maintain co-existence with Exchange 2013.
As we are upgrading from Exchange 2010, we can simply configure the endpoint at the organizational level with the Set-OrganizationConfig cmdlet and then restart the OWA app pool on our single server, as shown below:
|Set-OrganizationConfig -WacDiscoveryEndpoint https://<OOS FQDN>/hosting/discoveryRestart-WebAppPool MsExchangeOwaAppPool|
Figure 9: Configuring Exchange 2016 to use the Office Online Server
Testing Office Online Server with Exchange 2016
Finally, we’ll need to make sure that document viewing and editing works as expected. If all is configured correctly, then viewing an email with an attachment should present the View option against an attachment:
Figure 10: Checking integration of OOS
If you don’t see the option it may simply be that after making the Organization configuration change, Active Directory had not replicated before re-starting the OWA app pool and attempting access.
When you see the view option, simply select it to switch to view mode. If you’ve also enabled Editing in the Office Online Farm, you’ll see the Edit and reply option as well.
Figure 11: Viewing attachments using OOS
By selecting Edit and reply, you will be able to compose a reply and edit the document before sending. If the configuration is correct then you should see the full Office Online in editing mode displayed:
Figure 12: Editing attachments using OOS
In this penultimate part in the series we’ve migrated mail routing across from Exchange 2010 to Exchange 2016, and we’ve installed Office Online Server (if required) to allow viewing and editing of attachments in Outlook Web App. In the final part of this series we will migrate mailboxes, then decommission Exchange Server 2010.
Migrating the Pilot Group
Before migrating mailboxes en-mass to Exchange 2016, it’s important to validate that you’ve had an opportunity to identify any issues that using and moving test mailboxes didn’t expose.
First we will select a pilot group of users to migrate to Exchange Server 2016. They should provide feedback on any issues they encounter, and will represent a cross-section of end-users; for example users that are heavy mobile users, those that are primarily external users and those that regularly use features like shared calendars and delegation.
Many smaller organizations will find most pilot candidates within the IT department, but if you have users who are keen to be early adopters outside of IT, then you’ll get a better representation of real issues.
When migrating mailboxes from Exchange 2010 to Exchange 2016, we’ve got a number of methods that can be used to migrate mailboxes in large numbers.
The first method applies if you have created equivalent databases to match your source Exchange 2010 environment. For each database, you can queue up mailboxes to be moved using the following command:
Get-Mailbox -Database <Database> | New-MoveRequest -TargetDatabase<Database_E2016> -BatchName <Database>
Figure 1: Creating new move requests
If you are using traditional backups on your Exchange 2016 server then take into account the impact of log file usage when determining the batch sizes.
When a mailbox is moved, log files consuming the same amount of space as the mailbox itself are generated. This means that you can only move as many mailboxes as log space allows in between regular backup jobs.
You can mitigate against this by either performing additional incremental backups during mailbox migrations; or temporarily turning on circular logging.
We can keep track of the migrations using the Exchange Management Shell by calling the Get-MoveRequest cmdlet, again specifying the BatchName; then piping the output to Get-MoveRequestStatistics to gain a detailed insight into our current batch of migrations:
Get-MoveRequest -BatchName "<Database>" | Get-MoveRequestStatistics
Figure 2: Monitoring move requests from PowerShell
If you’d prefer to use the Exchange Admin Center rather than PowerShell to co-ordinate the migration, then consider using the migration batches, as shown during our test mailbox moves.
Figure 3: Using the EAC interface to the New Migration Batch cmdlets
Use the New Migration Batch wizard to select mailboxes from the Global Address List, as shown below:
Figure 4: Adding mailboxes to the new migration batch
After creating and starting a migration batch via the Exchange Admin Center, we can examine the progress of those moves by selecting the migration batch from the list, and then choosing View Details:
Figure 5: Viewing the list of Migration Batches
We’ll then be presented with a list of all mailboxes within the batch, each of which can be selected and the full status available for detailed examination:
Figure 6: Monitoring progress of a Migration Batch
Either of these two methods is equally effective, and whichever you use is down to which ever method makes most sense within your organization.
After performing migrations of end users you can verify that no additional mailboxes remain on Exchange 2010, using the following command at the Exchange 2016 Management Shell:
Get-Mailbox -Server <Server>
If any mailboxes do remain, then pipe the results of the command to the New-MoveRequest cmdlet as a new migration batch, for example:
Get-Mailbox -Server <Server> | New-MoveRequest -BatchName "Remaining Mailboxes"
We’ll also need to move the system mailboxes from Exchange 2010. We’ll find these by using the Get-Mailbox cmdlet with the –Arbitration parameter:
Get-Mailbox -Server <Server> -Arbitration
You’ll expect to see a couple. Move them to Exchange 2016 using the New-MoveRequest cmdlet again:
Get-Mailbox -Server <Server> -Arbitration | New-MoveRequest
After all mailbox moves from the Exchange 2010 server are complete, remove the mailbox move requests from Exchange 2016.
To remove successfully completed move requests, use the Remove-MoveRequest cmdlet in combination with the output of Get-MoveRequest:
Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest
Figure 7: Removing completed move requests
If you opted to use the Migration Batch method then you can remove it via the Exchange Admin Center by viewing the batch, and then if it is complete, hitting the Delete button:
Figure 8: Removing a completed batch
Decommissioning Exchange 2010
Getting ready to decommission Exchange 2010
By this point, we should be safe to remove Exchange 2010 from the environment. Earlier in the series we moved inbound and outbound mail flow to Exchange 2016, moved client access across; and we have just completed migrating all Mailboxes over to Exchange 2016.
Before removing the staging server, it’s important to verify that these servers are definitely no longer used. For example, if you have devices that use the Exchange 2010 server for SMTP relay, double check that all these devices have been updated to use the Exchange 2016 server.
Also double check you’ve implemented and migrated mail flow. We’ll need to verify that both Inbound and Outbound mail (via Receive and Send Connectors respectively) is configured to flow via Exchange 2016 only.
After checking that mail flow should no longer be configured to flow through the Exchange 2010 infrastructure, we should be ready to remove Exchange 2010 completely. To ensure that this is definitely the case, shut down the Exchange 2010 server and leave switched off for a reasonable period of time (for example, a week) to ensure that should anything have been missed the Exchange 2010 server can be started up and anything that wasn’t originally identified migrated.
Removing unused Offline Address Books
We’ll start off with a relatively simple task, removing the old default Offline Address Book.
As part of the installation of Exchange 2016, a new Offline Address Book was created and set as the default. This will have the suffix (Ex2013) signifying it is created by Exchange 2013 or above.
We’ll remove the old Exchange 2010 one by opening the Exchange Management Console and navigating to Organization Configuration>Mailbox and then within the Offline Address Book tab selecting the original address book, with the Generation Server specified as the old Exchange 2010 server. Simply choose Remove:
Figure 9: Removing obsolete Offline Address Books
In our example organization we do not use Public Folders, therefore we only have one type of Database we need to remove from our Exchange 2010 – Mailbox Databases.
Before we press ahead and remove the databases, we’ll need to double check that all mailboxes have been moved to Exchange 2016.
To verify all mailboxes have been removed from our Exchange 2010 server, we’ll use the following commands:
Get-Mailbox -Server <ServerName>
Get-Mailbox -Server <ServerName> -Arbitration
Get-Mailbox -Server <ServerName> -Archive
After verifying that no mailboxes exist on the server, we’re ready to remove the databases. As part of this process Exchange 2010 will double check that no mailboxes exist. It will not allow the removal of databases that contain mailboxes.
We’ll use the following PowerShell command from our Exchange 2010 server to first get a list of the databases:
Get-MailboxDatabase –Server <ServerName>
After confirming that the command is showing the correct databases, remove the Mailbox Databases using the following command;
Get-MailboxDatabase –Server <ServerName> | Remove-MailboxDatabase
Uninstalling Exchange 2010
With Mailbox Database configuration removed we can now uninstall Exchange Server 2010.
To do this, navigate to Programs and Features, within the Control Panel and choose Uninstall after selecting Microsoft Exchange Server 2010 from the list of installed applications:
Figure 10: Uninstalling Exchange 2010
The Exchange Setup application is used for the uninstallation process, much like it was used for the original installation. When prompted, we’ll therefore unselect each Exchange Role installed, for example Client Access, Hub Transport and Mailbox.
Additionally, we’ll choose to uninstall the Management Tools – which includes the Exchange Management Console and Exchange Management Shell:
Figure 11: Uninstalling all components of Exchange 2010
After choosing Next, Exchange Server Setup will perform checks to ensure that we’re actually ready to uninstall. After moving Send Connectors earlier in this series and performing the tasks in this article, we’ll expect each readiness test to complete successfully, allowing us to choose Uninstall:
Figure 12: Verification of successful uninstallation
After choosing Uninstall we’ll expect the setup program to continue with removal of Exchange 2010. After it completes successfully the server can be decommissioned, and the server removed from the domain.
In this six-part series we’ve walked through a straightforward migration to Exchange 2016 from Exchange 2010. If you had experienced migrations between previous versions you will have seen that in comparison, the Exchange 2016 migration process is relatively straightforward.
– I have taken the liberty to copy it from its source website.
- Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 1)
- Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 2)
- Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 3)
- Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 4)
- Migrating a small organization from Exchange 2010 to Exchange 2016 (Part 5)