We have very busy work and personal lives, which can easily involve several meetings in the span of one week. Outlook reminders serve an important role in helping to manage scheduled appointments and meetings. Although, it’s not sufficient to have a slot on the calendar for that demo scheduled next week with a software vendor. This is where Reminders come to the rescue of human memory shortcomings. A reminder will popup and say “your demo session with Vendor X starts in 15 minutes”. That’s not what it actually says, but you get the point.

Recently, I received a request from someone to have reminders disabled for all calendar items. Personally, I couldn’t survive without having reminders for upcoming events, but to each her own. This is a very simple request to fulfill, right? Just go into Outlook and click File > Options > Calendar Options to uncheck Default Reminders. After performing these steps, calendar reminders should be disabled…at least I thought. After making this change, reminders were still enabled by default.

To determine why reminders were still enabled on meeting invites, we have to turn our attention to the mailbox settings in Exchange. Specifically, we must examine the properties of the mailbox in the Exchange Management shell (EMS) to get the answer. Since the EMS is technically Powershell just customized with a different look and loaded with Exchange cmdlets, we can use it to get the properties and methods of any object. Naturally, one would think that a mailbox object would contain a property which contains settings for calendar reminders. Let’s see. In the EMS, I will run the following command to see the properties of my mailbox:

Get-Mailbox -Identity Burrs | Get-Member

The output of this command consists of a long list of properties, however the only calendar related items are:

Hmmm…not exactly what we are looking for.

If the Reminder settings are not configured by a property on the Get-Mailbox cmdlet, we must determine where that setting exists. Let’s check in the EMS by searching for any cmdlets that are related to Calendar configuration. The following search query will reveal any cmdlets that contain the noun calendar:

Get-Command *calendar*

The output of this query shows something interesting. It includes a command called “Get-MailboxCalendarConfiguration”. Let’s take a look at the properties of this command to see what we are able to configure. To do this, we must include the identity parameter in the command syntax to pipe to “Get-Member”. I will use my mailbox name as the Identifier.

Get-MailboxCalendarConfiguration -Identity Burrs | Get-Member

Bingo! One of the properties available for the “”Get-MailboxCalendarConfiguration” command is called “RemindersEnabled”. Also, you can see included in the properties definition is “{get;set;}”. This means we can apply a value to the RemindersEnabled property using the verb “Set”.

Now we have something to work with. If we take a look at the calendar configuration settings of my mailbox, here’s what we see:

Get-MailboxCalendarConfiguration -Identity Burrs | Format-List

It appears that reminders are enabled on my mailbox with the DefaultReminderTime being set to 15 minutes. Here’s how he we disable reminders:

With the expanded role of email in business communication, there is a need for organizations to preserve emails for compliance and security reasons. Email has become the lifeblood of companies, the primary means by which employees communicate with clients, coworkers and vendors. Since electronic messages contain business related data or content, emails often maintain importance that extends months or years into the future. Additionally, many times an Email administrator will be faced with the task of gathering and producing messages for legal cases. For these reasons, message Archiving is a vital process.

Lets examine some of the evidence for considering Exchange Archives over other solutions.

Exhibit A: The Archive is a secondary mailbox in Outlook

The Archive mailbox is a secondary mailbox that appears in Outlook beneath a user’s Primary mailbox. Archive Retention policies on the Exchange server are configured to move messages from the Primary mailbox into the Archive once the messages reach a certain age. For the end-user, this is a seamless process. Additionally, the archived messages are stored in the same folder hierarchy in which they resided in the Primary mailbox. For users, it’s a benefit to have a consistent view between the two mailboxes. However, there isn’t a process in place to synchronize the Primary and Archive mailbox folder structures. If a folder is deleted or moved in the Primary mailbox, the same actions are not applied to the corresponding folder in the Archive mailbox. This can lead to some divergence between the two folder structures.

Exhibit B: No third-party utility needed for management

This article will not explain the steps involved in creating Retention polices and Archive mailboxes. But will only highlight the advantages they provide towards managing them. For Exchange administrators, Archive mailboxes are managed using the Exchange Management shell or console. The Archive mailbox can be created via the shell or console. As with Primary mailboxes, limits can be placed on Archive mailboxes or the databases that contain them. If limits are placed on both, the mailbox settings will override limits that are configured at the database level. Also, the Retention policies that determine when and what items are Archived are setup in the console.

Exhibit C: Can leverage native Exchange HA solutions

The databases that hold Archive mailboxes are not different from the databases that contain Primary mailboxes. As a matter of fact, both types of mailboxes can reside on the same database. For this reason, Archive mailboxes are able to be included in a DAG and replicated. Some organizations may require Archives to be available in database *over scenarios.

Exhibit D: No Stubbed messages

Due to the fact that messages are not transferred to a separate database with Exchange Archives, there are no linked messages that point to the actual email. This is particularly important for compliance reasons. Most organizations have compliance standards that mandate emails are retained and produced for legal cases. When messages get archived with 3rd Party solutions, important meta data gets removed. This can render the message incomplete and not reflective of its original state when collected for discovery procedures.

Conclusion

Upon looking at the evidence, it can be stated that Exchange Personal archives in most cases is a better choice: seamless integration, access to native high availability, no linked messages, Of course, all situations aren’t equal and in some cases a 3rd party solution could be more viable. Each organization will have to evaluate its particular needs and challenges, and make a decision accordingly in regards to an archiving solution.

In this post, I will show how to view a delivery for a Sent Item. This report, which can be seen from Outlook and OWA, will provide information on the status of an email such as: when the message was submitted, delivered and if it was read.

View Message Delivery Report in Outlook 2013:

1. Open a Sent Item to view its report

2. Click File and select “Open Delivery Report”

3. The Message Delivery Report will open in a browser window

View Message Delivery Report in OWA

1. After logging into OWA, click on Options and select See All Options…

2. Next select Organize E-mail and then Delivery Reports

3. On the Delivery Reports page, fill in the criteria that you want to use to search for the desired message: ie, based on recipients, sender or subject. In this case, I searched for messages from a particular sender. Once the data has been inputted, hit search to get the results.

The results of the report shows that the the message was submitted and delivered on 6/10/2016 2:10 PM. Also, it indicates that the message has been read or at least opened.

Here are some useful cmdlets that I’ve collected over time and keep on hand in my toolbox. I hope they come in handy for you as well:

The following command will retrieve the entire Outlook folder hierarchy of a user’s Primary mailbox and export it to a csv file. It’s useful in situations where a user has a lot of folders and is unable to locate emails or certain folders. To get the Archive mailbox folder structure, add the “archive” switch.

This is how you enable a Retention Hold on a group of users for a specified period of time. The command will retrieve the input from a list of users and pipe it to the command. No items will be Archived for the users during this time frame:

Here’s how to move a group of users Primary mailbox to a another database. Change the PrimaryOnly switch to ArchiveOnly to move the Archive mailboxes. A list of users will get piped to the command to initiate the move to the target database:

I’m going to stray off of the beaten path and post a blog regarding an Active Directory DNS issue that I experienced. Although it’s not Exchange server related, I thought this would be worth publishing as I’m sure others have encountered this issue.

We noticed that client DNS records were not getting updated in a timely manner. More specifically, this was occurring primarily with clients that were connecting remotely to the internal network via VPN.

Suspecting that this was a client issue, one of the first measures we took was to give the DHCP servers the authority to update DNS on behalf of clients. This seemed to alleviate the issue somewhat, however it completely resolved the problem. Another step we took wected as to lower the DNS scavenging, where stale records would deleted sooner. This workaround did not help matters alot either.

As I stated previously, this issue was primarily occurring with clients that connected through VPN sessions. When client machines connect via VPN, the VPN appliance acts as the DHCP server and issues an IP address from its address pool. There is an option within the VPN appliance to allow the internal DHCP servers to assign IP addresses, however this is probably a less secure configuration. Once the client receives its IP address from the VPN DHCP server, the client will update its record in DNS. Herein lies the problem.

When VPN clients update their records in DNS, they then take ownership of the records. A look at the properties of a VPN client’s DNS record would show the client as the record owner. When users that previously connected via VPN returned to the office, the internal DHCP servers were unable to update DNS despite having authority to do so. The DHCP servers would need to be given permissions to overwrite records and take ownership. This was done by adding them to the DNS Admins security group. Afterwards, the DHCP servers were now able to update DNS records that were owned by clients that previously connected via VPN.

I had a situation where my test environment DAG was offline and not detected. I’m not sure what caused this issue, however the mailbox databases were dismounted and the Content Indexes were in a failed state. This environment has two sites with a single DAG expanding across the sites. One site is active with a single Mailbox server and one CAS/HUB multi-role server. The passive site has the same configuration.

The following was returned when I executed a Get-MailboxDatabaseCopyStatus |FL:

Attempting to mount the databases doesn’t work. I attempt to start the DAG and get the following error:

The errors associated with the Cluster API in the above figure show that the Cluster service is not in a healthy state. Furthermore, I was not able to determine which data center was the cluster owner as seen below:

After checking the cluster service in Services, I see that it’s not only disabled but greyed out as well. Therefore, I’m unable to start it. Next, I proceed to the Failover Cluster Manager snap-in and notice that none of the DAG nodes are listed. This article by Tim McMichael was helpful in resolving this issue by providing the following steps in restoring the cluster.

Since this server is running on Windows 2008 R2, I run this command: Import-Module FailoverClusters

Now I have to reset the DAG Cluster Name Object (CNO) in Active Directory. Once the object is located, you simply right click on the CNO and select reset. After this is complete the CNO has to be disabled. If it’s still enabled, you will not be able to recreate the Cluster using the existing name as Failover Cluster Manager will think it’s being used.

Finally, I’m able to recreate the Cluster in Failover Cluster Manager, I was able to restore the DAG and bring the mailbox databases back online.

In this blog, I covered the steps I used to recover from a scenario where the DAG in my Exchange 2010 test environment was offline.