Although it is possible to perform basic Exchange Server management through the GUI, more and more admins are turning to PowerShell for Exchange Server management. This can be attributed to factors such as the transition to the public cloud and also to the fact that many Exchange Server management functions are not exposed through the GUI. Given the ever increasing use of PowerShell (and the Exchange Management Shell), I thought that it might be fun to take a look at a long standing Exchange Server feature, journaling, and how it can be managed through PowerShell.
Exchange Server journaling comes in two different flavors. Standard journaling records all of the messages that are sent to or from mailboxes within a specific mailbox database. Premium journaling is more granular in scope. It allows an administrator to create journal rules in an effort to journal specific messages. Premium journal rules can be based on recipient or on scope (internal, external, etc.). It is worth noting that the use of premium journaling requires Exchange Enterprise client access licenses.
Before you can enable journaling, you will need a journal mailbox. This mailbox acts as a repository for the messages that are journaled. Keep in mind that Office 365 mailboxes cannot be used as journal mailboxes. It is also important to disable quotas for journal mailboxes and to determine exactly how your journal mailbox will be used. Depending on your organization’s security requirements, it may be possible to configure a single journal mailbox to accommodate all of your journal rules, but you also have the option of using a separate journal mailbox for each rule. For the purposes of this article, I have created an Exchange Server mailbox named Journal that will act as my journal mailbox.
If you are performing standard journaling, then using the Exchange Management Shell to manage the journal couldn’t be easier. After all, standard journaling captures all of the messages sent to or from the mailboxes within a database. As such, there is really nothing to configure beyond simply turning journaling on or off. Here is how the process works.
If you look at the figure below, you will notice that I have started out by entering the Get-MailboxDatabase cmdlet into the Exchange Management Shell. Although this cmdlet isn’t technically a requirement, I entered the cmdlet so that you could see the names of my mailbox databases. As you can see in the figure, I have several mailbox databases, so for demonstration purposes, I am going to enable journaling on the database named DB1.
The Get-MailboxDatabase cmdlet lists the mailbox databases.
Enabling journaling for a mailbox database is simply a matter of using the Set-MailboxDatabase cmdlet to associate a journal mailbox with the database. The syntax for this command is:
Set-MailboxDatabase -Identity <database name> -JournalRecipient <journal mailbox name>
You can see what this process looks like in the next figure.
You can enable standard journaling by associating a journal mailbox with a database.
One thing that I want to be sure to point out is that the terminology used here can be a bit confusing. Notice in the command above that I used the -JournalRecipient parameter to specify the journal mailbox. When it comes to standard journaling, Microsoft seems to use the terms Journal Mailbox and Journal Recipient interchangeably (at least in some cases). When it comes to premium journaling however, the term Journal Recipient takes on a completely different meaning, as I will explain later on.
If at any point you want to disable journaling, you can do so by setting the journal mailbox to $Null. You can see how this works in the next figure. Notice in the figure that I am using the Get-MailboxDatabase cmdlet to verify that journaling has been enabled, and then disabled.
You can disable journaling by setting the journal recipient to $Null.
Things work a little bit differently if you want to use premium journaling. Remember, premium journaling is based around the use of journal rules. There are four components to each journal rule. Those components include:
The basic syntax used for creating a premium journal rule is as follows:
New-JournalRule -Name <journal rule name> -JournalEmailAddress <journal mailbox name> -Recipient <journal recipient name> -Scope <rule scope>
This syntax is fairly simple, but there are a few things that you need to pay attention to. First, you will notice that we are using a completely different cmdlet than was used for standard journaling. Standard journaling involved the use of Set-MailboxDatabase, while premium journaling uses New-JournalRule instead.
Another thing that you need to know is that the Recipient parameter is optional. If you omit the Recipient parameter, then the rule will apply to all recipients.
Finally, the Scope parameter is also optional. If you omit the scope, then the rule will apply to all messages, internal and external. This is referred to as a global scope. The valid scope types that you can specify within the command are Global, Internal, and External.
The figure below shows an example of creating a journal rule. As you can see in the figure, I have used the Get-JournalRule cmdlet to confirm the rule’s existence. Notice that there are two rules listed. One of these rules is enabled and the other is disabled. A journal rule does not take effect until you enable it by using the Enable-JournalRule cmdlet. You can disable a journal rule if necessary by entering the Disable-JournalRule cmdlet.
You must enable a journal rule prior to using it.
As you can see, Exchange makes it easy to configure journaling through the Exchange Management Shell. Keep in mind however, that if you choose to use premium journaling, then you will need the appropriate licenses.
If you have open network shares on your network, you are opening the door to…
A spear-phishing email has resulted in a U.S. gas pipeline ransomware attack. Making the attack…
To really lower your Azure costs, you need actionable information. Get info on flexibility groups…
Data stolen from breaches often live on forever, as appears to be the case with…
If you have set up an Azure DevOps Wiki, there are two ways to organize…
Anthos is Google’s hybrid and multicloud platform. This platform is cloud-agnostic and has an incredible…