Friday, November 21, 2014

Missing Email Attachment

A few weeks ago, a client reported that when sending to a list of email addresses, one of the recipients was not getting the attachment. The recipient got the email message, but not the attachment. So, then you start to work it through logically:
  • Others get the attachment, so, it must not be on our end.
  • Send a test message from a non-client account and the attachment goes through, so, it must be on our end.
  • Apparently it's nobody's fault.
Of course it's always someone's fault, and it this case, I'm blaming Outlook. This turned out to be a new problem I've never seen with rich text formatting (RTF).

I'm sure that everyone that supports Outlook has at one time or another run into the winmail.dat attachment problem when Outlook sends RTF formatted email to a client that doesn't understand it. In this case, the client receiving the email partially understood RTF. It understood it enough to get the text message out, but not the attachment. The whole message was being delivered, but the client software dropped the attachment.

Outlook allows you to define on a per contact basis what formatting will be used when sending a message to a recipient. I'm yet to find a user that sets this on purpose, but in this case, it was accidentally set for RTF.

Rather than trying to fix this at the Outlook level and to ensure that it never happens again, I've disable RTF at the Exchange server level. If the client sends an RTF formatted message, Exchange will change it to HTML which is much more widely supported.

In Exchange Server, you can set how RTF format is used per domain. By default, there is a single domain in Organization Configuration > Hub Transport > Remote Domains, named Default. On the Message Format tab for this domain, under Exchange rich-text format, select Never Use. After doing this attachments were delivered correctly.

Properties of Default Remote Domain

Thursday, November 20, 2014

Free Office 365 and Windows Azure Exam Vouchers

Check it out:

Monday, November 17, 2014

Disable Inbound Proxy Probe Messages for Journaling

During a recent Exchange 2007 to Exchange 2013 migration, we ran into an issue with Managed Availability in Exchange 2013. Managed Availability provides health monitoring services.

This particular client is performing journaling by enabling journaling on each database and configuring all messages to be sent to a journaling mailbox in a separate database. They then have archiving software that removes the messages from the journaling mailbox. This allows them to retain a copy of all messages sent or received in the organization.

As we implemented Exchange 2013, the journaling mailbox was filled with messages generated by Managed Availability. The messages were from with a subject of Inbound proxy probe to a health mailbox.

Managed Availability was sending messages through the transport system to health mailboxes to verify that the system was functioning normally. However, this was resulting in a lot of messages that were not required being journaled. To avoid this, there are two options:
  1. Use a Journaling rule for specific users or group membership instead.
  2. Disable some monitors in Managed Availability.
I'm always reluctant to disable basic functionality in the system. So, our first attempt was by using a journaling rule with a dynamic distribution group for all users. When we did this we found that it was not reliably journaling the messages. So, we abandoned the journaling rule option and chose to disable the monitors generating the email messages instead.

In a knowledgebase article, Microsoft provides the following three commands for disabling the messages:
Add-GlobalMonitoringOverride -Identity "FrontendTransport\OnPremisesSmtpClientSubmission" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.620.29" -ItemType Probe
Add-GlobalMonitoringOverride -Identity "MailboxTransport\Mapi.Submit.Probe" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.620.29" -ItemType Probe
Add-GlobalMonitoringOverride -Identity "FrontendTransport\OnPremisesInboundProxy" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.620.29" -ItemType Probe
In these commands, you must provide the -ApplyVersion parameter which specifies which version of Exchange Server that the override applies to. When you apply new updates to your system, you must run these commands again.

To identify the version of Exchange you are running, you can use the following command:
Get-ExchangeServer | FL Name,AdminDisplayVersion
The Microsoft documentation does not talk about it, but unless you have a single database, you have more than one OnPremisesInboundProxy monitor. There is an OnPremisesInboundProxy monitor for each database and is unique for the health mailbox associated with each database and you need create an override for each one. On this system with four mailbox databases, the identity of each monitor was:
  • FrontendTransport\OnPremisesInboundProxy
  • FrontendTransport\OnPremisesInboundProxy_2
  • FrontendTransport\OnPremisesInboundProxy_3
  • FrontendTransport\OnPremisesInboundProxy_4
To identify all of the OnPremisesInboundProxy monitors on your system, you can use the following command:
(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/ProbeDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "OnPremisesInboundProxy*"}
After creating an override for each instance of OnPremisesInboundProxy, all of the Inbound Proxy Probe messages were disabled.

To ensure that the monitoring overrides take effect, you need to restart the Microsoft Exchange Diagnostics and Microsoft Exchange Health Manager services on all Exchange 2013 servers.

Additional resources:

iDRAC7 - No Mouse or Keyboard

We recently had an emergency issue with a client system and had issues with the iDRAC7 remote control features. We put iDRAC cards in all of our servers for exactly this scenario where there is an unknown issue and we might need to power cycle the system.

We were able to log into the iDRAC7 web console with no issues. However, on the summary screen it was not showing status for the power supplies. Also, if I tried to browse the disk status, it was indicating the no disks or controllers could be seen.

Fortunately, the fix was pretty easy. Just restart the iDRAC card. To do this, on the Summary screen, in the Quick Launch Tasks, click Reset iDRAC as shown below. This does not reset the configuration of the iDRAC, it just restarts the card.

Wednesday, November 5, 2014

Require Encryption for a Specific Email Domain

You might not realize it, but your Exchange server is probably already encrypting messages sent and received from the Internet. By default, Exchange uses opportunistic TLS. This means that it offers TLS for inbound messages, but does not require it. Exchange also tries to use TLS for outbound messages, but does not require it.

We have one client that works with an insurance company. In order to ensure that data is secure, they request that their customers force the use TLS instead of relying on opportunistic TLS. This is more secure because the messages will wait in the queue if TLS cannot be established.

To use TLS for inbound messages, you need to have a valid certificate installed on your Exchange server and have assigned the SMTP service to that certificate. That certificate needs to include the name that external servers use to reach your server, such as As long as Transport Layer Security is enabled as an authentication mechanism on the Receive connector, opportunistic TLS is used for inbound messages.

You do not need to do anything to use TLS for outbound messages. TLS for outbound message relies on the certificate of the recipient server. However, you can enforce the use of TLS for specific domains by creating a send connector for those domains. Then after the send connector is created, you can use the Exchange Management Shell (EMS) to for TLS for that send connector by using the following command:
Set-SendConnector TLSConnector -RequireTLS $True
You can also force TLS for a receive connector, however, those are based on IP address. If the sender changes the IP address, then TLS will not longer be required. So, in most cases opportunistic TLS is a better choice for inbound messages.

Note: If you have another proxying device like an antispam appliance between Exchange and the Internet then you need to setup encryption on that device rather than your Exchange server. 

Monday, October 27, 2014

Exclaimer Attaching Logo Instead of Showing Inline

We have a client that wants a very specific email signature attached all outbound email messages. They are a fairly small client with about 20 users. So, manually configuring Outlook worked for them. Where it fell apart was all the mobile devices that they use. They have both iPhones and iPads for various users.

By default iPhones and iPads don't sent HTML email. And there is no built-in method for creating messages with graphics such a logos in the signature. I did have some success copying an HTML signature from an existing email and pasting it into the signature for an iPhone, but the results were inconsistent. Some devices properly sent the signature with the logo and other didn't. Even more frustrating, sometimes it started working fine and then stopped.

The solution is to implement Exclaimer Signature Manager for Exchange ( on the Exchange server. Exclaimer manages the signature at the server level instead of at the device level. So, we don't need to worry about the type of device. It can also convert existing messages to HTML to allow the graphic logo to be embedded.

The Exclaimer software is very simple to install (almost too easy). The editing of signatures is quite intuitive and pretty easy to customize. However, I ran into problems when I was testing it.

I created a template that included the logo and applied it messages only for the Administrator account. When I sent messages, the logo appears as an attachment rather than inline in the text as it should. It looked like this:

When I was searching around, the only references I could find to logos not appearing properly suggested that it was because there were incorrect permissions for the the logo file. Network Service needs Read access to the logo. This didn't seem to apply here because the logo was being read, it just wasn't embedded properly. However, even when I gave Everyone Full permissions to the logo file, there was not fix. I also tried restarting services and disabling the antispam software running on that server. All with no fix.

If you look at the source html in the message, it does refer to the logo file with the following code, but can't seem to find it:
Fortunately, Exclaimer support was pretty quick to help me out. This server has a disclaimer configured in the hub transport rules. After disabling the disclaimer in the hub transport rules the logo was properly embedded. So, there must be an issue when both Exchange and Exclaimer try to manipulate the HTML content in the message.

Wednesday, October 22, 2014

Kill and Restart Hung Services by Using PowerShell

We have a client with a misbehaving service. An older version of Tomcat that runs a web application. The Tomcat service tries to restart itself at 1am each night but as often than not, it ends up hanging in the stopping phase. At this point, I manually kill the process and start the service.

After going through this process for a while, I figured we better script this and make it a scheduled task. Here is the script:
$tom = Get-Process tomcat6
Stop-Process $
Start-Sleep -s 5
Start-Service tomcat6
The script loads the process tomcat6 into the variable $tom. Then it stops the process based on the process id of $tom. If you try to pass the entire process object it fails.

Then the script pauses for 5 seconds and starts the tomcat6 service. I found that if I didn't have a pause between killing the process and starting the service, the service wouldn't start. I'm assuming this is because the process is not stopped entirely before it gets to starting the service. Putting in the pause ensures that the process is complete stopped before starting the service.

When setting up a PowerShell script as a scheduled task, you use the following options:
  • Start a program
  • Program/script: powershell
  • Add arguments: .\nameofscript.ps1
  • Start in: C:\scriptfolder