de-DEen-GB
 
MVP - Most Valuable Professional
rss

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft Technologies like Exchange, Office 365, Azure and Cloud Security.

Problem

You are not able to list public folders in a co-existence scenario with Exchange Server 2007 and Exchange Server 2010/2013 using the Exchange 2007 EMS or EMC.

When you try to execute Get-PublicFolder you receive the following error:

Get-PublicFolder " There is no existing PublicFolder that matches the following Identity: '\'. Please make sure that you specified the correct PublicFolder Identity and that you have the necessary permissions to view PublicFolder.

This might happen after you have removed the first Exchange 2007 mailbox server, but not the last Exchange 2007 mailbox server.

Exchange Server 2007 uses the Exchange System Attendant to access the public folder store and fails, if the System Attendant discovery in Active Directory does not provide a proper configuration.

KB 2621350 describes the discovery process:

  1. Exchange Server 2007 selects a mailbox database.
  2. Exchange Server 2007 obtains the LegacyExchangeDN attribute of the selected mailbox database. For example, Exchange Server 2007 obtains the following LegacyExchangeDN attribute value:
    /o=First Organization/ou=Exchange Administrative Group (group_name)/cn=Configuration/cn=Servers/cn=E14HUBCAS/cn=Microsoft Private MDB
  3. Exchange Server 2007 removes the "CN=Mailbox Database" part of the address. The address then resembles the following:
    /o=First Organization/ou=Exchange Administrative Group (group_name)/cn=Configuration/cn=Servers/cn=E14HUBCAS
  4. Exchange Server 2007 adds "CN=Microsoft System Attendant" to the LegacyExchangeDN value. After the value is appended, the LegacyExchangeDN attribute value resembles the following:
    /o=First Organization/ou=Exchange Administrative Group (group_name)/cn=Configuration/cn=Servers/cn=E14HUBCAS/CN=Microsoft System Attendant
  5. Exchange Server 2007 tries to log on to the public store by using the value in step 4.
  6. The store then tries to locate the System Attendant object.

There two annoying things about these steps

  1. Step 1:  Exchange Server 2007 selects a mailbox database

    There is no description available on how the database is being selected. But the co-existence scenario results in a mailbox database being selected that might be located on Exchange Server 2010 or Exchange Server 2013. Even thought that there still are Exchange Server 2007 mailbox database available. You still require to have a mailbox database hosted on an Exchange 2007 public folder server, due to the legacy public folder requirements with Exchange Server 2013.
     
  2. Steps 2-4: The LegacyExchangeDN example shows a E14HUBCAS name as a placeholder. In a situation where you have deployed dedicated mailbox servers this should read E14MBX.
     

Solution

The magic System Attendant mailbox has been removed from Exchange 2010. But the System Attendent configuration node does still exist in the Active Directory Configuration Partition for compatibility reasons. The configured attributes of the System Attendent entry vary depending on the version of the installed Exchange Server.

In regards of public folder issue, we need to focus on the following:

  • Exchange Server 2010 System Attendant
    • homeMDB: <not set>
    • homeMTA: <not set>
  • Exchange Server 2013 System Attendant
    • homeMDB: <not set>
    • homeMTA: CN=Microsoft MTA,CN=E15MBX,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]

To fix the public folder access issue for Exchange Server 2007, set the homeMDB and homeMTA attributes. Set the Exchange System Attendant attributes to appropriate values for your Exchange servers.

Exchange Server 2013

  1. Open ADSIEdit and connect to the Configuration context
  2. Open Databases node
    CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
  3. Open the Properties of an Exchange 2013 database
  4. View the distinguishedName property and copy the value to clipboard
    Example: CN=E15MBXDB01,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
  5. Close the Properties window and open the Servers node
    CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
  6. Expand the first Exchange 2013 server and open the Properties of the Microsoft System Attendant node
    Ensure that the view is not filtered to Show only attributes that have values
  7. Edit the homeMDB attribute and paste the distinguished name of the mailbox database copied in step 4
  8. Apply the changes and close the properties window

Repeat steps 4 to 8 for each Exchange 2013 server in your environment.

Exchange Server 2010

  1. Open ADSIEdit and connect to the Configuration context
  2. Open Databases node
    CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
  3. Open the Properties of an Exchange 2010 database
  4. View the distinguishedName property and copy the value to clipboard
    Example: CN=E14MBXDB01,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
  5. Close the Properties window and open the Servers node
    CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
  6. Expand the first Exchange 2010 server and open the Properties of the Microsoft System Attendant node
    Ensure that the view is not filtered to Show only attributes that have values
  7. Edit the homeMDB attribute and paste the distinguished name of the mailbox database copied in step 4
  8. Apply the changes and close the properties window
  9. Open the Properties windows of the Microsoft MTA of the same Exchange
  10. View the distinguishedName property and copy the value to clipboard
    Example: CN=Microsoft MTA,CN=E14MBXSRV01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
  11. Open the properties of the Microsoft System Attendant node for a second modification
    Ensure that the view is not filtered to Show only attributes that have values
  12. Edit the homeMTA attribute and paste the distinguished name of the mailbox database copied in step 10
  13. Apply the changes and close the properties window

Repeat steps 4 to 13 for each Exchange 2010 server in your environment.

Wait for Active Directory replication and retry to access the public folders using Get-PublicFolder in an Exchange Server 2007 Management Shell.

It might be required to restart the Exchange 2007 Information Store and System Attendant service of the Exchange 2007 server in question

