Site icon Franky's Web

Exchange Server: Create a backup of the configuration

Exchange Servers store a large part of the configuration in the Active Directory, which is why a backup of the Exchange Server does not include the configuration of the Exchange Server, but usually only the data (such as the mailboxes). Important settings such as permissions on mailboxes or settings for the virtual directories are stored in the Active Directory. Especially if there are several or many Exchange administrators, it can be useful to have a backup of the configuration of the respective Exchange servers.

It is relatively easy to create a backup; I have already prepared a small script for this. Unfortunately, I have not yet found a practical way to restore such a backup of the configuration.

However, you can use a second script to compare the backup with the current configuration and thus restore individual settings to the status of the backup (manually with the corresponding CMDLets). This can be particularly useful for configuration changes that subsequently turn out to be incorrect.

Here is a little background information on how PowerShell can be used to create backups of settings. Such backups can of course not only be made for Exchange configurations, but for almost everything that can be managed somehow via PowerShell. Using the PowerShell CMDLet "export-Clixml", the output (or the objects) of a command can be saved in an XML file.

Here is an example to save the configuration of the "Accepted Domains" of an Exchange Server in an XML file. The CMDLet "Get-AcceptedDomain" returns the settings of the accepted domains of an Exchange Server, the CMDlet "Excport-Clixml" now saves the object with all values in an XML file:

1
Get-AcceptedDomain | Export-Clixml c:\temp\accepteddomains.xml

The file "accepteddomains.xml" now contains the objects which were delivered by "Get-AcceptedDomain" (here once the "shortened XML):

To display the saved XML again, the following command can be used:

1
Import-Clixml C:\temp\accepteddomains.xml

Here you can now see all accepted domains and their settings. Incidentally, the XML contains all settings, the output above is only displayed in simple form. If you want to display all settings, you can use the following command, for example:

1
Import-Clixml C:\temp\accepteddomains.xml | select *

The import can also be saved in a variable and then processed further, for example like this:

1
$domains = Import-Clixml C:\temp\accepteddomains.xml

The variable $domains now contains all data from the file "accepteddomains.xml". You can now access this data and use it as you wish:

The CMDlet "Export-Clixml" is therefore quite suitable for saving settings from the PowerShell. Unfortunately, "Import-Clixml" is not suitable for importing the saved data back into an Exchange configuration.

The background in this case is as follows:

The settings were saved using the CMDLets "get-accepteddomain" and "export-clixml". In order to import the saved data again and adapt the Exchange configuration based on the imported data, the CMDLets "import-clixml" and, depending on the situation, certain Exchange CMDlets would be required.

For example: As can be seen in the screenshots, there is a domain "dummy.de" in the XML file. If the domain "dummy.de" was deleted in the current Exchange configuration, it would have to be created using the CMDlet "new-accepteddomain". If the domain "dummy.de" has only been changed but still exists, the domain would have to be edited using the CMDlet "set-accepteddomain".

The problem here is that "get-accepteddomain", which was used to save the settings, returns all settings, but "set-accepteddomain" or "new-accepteddomain" can only be called with very specific settings. The CMDLets "new-accpteddomain" and "set-accepteddomain" cannot do anything with the many settings provided by "get-accepteddomain".

To stay with this example, I have deleted the domain "dummy.de" from the Exchange configuration, the variable $domains still contains the data from the "backup" or the XML file:

The attempt to recreate the domain "dummy.de" from the "Backup ($domains)" is therefore a failure:

As already mentioned at the beginning, I have not found a feasible way to restore a configuration saved using "Export-Clixml". So you have to do this manually.

However, it is usually not even necessary to be able to automatically restore the configuration from the backup. As already mentioned, this is not about the data, but about the configuration. So if a configuration change has led to undesirable behavior, it is usually sufficient to compare the current configuration with the status from the backup and then undo or adjust certain changes accordingly. For example, if a domain (such as dummy.de) has been deleted and another domain "valid.de" has been added to the configuration at the same time, you don't want to delete "valid.de" just so that "dummy.de" can receive emails again. A technical check would therefore have to be carried out to determine which configuration change has resulted in "dummy.de" users no longer receiving emails.

The following two scripts are intended for precisely this case. The script "ExchangeConfigBackup.ps1" creates a backup of the most important Exchange settings using "Export-Clixml". The second script "CompareExchangeConfigChanges.ps1" compares the status from the backup with the current Exchange configuration and lists the changes.

The two scripts can be downloaded here and can easily be adapted to your own requirements:

The first lines in the "ExchangeConfigBackup.ps1" script must be adapted to your own environment:

In line 1, a path to a folder must be created in which the backup is saved; this can also be a share to which the user executing the script has access. In line 2, the password for the certificates is specified. The backup also contains the SSL certificates (for security reasons only). If the backup is to be sent by e-mail, lines 3-5 must be adapted accordingly.

The script can now be executed via a scheduled task:

The script then creates the backup in the selected folder, which looks like this, for example:

If required, an e-mail with the backup will also be sent as a ZIP archive:

The second script "CompareExchangeConfigChanges" now compares a status from the backup with the current Exchange configuration. The path to the backup directory must first be entered in the first line of the script:

The backup must be available in this folder in unzipped form, so the ZIP from the mail must be extracted into the folder.

As soon as a backup has been stored in the folder for comparison, the current Exchange configuration can be compared with the saved configuration using "CompareExchangeConfigChanges". I have done this here as a test.

I first created a backup of the configuration and then deleted the "dummy.de" domain. After the domain was deleted, I compared the current configuration with the configuration saved in the backup:. The result looks like this:

A change to the configuration in the "AcceptedDomains" file has been detected, the domain "dummy.de" is still present here in the backup (BackupValue). In the current Exchange configuration, the domain no longer exists (CurrentValue).

However, the two scripts are not completely reliable, as certain values sometimes change during normal operation (e.g. time stamps or trading). It therefore takes some practice to be able to identify a possible cause from a configuration change in the event of an error. However, I think that these two scripts can help somewhat if, for example, changes are planned and you want to have a "small backup" of the old configuration beforehand, just in case.

As the two scripts are quite lean, they can also be easily adapted to your own requirements.

Addendum

I have used an "accepted domain" in the examples. Like most Exchange settings, the accepted domains are stored in the Active Directory. In the case of the accepted domains here:

So if an accepted domain was deleted by "mistake", it cannot be restored by restoring the Exchange server from a backup. In this case, the domain controller would have to be restored... Or you can simply create the corresponding Exchange configuration again and save yourself the restoration...

Exit mobile version