The basic steps to creating a DAG of course means having Exchange servers setup prior with their respective databases.
Exchange 2013
Exchange 2013 – Moving and Renaming a Mailbox Database
1 |
"C:Program FilesMicrosoftExchange ServerV15MailboxMailbox Database *insert random number here*" |
1 |
Get-MailboxDatabase |
1 |
Get-MailboxDatabase | Dismount-Database |
1 |
Move-DatabasePath "DB01" -EdbFilePath "D:DatabasesDB01DB01.edb" -LogFolderPath "D:LogsLog01" |
1 |
Get-MailboxDatabase -Status | select name,mounted |
1 2 3 |
Get-MailboxDatabase | Mount-Database Get-MailboxDatabase -status | select name,mounted |
1 |
Test-MAPIConnectivity |
Exchange 2013 – Exporting Certificate Private Keys
1 |
openssl pkcs12 -in myfile.pfx -nocerts -out private_key.pem -nodes |
Exchange 2013 – Blocked Port 25? No problem.
The setup could be summarized as follows:
Buy a Domain
- Set A record for domain name and point to router (My Public IP)
- Set A record for subdomain name and point to router (My Public IP)
- Set MX record for mail server. (This will be the FQDN of the mail server that will be forwarding your mails from the internet to your home server. In my case it was “smpt.dnsexit.com”)
Setup Port Forwarding
- Select Mail Flow
- Select the receive connectors tab
- Select the Default Frontend
- Select Scoping
- Save your changes
- Select the Send Connectors tab
- Create or edit an existing send connector
- Select the basic authentication option and enter in the credentials that your provider gives you.
- Set the address space to “*” and add your exchange servers.
- Save your new send connector.
- Open the Exchange Management Shell
- You will need to use the Set-SendConnector cmdlet to specify the port of your new send connector.
1 |
Set-SendConnector -Identify "SENDCONNECTORNAME" -port 26 |
Exchange 2013 – Importing Certificates
In Exchange 2013 installing certificates is fairly straightforward. With a CAS/Mailbox duo setup on three of these configured, I encountered one problem with the certificates that I thought was worth noting.
I wanted to add a certificate to my lab. So I went to one of the free sites (in my case, StartSSL) and got myself a certificate for my lab domain, after submitting my certificate request from my first Exchange server.
Once I had finally received my certificate, I used the Exchange EAC web GUI to import my certificate onto all of my Exchange servers. Exchange seemed happy, notifying me that the import was successful to all servers.
At this point, something isn’t right. I ran into a weird problem. I went to check the certificate I just imported on all of my servers through the GUI and I found that the certificate was only visible on my first Exchange server. This was weird to me because I had not received any errors when the first Exchange server was importing. Naturally I checked the logs, and found no error on any of my servers.
Logically the next step that came to mind was to try to re-import the certificate on the servers that it was not showing on.
What’s interesting is that when I tried to import the certificate directly onto either of the servers, it still wasn’t showing up. I was prompted by Exchange that the certificate had already been installed with its respective thumbprint. This continued after exporting and removing the certificate from each of the servers and starting back from square one.
After getting frustrated, I decided to do a little more digging, I loaded up MMC with the Certificate snap-in to take a closer look at the certificate I had just imported to my Exchange server. I was able to successfully see the certificate I had just imported, but on closer inspection I saw that it didn’t have the private key installed, which in turn makes the certificate useless.
With this new found information, I removed the certificate from all stores on all of my labs Exchange servers. During the removal however from my first Exchange server, I exported a copy of it which included the private key and all extended properties. I then decided to try to import the certificate using the Exchange shell so I could see more of what might be happening on the back-end.
What I found worked, could be summarized as follows:
If you have already installed a certificate like me, make sure you have already removed the certificate from each server you imported it to.
Import the certificate using the Import-ExchangeCertificate powershell command:
1 2 3 4 5 6 7 |
Import-ExchangeCertificate ` -Server <Server Name> ` -Filedata([Byte[]]$(Get-Content ` -path \EX01Sharemycert.pfx ` -Encoding byte ` -ReadCount 0)) ` -Password:(Get-Credential).password |
This command will import the certificate from a file called mycert.pfx from a file share called share. (Use the UNC path here) The password parameter prompts for a password here, as it is required for a file storing both a certificate and its private key.
Then you would use the command Get-ExchangeCertificate to receive a list of the installed certificate. I used the -server <Server Name> parameter to view each individual server and verify the certificate installed.
Next you would use the Enable-ExchangeCertificate cmdlet to assign the certificate it’s roles with exchange.
This command will enable the certificate with the thumbprint you specify to secure communication over IMAP, POP3, IIS, and SMTP etc.
At this point, you should be practically ready to go with your Exchange certificate. After refreshing the view in the Exchange admin console, you should see the certificate you’ve installed listed on all servers you imported it on.
I will not however that when importing the certificate through PowerShell it does not allow you to give it a friendly name, so you will have to give it one through EAC if you want to easily identify it this way.