Use an administrative PowerShell

Restart-Service MSExchangeIS 
Restart-Service MSExchangeSA 

I haven’t noticed any issues in production environments so far. If you encounter any issues in your environment, feel free to leave a comment.

Links


You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?

Contact me at thomas@mcsmemail.de
Follow at https://twitter.com/stensitzki

Read More »

You might encounter a situation when the MSExchangeSA service is stopped and you are not able to start the service.

When you try to start the service the follow event log error is logged:

MSExchangeSA-Error-1005

Log Name:      Application
Source:        MSExchangeSA
Date:          08.01.2016 09:40:33
Event ID:      1005
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SERVER01.MCSMEMAIL.DE
Description:
Unexpected error Access is denied. Facility: Win32 ID no: c0070005 Microsoft Exchange System Attendant  occurred.

This issue happens most likely due to an endpoint protection solution (aka AV Scanner) blocking access to the MSExchangeSA executable.

The simple apporach to get the service running is to restart the server.

If you need to run local endpoint protection on your Exchange servers, keep in mind to configure the appropriate scan exclusions:

Read More »

An Exchange Receive Connector requires a configuration for who can submit messages to the connector. The original TechNet description of the Set-ReceiveConnector cmdlet and the PermissionGroups attribute is as follows:

"The PermissionGroups parameter specifies the groups or roles that can submit messages to the Receive connector and the permissions assigned to those groups. A permission group is a predefined set of permissions granted to well-known security principals. The valid values for this parameter are as follows: None, AnonymousUsers, Custom, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, and Partners. The default permission groups assigned to a Receive connector depend on the connector usage type specified by the Usage parameter when the Receive connector was created. "

The description implies that it is possible to set the PermissionGroups attribute to Custom.

When you try to set the permission group to Custom, you will notice that this results in an error. You will encounter this error especially when you try to copy a receive connector from one Exchange Server to another Exchange Server.

The attribute itself is being set to Custom by Exchange itself when add AD permission explicitly.

Example

The example shows the configuration of a FerrariFax receive connector that needs to be configured across all Exchange 2013 DAG member servers.

Receice connector set to None

Receive Connector with PermissionGroups set to None

Add a dedicated Permission

Get-ReceiveConnector "SERVER\Connector for UMS (SERVER-FAX)" | Add-ADPermission -User DOMAIN\FaxUser -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-Bypass-Anti-Spam,ms-Exch-SMTP-Accept-Any-Recipient

Receive connector set to Custom by Exchange

Receive Connector with PermissionGroups set to Custom

 

Note

You can copy a receive connector across a number of Exchange servers using the PowerShell script Copy-ReceiveConnector.ps1 hat has been published at TechNet Gallery.

The script has not been modified to handle this situation, yet. The source code repository is available at Github

Read More »

The standard configuration of the ENow Management System (EMS) provides automatic Refresh for the One-View Dashboard Homepage only.

If an automatic refresh is required for any other page of the EMS Dashboard, i.e. Exchange 2013 Namespace, you need to modify the associated ASPX file.

Example

Modification of ExchangeWorkloadTest.aspx

Original ASPX file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
	<HEAD>
		<meta http-equiv="X-UA-Compatible" content="IE=edge" />
		<title><%=GetHeadTitle()%></title>
		<meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1">
		<meta name="CODE_LANGUAGE" Content="C#">
		<meta name="vs_defaultClientScript" content="JavaScript">
		<meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">
		<%
			skin.WriteCommonHtmlHeadEntries(Response);
		%>
	</HEAD>

Modified ASPX file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
	<HEAD>
		<meta http-equiv="X-UA-Compatible" content="IE=edge" />
		<title><%=GetHeadTitle()%>
		</title>
		<meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1">
		<meta name="CODE_LANGUAGE" Content="C#">
		<meta name="vs_defaultClientScript" content="JavaScript">
		<meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">
		<%
		   skin.WriteCommonHtmlHeadEntries(Response);
		   skin.WriteAutoRefreshHeader(Response);
		%>
	</HEAD>

Be aware that changes made to the APSX files will be overwritten by a software update. Any changes made need to be applied after updating the ENow Management System.

 

Mailscape is a component of the ENow Management System to monitor your Exchange Server Infrastructure. To learn more about Mailscape visit https://www.granikos.eu/en/Products/ENowManagementSuite

 

 

Read More »
On January 4, 2016
0 Comment
2506 Views

Problem

When you move your DotNetNuke 7 instance from Windows Server 2012 to a new Windows Server 2012 R2 instance you might end up with a not properly rendered skin. This issue relates to a situation where the releated Telerik Script Manager is not properly loaded.

Querying the affected website with Web Page Test showed in this case that the query for the Telerik.Web.UI.WebResource.axd resource resulted in an 404 http error.

Solution

Searching the web resulted in a variation of proposed solutions to this issue. In this case the solution is as follows.

The Telerik.Web.UI.WebResource.axd handler requires to be added to the system.webServer/handlers section of the web.config.

<handlers>
	<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />   
	<add name="Telerik.Web.UI.WebResource" path="Telerik.Web.UI.WebResource.axd" verb="*" type="Telerik.Web.UI.WebResource, Telerik.Web.UI, Culture=neutral, PublicKeyToken=121fae78165ba3d4" /> 
</handlers>

If the system.webServer node does not have a handlers node, just add it.

Links

 

Read More »