We are now in the final stretch in this series with this being the second to last part of creating a test lab from scratch with Windows Servers 2012 and Exchange 2013. I could in truth perhaps go on forever as there are loads of things that I have not covered. But that is the beauty of a test lab, once you have one that is up and running – it is yours to do with as you choose and that is what I hope that you will all do.
For those of you who are joining us at this stage you can find the previous 7 parts below.
Part 1
We established our domain design, covered how to provision the Domain Controller for the LAB in Hyper-V and then how to install Windows Server 2012 on the Domain Controller.
Part 2
We went through the process of installing Active Directory Domain Services on the LAB domain controller using PowerShell.
Part 3
We covered how you can install a very simple PKI infrastructure on the domain controller using Active Directory Certificate Services. These will be used in a later part to configure SSL for various parts of Exchange 2013.
Part 4
We covered how to use PowerShell to provision Exchange server VM’s in the lab, and went through the pre-requisite software installation.
Part 5
We covered the Directory, organization and Exchange preparation – and then went on to install the relevant Exchange servers using the unattended setup feature.
Part 6
We covered Database Availability Groups and provided a script which automates the creation of DAGs from a CSV.
Part 7
We covered adding databases to the DAG and configuring SSL.
In this part I will be covering:
The creation of user accounts in Active Directory.
The creation of Mailboxes.
The creation of Distribution Lists.
The creation of “Modern” Public Folders.
In addition to the above I will also cover some further reading that you might want to do on your own in regard to making your OWA CAS configuration highly available.
In order to create around 500 or so users ready to be placed within the relevant databases run the Create Users script (which you can get from the link above) – when prompted – select the relevant users CSV file from the browse dialog box – see below.
When the script has completed – you will be presented with a message explaining that the execution has completed. You will then be able to find all of your users within an OU called “Exchange Users” in Active Directory Users and Computers – see below.
The EBUCT (Exchange Bulk Users Creation Tool) – is available from the download link above. Download it to one of the servers in your LAB and fire it up. Click on the “refresh” button to populate the AD accounts section, and then choose each of the accounts that you want to put in each Mailbox Databases; when ready click on “Enable” – then repeat the process as required – see below.
If you then drop into the Exchange Administrative Centre you should now see all of your mailboxes.
Very similar to the LAB Users Creation Tool – the Distribution Lists script operates in the same way – run the script, and select the relevant CSV file – see below.
The script will create a sub-OU under the ExchangeUsers OU called “DistLists” – in here you will find the Distribution Lists that the script created.
When the script has completed – you will be presented with the “Completed” message – see below.
Exchange 2013 introduces what is perhaps the first “major” architectural changes to Public Folder databases in … well … forever! I would say that the biggest leap is now the concept of Public Folder replication is now dead in the water (thankfully). “Modern” Public Folders now share the same high availability and storage technologies as the mailbox store. In fact – the Public Folder hierarchy is in fact a special mailbox contained within a mailbox store which can be part of a DAG.
There are of course other changes (administration and the like) and you need to be aware that you cannot in the RTM of Exchange 2013 access public folders from Outlook Web App.
Creating Exchange 2013 Public folders are not very hard to create in Exchange 2013 via either the Exchange Management Shell of Administrative Centre. However, as I mentioned in previous articles my aim in this series has been to provide you with examples where appropriate of using the shell.
The script performs the following actions within the LAB environment:
Get the full list of available Mailbox Databases and presents the as options as the destination location for the Public Folder Mailbox Hierarchy.
Creates Public Folders for Dublin, Paris and London within the hierarchy.
<# Exchange 2013 LAB - Create "Modern" Public Folders http://www.telnetport25.com Author: Andy Grogan Version: 0.1 .Compatibility Windows Server 2012 Powershell 3 Exchange 2013 Not Supported with any other versions of the software mentioned above. .Parameters None .Example .\CreatePublicFoldersLab.ps1 #> $MailboxDatabases = Get-MailboxDatabase | Select -expandProperty Identity $Count = -1 Write-Host "Create Public Folders" -ForeGroundColor Cyan Write-Host "" foreach($DB in $MailboxDatabases){ $Count ++ Write-Host "$Count . " $DB } Write-Host "" $DBChoice = Read-Host "Please select a mailbox database where you would like to locate the public folders" New-Mailbox -publicFolder –Name "artTest_PFHierarchy" –Alias "artTest_PFHierarchy" –Database $MailboxDatabases[$DBChoice] New-PublicFolder -Name "London_Office" New-PublicFolder -Name "Paris_Office" New-PublicFolder -Name "Dublin_Office" Write-Host "" Write-Host "Script has completed..." -ForeGroundColor Green
Either download the script to a location on one of the LAB Exchange servers or copy and paste it from the code block above. Open an Exchange Management Shell and type in:
.\CreatePublicFoldersLab.ps1
From the Mailbox options list – select a destination by typing in the corresponding numeral:
The script will then create the hierarchy and the relevant public folders:
So there have been a number of changes in Exchange 2013 – not least of which are how clients connect to the respective Exchange infrastructure.
Before we get into that – let's have a look at the changes in the roles architecture. From Exchange 2007 and in Exchange 2010 we had the following discrete roles:
Mailbox Server
Hub Transport
Client Access
Edge Transport
Unified Messaging
In Exchange 2013 – these roles have been consolidated down into:
Mailbox Server
Client Access Server
You might be thinking that this is very reminiscent of the good old Exchange 2003 days of Front End Servers (FES) and Mailbox Servers, which you would be sort of right – but it would be true to say that the concept has advanced significantly.
In Exchange 2013 the Mailbox server performs the following functions:
Mail routing
Voice Mail
Renders Web Service based content
The Client Access Server Role performs the function of authenticating and routing client requests to the correct Mailbox Server. One key concept that has changed with the Client Access Server is that it no longer performs the rendering of OWA – it is in essence a reverse proxy. It will authenticate a user, direct them to the correct mailbox server and then hand offs everything else from that point onwards.
One other major change is that clients now connect purely over HTTPS (MAPI via RPC is gone).
With these changes – the concept of Load Balancing Exchange has also changed. Affinity now works as intended – it now does not matter if a client request hits another client access server it is still rendered by the mailbox which hosts the mailbox – therefore there is not performance degradation. With form based authentication the authentication cookie is provided to the client post logon which is encrypted using the SSL certificate of the given CAS server.
The logged on user can then maintain authentication on another CAS without having to be re-authenticated if there is a shared certificate between the Client Access Server.
All of the above means that you have a lot of flexibility in terms of the “Load Balancing” technologies that you can realistically make use of.
Broadly speaking – these fall into the following options:
Round Robin DNS – we will be covering this in this post, I would recommend this in Test Labs where budget is tight – but not in Production as it is technically not true load balancing, and is a little “flaky” to say the least.
Windows Network Load Balancing (WNLB) – Can be used in production (but again I would not recommend it) – remember that you cannot have WNLB and Failover clustering on the same server – therefore; NLB is not possible in our LAB without major modification.
Third Party Load Balancing product – KEMP, LOADBALANCER.org etc. - These are highly recommended for production scenarios.
Logon to your Windows 2012 Domain Controller and open the DNS management MMC. Right click on the name of your LAB domain controller and from the context menu that appears choose “Properties”.
From the dialog that appears, click on the “Advanced” tab – ensure that the “Enable round robin” check box is check from within the Server Options section – see below.
Now you need to add in additional DNS [A] records for the relevant web services that we created in part 7 – to recap these were:
OWA
Autodiscover
You can either do this from the DNS Manager MMC – or, like we did in part 7 use Powershell via the following cmdlet.
Add-DnsServerResourceRecordA
If we look at the topology of our LAB so far we have the following Client Access Servers:
art-MBXCAS-01 = 172.31.253.108
art-MBXCAS-02 = 172.31.253.109
So that means that we need two DNS records for the above DNS entries – so you are looking to have the following records on your DNS server:
This will give you a very basic level of fault tolerance using Round Robin DNS – but if you are looking for something more sophisticated then you should have a look at a commercial Load Balancing option; especially if you are planning on moving what you have learned in this series in to production at any point.
So to finish up in this series – it is probably worth looking conceptually at what we have created diagrammatically – here we can see the whole configuration – right from the Virtualization host – all the way through to the virtual machines, database availability groups and CAS Load Balancing from the client end.
You might be thinking where to next? Well – that is up to you– I have not covered absolutely everything possible with your LAB – and indeed there is lots that can be changed / improved – but the point is that I am hoping that you are in position to begin to “tweak” the configuration. I will be continuing in future posts to add to this LAB (you may see its name crop up) – but I urge you all to play around as much as you can.
I also hope that you have found this series useful and I am more than happy in receiving any thoughts that might wish to share.