Office 365 – Server-side vs Client-only Rules


Office 365 – Server-side vs Client-only Rules

Rules are either server-side or client-only based on the conditions and actions you apply to them.

Server-side rules    use conditions and actions handled by the Exchange server and these rules run whether or not you log into Outlook on your computer. Here’s an example of a server-side rule:

From <people or distribution list in the GAL or your contacts list>, move it to the <specified> folder

This rule uses all Exchange server information, like moving a message from a sender who’s in the Global Address List (GAL) to a specific folder that’s in your Exchange mailbox. But if the folder you’re moving the message to exists on your PC only, then it becomes a client-only rule.

Client-only rules    have at least one condition or action that uses an Outlook feature and they don’t run until you log into Outlook with the account that you used to create the rule. For example, this is a client-only rule:

From <people or distribution list>, flag message to <play a sound>

In this example, you ask the rule to play a sound when you receive a message and this condition can be performed only by Outlook, which makes it a client-only rule.

Examples of common conditions specified in a rule that make it a client-only rule:

  • With specific words in the subject
  • Marked as importance
  • Marked as sensitivity
  • Flagged for action
  • With specific words in the body
  • With specific words in the message header
  • With specific words in the recipient’s address
  • With specific words in the sender’s address
  • Assigned to category

Examples of common actions specified in a rule that make it a client-only rule:

  • Assign it to the category
  • Permanently delete it
  • Flag message for follow up at this time
  • Clear the Message Flag
  • Print it
  • Play a sound
  • Mark it as read
  • Display a specific message in the New Items Alert window
  • Display a Desktop Alert

https://kb.wisc.edu/office365/page.php?id=41575

Advertisements

Exchange 2013 Monitoring Mailboxes


Exchange 2013 Monitoring Mailboxes

Introduction

Exchange Server 2013 introduced a new feature called Managed Availability, which is a built-in monitoring system with self-recovery capabilities. Managed Availability performs continuous tests (probes) that simulate end-user actions, to detect possible problems with Exchange components or their dependencies. If probes are failing, it performs gradual simple recovery actions to bring the affected component in healthy state. It uses special type of mailboxes, called Monitoring Mailboxes or health mailboxes, to simulate end-user kinds of tests.

The life cycle of monitoring mailboxes is taken care entirely by Managed Availability components.

In this post, we’ll see how Managed Availability takes care of monitoring mailboxes, what best practices to keep monitoring mailboxes happy are and some related troubleshooting.

Monitoring Mailboxes

Functioning of Managed Availability is implemented by Microsoft Exchange Health Manager Service running on each Exchange Server 2013 role.

The Microsoft Exchange Health Manager Service is responsible for creating and maintaining monitoring mailboxes

Let’s take a look at how the Health Manager creates them!

How do we create monitoring mailboxes?

The MS Exchange Health Manager Service runs in two processes, MSExchangeHMHost.exe and MSExchangeHMWorker.exe (let’s call it the HM worker).

HM worker process, at the time of startup, checks for availability of monitoring mailboxes and creates monitoring mailboxes as needed.

Starting with Exchange Server 2013 Cumulative Update 1, accounts for monitoring mailboxes are created under following container in the domain Exchange server resides:

<ADdomain>\Microsoft Exchange System Objects\Monitoring Mailboxes

Example:


The logic HM worker process uses to detect and create monitoring mailboxes depends on Exchange Cumulative Update (CU) installed, Exchange role installed on the box and mailbox databases present.

The Following logic was used to create monitoring mailboxes for Exchange Server 2013 servers between RTM to Cumulative Update 5:

  • One monitoring mailbox per mailbox database copy, plus one for all of CAS servers.

Here’s an example of monitoring mailboxes created on Exchange Server 2013 SP1 server that hosts both CAS and mailbox role:

Get-Mailbox -Monitoring | ft displayname,whencreated -AutoSize

[PS] C:\>Get-Mailbox -Monitoring | ft displayname,whencreated 
DisplayName                                         WhenCreated 
———–                                         ———–
HealthMailboxb285a119be6649b3a89574f078e947f5      11/10/2014 9:07:29 AM 
HealthMailbox60d8a8d1285e41bfa5ce1ef1fb93d14e      11/10/2014 9:07:36 AM

The display name of the monitoring mailbox created for database copy contained the GUID of the mailbox database for which it was created.

Example:


The display name of the monitoring mailbox created for CAS server contained the GUID of the Exchange server for which it was created.

Example:


http://blogs.technet.com/b/exchange/archive/2015/03/20/exchange-2013-monitoring-mailboxes.aspx

 

 

Exchange 2013 uses Managed Availability to monitor it’s own health.  A key part of this monitoring is the use of synthetic transactions which mimic user activity such as sending and receiving Email.  As you can imagine, this activity needs to come from and get to somewhere, which is where the Health Mailbox comes into play.  The Health Mailbox is, for all intents and purposes, just like a normal mailbox with an Active Directory account.  There have been a few changes in the Health Mailbox architecture since RTM, namely the location of the AD accounts, the naming convention and the amount of Health Mailboxes created.

Active Directory Location

In RTM we created the Health Mailboxes in Contoso/Users.  I would love to you show you a pretty picture here, but I don’t have an RTM lab and I don’t feel like building a new forest just for one screenshot.  Close your eyes and it should come to you.

In CU1 we created a dedicated home for these objects, as per below:


http://blogs.technet.com/b/admoore/archive/2015/03/11/exchange-2013-health-mailboxes.aspx

 

 

 

How to re-create monitoring mailboxes (NOT considered regular maintenance!)

The mailbox database removal doesn’t cleanup the AD user account associated with monitoring mailboxes. This can then result in orphaned AD user accounts. This happens because of deny permission inherited on Monitoring Mailboxes container. KB article 3046530has details on this, as well as the workaround to resolve it.

If there are too many orphaned monitoring mailbox accounts, you may want to re-create them.

Steps:

1) Make sure “Monitoring Mailboxes” container is present

  • Open Active Directory Users & Computers
  • Click on View and select “Advanced Features”
  • The Browse to Microsoft Exchange System Objects
  • Verify the presence of the “Monitoring Mailboxes” container.

Example:


If the Monitoring Mailboxes container is missing:

  • Make sure you have Exchange Server 2013 CU1 or above installed.
  • Perform PrepareAD with the Exchange Server 2013 version installed.

2) Stop the “Microsoft Exchange Server Health Manager” service on all Exchange Server 2013 servers.

3) Open Exchange Management Shell and use following command to disable existing health mailboxes:

Get-Mailbox -Monitoring | Disable-Mailbox

4) Go back to Active Directory users & computers, right click on domain and search for “HealthMailbox”



5) Delete the health mailbox user accounts.

6) Wait for AD replication or force AD replication.

7) Start the “Microsoft Exchange Server Health Manager” on all Exchange Server 2013 servers.

 

 

Ref: http://blogs.technet.com/b/exchange/archive/2015/03/20/exchange-2013-monitoring-mailboxes.aspx

 

 

 

Best practices

Here are some best practices regarding management of user accounts associated with monitoring mailboxes as well as mailboxes themselves:

  • Do not apply third party customized password policies to user accounts of monitoring mailboxes
  • Exclude monitoring mailboxes from user account lockout policies
  • Do not move the user accounts out from the Monitoring Mailboxes container
  • Do not change the user account properties, like restricting password change etc.
  • Do not change AD permission inheritance
  • Since HM worker handles password resets for monitoring mailboxes, in a large environment, it is normal to see increased password reset traffic for monitoring mailbox accounts; note that doing one of the things above might increase the frequency of those resets
  • Do not move the monitoring mailboxes between mailbox databases
  • Do not apply mailbox quotas to monitoring mailboxes
  • If applying a retention policy, ensure the data within the monitoring mailbox is retained for a minimum of 30 days before being deleted

If you see a mailbox size increasing significantly
for specific monitoring mailbox; you can simply disable the specific mailbox. The HM worker will create a new mailbox at next startup.

http://blogs.technet.com/b/exchange/archive/2015/03/20/exchange-2013-monitoring-mailboxes.aspx

 

Common Issues

So now we know a bit more about the Health Mailboxes, lets look at two common issues.

1. “Corrupt” Health Mailboxes.  We often hear this term, and it seems to come from the error message which is sometimes shown when you run Get-Mailbox -Monitoring.  “/HealthMailboxXXXXXXXXX has been corrupted, and it’s in an inconsistent state. The following validation errors happened: Database is mandatory on UserMailbox”.So what does this mean, and is the mailbox really “corrupted”?  Well, no, not really.  What has actually happened is that this Health Mailbox has the database it corresponds to deleted.  It is therefore “orphaned” and will throw up this error.  This can often happen when admins install a new server, which gets a database created by default, and this is then removed and the clean-up piece doesn’t happen properly.  The AD account is still there, but the mailbox is gone and the database attribute is empty.  These can (and should) be safely removed from Active Directory. It may be prudent to restart the Health Manager service on the affected server, too, just in case any probes are referencing them.

2. Account Lockouts. How on earth can a “system” mailbox account get locked out?  Well, as I said, for all intents and purposes, you can look at these Health Mailboxes as normal mailboxes with a corresponding AD account.  They have passwords which are periodically reset.  The password is a random 128 character secure string, so if you have any kind of domain password policy which could affect that, then it’s possible to cause issues when the passwords are reset on the Health mailbox accounts.  It is best practice to make sure /Monitoring Mailboxes is not included in ANY domain password policies (including lockouts).  You can view password change/failure activity from the following log:

 

…\Exchange Server\V15\Logging\Monitoring\Monitoring\MSExchangeHMWorker\ActiveMonitoringTraceLogs

 

http://blogs.technet.com/b/admoore/archive/2015/03/11/exchange-2013-health-mailboxes.aspx

Steps to Disable Managed Availability in Exchange 2013 for few Health Checks


Steps to Disable Managed Availability in Exchange 2013 for few Health Checks

 

 

Managed availability is one of the best feature which is been introduced and it’s an excellent feature from Exchange 2013. By using this feature it’s very easy for monitoring the Exchange servers without adding any monitoring software pack like SCOM and few more.

In addition to this it also has the capability to resolve the issues by its own if it finds something wrong on any of the Exchange Functionality. Also it drops an email to the Health mailbox and specified mailbox (administrators) if in case the solution is unidentified by Managed Availability.

In a real time scenario it’s very useful in monitoring the Exchange servers in all aspects and definitely reduces the impact of the exchange servers from any disaster by its own. There can be few scenarios where there can be additional monitoring software’s installed on the servers  and in those cases we can disable the Managed Availability if at all we do not need the report to be generated twice for the same alert.

Also in case of few servers in organization which is running on low memory can also be disabled since it queries, polls hundreds of health metrics as it could consume extra memory.

Also it collects few logs and data by default which is present in the below location which occupies some disk space  depending upon each environment which should be considered for low hard disk space servers as well.

Note:

It’s not  recommended to disable the Managed Availability until and unless there is any specific reason to be done because we will be losing this excellent monitoring feature available in Exchange 2013 at no additional cost.

 

Here is how to disable the managed availability

 

 

 

http://social.technet.microsoft.com/wiki/contents/articles/24038.steps-to-disable-managed-availability-in-exchange-2013-for-few-health-checks.aspx

Outlook clients repeatedly disconnect from and reconnect to Exchange Server 2013


Outlook clients repeatedly disconnect from and reconnect to Exchange Server 2013

 

You experience one or more of the following symptoms in Microsoft Exchange Server 2013.

Symptom 1

The Microsoft Outlook 2013 client, Microsoft Outlook 2010 client, or Microsoft Outlook 2007 client disconnects from the server that is running Microsoft Exchange Server 2013. Shortly after the disconnection, the client reconnects to the Exchange server. This behavior continues repeatedly.

Symptom 2

The MSExchangeRpcProxyAppPool is continually recycled. In Event Viewer under “Application and Services Logs \ Microsoft \ Exchange \ ActiveMonitoring” in the ProbeResult log, you see probe result errors for the “Outlook” service for different 2013 databases that indicate the following value:

StoreError=UnknownUser

In the Details view in the log entry, you see the following line:

Microsoft.Exchange.Data.Storage.DatabaseNotFoundException: The database with ID <GUID> couldn't be found


To resolve this problem, use one of the following methods, as appropriate.

Method 1

Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk. 

If you are not using legacy public folder databases, or if you are working in a pure Exchange 2013 environment, remove the default public folder database setting on each Exchange 2013 Mailbox database that points to the deleted public folder database object.

To do this, connect to CN=Configuration in ADSI Edit, and then navigate to the following location:

Domain.com/Configuration/Services/Microsoft Exchange/Org/Administrative Groups/Exchange Administrative Group (FYDIBOHF23SPDLT)/Databases

Clear the msExchHomePublicMDB value so that it reads as <not set>.

Method 2

If you are in an Exchange co-existence environment that includes Exchange 2013, and you are still connecting to legacy public folder databases (that do not use Exchange 2013 public folders), you can set the default public folder database to a valid Exchange 2010 or Exchange 2007 legacy public folder database. To do this, run the following command in Exchange Management Shell:


Set-MailboxDatabase <Exchange MDB> -PublicFolderDatabase <Legacy Public Folder DB to use>
				

 

YOU ARE HERE: HOME / SOLUTIONS / HOW TO REMOVE THE DEFAULT PUBLIC FOLDER DATABASE FOR AN EXCHANGE MAILBOX DATABASE

How to Remove the Default Public Folder Database for an Exchange Mailbox Database

FEBRUARY 29, 2012 BY PAUL CUNNINGHAM 25 COMMENTS

Microsoft has made it pretty clear in recent years that public folders will be going away at some stage in the future of Exchange Server.

If you’ve been using public folders in your Exchange organization and decided to get rid of them completely then you may run into this particular issue.

In this scenario I have gone ahead and prepared to remove the public folder database by:

  • Removing all of the public folder content
  • Ensured OAB distribution is set to web only
  • Ensured all my clients are Outlook 2007 and above

When I attempt to remove the public folder database I receive this error.

The public folder database cannot be deleted

The public folder database ‘PF-BR-01’ cannot be deleted.

PF-BR-01

Failed

Error:

Public folder database “PF-BR-01” is the default public folder database for the following mailbox database(s):

MB-BR-01

. Before deleting the public folder database, assign a new default public folder database to the mailbox database(s).

The solution seems logical. All I need to do is modify that mailbox database so it no longer uses the public folder database.

It is simple enough to change the public folder database configured for a mailbox database to some other public folder database, but in this situation I’m trying to get rid of public folders entirely. So instead I want to set the mailbox database to have no default public folder database.

Here is what happens if I try to use Set-MailboxDatabase to set the value to $null.

[PS] C:\>Set-MailboxDatabase MB-BR-01 -PublicFolderDatabase $null

Cannot validate argument on parameter 'PublicFolderDatabase'. The argument is null or empty. Supply an argument that is

 not null or empty and then try the command again.

    + CategoryInfo          : InvalidData: (:) [Set-MailboxDatabase], ParameterBindingValidationException

    + FullyQualifiedErrorId : ParameterArgumentValidationError,Set-MailboxDatabase

It doesn’t work. However all is not lost, there is another way, using ADSIEdit.msc.

Open ADSIEdit.msc and connect to the Configuration naming context.

Connect to the Configuration naming context with ADSIEdit

Navigate to the container that holds the Exchange databases. For Exchange 2010 you’ll find this in CN=Services -> CN=Microsoft Exchange -> CN=(your organization name) -> CN=Administrative Groups -> CN=Exchange Administrative Group (FYDIBOHF23SPDLT) -> CN=Databases.

Right-click the mailbox database you want to remove the default public folder database from and choose Properties.

Scroll down until you find the msExchHomePublicMDB attribute. Highlight it and then clickEdit.


Click the Clear button so that the value changes to “not set”.

Click OK, and OK again to commit the change.

 

 

 

Ref: https://support.microsoft.com/en-us/kb/2962915

http://exchangeserverpro.com/remove-default-public-folder-database-exchange-mailbox-database/

Connect to Exchange Online Protection using remote PowerShell


Connect to Exchange Online Protection using remote PowerShell

 

https://technet.microsoft.com/en-us/library/dn621036(v=exchg.160).aspx

 

 

  1. On your local computer, open Windows PowerShell and run the following command.
  2. $UserCredential = Get-Credential

    In the Windows PowerShell Credential Request dialog box, type your Exchange Online Protection user name and password, and then click OK.

  3. Run the following command.
  4. $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

    Note   If your Exchange Online Protection subscription is Exchange Enterprise CAL with Services (includes data loss prevention (DLP) and reporting using web services), use the following value for the ConnectionUri parameter: https://outlook.office365.com/powershell-liveid/.

  5. Run the following command.
  6. Import-PSSession $Session

 

 

 If your Exchange Online Protection subscription is Exchange Enterprise CAL with Services (includes data loss prevention (DLP) and reporting using web services), use the following value for the ConnectionUri parameter: https://outlook.office365.com/powershell-liveid/.

Note:

Be sure to disconnect the remote PowerShell session when you’re finished. If you close the Windows PowerShell window without disconnecting the session, you could use up all the remote PowerShell sessions available to you, and you’ll need to wait for the sessions to expire. To disconnect the remote PowerShell session, run the following command.

Remove-PSSession $Session