Tuesday, October 14, 2014

Exchange 2010 User Sends Two Out of Office Messages

One of my customers had a mailbox user which generated two Out of Office messages whenever her Out of Office automated replies were enabled.  The first Out of Office message is the message the user set on her mailbox as the automated reply for both internal and external Out of Office.  The second Out of Office message is a different message for a user which no longer exists on the network and the contents of the Out of Office message does not display in Outlook Web App or Outlook.

The legitimate Out of Office is provided with a message subject of:

Automatic reply:

The second unwanted Out of Office is provided with a message subject of:

Out of Office

I created a test user account and send the problematic user a test email when her Out of Office was enable.  The following screenshot shows the extra Out of Office message sent:



First thing I checked was the MailboxAutoReplyConfiguration set on the mailbox which shows the Out of Office message set on the Mailbox for both Internal and External recipients.  This did not reveal the second Out of Office message causing the problem for this user account.


This means the second problematic Out of Office response must be stored elsewhere in the users mailbox.  Before going gown the path of downloading MFCMAPI and manually browsing through the problematic mailbox for the second Out of Office rule, I decided to run the "outlook.exe /cleanrules" Outlook 2010 command.  This command cleans and removes both server side and client side rules including any Out of Office rules which may exist in the mailbox.

Simply close Outlook on the users PC and then execute the following command:

 
After cleaning the rules and retesting the users Out of Office from my test mailbox, I only received the single Out of Office message which is the one we configured on the users mailbox as shown in the following screenshot.
 
 
Summary

Whilst a resolution to the issue was found, I am not sure what caused this issue.  The problematic mailbox is a member of a Database Availability Group cluster and was migrated cross-forest from an Exchange 2007 environment.  This should not cause problems as Exchange 2007 utilises a similar architecture for Out of Office messages as Exchange 2010 supporting the concept of both Internal and External Out of Office responses.  I believe this mailbox has been around for a long time and this legacy rule may have been brought across from Exchange 2003 as this particular customer uses role based mailboxes and when new users come on-board they inherit the last users mailbox keeping the same email address.

Please leave your comments if you also experience this issue.

Monday, October 13, 2014

Error Moving Mailbox Exchange 2007 to Exchange 2010

Today I had an issue moving a mailbox from Exchange 2007 to Exchange 2010 where the following error was generated in Exchange Management Shell.

Active Directory operation failed on domaincontroller.domain.local. This error is not retriable. Additional information: Insufficient access rights to perform the operation.
Active directory response: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
    + CategoryInfo          : NotSpecified: (0:Int32) [New-MoveRequest], ADOperationException
    + FullyQualifiedErrorId : 7189915F,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest


 
The error occurs if the account being moved does not have correct Exchange 2010 permissions set on the user account in Active Directory.  On the user account in Active Directory Users and Computers on the Security Tab under Advanced, "Include inheritable permissions from this object's parent" was not selected as shown below:
 
Note: In order to see the Security Tab on the user account in Active Directory Users and Computers you must enable "Advanced Features" which can be found under the view menu.
 
Simply select Include inheritable permissions from this object's parent.
 
 
 After making this change the move worked as expected.

 

Thursday, October 9, 2014

Windows XP clients must match the Certificate Common Name in Outlook for RPC over HTTP

Back in 2009 I wrote an article called "Configuring Outlook Anywhere Settings via Autodiscover" which can be found at the following URL:

http://clintboessen.blogspot.com.au/2009/06/configuring-outlook-anywhere-settings.html

Also in 2009 I wrote an article called "Outlook Anywhere keeps prompting for Password" which can be found at the following URL:

http://clintboessen.blogspot.com.au/2009/06/outlook-anywhere-keeps-prompting-for.html

In this blog post I am going to touch on these two topics a bit further as this issue will impact many organisations moving to Exchange 2013 for those still running Windows XP (despite the fact it is no longer supported) seeming Exchange 2013 only supports RPC over HTTP or MAPI over HTTP (out of scope for this article).  To recap what I wrote about in the previous articles 5 years ago, for RPC over HTTP(s) aka Outlook Anywhere to work on any version of the Outlook Client on the XP, the MSSTD value must match the "Common Name" on the certificate.  What am I talking about?  Well let me show you...

