Friday, August 19, 2016

Exchange PowerShell Variables

Since the release of Exchange Server 2007 (the first version to include PowerShell) that the Exchange Management Shell (EMS) includes the following three pre-defined variables:
  • $exbin - contains the full path to Exchange's Bin directory;
  • $exinstall - contains the full path to Exchange's install folder;
  • $exscripts - contains the full path to the Exchange's script folder.

In a default installation of Exchange 2016, this is what these variables contain:

These variables are used in different scenarios such as some scripts provided by Microsoft, and can also be used by administrators to facilitate the management of Exchange. But where are these variables defined? Can we add a couple more?

When we load the EMS, the Exchange.ps1 script located in the Bin directory is run. Within this script we can find these variables defined:
$global:exbin = (get-itemproperty HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup).MsiInstallPath + "bin\"
$global:exinstall = (get-itemproperty HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup).MsiInstallPath
$global:exscripts = (get-itemproperty HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup).MsiInstallPath + "scripts\" 

If, for any reason, you would like to add another variable, you can add it here. For example, to add a variable to your Message Tracking Logs directory you could do something like this:
$global:exmsgtl = "E:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking\"

Exchange Install Error Database is mandatory on UserMailbox

The other day I was trying to update the first Exchange 2013 server in this particular test environment to CU13 when I got the following error when installing the Mailbox role:

The error itself contained the code Exchange tried to run, so it wasn't clear what the exact problem was. An event in the Application event log mentioned the exact same thing:
Log Name:      Application
Source:        MSExchangeSetup
Date:          8/7/2016 2:34:52 PM
Event ID:      1002
Task Category: Microsoft Exchange Setup
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX...
Description:   Exchange Server component Mailbox role: Mailbox service failed.
Error: Error:  The following error was generated when $error.Clear();
(...)

Time do dig deeper and look at the ExchangeSetup.log file! In here, I got some more information about what the problem was: Exchange was failing while trying to do something to the arbitration mailbox SystemMailbox{bb55...} (the one used in the Offline Address Book generation process):
[08/07/2016 10:34:51.0582] [2] Processing object "domain/Users/SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}".
[08/07/2016 10:34:51.0582] [2] [ERROR] Database is mandatory on UserMailbox.
[08/07/2016 10:34:51.0598] [2] [ERROR] Database is mandatory on UserMailbox.
[08/07/2016 10:34:51.0598] [2] [ERROR] Database is mandatory on UserMailbox.
[08/07/2016 10:34:51.0598] [2] Ending processing set-mailbox
(...)
[08/07/2016 10:34:52.0004] [1] The following 2 error(s) occurred during task execution:
[08/07/2016 10:34:52.0004] [1] 0.  ErrorRecord: Database is mandatory on UserMailbox.
[08/07/2016 10:34:52.0004] [1] 0.  ErrorRecord: Microsoft.Exchange.Data.DataValidationException: Database is mandatory on UserMailbox.
(...)
[08/07/2016 10:34:52.0004] [1] [ERROR] Database is mandatory on UserMailbox.
[08/07/2016 10:34:52.0004] [1] 1.  ErrorRecord: Database is mandatory on UserMailbox.
[08/07/2016 10:34:52.0004] [1] 1.  ErrorRecord: Microsoft.Exchange.Data.DataValidationException: Database is mandatory on UserMailbox.
(...)
[08/07/2016 10:34:52.0004] [1] [ERROR] Database is mandatory on UserMailbox.
[08/07/2016 10:34:52.0004] [1] [ERROR-REFERENCE] Id=SystemAttendantDependent___1DEE95834DBA48F2BB211C2FB6765A5A Component=EXCHANGE14:\Current\Release\Client Access\Unified Messaging
[08/07/2016 10:34:52.0004] [1] Setup is stopping now because of one or more critical errors.
[08/07/2016 10:34:52.0004] [1] Finished executing component tasks.
[08/07/2016 10:34:52.0036] [1] Ending processing Install-MailboxRole
[08/07/2016 10:36:39.0444] [0] CurrentResult setupbase.maincore:396: 0
[08/07/2016 10:36:39.0444] [0] End of Setup
[08/07/2016 10:36:39.0444] [0] **********************************************

But what exactly does it mean by "database is mandatory"? Checking all the arbitration mailboxes using the Get-Mailbox cmdlet, I noticed that this mailbox was corrupted, it did not have a database, and I received the exact same error as during the installation:

