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

Tuesday, October 21, 2014

Extension Custom Attributes for Dynamic Distribution Lists in Office 365

I was browsing an online forum recently and saw someone with an issue creating dynamic distribution groups in Office 365. The mailing lists were based on the Office property. However, to accommodate users that work out of multiple locations the poster was trying to put a comma separated list in the Office property. Then for the distribution group the poster wanted to do a recipient filter including something like:
Office -like '*location1*'
This syntax works properly for on-premises Exchange but won't on Office 365. I assume that it is because Office 365 is trying to limit the load these queries place on the infrastructure.

In Office 365, you can't start your query with a wildcard. So, you can search for 'location*' but this only returns true if the value is at the start of the string.

The second bright idea I had was to fake it out and put a dummy value first. The I could use two wildcards to get the same effect. So, the query would be for 'X*location1*' but this didn't work either. There was no error for this one, but it never returned true. I suspect that the query is just tossed in the background.

Then I found out about some new attributes that were added starting with Exchange 2010 SP2 and are also in Exchange 2013/Office 365:
  • ExtensionCustomAttribute1
  • ExtensionCustomAttribute2
  • ExtensionCustomAttribute3
  • ExtensionCustomAttribute4
  • ExtensionCustomAttribute5
These 5 attributes are not the same as the 15 CustomAttributes that have in Exchange Server for many versions. The CustomAttributeX properties are a single text string. The ExtensionCustomAttributeX properties are an array. This means that they can store multiple values that can be properly queried for a dynamic distribution group.

You can set multiple values for an extension custom attribute as follows:
Set-Mailbox Byron -ExtensionCustomAttribute1 London,Paris,Montreal

If you need to add or remove individual items to the attribute for a user, you can use the following syntax:
Set-Mailbox Byron -ExtensionCustomAttribute1 @{Add="Vancouver"; Remove "London"}

Creating the dynamic distribution list for recipients with Vancouver as an item in ExtensionCustomAttribute1 would be as follows:
New-DynamicDistributionGroup VancouverList -RecipientFilter {ExtensionCustomAttribute1 -eq "Vancouver"}
A final quirk about ExtensionCustomAttributeX and Dirsync. When you use Dirsync (Windows Azure Active Directory Synchronization), it will appear that ExtensionCustomAttributeX is syncing up to Office 365. However, it will never appear in the properties of the users. Somewhere in the background Windows Azure AD or Exchange Online discards the value. This is a known issue.

Monitor the following forum posts to see if there is any change:

Sunday, October 12, 2014

Change UPN After Rename with Dirsync

It's pretty common to rename user accounts in your organization. This is typically done when a person gets married. In a large organization, this happens fairly often. If you are syncing with Office 365, you want to change the user id there also. Unfortunately, this is a manual process. Let me explain....

Let's say that I have a user with the UPN of in my organization. When I first run Dirsync, this UPN is synchronized in Azure AD and Office 365. I can not use this UPN for authenticating to both on-premises services and Office 365.

Several months later I meet the lady of my dreams and get married. Now I change the on-premises information including the UPN. So, my new UPN on-premises is The updated last name, display name, and UPN show as synchronized when I view the logs in DirSync. However, in Office 365, the new UPN never appears. In Office 365, I still need to authenticate as the original UPN of

While this behaviour is surprising the first time you run into it, it is normal. The domain for your UPN can be updated by using DirSync, but not the username portion. Instead, to update the UPN, you need to do a remote connection to Office 365 and run the following command:

Set-MsolUserPrincipalName –UserPrincipalName oldUPN –NewUserPrincipalName newUPN
In my example the command would be:
Set-MsolUserPrincipalName –UserPrincipalName –NewUserPrincipalName
UPDATE: This information is no longer accurate. I'm not sure when it changed, but during a migration yesterday for a client and a test I performed today (March 21/15) the username is now properly updated by DirSync. You should not need to run Set-MsolUserPrincipalName when using Dirsync.

UPDATE: And on a project today (June 23/15) we had issues with UPN sync and needed to use Set-MsolUserPrincipalName. Not sure if MS changed something or whether I was out of my mind previously.

Friday, October 10, 2014