The MSSTD is specified under "Only connect to proxy servers that have this principal name in their certificate" which can be found within Outlook under Account Settings, Open the Account, More Settings, Connection Tab and finally Exchange Proxy Settings.

 
This value must match the "Common Name" of the certificate which in this example is mail.example.com as shown below next to "Issued to:"
 
 
From Windows Vista onwards the MSSTD can match any name in the Certificate which includes the Certificate Common Name as shown above and any Subject Alternative Names (SAN) which may exist on the certificate.  These are often used and can be easily located on the details tab of a certificate in Microsoft Windows as shown below:
 
 
For Windows XP the "Only connect to proxy servers that have this principal name in their certificate" value MUST MATCH the common name on the Certificate.  The symptom for having this not matching is the user continuously being prompted for credentials in an infinite loop as I addressed under the article Outlook Anywhere keeps prompting for Password.
 
 Note: This also applies to Windows Server 2003 for people with legacy Terminal Server / Citrix environments.
 
What about for Wild Card certificates, how do I set the "Only connect to proxy servers that have this principal name in their certificate" MSSTD value for these for legacy Windows XP clients?
 
For Wild Card certificates the MSSTD value must be set to:
 
msstd:*.domain.com
 
You must actually put the astricts in the DNS name instead of the name the client is connecting to in order for Windows XP to be happy so it matches the exact name of the Wildcard certificate.
 
What about Autodiscover?
 
Now that we understand that the MSSTD must match the common name of the certificate for our legacy Windows XP clients, how do we automatically push this out to our clients via Autodiscover?
 
Exchange 2013 no longer directly uses EXPR/EXCH Outlook Providers which we configured in Exchange 2007/2010, it has two different dynamically generated EXHTTP providers. Users with mailboxes on 2013 will get one set of EXHTTP settings for internal usage and one set of EXHTTP settings for external usage.  You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP.
 
However ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings.  The concept of internal Outlook Anywhere and External Outlook Anywhere is new in Exchange 2013 as we
got rid of direct RPC to the Exchange server.  We want the ability to set NTLM authentication for internal and Basic authentication for External as well as different connection URLs.
 
To change the internal MSSTD returned value from Autodiscover use the following command:
 
Internal Outlook Anywhere:
 
Get-OutlookProvider "EXCH" | Set-OutlookProvider -CertPrincipalName "msstd:mail.domain.com"
 
External Outlook Anywhere:
 
Get-OutlookProvider "EXPR" | Set-OutlookProvider -CertPrincipalName "msstd:mail.domain.com"
 
If you have a private internal namespace such as .local, .lan or .internal you may also need to setup split horizon DNS so that you can make the Certificate Common Name match the MSSTD!
 
Hope this article has been helpful.

Monday, October 6, 2014

Setup Wizard for Update Rollup 7 for Exchange 2010 Service Pack 3 (KB2961522) ended prematurely

When installing Update Rollup 7 on Exchange Server 2010 Service Pack 3 I received the following error message:

Setup Wizard for Update Rollup 7 for Exchange 2010 Service Pack 3 (KB2961522) ended prematurely.

Setup Wizard for Update Rollup 7 for Exchange 2010 Service Pack 3 (KB2961522) ended prematurely because of an error.  Your system has not been modified.  To install this program at a later time, please run the installation again.


This error was encountered after running the Exchange2010-KB2961522-x64-en.msp file downloaded from the Microsoft Website.

In the ServiceControl.txt file located under C:\ExchangeSetupLogs the following errors were present:

[12:58:25] Service 'IIS Admin Service (IISAdmin)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeAB'.
[12:58:25] Service 'Microsoft Exchange Address Book (MSExchangeAB)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeADTopology'.
[12:58:25] Service 'Microsoft Exchange Active Directory Topology (MSExchangeADTopology)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeAntispamUpdate'.
[12:58:25] Service 'Microsoft Exchange Anti-spam Update (MSExchangeAntispamUpdate)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeEdgeSync'.
[12:58:25] Service 'Microsoft Exchange EdgeSync (MSExchangeEdgeSync)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeFBA'.
[12:58:25] Service 'Microsoft Exchange Forms-Based Authentication service (MSExchangeFBA)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeFDS'.
[12:58:25] Service 'Microsoft Exchange File Distribution (MSExchangeFDS)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeIMAP4'.
[12:58:25] Service 'Microsoft Exchange IMAP4 (MSExchangeIMAP4)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeIS'.
[12:58:25] Service 'Microsoft Exchange Information Store (MSExchangeIS)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeMailboxAssistants'.
[12:58:25] Service 'Microsoft Exchange Mailbox Assistants (MSExchangeMailboxAssistants)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeMailboxReplication'.
[12:58:25] Service 'Microsoft Exchange Mailbox Replication (MSExchangeMailboxReplication)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeMailSubmission'.
[12:58:25] Service 'Microsoft Exchange Mail Submission (MSExchangeMailSubmission)' cannot be configured due to the following error: Access is denied
[12:58:25] Enabling service 'MSExchangeMonitoring'.


and so on..