Looking at its properties in Active Directory, the homeMDB attribute was indeed blank:

There are two ways to fix this: either remove this arbitration mailbox using ADSIEdit, re-run the Exchange setup to re-create it and then use the New-Mailbox cmdlet to complete its configuration; or rehome the mailbox by running the following cmdlet:

After this, the homeMDB attribute had the correct value:

And the installation process completed successfully!

Saturday, July 30, 2016

Exchange Lab in Azure

Do you want to set up an Exchange 2016 lab so you can test it but you do not have the resources to do so? Or perhaps you want a small lab that you can access from anywhere? Azure might be your solution!
 
Microsoft has recently released a guide with step by step instructions on how to set up an Exchange 2016 dev/test deployment in Azure. The end result, if you follow the guide, is a small environment with one Exchange server and one Domain Controller.
 
By default, this is only for internal email and application testing as external email flow is not configured, but this is something that you can add at a later stage. Exchange will, however, accept (external) incoming connections on port 443 for admin and testing    :)
 
If you do not already have an Azure subscription, you can sign up for an Azure Free Trial. If you have an MSDN or Visual Studio subscription, see Monthly Azure credit for Visual Studio subscribers.
 
For the full step-by-step guide, please go to Exchange 2016 dev/test environment in Azure.

Thursday, July 28, 2016

Clear Outlook AutoComplete Cache

Microsoft Outlook maintains a nickname list that is used by both the automatic name checking feature and the automatic completion feature. The nickname list is generated automatically as users use Outlook. If the nickname cache is corrupted, Outlook may be unable to identify recipients, may offer incorrect recipients when automatically completing the email address, or may send the message to the wrong person.
Please note that the AutoComplete list for Outlook is specific to Outlook and is not shared by Outlook Web App (OWA). OWA maintains its own AutoComplete list.

Unlike earlier versions of Outlook that store the nickname cache in a file on the local computer, Outlook 2010 and later versions store the nickname cache in the user’s primary message store. This means that deleting the entire nickname cache is no longer a matter of deleting the famous .NK2 file.

To reset the whole Outlook nickname cache for Outlook 2010 and later versions, first open Outlook, go to the File tab, click Options, click the Mail tab and, under Send messages, click Empty Auto-Complete List:

Outlook will then generate a new nickname cache.

Alternatively, you can close Outlook, click the Start menu, click Run (depending on which version of Windows you are using), and start Outlook by using the /CleanAutoCompleteCache switch: Outlook.exe /CleanAutoCompleteCache
Outlook will start up and generate a new nickname cache.

Exchange Shell Certificate Error

The other day, a colleague of mine experienced an issue when updating the certificate for one of his Exchange servers. After using the EAC to update the certificate, the Exchange Management Shell would not start and give the following error:
New-PSSession : [server.domain.com] Connecting to remote server server.domain.com failed with the following error message : [ClientAccessServer=server,BackEndServer=server.domain.com,RequestId=357032aa-2312-477e-be88-8d99 db9027c5,TimeStamp=07/12/2016 23:10:21] [FailureCategory=Cafe-SendFailure]  For more information, see the about_Remote_Troubleshooting Help topic.

In the System event log we would find the following:
Log Name:      System
Source:        Microsoft-Windows-HttpEvent
Date:          6/18/2016 4:45:40 PM
Event ID:      15021
Level:         Error
Computer:      server.domain.com
Description: An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data.

Because this was a passive server of a DAG, no users were connecting to it so they were not impacted. However, we were not able to access OWA/EAC directly on this server.

The problem turned out to be in IIS and the fact that the new certificate was not binding to the Exchange Back End site. To fix it, open IIS, expand the server name, expand Sites, right-click on Exchange Back End and select Edit Bindings. In the new window, select https and then click Edit...:

As you can see, no SSL certificate was selected:

To fix it, simply select the new certificate from the SSL certificate drop-down box and click OK.

Saturday, June 18, 2016

Check Distribution Groups Created

Some organizations provide self-service for Distribution Groups (DG), that is, users are able to create DGs that are available in the Global Address List for everyone to use. Even if an organization does not have a naming convention in place, it is always important to keep an eye on what DGs are created in case a user creates one that is not acceptable.

To do this, we can use the Get-DistributionGroup cmdlet together with the WhenCreated parameter to search for DGs created in the last week, for example. However, using this cmdlet we can see who the DG’s manager is but not exactly who created it. So, we need to use the Admin Audit Logs feature already covered in some tips and articles at MSExchange.org such as the Administrator Audit Logging article by Neil Hobson. Since we will be relying on this feature, it is important that it is enabled and that we keep these logs for as long as we need to.

