In part 10 of this mini-series, I’ll look at how to configure the virtual directories used by Exchange 2013. We’ll need to configure these to match the FQDNs we request on our SSL certificate.
It’s assumed that split-brain DNS will be setup for the configuration to work. The essenace of split-brain DNS is that your external domain name is also configured on your internal DNS servers, but the A records on the internal DNS server point to the internal IP address of the server whereas the domain name configured on your external DNS servers point to the external IP address of your server. So whether a client is internal or external the FQDN will always resolve to the correct IP address.
In part 9 of this mini-series, I’ll look at how to configure the Fully Qualified Domain Name (FQDN) of the Default Frontend receive connector in Exchange 2013.
Firstly a warning: Don’t modify the FQDN value on the default Receive connector Default that’s automatically created on Mailbox servers. If you have multiple Mailbox servers in your Exchange organization and you change the FQDN value on the Default Receive connector, internal mail flow between Mailbox servers fails.
In a single Mailbox server environment to change the Default Frontend receive connector FQDN follow the steps below.
In this post I’ll look at how to configure a postmaster address for our Exchange Organisation.
The postmaster address is used for non-delivery reports (NDRs) sent to recipients outside of your Exchange Organisation and is specified in RFC 2821.
In Exchange 2013 the external postmaster address is blank by default. This has the effect of the external postmaster address being postmaster@YourDefaultAcceptedDomain.
It can be useful to create a postmaster mailbox, or assign the email address to an admin mailbox so that recipients can reply to NDR messages for assistance. Anyone who is familiar with NDRs will appreciate they are far more useful to admins than they are to end users! The downside of this though is as it’s a well known address it can be open to abuse and spam.
This will be a quick post and one of the easiest steps in setting up your Exchange environment. In this seventh part of the series I’ll look at where to enter the product key for Exchange 2013.
Unless you deploy lots of Exchange 2013 servers, licensing an Exchange 2013 server may be something you only do once so here’s a quick guide on applying the license key in the Exchange admin center and via the Exchange Management Shell.
Once the license is applied you’ll need to restart the Information Store.
Following on from previous posts on How to install Exchange 2013 SP1 and Exchange 2013 Initial Configuration Settings, in this first part of a series of posts I’ll look at setting the SMTP accepted domain.
By default when you install Exchange 2013 the default accepted domain will be the fully qualified domain name of the Active Directory domain you installed the server into.
In my demo environment the AD domain is ad.oxfordsbsguy.com, so the default accepted domain is ad.oxfordsbsguy.com. Obviously we want to remove the ad part of the address to hide the internal ad structure and make the actual email address more useable, so let’s look at adding another accepted domain.
Following on from the previous post Exchange 2013 Initial Configuration Settings: Setting SMTP accepted domains (Part 1) , in this second part of a series I’ll look at setting up an email address policy.
Until you create a new email address policy any recipients (users, resources, contacts, groups) you create will get their email address from the default email address policy. Therefore we’ll create a new email address policy with settings that we want before creating new recipients.
Another reason for having it in place before you create recipients is in large environments applying an email address policy can take a long time depending on the number of recipients it effects.
Following on from the previous post Exchange 2013 Initial Configuration Settings: Setting default email address policies (Part 2), in the third part of the series I’ll look at renaming the mailbox database.
To help with Exchange Server management it is important to keep things as simple and logical as possible, and a properly named mailbox database can greatly aid in the administration of the server. Give it a unique descriptive name to your company for example e.g. OxSBSEngineeringMailbox01 or OXSBS-MBX-Execs-01, and once you have created a naming convetion stick to it.
In this example because I mostly work with SMEs who have one mailbox database so I’m going to call our database OxfordSBSGuy-Users-MBX01 for to me this means OxfordSBSGuy Users Mailbox Database 01.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.