Generally when you run a .msp update file it automatically provides an User Account Control (UAC) exception however on this customers network it did not.  As a result UAC prevented the update from performing the required tasks.

To resolve the problem I simply needed to run the update from an elevated command prompt window as follows:

 

Cannot bind argument to parameter 'Identity' because it is null

When attempting to install Exchange 2010 SP3 Service Pack on an Exchange 2010 SP1 Server I received the following on the Mailbox Server Role.

Error:
The following error was generated when "$error.Clear();
          if ($RoleCreatePublicFolderDatabase)
          {
            $publicDB = get-PublicFolderDatabase -Server:$RoleFqdnOrName -ErrorAction SilentlyContinue;
            $DB = get-MailboxDatabase -Server:$RoleFqdnOrName -ErrorAction SilentlyContinue;
            if ($publicDB -and $DB)
            {
                set-mailboxdatabase `
                  -Identity:$DB.Identity `
                  -publicFolderDatabase:$publicDB.Identity `
                  -DomainController $RoleDomainController
            }                 
          }
        " was run: "Cannot bind argument to parameter 'Identity' because it is null.".

Cannot bind argument to parameter 'Identity' because it is null.


If you received this error you most likely also received:

http://clintboessen.blogspot.com.au/2014/10/this-server-role-cant-be-installed.html

This error occurs if the original Exchange 2010 SP1 or SP2 installation did not finish "Finalizing Setup" which is the final stage in the installation process.  Failure means important registry keys are not set correctly.  In my case the Finalizing Setup did not complete because of the following error:
 
 
This error is generated if the MailboxRole is missing a ConfiguredVersion string value under the following registry key:
 
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\MailboxRole
 
As you see in the following screenshot the ConfiguredVersion string value is missing:
 
 
Simply create the string value called ConfiguredVersion and give it the same value as UnpackedVersion as shown in the following screenshot:
 
 
After this I deleted the Exchange 2010 SP3 installation watermark (both the “Action” and “Watermark” entries in the registry) and re-ran setup.  Google for this, lots of information already available on the Internet

This server role can't be installed because the following roles aren't current: AdminToolsRole

When attempting to install Exchange 2010 SP3 service pack on an Exchange 2010 SP1 server I received the following error:

This server role can't be installed because the following roles aren't current: AdminToolsRole

 
This error occurs if the original Exchange 2010 SP1 or SP2 installation did not finish "Finalizing Setup" which is the final stage in the installation process.  Failure means important registry keys are not set correctly.  In my case the Finalizing Setup did not complete because of the following error:
 
 
The above error is triggered if the ConfiguredVersion does not match the UnpackedVersion registry key.  These registry keys can be found under the following location:
 
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\AdminTools
 
To fix this I made sure the ConfiguredVersion key matches the UnpackedVersion key as shown in the following screenshots:
 
Before:
 
 
After:
 
 
After this I deleted the Exchange 2010 SP3 installation watermark (both the “Action” and “Watermark” entries in the registry) and re-ran setup.  Google for this, lots of information already available on the Internet.
 
Note: If you experienced this error you may also experience the following:
 

Couldn't resolve the user or group "domain.local/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.

I ran into a problem when running the Exchange 2010 SP1 setup in an environment with a single Exchange 2007 SP3 server.  The setup failed on the Mailbox Server role with the following error:

Error:
The following error was generated when "$error.Clear();
          $name = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]::DiscoveryMailboxUniqueName;
          $dispname = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]::DiscoveryMailboxDisplayName;
          $dismbx = get-mailbox -Filter {name -eq $name} -IgnoreDefaultScope -resultSize 1;
          if( $dismbx -ne $null)
          {
            $srvname = $dismbx.ServerName;
            if( $dismbx.Database -ne $null -and $RoleFqdnOrName -like "$srvname.*" )
            {
              Write-ExchangeSetupLog -info "Setup DiscoverySearchMailbox Permission.";
              $mountedMdb = get-mailboxdatabase $dismbx.Database -status | where { $_.Mounted -eq $true };
              if( $mountedMdb -eq $null )
              {
                Write-ExchangeSetupLog -info "Mounting database before stamp DiscoverySearchMailbox Permission...";
                mount-database $dismbx.Database;
              }

              $mountedMdb = get-mailboxdatabase $dismbx.Database -status | where { $_.Mounted -eq $true };
              if( $mountedMdb -ne $null )
              {
                $dmRoleGroupGuid = [Microsoft.Exchange.Data.Directory.Management.RoleGroup]::DiscoveryManagementWkGuid;
                $dmRoleGroup = Get-RoleGroup -Identity $dmRoleGroupGuid -DomainController $RoleDomainController -ErrorAction:SilentlyContinue;
                if( $dmRoleGroup -ne $null )
                {
                  Add-MailboxPermission $dismbx -User $dmRoleGroup.Identity -AccessRights FullAccess -DomainController $RoleDomainController -WarningAction SilentlyContinue;
                }
              }
            }
          }
        " was run: "Couldn't resolve the user or group "domain.local/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.".

Couldn't resolve the user or group "domain.local/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.
The trust relationship between the primary domain and the trusted domain failed.


The mailbox role is the last role which is installed as part of the Exchange 2010 SP1 setup process.  Despite this error occurring, the Exchange 2010 SP1 installation did complete with all Exchange 2010 services present on the server, started and in a functional state.  The Exchange 2010 SP1 management tools were also installed and working.

As a result I pushed on and began installing the Exchange 2010 SP3 upgrade installation package.  The Exchange 2010 SP3 upgrade installation package also did not complete the installation correctly and failed with the same error:

Error:
The following error was generated when "$error.Clear();
          $name = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]::DiscoveryMailboxUniqueName;
          $dispname = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]::DiscoveryMailboxDisplayName;
          $dismbx = get-mailbox -Filter {name -eq $name} -IgnoreDefaultScope -resultSize 1;
          if( $dismbx -ne $null)
          {
            $srvname = $dismbx.ServerName;
            if( $dismbx.Database -ne $null -and $RoleFqdnOrName -like "$srvname.*" )
            {
              Write-ExchangeSetupLog -info "Setup DiscoverySearchMailbox Permission.";
              $mountedMdb = get-mailboxdatabase $dismbx.Database -status | where { $_.Mounted -eq $true };
              if( $mountedMdb -eq $null )
              {
                Write-ExchangeSetupLog -info "Mounting database before stamp DiscoverySearchMailbox Permission...";
                mount-database $dismbx.Database;
              }

              $mountedMdb = get-mailboxdatabase $dismbx.Database -status | where { $_.Mounted -eq $true };
              if( $mountedMdb -ne $null )
              {
                $dmRoleGroupGuid = [Microsoft.Exchange.Data.Directory.Management.RoleGroup]::DiscoveryManagementWkGuid;
                $dmRoleGroup = Get-RoleGroup -Identity $dmRoleGroupGuid -DomainController $RoleDomainController -ErrorAction:SilentlyContinue;
                if( $dmRoleGroup -ne $null )
                {
                  Add-MailboxPermission $dismbx -User $dmRoleGroup.Identity -AccessRights FullAccess -DomainController $RoleDomainController -WarningAction SilentlyContinue;
                }
              }
            }
          }
        " was run: "Couldn't resolve the user or group "domain.local/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.".

Couldn't resolve the user or group "domain.local/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.
The trust relationship between the primary domain and the trusted domain failed.


In the Exchange 2010 with SP1 installation package, the Management Tools were installed before the Hub Transport, Client Access and Mailbox Server roles.  When running Exchange 2010 SP3 upgrade package, the Management Tools are installed after the Hub Transport, Client Access and Mailbox Server roles and as a result were not upgraded as part of the Service Pack.  When the Service Pack failed on the Mailbox role it skipped updating the Management Tools - as a result this problem needed to be addressed.

The error is stating it could not resolve user or groups for Discovery Management - there is only one discovery user created by default with Exchange 2010 called:

DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}

As a result I decided to recreate this mailbox by deleting it and recreating it.  This was done with the following commands:

Disable-Mailbox "DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}"

Enable-Mailbox "DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}" -Arbitration


Next I assigned the Discovery Management user permissions to the new mailbox with the following command:

Add-MailboxPermission -Identity:"cosp.internal/Users/DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}" -User:"Discovery Management" -AccessRights:"FullAccess"


After this I deleted the Exchange 2010 SP3 installation watermark (both the “Action” and “Watermark” entries in the registry) and re-ran setup.  Google for this, lots of information already available on the Internet.

After making these changes I was able to successfully patch the Exchange 2010 SP1 server with Exchange 2010 SP3.

 

Thursday, October 2, 2014

What is the SCCM Management Point?

A management point is a site system role that provides policy and service location information for clients and it also receives configuration data from clients. When we deploy software to a client, the client sends a content request to a management point.  The management point sends a list of the preferred distribution points to the client, and the client uses one of the preferred distribution points as source location for content. If contents are not available on the preferred distribution point, the management point sends a list to the client with distribution points that have the content available.

Management Point can be defined on client computers when they are installed, or client can get the list of Management points through DNS or WINS.

Clients search for a Management Point by using the below options in the order specified:
  • Management point
  • Active Directory  Domain Services
  • DNS
  • WINS