Unknown's avatar

About Michel de Rooij

Michel de Rooij, with over 25 years of mixed consulting and automation experience with Exchange and related technologies, is a consultant for Rapid Circle. He assists organizations in their journey to and using Microsoft 365, primarily focusing on Exchange and associated technologies and automating processes using PowerShell or Graph. Michel's authorship of several Exchange books and role in the Office 365 for IT Pros author team are a testament to his knowledge. Besides writing for Practical365.com, he maintains a blog on eightwone.com with supporting scripts on GitHub. Michel has been a Microsoft MVP since 2013.

Exchange 2007 SP3 Update Rollup 7


Today the Exchange Team released Rollup 7 for Exchange Server 2007 Service Pack 3 (KB2655203). This update raises Exchange 2007 version number to 8.3.264.0.

Here’s the list of changes included in this rollup:

  • 2617514  Old spelling rules on the Brazilian Portuguese dictionary in OWA in an Exchange Server 2007 SP3 environment
  • 2645789  MAPI_E_NOT_FOUND error when a MAPI application calls the GetProps method on an Exchange Server 2007 mailbox server
  • 2654700  Certain mailbox rules do not work automatically after you move a mailbox from an Exchange Server 2007 server to an Exchange Server 2010 server and then move it back
  • 2677583  Move operation is not completed and 100 percent of CPU resources are consumed on an Exchange Server 2007 Mailbox server
  • 2677979  MSExchangePOP3 service crashes in an Exchange Server 2007 environment
  • 2680793  Free/busy lookups between Lotus Notes and Exchange Server 2007 users stop responding
  • 2682570  Store.exe crashes on Exchange Server 2007 servers when a public folder that contains an empty PR_URL_NAME property is replicated in a mixed Exchange Server 2007 and Exchange Server 2010 environment
  • 2690628  Pre-reform spelling rules are used in the Portuguese (Portugal) dictionary in Outlook Web Access in an Exchange Server 2007 environment
  • 2694267  MSExchangeRepl.exe process crashes when Active Directory returns the LDAP_PARAM_ERROR value in an Exchange Server 2007 environment
  • 2694274  User who has the Full Access permission cannot open another user’s mailbox by using Outlook Web App in a mixed Exchange Server 2007 and Exchange Server 2010 environment
  • 2694291   The autocomplete=”off” parameter is missing in Outlook Web Access in an Exchange Server 2007 environment
  • 2696628  You receive duplicate read receipts from a user who is using an IMAP4 client in an Exchange Server 2007 environment

Note that this version will also fix the CAS-CAS proxy issue with Exchange 2010 SP1 (KB2696649).

When running ForeFront Protection for Exchange, make sure you disable ForeFront before installing the rollup and re-enable it afterwards, otherwise the Information Store and Transport services may not start. You can disable ForeFront using fscutility /disable and enable it using the fscutility /enable command.

Note that update rollups are cumulative, i.e. they contain fixes released in earlier update rollups for the same product level (RTM, SP). This means you don’t need to install previous update rollups during a fresh installation but can start with the latest rollup.

One special note: Exchange 2007 Mainstream Support has ended, making this the final standard support release. Extended support will end on April 11th, 2017.

You can download Exchange 2007 SP3 Rollup 7 here.

Exchange 2010 Mailbox Role Calculator 18.9


It’s been a while since the last update, but today the Exchange Team released a minor update to the Exchange 2010 Mailbox Role Calculator, bringing it to version 18.9.

Note: Apparantly there was also a 18.2 version, which wasn’t announced publicly on the EHLO blog. It looks like 18.2 was released on April 7th. I’ll also mention the changes in that version compared to the last publicly announced version, which was 17.8.

Enhancements and Bug Fixes since version 18.2:

  • Fixed the Storage worksheet’s “RAID Storage Configuration” Table to exclude showing “Total Number of Disks Required” for designs that do not have lagged database copies and are deploying in a JBOD configuration.
  • Added a notification to Role Requirements regarding scenarios that result in >2TB databases.
  • Fixed an error notification to indicate when the input parameters have resulted in a design that has more HA copies than available Mailbox servers.
  • Fixed the DAG LUN total space calculation to be based on the total number of database copies, not the total number of mailbox servers.
  • Fixed the database copy validation formula to ensure there is at least 1 HA copy or lagged database copy in the secondary datacenter when site resilience is enabled.
  • Fixed servers.csv to not add a space between the comma and drive letter.
  • Fixed cells to have the correct color formatting.
  • Updated BDM throughput requirements to stipulate 7.5MB/s per database as the worst case, which aligns with what can potentially be seen in Jetstress runs.

Enhancements and Bug Fixes in version 18.2 when compared to version 17.2:

  • Fixed the calculator’s database copy validation check function to allow for a single DAG to be stretched between datacenters when the database copy count is even.
  • Fixed the “Storage Design Results Pane – Total Disks Required” when leveraging the “As Calculated” results to not highlight RAID disks for a datacenter’s server when JBOD was the appropriate choice in the “RAID Storage Configuration” choice.  Likewise, the “JBOD Storage Configuration” table’s calculations were also fixed to not highlight the use of JBOD disks for a datacenter’s server when RAID was the appropriate choice.
  • Fixed an error in Storage Results where the Secondary Datacenter storage architecture tables would report the Primary Datacenter disk type and capacity instead of Secondary Datacenter disk type for RAID architectures.
  • Fixed an erroneous alert on the Input worksheet regarding not having enough IO capability for JBOD due to isolating logs from databases.
  • Fixed the calculated maximum database size for JBOD scenarios to allow for 2TB databases when >2.5TB disk sizes are selected.

You can download the calculator here. For more information please consult the changeblog or usage instructions.

Office 365 and “There are no items to show in this folder”


Be advised that when accessing shared mailboxes on Office 365 using Outlook in online mode, you may experience an issue with Outlook not properly updating the mailbox view.

Instead, Outlook will return a “There are no items to show in this view” message. The folder in the folder navigation pane displayed the proper number of (unread) items in the folder.

This could be the symptom of an issue which was already solved in Exchange 2010 Service Pack 1 Rollup 5. It seems the Office 365 data centers are not running a current version of Exchange, as today I received the message the Office 365 environment is currently being upgraded with Exchange 2010 Service Pack 2. The message also mentions the upgrade is to be completed at the end of the month.

More information on the issue in knowledge base articles kb2500648, announcing the fix is included in Exchange 2010 SP1 RU5.

Until then, the suggested workaround is to click one of the columns twice after which Outlook will update the view properly. Of course, you could also enable cached mode, if your setup and company policy permits (e.g. not running Outlook on terminal server).

Exchange Hybrid deployment and SMTP inspection


When setting up secure SMTP connections, also known as SMTPS or SMTP over TLS (Transport Layer Security), you encounter issues with SMTP obfuscating appliances, like Cisco ASA or PIX.

These appliances contain a feature called fixup protocol smtp, SMTP fixup, (E)SMTP inspect(ion) or Mailguard (Cisco), which – when enabled – limit the number of allowed SMTP verbs or obfuscate parts of SMTP dialogs. This tampering will cause problems when you try to configure SMTPS connections between e-mail servers and will prevent you from configuring a working Exchange Hybrid deployment, where TLS secured communications between the on-premise environment and Office 365 is enforced.

Note: By enforced, I mean it requires TLS which is more strict than opportunistic TLS,  which will attempt to set up TLS before continuing with regular SMTP communications.

You’ll end up with Office 365 specific Receive and Send connectors after setting up your Hybrid configuration using the Hybrid Configuration Wizard (or manually). Then, when sending e-mail between on-premise and Office 365, you notice e-mail doesn’t arrive and will remain queued.

After verifying your ISA or TMG isn’t blocking things (ports are open, SMTP filter not blocking STARTTLS etc), you start troubleshooting the issue by enabling Verbose logging for the Office 365 send connector (of course, this can also be achieved using the Exchange Management Console):

Set-SendConnector “Outbound to Office 365” –ProtocolLoggingLevel Verbose

The logs will by default be generated in the $exinstall \V14\TransportRoles\Logs\ProtocolLog\SmtpSend ($exinstall will contain the Exchange installation path).

If you look at the current log file, you’ll see the following pattern for each possible destination – in the example below the TX2EHSMHS017.bigfish.com – as the local Exchange 2010 hybrid server will try to get the message(s) delivered:

Outbound to Office 365,08CEBBEB07152FBC,0,,65.55.88.22:25,*,,attempting to connect 
Outbound to Office 365,08CEBBEB07152FBC,1,192.168.1.11:51841,65.55.88.22:25,+,, 
Outbound to Office 365,08CEBBEB07152FBC,2,192.168.1.11:51841,65.55.88.22:25,<,220 **********************************************************************************************, 
Outbound to Office 365,08CEBBEB07152FBC,3,192.168.1.11:51841,65.55.88.22:25,>,EHLO mail.contoso.com, 
Outbound to Office 365,08CEBBEB07152FBC,4,192.168.1.11:51841,65.55.88.22:25,<,250-TX2EHSMHS017.bigfish.com Hello [92.70.102.115], 
Outbound to Office 365,08CEBBEB07152FBC,5,192.168.1.11:51841,65.55.88.22:25,<,250-SIZE 157286400, 
Outbound to Office 365,08CEBBEB07152FBC,6,192.168.1.11:51841,65.55.88.22:25,<,250-PIPELINING, 
Outbound to Office 365,08CEBBEB07152FBC,7,192.168.1.11:51841,65.55.88.22:25,<,250-ENHANCEDSTATUSCODES, 
Outbound to Office 365,08CEBBEB07152FBC,8,192.168.1.11:51841,65.55.88.22:25,<,250-XXXXXXXA, 
Outbound to Office 365,08CEBBEB07152FBC,9,192.168.1.11:51841,65.55.88.22:25,<,250-AUTH, 
Outbound to Office 365,08CEBBEB07152FBC,10,192.168.1.11:51841,65.55.88.22:25,<,250-8BITMIME, 
Outbound to Office 365,08CEBBEB07152FBC,11,192.168.1.11:51841,65.55.88.22:25,<,250-BINARYMIME, 
Outbound to Office 365,08CEBBEB07152FBC,12,192.168.1.11:51841,65.55.88.22:25,<,250 XXXXXXXB, 
Outbound to Office 365,08CEBBEB07152FBC,13,192.168.1.11:51841,65.55.88.22:25,*,,Connector is configured to send mail only over TLS connections and remote doesn't support TLS 
Outbound to Office 365,08CEBBEB07152FBC,14,192.168.1.11:51841,65.55.88.22:25,>,QUIT,

As you can notice in this example, the SMTP banner has been turned into stars and AUTH and STARTTLS have been changed by the appliance into XXXXXXXA and XXXXXXXB. This behavior is typical of Cisco’s Mailguard feature; other smtp obfuscating appliances might result in different output. Key indicator is, expected elements are missing or garbled.

In such cases, you need to make sure SMTP traffic between on-premise and Office 365 goes through unfiltered. Depending on the capabilities of the device, you could allow the FOPE addresses to go through unfiltered. If that’s not an option, or you don’t like managing that address set, you need to disable the feature completely.

Note that Cisco is not the only vendor offering SMTP obfuscating products; companies like Checkpoint, Barracuda, Sonicwall or Symantec offer products with the feature mentioned above.

Federation Information could not be received ..


When setting up federation between Exchange organization using the Hybrid Configuration Wizard, to connect your on-premise Exchange environment with Office 365, you may encounter an error message in the 2nd step of the Hybrid Configuration Wizard, Update-HybridConfiguration:

image

When inspecting the Update-HybridConfiguration results, it reads:

Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships.
Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.
Federation information could not be received from the external organization.
..

The problem lies in the sentence “Federation Information could not be received from external organization”. To see where it goes wrong, you could run Set-HybridConfiguration and Update-HybridConfiguration manually, using additional parameters as shown in the result screen, providing proper credentials and additionally addint the Verbose parameter to increase output logged.

Most of the time this problem comes down to one of the following issues, which can be verified by running the following cmdlet, where example.com is to be replaced by the federated domain:

Get-FederationInformation example.com –Verbose

You’ll probably see the cmdlet going trough the discovery motions using autodiscover, ending up in the same “Federation information could not be received from the external organization” message. When analyzing this output, you’ll see it contains two hints on the potential issues:

Get-FederationInformation : The discovery process returned the following results:
Type=Failure;Url=https://autodiscover.example.com/autodiscover/autodiscover.svc;Exception=Discovery for domain example.com failed.; …

1. Autodiscover
The first issue often overlooked is internal autodiscover not working via DNS or not being set up properly, i.e. split DNS configurations. Some customers don’t configure internal DNS autodiscover records or don’t allow (internal) autodiscover to go through the proxy from inside.

Normally, when using regular clients like Outlook, this isn’t an issue because domain joined clients will be using SCP records from AD. However, federation will use DNS records so you need allow it or set it up in DNS; a CNAME for autodiscover.example.com as well as autodiscover.service.example.com pointing to your hybrid server will suffice.

Also make sure you enable WSSecurity authentication for autodiscover on your hybrid server using:

Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication $true

2. Proxy rules
In the error message you’ll notice a autodiscover-related request going to /autodiscover/autodiscover.svc. These requests are normally caught by the autodiscover rule (path /autodiscover/*) in ISA or TMG. Issue is, these service requests require unauthenticated traffic. When you turn on logging in TMG, you’ll notice the requests for /autodiscover/autodiscover.svc will be denied.

To solve this issue, and to get federation working, you need to set up an additional ISA/TMG rule pointing to the hybrid server, using the proper public names (don’t forget autodiscover), bound to the OWA listener. You need to allow All Users (as opposed to Authenticated Users), set authentication to “No Authentication, but users can authenticate directly” and configure the following paths:

  • /EWS/Exchange.asmx/wssecurity
  • /Autodiscover/Autodiscover.svc
  • /Autodiscover/Autodiscover.svc/wssecurity

After configuring the rule, you need to put it above all the other Exchange rules, making it the first matching rule when federation traffic hits ISA/TMG.

After applying the rule changes, Get-FederationInfo example.com should work and you can continue with the Hybrid Configuration.

For more information on setting up co-existence, consult the steps provided by the Exchange Deployment Assistent.