Another advantage of using these logs, is that we can check for DGs that were created and subsequently deleted!

The following basic script will search the Admin Audit Logs for any DG created and return some information about it such as when it was created, by whom and its display name:
Param (
 [Parameter(Position = 0, Mandatory = $False)]
 [String] $From = "01/01/2016"
)


[Array] $DGs = @()

Search-AdminAuditLog -StartDate $From -Cmdlets New-DistributionGroup | Sort RunDate | % {
 $DG = $_.ObjectModified.Split("/")
 $DG = $DG[$DG.count - 1]

 $user = $_.Caller.Split("/")
 $user = $user[$user.Count - 1]
 $userDN = (Get-Mailbox $user).DisplayName

 $DG = New-Object PSObject -Property @{
  Date  = $_.RunDate
  UserAlias = $user
  UserDN  = $userDN
  DG  = $DG
 }

 $DGs += $DG

}

$DGs | Sort Date | FT Date, UserAlias, UserDN, DG -AutoSize

  
 
For a more complete report, please check my Exchange Distribution Group Creation Report article on MSExchange.org which generates an HTML report similar to:
 


Enable or Disable File Formats for Exchange Search

In Exchange 2013/2016, Exchange Search includes built-in support for indexing many file formats. In order to enable or disable specific file formats for Exchange Search, we use the Set-SearchDocumentFormat cmdlet (which is only available in on-premises Exchange 2013/2016).

When we disable a file format for content indexing by Exchange Search, contents of the file become unsearchable by Exchange Search clients such as Outlook Web App, Outlook in online mode and In-Place eDiscovery.

Let us say that we do not want to include ZIP files. To do this, we simply run the following cmdlet:
Set-SearchDocumentFormat ZIP -Enabled $False

If we disable indexing for a supported file format, such as in the example above, items containing an attachment of that file type are not considered unsearchable. When we perform an In-Place eDiscovery search, and we select the option to include unsearchable items, only items that are actually unsearchable are returned. Items that were not searched because the associated file format is set as unsearchable are not returned.

Please note that JPG and GIF formats are not really used even if enabled. Exchange indexes their metadata but will not scan/OCR the image itself. Exchange will deliberately skip over images and mark the items as partially processed.

Undo Ignore Conversation in Outlook

Outlook has a great feature that allows us to “ignore” particular email conversations that do not really interest us without asking the sender(s) to remove us from future emails. When we select Ignore on an email message, Outlook deletes that email and it also keeps track of all future emails related to the ignored message. If a future email related to the originally ignored email arrives in our Inbox, Outlook automatically moves these future emails to our Deleted Items folder.
 
But how about if we no longer want to ignore a particular conversation? Easy! Simply remove the “ignore” status of the email thread using the following steps:
    1. Select your Deleted Items folder;
    2. Select the email that is currently set to be ignored by Outlook;
    3. Click Ignore on the Delete section of the Home tab on the ribbon:
 
    4. If prompted, click Stop Ignoring Conversation:

 At this point, the email is automatically moved from our Deleted Items folder to the folder from which the it originated, and future emails for this thread will not be automatically deleted.

We can determine if an email is being ignored by the status of the Ignore button in the ribbon. If the Ignore button is highlighted (as in the screenshot above), the conversation thread on that email is currently being ignored by Outlook.

When we enable the Ignore option on a conversation, a message is created in the Associated Contents table of the Conversation Action Settings folder of our mailbox (which we can look at using MFCmapi for example):


It is important to have the following in mind:
  • If there is no activity on a thread for 14 days, the conversation action message for the thread is automatically deleted;
  • The age of the conversation action message is determined by the oldest message for the conversation;
  • We can modify the number of days at which the conversation action messages expire using the following registry data:
    • Key: HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Options\Conversations
    • DWORD: OnGoingActionsExpiration
    • Value: integer specifying the number of days after which an inactive conversation has its conversation action message deleted.
  • We can start Outlook using the following switch to delete all conversation action messages: Outlook.exe /CleanConvOnGoingActions. Using this switch will not move emails back to their original location, but because the conversation action message no longer exists for the conversation, any new messages for the conversation will remain in the Inbox;
  • We can also get different behavior from this feature, depending on the version of Exchange being used:

o   With Exchange 2007 and a cached mode profile, Ignore is based on SUBJECT. For example, any message with “Help!” as the subject will be automatically sent to Deleted Items as long as we clicked Ignore for a previous message with Help! as the subject;

o   With Exchange 2010 and later versions, Ignore is based on the CONVERSATION ID and only the messages related to the same ignored conversation are automatically sent to the Deleted Items folder.

 

Wednesday, June 15, 2016

432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded

The Exchange Team wrote a post named Store Driver Fault Isolation Improvements in Exchange 2010 SP1 a while back regarding a new feature introduced in Exchange 2010 SP1 to throttle the volume of messages delivered to a single recipient.
 
However, this featured caused some issues for organizations with a large volume of emails to Public Folder and, more commonly, a Journal mailbox. In these cases, administrators will see mail queues with the following error:
432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded
 
The solution mentioned is to create the following two keys:
<add key="RecipientThreadLimit" value="2" />
<add key="MaxMailboxDeliveryPerMdbConnections" value="3" />
 
And add them to the EdgeTransport.exe.config file (located at ...\Program Files\Microsoft\Exchange server\V15\Bin).

However, for organizations using Exchange 2013 or 2016, these two keys need to be added to the MSExchangedelivery.exe.config file located in the same folder!

After adding the keys, restart both the Microsoft Exchange Transport (MSExchangeTransport) and Microsoft Exchange Mailbox Transport Delivery (MSExchangeDelivery) services.

Friday, May 20, 2016

Improved “Automatic Reply” options in OWA

You might have noticed that since last April Microsoft has added a few new (great!) options to the Automatic Replies feature in Outlook on the Web:


These options make it easier to clear our calendar and automatically decline meetings before we head out for some time away from the office. When we set an automatic reply in Outlook on the web, Outlook offers to do the following on our behalf:
1. Block our calendar so people know we are away;
2. Clear existing meetings on our calendar by declining/cancelling them;
3. Automatically send a response to incoming invitations while we are away.



Block my calendar for this period
This option will create an appointment for the duration of our automatic reply with the title we specify:


Automatically decline new invitation for events that occur during this period
Outlook is now able to automatically decline a new invitation on our behalf while we are away! With this option, users will immediately know we will not be attending a meeting that gets scheduled while we are away. After responding on our behalf, Outlook will leave the invitation in our inbox so we know what happened while we were gone.

Decline and cancel my meetings during this period
That last option is to decline and cancel events currently in our calendar. When we now set an automatic reply, Outlook on the web finds all events that occur while we are away and gives us the option to indicate which meetings we would like to cancel or decline, as well as give you reply options to include.

First we select a reply to use when cancelling these meetings:

And then we can select which meetings we actually want to cancel:

Outlook on the web selects all meetings with attendees by default, leaving events without any attendees unchecked (as these are normally reminders or notes users create for themselves). If there is a meeting we don’t want to cancel, we simply uncheck it from the list and Outlook on the web will leave the event in our calendar.

How cool are these new options?! No more manually blocking our calendar and rejecting meetings one by one! Now I just hope this will come to Exchange on-prem soon, but it won’t surprise me if it takes a few good months...


Wednesday, May 18, 2016

Outbound DKIM Signing in Office 365

About a year ago, I wrote an article entitled DKIM and DMARC in Office 365 where I explored what DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) are, and how exactly they work with Exchange Online in Office 365.

At the time of writing that article, Office 365 only supported inbound validation of DKIM over IPv4 and IPv6. Outbound DKIM signing was not yet available but was in the roadmap. Well, it is here now!

To continue reading about DKIM signing in Office 365, please check this article at MSExchange.org.

Remote Exchange Monitoring and Reporting using Email

We all know how crucial a messaging service is to most organizations. With the exception of maybe telephones, businesses today rely on email and messaging systems more than any other piece of infrastructure. Every Exchange administrator knows the importance of continuously monitoring Exchange, not only to prevent downtime and quickly fix problems after they occur, but also to be aware of the health of the infrastructure and to help identify potential problems and performance degradations before they turn into problems and cause downtime.

Monitoring solutions like Microsoft’s System Center Operations Manager, SolarWinds, Nagios, MailScape, etc., are just some examples of monitoring tools for Exchange. However, some organizations do not provide access to these tool’s consoles or dashboards outside the internal network. So what happens if an administrator is out and about without anything other than his/her phone and needs to check if this user has gone over their quota and cannot send emails, on which server a particular database is mounted, or even if ServerA has just been rebooted?

These type of situations might be rare, but I have personally been there and it would have been extremely useful if I could send an email to my mailbox with a particular PowerShell cmdlet and get the output of that cmdlet back. And this is what this article is about. We will develop two basic scripts that will monitor incoming emails between two users (for security reasons), run the cmdlet(s) in the email’s subject and reply with the output from that same cmdlet. The first script will use Message Tracking Logs while the second Exchange Web Services (EWS).

To continue reading, please check this article at MSExchange.org.
 
 

Saturday, May 14, 2016

Clutter Disabled by Default in Exchange Online? No!

There have been some discussions online where people are saying that Clutter seems to be disabled by default for new mailboxes in Exchange Online. It turns out that Clutter has not been disabled by default for new Office 365 mailboxes. As we know, Clutter is a learning system, and it requires a certain lower limit of messages in the mailbox to confidently learn about a user's behaviour before Clutter is auto enabled for a mailbox. This means that, for newly created mailboxes and mailboxes that are migrated from an on-premises environment into Exchange Online, the following requirements need to be meet:
  1. At least 1,000 messages delivered to the mailbox after the mailbox was created or migrated;
  2. The user needs to have logged into the mailbox once after creation/migration.
 
After both these requirements are meet, Clutter is auto enabled for that mailbox within 24 hours.

"The Delegates page is not available" Error Message

The other day, a user was trying to give his new personal assistance Delegate permissions to his mailbox. However, whenever he clicked on Delegate Access:

He would receive an error message stating: “The Delegates page is not available. Cannot access Outlook folder.

After some troubleshooting and digging around, it turned out that this was being caused by a particular Outlook (Inbox) rule! I am still to investigate why this rule was causing this problem and why would any rule prevent configuring delegates, so this is still a mystery...

If you are experiencing the same problem, simply disable any existing rules one by one until you are able to configure delegates. Alternatively, you can start Outlook by typing “Outlook /CleanRules” in the Start Menu to start Outlook and delete all rules (probably not recommended).

Thursday, May 5, 2016

Product Review: Stellar Exchange Toolkit v7.0

In this product review, I reviewed the latest version of Stellar Exchange Toolkit, v7.0 launched in March 2016. This toolkit is designed to help Exchange administrators extract data from corrupt Exchange EDB or backup files, easily convert OST to PST files, and to reset domain account passwords. It supports all Exchange versions since 5.5 and all it requires is a machine running Windows Vista / Server 2003 or above to install the software, plus a version of Outlook compatible with the Exchange server being used in order to perform certain export/import operations.

The Toolkit, as the name suggests, is a collection of the following tools that we will review one by one:
  • Stellar Phoenix Mailbox Exchange Recovery
  • Stellar Mailbox Extractor for Exchange Server
  • Stellar OST to PST Converter
  • Stellar Mailbox Extractor for Exchange Backup
  • Stellar Phoenix Password Recovery for MS Exchange

To read the full review, please visit MSExchange.org.
 
 

Wednesday, May 4, 2016

Determine Client Used to Send Email

Just recently someone asked me if there was a way to determine which email client (Outlook, OWA or ActiveSync) was used to send a particular email. On top of that, this person was also interested is finding out how many emails are sent per day using each of these clients.

The good news is that the Message Tracking Logs register this information. Every email sent has a SourceContext property which contains, amongst other information, the ClientType used to send the email. The important thing is to check this property for SUBMIT events, i.e., when the Mailbox Transport Submission service successfully transmits the email to the Transport service.

For SUBMIT events, the SourceContext property contains the following details:
  • MDB: the mailbox database GUID;
  • Mailbox: the mailbox GUID;
  • Event: the event sequence number;
  • MessageClass: the type of message. For example, IPM.Note;
  • CreationTime: date and time of the message submission;
  • ClientType: for example OWA or ActiveSync.


Please note that this only applies to emails sent by internal users. There is no SUBMIT event when an external sender sends an email to an internal user, meaning there is no ClientType property for these emails. In these cases, the only information we have regarding the sender is what the email headers contain, which does not include email client information.

To check what email client was used to send a particular email, we can run something like the following cmdlet and look at the SourceContext field:
Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT -Sender nuno@nunomota.pt -MessageSubject Test | Select SourceContext

This field will contain information like the following:
MDB:34f3dc86-91bb-4ee7-a6a5-3d3ddc536050, Mailbox:a1de664f-9826-43a3-b9c8-3db019c86d8b, Event:29647741, MessageClass:IPM.Note, CreationTime:2016-05-11T07:17:14.922Z, ClientType:MOMT

In this case, MOMT stands for MAPI on the Middle Tier, basically clients that connect using Outlook or any other application that connects using RPC/HTTP or MAPI/HTTP.

To count the number of emails sent using OWA today, we can run something like this:
(Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT | Where {$_.SourceContext -match "OWA"}).Count

Easy as that! :)

Friday, April 29, 2016

Empty StorageLimitStatus when running Get-MailboxStatistics in Exchange 2013/2016

The old version of this script, used to gather some statistics out of mailboxes, made use of the StorageLimitStatus attribute of mailboxes (when running the Get-MailboxStatistics cmdlet). However, if you run the script in an Exchange 2013/2016 environment, you will notice that this attribute is always blank while with Exchange 2010 it is not... Unfortunately, this is by design...
 
Unlike versions of the Information Store earlier than the one that comes with Exchange 2013, the Information Store in Exchange 2013 does not cache the values of mailbox quotas. Therefore, the Information Store makes frequent calls to Active Directory (AD) to retrieve the values of mailbox quotas for each mailbox that is specified in the Get-MailboxStatistics cmdlet. Because of the frequent calls to AD, admins may experience poor performance in Exchange. To avoid this, the default Get-MailboxStatistics cmdlet does not retrieve the mailbox quotas and does not display a value in the StorageLimitStatus field...
 
To work around this issue, all we can do is either use the Exchange Admin Console (EAC):
  1. Log on to EAC by using a user account that is assigned at least the Mail Recipients role;
  2. In the feature pane, click recipients. A list of mailboxes is displayed;
  3. Select the mailbox of which you want to verify the quota status and then click the Edit button on the toolbar;
  4. Click mailbox usage. The mailbox quota usage is displayed.
Or we can use the Exchange Management Shell and run the following cmdlet:
Get-Mailbox "user" | FT *quota*, *size -AutoSize

The script has now been updated for Exchange 2013/2016 environments to work around this "issue".

Outlook Chinese NDR

There is a known bug with Outlook 2010 and 2013 that causes Non Delivery Reports (NDR) to be converted to Chinese-like characters when they are forwarded:


The same NDR does not get converted when being forwarded using OWA or when forwarded as an attachment.

The good news is that there are updates to fix this:

Saturday, April 23, 2016

Monitor Mailbox Database Transaction Logs

Excessive database and/or transaction log growth is, unfortunately, not an uncommon problem in Exchange deployments. On top of being hard to troubleshoot, if it is found too late, it can cause serious issues for users and even the business. As such, it is crucial to have an adequate monitoring solution. However, this is not the case in every single organization, so I decided to write a basic script to keep an eye on the number of logs being generated across databases.
 
You can, for example, run the script every hour and if any database currently has more logs than a specified threshold, it sends an alert by email with the number of transaction logs for all databases, highlighting the one(s) that triggered the alert, and the current free space for the database (you might need to update it depending on whether you have the .edb file and logs on the same or different locations).
 
The script simply counts all files in the LogFolderPath location (variable for each database) as this makes it quicker than only looking for *.log files, and still be accurate for what we want to achieve.

You can download the complete final script from the TechNet Script Gallery.

Friday, April 22, 2016

Preserving Auto-Forwarded Messages in Exchange

Over the last few versions of Exchange, the Information Protection team has done an amazing job in improving Exchange’s compliance capabilities. One of these features, called In-Place Hold, does a great job in preserving mailbox items. However, it did not capture emails automatically forwarded by users. This can be important as sometimes emails are forwarded without a copy of the email being stored in the user’s mailbox.



If the email does not get delivered to the mailbox at all, it cannot be placed on hold and, as such, will not be available for eDiscovery. For organizations wanting to stay in compliance, the recommendation has been to either disable automatic forwarding completely or to use Journaling.

Well, not anymore! Microsoft has rectified this and now Exchange Online is able to capture auto-forwarded messages. Transport detects if the user that has AutoForwarding configured is on hold and, if yes, automatically preserves a copy of the email in the Recoverable Items folder, making it available to eDiscovery.

At the time of writing this tip, this feature does not yet seem to be available in Exchange 2016 RTM, but it is already available in Exchange Online. In the following screenshot, we can see an eDiscovery search that contains an item that was sent from Nuno to Mota when Mota had auto forwarding configure to an external recipient without a copy being saved in Mota's mailbox. As we can see, the email was still placed on hold: