Tag Archives: Exchange 2010

User Cannot Set an Out of Office in Exchange 2010/2013 or EventID 3004 Appears in your Event Log

exchange 2007, Exchange 2010, Exchange 2013

Recently had an issue where a user was setting an out of office in their Outlook client, but when a different user emailed them, no Out of Office was sent.  We did the traditional troubleshooting steps, check rules on the far side, check junk box, check OWA to ensure the Out of Office was set.  Everything looked good.  Strange enough, if an internal user went to email the person going on vacation, they would receive a MailTip to that effect:


But, went you sent the email to Paul Ponzeka, you would not get an Out of Office back.  So what gives?

One of the steps we took was to check if Microsoft Exchange Mailbox Assistants service was running.  It was, we restarted it, but still same effect.  One of the responsibilities of the Microsoft Exchange Mailbox Assistants service is to handle enabling the Out of Office.  In this case, it didn’t resolve anything.

The next step we took was to try disabling, and re-enabling the Out of Office message, and then checking the event log on the Mailbox server.  Low and behold, we found our answer:


The above is EventID 3004 from the MsExchangeMailboxAssistants.  As you can see, there is an error stating the rules quota of the mailbox has been reached and the automatic reply rules can’t be enabled or updated.

Well, we found our issue, how do we fix it?  There are two ways.

The first the user can go through their Outlook rules and edit or delete existing rules.  Keep in mind that the length of both the rule actions, as well as the NAMES of the rules themselves will affect the size of the rule

The second is, the Exchange admin can increase the size of the rules quota.  By default, all mailboxes have a 64 KB quota, think of this as mailbox limits for Outlook rules.  We can increase this up to 256 KB on Exchange 2007 and later.  Exchange 2003 we cannot increase the rule size unfortunately, but that’s okay, because you should be off Exchange 2003 by now!

So, how do we increase the quota?  Easy.  Open Exchange Management Shell.  We can check the existing quota of the user pponzeka by running the command:

Get-Mailbox –Identity pponzeka | select RulesQuota


As we can see, its set to 64 KB.  To increase it, we run:

Set-Mailbox –Identity pponzeka –RulesQuota 256KB


And there we go, we can check by running the same Get-Mailbox as above to confirm:


Now, you cannot go past 256KB, this is the error you get, in this example I tried to set it to 512KB:


Get a “You don’t have sufficient permissions. This operation can only be performed by a manager of this group.” in Exchange 2010.

Role Based Administration


In our environment, like most bigger organizations, we have separate teams for helpdesk, and separate teams for engineering.  Helpdesk should have rights to perform actions on certain items, such as users and distribution groups, but not on the server level.  We utilize Role Based Administration in Exchange 2010 to give our helpdesk team the ability to manage end users, but not the servers.  I recently received a ticket regarding the helpdesk guys not being able to add certain users to a distribution list, they would receive the error “You don’t have sufficient permissions. This operation can only be performed by a manager of this group.”:



There was a bug in Exchange 2010 SP1 that was fixed in RU 3 for 2010 SP1 (http://support.microsoft.com/kb/2487852), but we are running Exchange 2010 SP2 RU1, so we were way past that.

What was the issue?  Role based administration.  We had assigned the helpdesk group the “Recipient Management” role.  When I checked the group that the helpdesk tech was trying to add the user to, I noticed that the group was a Mail Universal Security Group.  The tech had no trouble adding the user to a Mail Universal Distribution Group.

We could see the issue when the tech tried to create a new distribution group.  A distribution group type worked fine, but when he tried to create a security group he got the error that “A parameter cannot be found that matches parameter name ‘Type’”:


So we needed to add the management role “Security Group Creation and Membership” to the group the helpdesk team was in.

Since we were running in a resource forest setup, we needed to create a new role group, and matching Universal Security Group in the management domain and add the role group to this group.  Then we could add the users we want to it.

In our management domain, aptly named management.corp we created a group called Group-HelpDesk-SecurityGroup and add our helpdesk technicians to this group.  Then in the Exchange Management Shell, as an Organization Admin we run:

$remotecred = get-credential

This will cause a windows pop up box, where we need to enter our security credentials for management.corp for later.

Then run:

New-RoleGroup “NameofRoleGroup” –LinkedForeignGroup Group-Helpdesk-SecurityGroup –LinkedDomainController DC01.management.corp –LinkedCredentials $remotecred –Roles “Security Group Creation and Membership”

Now, have the helpdesk technicians close and reopen their Exchange Consoles or Exchange Management Shell and they should be able to add the group members to distribution lists, as well as security groups.


If your wondering how to create a linked group and assign it to a role, follow the below.  In this case we want to add a group called REMOTE-ORGMGMT to the role “Organization Management” in Exchange 2010.

Create group in management.corp called “REMOTE-ORGMGMT” and add the admins to this group that you want to have this right.  In the Exchange Management Shell run:

$remotecred = get-credential

This will cause a windows pop up box, where we need to enter our security credentials for management.corp for later.

$roles = Get-RoleGroup “Organization Management”

New-RoleGroup “MANAGEMENT-OrganizationManagement” –LinkedForeignGroup “REMOTE-ORGMGMT” –LinkedDomainController DC01.management.corp –LinkedCredentials $remotecred –roles $roles.roles

Then have the Management.corp admin users close and re-open their Exchange Management Consoles and you should be all set.

Cisco Call Manager and Exchange 2010 Unified Messaging–Fast Busy Signal When Calling Voicemail

Exchange 2010, Unified Messaging


In this article I spoke about how to configure the Exchange 2010 side of Unified Messaging with Cisco Call Manager:


I wanted to point out this issue in a separate article because it seems a decent amount of people are having the same issue.

After we configured Exchange 2010 UM with Cisco Call Manager, we got a fast busy signal when calling the users voicemail.  After turning up diagnostic logging on all of the Exchange UM servers, we would see the SIP connection hit:


But the user would get a fast busy, and we saw event ID 1006 in the event log, which stated The Unified Messaging server has ended a call with ID … because the user at the far end disconnected


We checked the trunk between Exchange and CCM, and it was set to the G.711 codec (as Exchange doesn’t support G.729).

After some digging inside the call manager, I changed this setting inside Cisco Call Manager:

System->Service Paramters

Select one of your call manager servers, and select the serviceCisco CallManager (Active):

Change the Default Interregion Max Audio Bit Rate from the default setting of 8 kbps (G.729) to 64 kbps (G.722, G.711).





After this change, everything worked!


Cisco Call Manager and Exchange 2010 Unified Messaging

Exchange 2010, Unified Messaging


Recently had an implementation in between Cisco Call Manager 8 and Exchange 2010 SP2 Unified Messaging.  We followed the documentation from Cisco on how to configure the Cisco Call Manager:


Essentially here is the breakdown from the cisco side:

  1. Set up a SIP trunk from Cisco Call Manager to Exchange 2010 UM Server
  2. Create a pilot identifier that points to the UM Server, in our case 1000

Trust me, this is very light, but is meant for Exchange admins who are looking at how to configure the Exchange side of things.  One thing to note, the walkthrough does not tell you of an issue you need to watch out for, which is Exchange 2010 UM only speaks over G711, not G729.  Even if your SIP trunk is configured for G711, you need to make the following change in Cisco Call Manager:

System->Service Paramters

Select one of your call manager servers, and select the service Cisco CallManager (Active):

Change the Default Interregion Max Audio Bit Rate from the default setting of 8 kbps (G.729) to 64 kbps (G.722, G.711).  Otherwise you will get a fast busy when calling your voicemail.

So, here is our configuration:

(2) Cisco Call Manager Servers [phdc-voiccm01.voice.com] and [phdc-voiccm01.voice.com]

(1)  Exchange 2010 UM Server [nysrv2-um01.exchange.corp]

Pilot Identifier = 1000

Number of digits in extension = 4

We need to create a UM Dial Plan. Navigate to Organization Configuration->Unified Messaging->UM Dial Plan->New UM Dial Plan


Here we set the digits to 4, the URI type to Telephone Extension, and since we are not using SIP with TLS, leave it as unsecured. Also, since we are North America, the country/region code is 1.

Click Next, and you can add nysrv2-um01 to the dial plan:


Open the dial plan you just created, as there are some settings we need to change:

Subscriber Access Tab

Add “1000” as Telephone number to associate:


Settings Tab

Change Audio Codec to G711


Save and close.

Next we need to add a new UM IP Gateway.

Go to Organization Configuration->Unified Messaging->UM IP Gateways->New UM IP Gateway

Create a separate UM IP Gateway for each cisco call manager, ensure to add the dial plan you created above:




You’ll notice also that you will get a “Default Hunt Group” listed underneath the IP Gateways if you associate it with a dial plan:


Creating the Dial Plan also automatically creates your UM Mailbox Policy, which you can check out at Organization Configuration->Unified Messaging->UM Mailbox Policies


This goes into the default pin settings for users mailbox’s, as well as features they can access.  Besides security purposes, there is not much to change here.

Next, enable a user for Unified Messaging by right clicking on his mailbox and selecting “Enable for Unified Messaging”


Set the Unified Messaging Mailbox Policy and set the PIN:


For the extension, if you have entered in the phone number in AD, it will automatically be filled in:


Once it’s done, your user will get an email letting them know they have been enabled for Exchange Unified Message:


You should be all set!

How to Import Users via CSV in Exchange 2010

exchange 2007, Exchange 2010

Create an csv file with the necessary information across the top row of the file as such:


The top row is going to coordinate with the S_.value that you are going to use in the following Exchange Shell command:

Import-CSV “C:Mailboxes.csv” | foreach {new-mailbox –Name $_.name –Alias $_.alias –UserPrincipalName $_.userprincipalname –Database $_.Database –OrganizationalUnit $_.organizationalunit –password (ConvertTo-SecureString $_.password –AsPlainText –force)}


And you should see the mailbox’s created below:


That’s it.  You can see how the values map with their respective column names.  You can add as many users as you want, and change it so they go to different database’s.

You can even create an automated job to export from your production servers, and them import them to your DEV Exchange Servers for testing. 

How to View Disconnected Mailbox’s and Purge Disconnected Mailboxes from Exchange 2010

Exchange 2010, High Availability


To view disconnected mailbox’s, essentially mailboxes that have been deleted from their user accounts, you need to first ensure that Exchange has gone through and cleaned the database.  This is done to ensure that it marks that mailbox as deleted.  If your database is MDB36, run the following command:

Clean-MailboxDatabase MDB36


Exchange gives no result from the command.  But now you can view Disconnected mailboxes through the “Disconnected Mailbox” view in the EMC:



You can also view it in the shell by running the following command:

Get-MailboxStatistics –Database MDB36 | where {$_.disconnectdate –ne $null}


And you will receive the following output:


By default, Exchange 2010 keeps disconnected mailbox’s in the DB for 14 days.  But say you want to remove this mailbox now and return it’s white space to use in the DB.  You need to remove the mailbox from the shell. 

You can do this by getting the GUID for the mailbox by running the command:

Get-MailboxStatistics –Database MDB36 | where {$_.disconnectdate –ne $null} | select displayname,MailboxGUID


And you will receive the following output:


Now run the following command to remove the mailbox:

Remove-Mailbox –Database MDB50 –StoreMailboxIdentity 7b40b106-5941-4de0-9fce-27ede21c474e


You’ll receive a confirmation prompt, just accept it, and your all set:



User’s Cannot Log into Exchange 2007 or Exchange 2010 OWA with UPN Suffix

Client Access, Exchange 2010, Hosting, Resource Forest


Lets say you have the following environment:


ExchangeResource.corp hosts all the Microsoft Exchange 2010 servers, and linked mailbox accounts.  The actual user accounts are stored in the Tailspin.corp and Mantech.corp forests.  The Tailspin.corp and Mantech.corp forests have a one way forest trust with ExchangeResource.corp so that users in the Tailspin.corp and Mantech.corp forests can access their linked mailboxes in the ExchangeResource.corp domain.

Now to make things easy on the users, you set the OWA directory to use UPN suffix names instead of Domainuser:


This will allow users in Tailspin to login using username@tailspin.corp and users in Mantech to use username@mantech.corp.

Everything works fine, but then you add a UPN suffix to each individual forest that makes the UPN suffix match the users email address. Below is an example shown with the user Tom Jones in the Tailspin forest:


Now users in Tailspin login using username@tailspin.com and users at Mantech login using username@mantech.com.

A user goes to login with the new UPN and is greeted with an error message that they could not login:


But using the old UPN still works fine, so what’s going on?

Well, if we check the event logs of the DC in the ExchangeResource.corp domain we find EventID 6034 for LsaSrv in the security event log:


The DC is telling us that it does not know how to route the Tailspin.com suffix.  It notes that it has been added to the forest tailspin.corp, as it learns it through the forest trust, but that the name suffix is not enabled.  It does very nicely tell us how to fix this.  Go to Active Directory Domains and Trusts->Right click on ExchangeResource.corp->Properties


Go to the Trusts tab.  Here you will see all the forests that you have trusts with.  Highlight the tailspin.corp forest and click on properties:


Navigate to the Name Suffix Routing tab:


Here we can see the new tailspin.com suffix has been added, it even has a status of “New”, but the Routing is disabled.  Highlight the suffix and then click Enable:


If you do not see the new suffix you created listed here, simply click the Refresh button and it should appear.

After hitting apply both names should be enabled:


Now if a user try’s to login, they should be all set!


Keep in mind you will need to do this each time you add a new UPN Suffix to one of the domains that are being trusted by ExchangeResource.corp.


Exchange 2010 Database’s Fail to Replicate or Seed

Exchange 2010, High Availability


Recently had a colleague that ran into an issue with an Exchange 2010 migration.  He could fail over the mailbox databases with no issue to DR, but that’s where the trouble started.

The production database would start to report that there was a high copy queue length that would increase as more activity occurred on the DB.  The production database pure and simple was not receiving the transaction logs from the newly activated database in DR. 

The setup was simple, two nodes, one in production, one in DR with a FSW.  The nodes were all-in-one 2010 boxes, with one NIC for MAPI and one NIC for replication.

My colleague also informed me that he had some trouble initially seeding the database.  All roads pointed to an issue with replication.  We quickly checked his replication network settings and found the following setup:


His DAG network had both replication networks for the separate sites under one object.  Once we moved them to their own separate networks:


Everything went back to normal!

Till the next time!

Delayed Email or Message Rescans with BES 5 and Exchange 2010

Blackberry, Exchange 2010


I recently ran into an issue where users were reporting that messages to their Blackberry handhelds were being delivered in clumps, and were also extremely delayed.  These are symptoms of a Blackberry Server rescan.  We were running BES 5.0.2 and Exchange 2010 SP1.  We upgraded the BES to 5.0.2 MR4, but the issue remained.

This essentially means that the BES server cannot keep up with email delivery, and thus cannot deliver the emails as they arrive.  It is forced to queue them, and deliver them in chunks.

I had already configured the Exchange 2010 throttling policy as per Blackberry’s documentation:

BES 5 and Exchange 2010 Throttling Policy

So throttling wasn’t the issue.  The issue ended up being that the BES server was only creating one mailbox agent in the BES server.  This has to do with the DAG model in Exchange 2010, and the way around it is to create static mailbox agents for EVERY user, or force the BES server to create multiple mailbox agents.  We can do this with two registry keys.  The first one:

HKLMSoftwareResearch In MotionBlackberry Enterprise ServerDispatcher

If it is not there, create a DWORD named MaxUsersPerAgent and set the decimal value to the maximum number of users per agent, in my case 40 users:


The second registry edit is:

HKLMSoftwareResearch In MotionBlackberry Enterprise ServerAgents

If it is not there, create a new DWORD with the name MaxMailboxesPerSession and set the decimal value to the value that you want the maximum number of mailboxes to be piped through a single MAPI session.  This is separate from the agent above.  For instance, I set mine to 35, which means at the 36th mailbox, the BES will create a new MAPI session.


After you make those changes, restart your BES server.  After making the above changes, your performance should increase, and you should see extra instances of the BlackberryAgent.exe process:


Just an FYI, SQL Express and MSDE are limited to five agents on the server.  For more agents, you will need to be using SQL Standard or higher, and edit the key:

HKLMSoftwareResearch In MotionBlackberry Enterprise ServerAgentsNumAgents and change its decimal value to a number higher than 5:


Again, this value will be ignored higher than a value of 5 on SQL Express and MSDE.  If you have 1000 users, and you set the MaxUsersPerAgent value to be 40 as above, your agent breakdown will be as follows:

BlackberryAgent (1) = 40 Users

BlackberryAgent (2) = 40 Users

BlackberryAgent (3) = 40 Users

BlackberryAgent (4) = 40 Users

BlackberryAgent (5) = 840 Users

So be careful to set the MaxUsersPerAgent value appropriately for your environment if your limited to the number of agents.

As for the BES server itself, we saw slightly higher memory utilization due to the extra agents (around 400 MB), but much lower CPU usage.

Hope you guys find this helpful!

Users Receive a Login Prompt After a Database Failover in Exchange 2010

Client Access, Exchange 2010, High Availability, Outlook Anywhere


When performing a database *over in Exchange 2010, especially a planned one, it is suppose to be as seamless as possible to the end user.  An Outlook user for example, will receive a small pop up informing them that the connection to Exchange has been lost, and their Outlook may hang for a couple of seconds before reconnecting and resuming normal behavior.

I recently ran into an issue where this was not the case.  Users would call the helpdesk as soon as a database failover was initiated with complaints that their outlook was prompting them for a login:

Jan. 2601 09.54

Well, needless to say this is not expected behavior.  After a little troubleshooting that involved a packet capture, it seemed that the Outlook clients were making an HTTPS call to the CAS servers at that moment.  Turns out it was an attempt to connect to them over Outlook Anywhere, and this was the reason of the login prompt.  When I checked the Outlook client, they in fact had the Outlook Anywhere Settings enabled.  This was due to Autodiscovery.  To check the settings in Outlook 2007 navigate to Tools->Account Settings->Change->More Settings->Connection  If yours is enabled, it will look like the following:

Jan. 2603 09.55

Under Exchange Proxy Settings, you’ll find the settings enabled:

Jan. 2604 09.55

Since these were internal clients, and had no need to use Outlook Anywhere, simple unselect the Connect to Microsoft Exchange using HTTP:

Jan. 2606 09.58

This will disable the Outlook Client from connecting.  The only issue is, if you use automatic profile generation through Group Policy, this leverages autodiscovery, so it will continue to put the setting back.  You can do one of two things.  The first is to delete the Outlook Anywhere provider using the Remove-OutlookProvider command, which is NOT recommended.  This will stop Autodiscovery from publishing Outlook Anywhere GLOBALLY. 

The second is to use Group Policy.  Create a blank GPO named something like Disable Outlook Anywhere Settings.  Download the Outlook Anywhere ADM template from here, and import it into the template under User Settings.  You’ll now have the Outlook Anywhere (RPC/HTTP) options available in Group Policy:

Jan. 2608 11.23

The only value you need to edit here is the RPC/HTTP Connection Flags setting:

Jan. 2609 11.24

Edit the setting, set it to Enabled and No Flags

Jan. 2610 11.25

This will disable the Connect to Microsoft Exchange Using HTTP in the outlook clients after its been applied, notice how its greyed out:

Jan. 2611 11.25

Once this GPO has applied to all your users, you should now be able to failover databases without the users receiving a log in prompt.