Exclude Resource Mailboxes from Address Lists and Dynamic Distribution Groups

In Exchange 2010 when you generate an address list or dynamic distribution group containing Users with Exchange mailboxes this includes room and equipment mailboxes. If you want to exclude resource mailboxes, you'll need to use PowerShell to set the recipient filter.

Here is a command that creates an address list for users with Exchange mailboxes, which includes resource mailboxes:
New-AddressList "MailboxUsers" -RecipientFilter {(RecipientType -eq 'UserMailbox')}

Here is a command that creates an address list for user with Exchange mailboxes, but excludes resource mailboxes:
New-AddressList "MailboxUsersNoRooms" -RecipientFilter {(RecipientType –eq ‘UserMailbox’) –and (-not(ResourceMetaData –like ‘ResourceType:*’))}

There is an oPath filterable property named IsResource however, I couldn't use that for address lists because there is no LDAP equivalent and the cmdlet errored out.

Thursday, October 9, 2014

Find Stale Computer Accounts in Active Directory

The simplest way to find old unused computer accounts is by using a PowerShell query. You can use Get-ADComputer to do the query. In smaller environments, you can do a simple query for all computer accounts sorted by LastLogonDate. This query puts the oldest logon dates at the top:
Get-ADComputer -Filter * -Properties LastLogonDate | Sort-Object LastLogonDate | Format-Table Name,LastLogonDate
The -Filter parameter is required, by using an asterisk, you are querying for all computer accounts. You need to use the -Properties parameter because the Get-ADComputer cmdlet doesn't query for all computer account properties by default. So, you can use the -Properties parameter to specify that LastLogonDate should be retrieved.

Be aware that servers will be included in this list and that LastLogonDate is not entirely accurate when identifying whether servers are in use. For example, I just did a query for a client with an active application server that shows the LastLogonDate as being three months ago. However, I know for sure that clients are actively using the application on that server.

The idle time for computers in your organization may vary. So, for desktop computers 3 months or so is probably a good guideline for identifying unused computer accounts.

In a larger environment you don't want to see all of the computer accounts listed by your query. Instead you want to see only the accounts that you may be concerned about that haven't logged on for a certain timeframe. The command below queries only computer accounts that have not logged on for 90 days.

Get-ADComputer -Filter * -Properties LastLogonDate | Where-Object {$_.LastLogonDate -lt (Get-Date).AddDays(-90)} | Sort-Object LastLogonDate | Format-Table Name,LastLogonDate

Wednesday, October 8, 2014

Port 25 Blocked for Specific Domains

This was such a strange issue that I don't know if this post will ever help anyone. I just need to write it for therapy......

Starting on Friday of last week, I got reports from one client that some emails were not being delivered. This has happened to clients in the past when they were on block lists. So, my first step was to check some block list tools to see what's up. Each of the block list tools indicated that the IP was not being blocked.

Some of the antispam appliances have block lists that are not checked by the typical web sites. So, I tried to dig into it a bit further. One of the sites that was being blocked is a local university and I know several of the server/email admins there. So, emailed, explaining that I figured it was an antispam issue. They sent me the site to check block list for their appliance and it came up clean. In fact, they said my request for delivery wasn't showing up in the logs at all.

I should also note that access to ports other than 25 was unaffected. You could do ping the IP of the mail servers and connect to websites on that IP if a website was there. Only port 25 connectivity was blocked.

One of the things I had tried to do was use Putty (a free telnet client) to telnet to some of the failing email servers. Often the email server provides a message that indicates which antispam product is being used so that you can investigate why you're being blocked. In this case, each of the attempts to connect ended with a dropped connection.

Of course my other concern is that the firewall has gone nuts and is blocking things that it shouldn't. So, I did some logging and testing of rules. Nope, didn't look like the firewall was blocking anything.

As the suggestion of the admin at the university, I called the ISP. The admin at the university indicated that they had a call from someone else on Bell that couldn't deliver to them also. Weird....

So, next step is call the ISP. In the past my experience with ISPs and tech support has been rather poor overall. In this case Bell was great, they took the info and began investigating. They didn't blame my configuration. They also came back and indicated that it was their connectivity through Shaw that was the issue. So, anything being delivered to Shaw or routed through the Shaw network was affected.

It took about 5 days for Bell to convince Shaw that the issue was on their network, but the problem is now resolved. My best guess is that Shaw was marking the traffic from Bell like they do consumer Internet tracking and blocking port 25.

Need to Find Your Android Device?

This web page allows you log on with your Google account (which was required when getting the device online) and shows the location of your device. You can wipe it if you lost it. You can also ring it to find it in your house.
The hard part is remembering the credentials for your Google account if you don't use it very often.

Monday, October 6, 2014

Script to Resolve Error When Running Enable-RemoteMailbox

If you have existing user accounts in your hybrid environment, and want create a mailbox in Office 365 for those users, you can use the Enable-RemoteMailbox cmdlet. However, when you try to use Enable-RemoteMailbox you commonly get the following error:

The address '' is invalid: "" isn't a valid SMTP address. The domain name can't contain spaces and it has to have a prefix and a suffix, such as
This error occurs because the cmdlet is not building the RemoteRoutingAddress properly. This address is used for routing messages to the Office 365. So, we need to create that RemoteRoutingAddress property as part of a piped command or script.

I've seen several examples using piped commands, but I prefer a script because I find it easier to follow the logic. Here is the script I used recently:
$users = get-user -OrganizationalUnit "OU=xx,DC=domain,DC=com" -RecipientTypeDetails User 
foreach ($u in $users) {
   $alias = $u.FirstName + "." + $u.LastName
   $RR= $alias + ""
   Enable-RemoteMailbox -identity $u -RemoteRoutingAddress $RR
This script obtains a list of users without mailboxes from a specific OU. Then it loops through that list of users, takes user properties to build the remote routing address in the variable $RR. Finally it enables the remote mailbox for each user.

When you use the Enable-RemoteMailbox cmdlet, it also automatically adds that remote routing address as an email address for the account. Which is of course required for Office 365 to accept the mail.

Friday, October 3, 2014

Exchange Hybrid Mode and Dynamic Distribution Groups

Exchange Online/Office 365 does not have dynamic distribution groups. So, in a hybrid deployment, it's not possible to synchronize dynamic distribution groups from on-premises to Office 365. There are two work arounds:

Option 1
If you like scripting, you can create a script that updates the membership of a normal distribution group. You'll need to run the script as a scheduled task. The main benefit to this method is that it is contained entirely within the on-premises environment.

There are two drawbacks to this method:
  1. It's not actually dynamic, so there is a lag time from when new members are created and when they're added to the group.
  2. It's relatively complex to create the script and schedule a powershell script to run as a task with the correct snap-ins loaded.
Option 2
My preferred option for this is to create a contact in Office 365 that points at the dynamic distribution group on-premises. This allows you to continue using true dynamic distribution groups on your on-premises environment and give Office 365 users the ability to send messages to them.

When you create the dynamic distribution group you need to select the following recipient types:
  • Users with Exchange Mailboxes. These are your on premises users.
  • Users with external e-mail addresses. These are your office 365 users.
After you create the dynamic distribution group, collect the following information from it:
  • Display Name
  • Alias
  • Email address (not the address)
Now use the Office 365 admin console to create a mail contact (do not create on-premises contact and sync it) with the following attributes:
  • Display Name: same as dynamic distribution group
  • Alias: same as dynamic distribution group
  • External email address: same as email address from dynamic distribution group
From a management perspective, this is a bit of a pain because you need to remember to manually create an extra contact in Office 365. However, I still think this is the easiest way to get it going.

You can't create the contact locally and sync it for two reasons:
  1. You can duplicate the same display name on two objects. So, you'll end up with two objects using the same display name. This will be confusing for on-premises users who will see both objects.
  2. You can't duplicate the external email address for a contact with the actual email address for the dynamic distribution group. This makes it not just a bad idea, but a technical impossibility.

Exchange Online Limits

When you implement Office 365, you are using Exchange Online for email. Exchange Online is regularly changing the limits that apply for things like the size of the mailbox and attachment sizes. This web page is maintained with the up to date information on limits for Exchange Online: