Autodiscover can be a lengthy process, especially if you are in a hosted environment or if your mailbox is in Office 365.
The autodiscover process consists of five different steps, it depends on your environment where autodiscover stops and returns the information. Autodiscover is using the following mechanisms:
- Service Connection Point (SCP) in Active Directory. This is used by domain clients.
- Root domain discovery, used by non domain joined clients or clients not being able to access Active Directory. All other steps are used by these clients as well.
- Autodiscover.contoso.com (standard autodiscover mechanism)
- Autodiscover redirect to autodiscover site (often used by hosting companies)
- Autodiscover SRV records in DNS (sometimes used by hosting companies)
- Autodiscover redirect to Office 365 (outlook.com)
If your mailbox is in Office 365, outlook will go through all these steps until it finds the information in Office 365. All steps will fail with the accompanying time-out and this will take quite some time. This can be seen in the Outlook Test Email AutoConfiguration option:
Continue reading Improve autodiscover performance
In a previous blogpost, I already discussed DKIM signing with Exchange 2016: SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II
Exchange out-of-the-box does support SPF checking, but DKIM signing/verifying and DMARC verifying are not supported. There are free 3rd party tools for DKIM Signing that can be found on GitHub, but at the moment of writing this tool only supports DKIM Signing, but does not support DKIM verifying. I have to admit that DKIM signing with this tool works very well.
I already explained earlier that I’ve installed and configured a Cisco Email Security Appliance (ESA, previously known as IronPort) appliance in my lab environment, and this is installed like this:
Figure 1. My testlab Exchange environment.
All outbound SMTP mail is via the ESA. The FQDN of the ESA is smtphost.exchangelabs.nl, of course it has a public IP address with a corresponding PTR record.
Continue reading Cisco Email Security Appliance and DKIM Signing
Last week I got a request from a customer. A long time ago I posted a blogpost on Exchange 2010 recovery databases, but after the customer migrated to Exchange 2016 his procedure around recovery databases didn’t work anymore. His request was basically to rewrite my blogpost.
For this blogpost I have a pretty simple Exchange 2016 Mailbox server, configured with one Mailbox database which is stored on a dedicated disk, and I’m using Windows Server Backup to backup the entire Mailbox database disk (VSS full backup).
Don’t pay too much attention to the naming of my Exchange server and the Mailbox database I’m using here. In fact, this is an Exchange 2016 hybrid server I’m misusing for the purpose of this blog
You can restore a mailbox database to its original location and mount again, but you can also use a Recovery Database to restore and recover your data. A recovery database is a mailbox database that can be mounted on your Exchange server, but it is not visible for regular users but only for the Exchange administrator. The Exchange administrator can access this recovery database and recover data, for example create a PST of a particular mailbox in this database.
When restoring a database from backup, select the restore option and follow the wizard. When you reach the Select Recovery Type window select Applications as shown in the following screenshot.
Continue reading Exchange 2016, backup and recovery databases
Recently I had to replace my two lab servers, so I bought two brand new HP DL360-Gen9 servers. Lots of memory and a number of disks and processor capacity. Two weeks after installing Windows 2016 Hyper-V I noticed that my system disk (C:\ drive, approx. 185 GB) was filling up rapidly.
Initially I thougt it was the paging file (with 192 GB internal memory this can be an issue) but this was not the case since the paging file was located on drive D:\
Further investigation revealed that most data was located in the directory C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines, where all VM related files are located (except the virtual hard disks which were located in D:\Hyper-V\Virtual Hard Disks). It turned out to be very dynamic data located in .VMRS file. When a VM was turned off the VMRS file was gone, as soon as the VM was turned on again dir VMRS file was allocated again, and the size of the file was identical to the amount of memory of the Virtual Machine as can be seen in the following screenshot:
Next I’ve been looking at the smart paging option in Hyper-V, but this only makes sense when using dynamic memory, which was not the case in my environment (VMs were running Exchange 2013/2016).
Production snapshots are new in Windows 2016 Hyper-V. Production snapshots use VSS to create a snapshot (where the traditional snapshots create a system state using .VSV and .BIN files) so that would make sense in my scenario. But disabling snapshots at all on a VM basis didn’t make any difference, and the .VMRS files were still created.
The last option I had was the Automatic Stop Action option in Hyper-V (on a per VM basis). Using this option you can control what happens when the host shuts down. By default it is set to Save the virtual machine state, so when the Hyper-V host shuts down the entire VM is saved at that particular moment. To achieve this, space on disk is reserved equal to the amount of memory used by VM. Other options here are Turn off the virtual machine and Shut down the guest operating system.
Bingo, this was my issue. Save state will certainly have performance benefits, but I prefer to use the shut down option in my lab environment. After changing this on (most of) my VMs I have plenty of free space on my system disk