Office 365 Welcome Message

I’ve known about Microsoft FastTrack for some time but not really taken advantage of the resources it offers. One of the resources are pre-created end-user communications, like posters and email messages, letting the users know about the upcoming Office 365 project.

So, in my current project I thought that I would be an improved consultant and make use of the Office 365 Welcome Message that can be found on the FastTrack website located at http://fasttrack.microsoft.com In the ribbon go to Office 365 > Drive Value > Engage. You’ll find the email template at the link ‘Announcement template’

One thing I found strange at first, was that the email template was in Microsoft Word format, not an .eml format targeted for Outlook. That got me thinking about a feature I have seen other people make use of, called merged documents. Obviously there must be a way to create an email template and have Outlook populate individual data so you can mass email the migrated users and inform them of the username and password without having to manually create 2000 email messages. And as it turns out, there is, but it’s not Outlook but rather Word that makes this magic happen.

What you need:

• An Excel spreadsheet containing the values you want Word to populate
• A Word template (if you don’t want to create one yourself)
• Outlook to send the messages out. (Tip! Remember to create an Outlook-profile pointing to the Shared Mailbox you want the email message to come from as the sender.)

If we start with the Excel spreadsheet, mine is as simple as the one below. It’s important to have row 1 containing column headers. You can name these to your liking. Remember that you will reference the names in the Word document as anchor points for the data merged from the Excel document.

Save the file as a regular .xlsx workbook. Then, go into Word and open the email message template and go to ‘Mailings’ and ‘Start Mail Merge’ as seen below.

Now a new Mail Merge menu appears to the right. Select ‘E-mail messages’ and then ‘Next’ at the bottom of the menu.

In Step 2, choose ‘Use the current document’

In Step 3, choose ‘Use an existing list’ and select your Excel document created earlier. After pointing out your Excel spreadsheet, you get two dialog boxes:

Just hit ‘OK’

You have the option to alter your list here if you want to, but for now, just click ‘OK’ and in the Mail Merge menu to the right, click ‘Next.

Now it’s time to customize our email message to our liking. First thing is to remove the top notification to avoid any embarassment.

In the main section, I’d like to change these three places to merge personal data from the Excel document.

We accomplish this by going to ‘Insert Merge Field’ and choosing the correct column value. (see why row 1 should be column headers?!)

It should look something like this when you are done

When you are finished customizing, in the Mail Merge menu to the right, click ‘Next’

Now you have the chance to preview how your e-mail message will look like. Just jo back in the wizard if you’re not happy with something. When you are sure you have it the way you want it, go to Step 6 ‘Complete the merge’. You are finished! But wait, there is no e-mail being sent out? Did I miss something? Yes, you need to perform one last step to initiate the sending of the email message. Back to the ribbon and Mailings tab and click

And fill in the last things

And your users will get this butiful email message welcoming them to Office 365.

Now you might think; Well, that’s just fine and dandy for all English speaking countries, but then you are mistaken. If you go to the bottom of the FastTrack page, you can change the language to match yours, and best of all, the content language changes as well. So now you can download the email message template in your own language. Sweet!

An exception ocurred while setting shared config DC

So there I was, embarking on a new project to move a customer to Office 365 and Exchange Online. Thinking that I could jump start things with the simple task to install Exchange 2013 CU15 to act as a hybrid server (yes, I know, there is no such role but you know what I mean). Kicking off setup.exe expecting nothing special … BANG! Red, error, setup failed! Whaaaat??!!

The error message was “An exception ocurred while setting shared config DC”. Huh? What does that mean? Google to the rescue. Most blog post seemed to indicate issues with disabled IPv6 but I never disable IPv6 so this wasn’t my issue. Googling along. Found  some tech forum replies talking about strange behaviour with Exchange AD Topology Service and the proccess of locating/selecting Domain Controllers. Found a KB-article from Microsoft providing information and a workaround: Exchange 2013 CU6 and later uses out-of-site domain controllers and global catalog servers I tried this, but to no avail. This wasn’t my issue either. Now what?

I kept on googling and reading through a lot of TechNet forum posts. After an hour or so, I stumbled upon this reply here: https://social.technet.microsoft.com/Forums/office/en-US/bb08b38e-a0b5-436d-83ac-a76d7960d87c/exchange-2013-sp1-installation-fails-at-transport-service-97?forum=exchangesvrdeploy

I got to Microsoft Support and here’s what we found:

During the AD Prep stage one of the permissions that is set in the default domain controllers group policy was not transferred to the custom domain controllers policy.  Support found a plethora of Event 2112 in Windows Event Viewer that pointed to the permission.  Fixed that and Exchange installed just fine.

Going into Event Viewer > Application Log and sure enough …

Opening the Group Policy Management console and looking at the Domain Controllers node, I found this:

Interesting. Maybe we’re onto something here … Comparing the two GPOs revealed one crucial difference:

Specifically the User Right called “Manage auditing and security log” was missing the security group called “<domain>\Exchange Servers” on the custom GPO with Link Order 1, thus taking precedence over the regular “Default Domain Controller Policy” that actually had this user right assingment set.

Solution: Added the group “<domain>\Exchange Servers” to the user right assignment “Manage auditing and security log” on the custom GPO with the higher Link Order (precedence) and Exchange installed just fine after performing GPUpdate on the Domain Controllers.

 

Dynamic Distribution Groups in Exchange Hybrid environments

Using Dynamic Distribution Groups (DDG’s for short) in a Hybrid environment poses a certain challenge. First of all, these DDG’s do NOT sync with Azure AD Connect. Second, you have to base your filters on synced attributes and not local OU structure. And lastly you need to provide a mail-contact on the opposite side of the DDG. Yes, you need to decide where you place the DDG’s (on-premises or Exchange Online) and then provide the other side with a mail-contact, pointing to the DDG, for address book lookups. For my post I’ll put my DDG’s in Exchange Online and hence create mail-contacts for each DDG in my on-premises Exchange environment for easy GAL lookups.

In this example I’ll create DDG’s that filter on 3 custom attributes;

• CustomAttribute3
  (Account type: F (Full-Time Employee), C (External Consultant))
• CustomAttribute6
  (If any text – exclude from DDG)
• CustomAttribute11
  (Department: HR, IT, Dev)

By using any combination of these attributes we can have great flexibillity in filtering recipients in our DDG’s. One often asked function is an easy way of excluding a specific recipient for a limited time. Often used when sending to ‘All Company Employees’ asking for chipping in to a birthday gift for a colleague. In or DDG’s we only need to put any text into field 6 and that person is excluded from the email list as by magic. Just don’t forget to await Azure AD Sync to complete a sync cycle (happens every 30 minutes) or force a manual sync with “Start-ADSyncSyncCycle delta“.

Since we are creating a custom query for our DDG’s we need to make use of Powershell, remotely connect to Exchange Online. After we are connected, issue the command:

New-DynamicDistributionGroup -Name “Mail Group IT” -Alias “mail_group_it” -RecipientFilter {((RecipientType -eq ‘UserMailbox’ -or RecipientType -eq ‘MailUser’) -and ((CustomAttribute6 -notlike “*” -and CustomAttribute11 -eq ‘IT’ -and (CustomAttribute3 -eq ‘F’ -or CustomAttribute3 -eq ‘C’))))} -PrimarySmtpAddress “mail_group_it@aureance1.mail.onmicrosoft.com”

In the above command we create a Dynamic Distribution Group, DDG, called Mail Group IT the contains both Full-Time Employees and external consultants. To preview the recipient filter, we need to run:

1. $ddg = Get-DynamicDistributionGroup -Identity “Mail Group IT”
2. Get-Recipient -RecipientPreviewFilter $ddg.RecipientFilter

All that’s left for us to make this complete is to add a mail-contact in our on-premises environment so that our on-premise users can find our DDG in the Global Address Book, GAL. This command needs to be performed in Exchange Management Shell to hit your local Exchange environment.

New-MailContact -Name “Mail Group IT” -OrganizationalUnit “corp.azureance.com/users” -ExternalEmailAddress “mail_group_it@azureance.mail.onmicrosoft.com”

One important thing to consider is to place the contact in a OU that isn’t being synchronized to Azure Active Directory. Otherwise you’ll get duplicate entries for the Exchange Online users, both the real DDG and the pointer contact, which is confusing. Simply don’t synchronize it to keep things clean.

One last thing to comment is why we make use of @azureance.mail.onmicrosoft.com as Primary SMTP Address and External Email Address. The SMTP name space <tenant>.mail.onmicrosoft.com (azureance is my tenant name) is called the routing address in an Exchange Hybrid configuration. It’s the glue between Exchange Online and Exchange on-premises mail objects. It is also the address that gets specified in the auto generated SMTP Send Connector called “Outbound to Office 365”. This connector makes it so that all email addressed or routed to that name space it authenticated and encrypted between both environments, making it both secure but also marked as internal. You can verify this by looking at the email header, specifically X-MS-Exchange-Organization-AuthAs: Internal. This is the correct way of linking objects between the two environments.

Improve security in Azure AD Connect

A little known fact about running Azure AD Connect is that is defaults to a weaker than necessary TLS version (version 1.0). Or rather, the host OS Windows Server 2012 (incl R2) does. It perhaps isn’t the end of life as we know it but it’s unnecessary since both Azure AD and Windows Server 2012 (R2) has it enabled and is ready for us to make use of. All we have to do is to force Windows to always use it.

Using Wireshark to see what the default behavior is (192.168.1.205) is my Azure AD Connect Server and 104.44.254.138 is Microsoft Azure. We clearly see that Client Hello (our server) is asking for TLSv1.

The much needed registry key, that enables us to force Windows Server to always use TLS 1.2 is “SchUseStrongCrypto”=dword:00000001 as documented here: Prerequisites for Azure AD Connect (scroll down to the section titled Enable TLS 1.2 for Azure AD Connect. The key (DWORD) goes into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

Reboot the Azure AD Connect server and let’s have another look:

YEY!!

Enable Manage Out in DirectAccess

What is DirectAccess Manage Out and what’s all the fuzz about? Well to begin with, Manage Out is the concept of managing remote DirectAccess connected computers from an internal computer. When implementing DirectAccess for the first time it’s easy to believe that if remote computers can connect to inside computers/servers then inside computers/servers must be able to reach DirectAccess connected clients right? Nope, it’s not that easy unfortunately. Why is that? It’s because of the mechanism that makes the magic behind DirectAccess work and its limitations. As I guess you know, DirectAccess is a strict IPv6 technology and since almost none of us has implemented IPv6 in our corporate networks yet, we need some sort of magic glue between IPv6 and IPv4. Enter IPv6 protocol translation. Two of those protocols that are making DirectAccess IPv6 clients able to talk to internal IPv4-only resources are NAT64 (RfC:6146) & DNS64 (RfC:6147). Before I bore you to death, my point is that these translators only work one-way; from IPv6 to IPv4, not the other way around, which is what we try to do when connecting from an internal IPv4 computer to our IPv6 connected DirectAccess computers. We need more magic glue. Enter ISATAP (RfC:5214)!

Okay, so now we know what we want and why we need it, but how to implement it then? There are some things to consider when thinking about making use of ISATAP. First of all is that it’s not really made for production networks. At least not large networks, according to this article https://technet.microsoft.com/en-us/library/dn464274.aspx#bkmk_isa by Microsoft. In it, Microsoft says “If ISATAP is deployed in a multisite, load balancing, or multidomain environment, you must remove it or move it to a native IPv6 deployment before you configure DirectAccess.“ For most of us, that’s a pretty tall order. If you’ve never dealt with IPv6 before just looking at the IPv6 addresses is scary enough. But keep calm. We have options. Option 1 is to manually set an IPv6 address on one or more management computers (instead of the whole network) and go native IPv6 in a minimized fashion. The process of how to go about that route is described in this article http://blogs.technet.com/b/jasonjones/archive/2013/04/02/windows-server-2012-directaccess-manage-out-using-native-ipv6.aspx by the brilliant Jason Jones. It’s possible I guess but my fear of taking that specific path is the question if your network is capable of routing IPv6 packets. Is it? I don´t know?!

So I’m going with Option 2 which is implementing a mini ISATAP network on top of the regular old IPv4 network. Once again Jason Jones comes to the rescue; http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html It’s written with Microsoft UAG in mind but the DirectAccess in UAG is more or less the same as in Windows Server 2012/R2 so it’s applicable. One final pre-reading tip is Deb Shinders excellent article about how ISATAP work; http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Configuring-ISATAP-Router-Windows-Server-2008-R2-Part2.html In the early days of DirectAccess, Server 2008 R2 that is, there was no built-in ISATAP Router like there is now, so we don’t have to care about building one, but its inner workings are the same.

And now, finally to my reason for blogging about this 😉 When I tried this in my home lab environment (and I’ve seen this in customer production implementation as well) it doesn’t work? Why can’t I connect to the DirectAccess connected clients? What’s wrong? If you did your homework and read Deb’s article you know that the ISATAP Router has to advertise itself and also forward IPv6 packets. You enable these functions on the ISATAP Interface on the ISATAP Router. Since my DirectAccess implementation is a 2-node WNLB cluster with 2 NICs in each server I get 4 ISATAP adapters created in Windows. You can see them by using netsh interface ipv6 show interface:

As you can see it’s not clear which one is bound to the external NIC and which one is bound to the internal NIC. Remember that ISATAP is a feature for internal IPv4 clients to be able to reach external IPv6 hosts, so the advertisement and forwarding is needed on the internal ISATAP interface. There is a way to find out by using wmic <ENTER> nicConfig get Description,SettingID The column SettingID is the GUID of the physical NIC and that is also what is shown after isatap.{guid}. After digging around in my DirectAccess server I could see that forwarding and advertising was enabled on the external NIC instead of the internal which of course isn’t going to work. We need to fix this. A quick way would be just to enable the needed features on the ISATAP adapter for the internal NIC but there is a way to make this more crisp and clear.

Simply:

1. Go into Device Manager
2. Under View, click Show hidden devices.
3. Uninstall both ISATAP adapters
   
4. On the Internal NIC, IPv4 Settings, Advanced, DNS tab, fill in your internal domain’s DNS suffix
   
5. Reboot the DirectAccess server
6. Proceed with Node 2, etc if you have multiple DirectAccess servers.
7. After reboot it’s clear what adapter is the internal one
   
8. Now we only have to enable Forwarding and Advertising; netsh interface ipv6 set interface 32 advertise=enabled forwarding=enabled
   

If all other parts mentioned in Jason Jones article are in place you should be good to go. Happy ISATAP:ing!

Automatically delete log files in Exchange 2013

A common request from my customers is a way to control the number of diagnostic log files Exchange 2013 creates. The number of parameters being logged in Exchange 2013 is far greater than in previous versions and therefor the space requirements are also greater. It’s not all that uncommon for the disks to fill up and if you are really unlucky, and you store the log files on the same disk as your transaction log files and/or your databases, you can make Exchange completely stop when running out of disk space. Not a good place to be in.

A quick google finds a couple of scripts dealing with this situation but I found some issues trying to make it all work so I thought I’d put together a post on how I made it work in my environments.

We need to do the following:

1. Create the Purge-LogFiles.ps1 script from the TechNet Script Center repository
2. Make one edit in the script
3. Schedule the script in Task Scheduler

Seems easy enough but I found it to be a bit tricky. At least for my taste.

Step 1: Go to the link [https://gallery.technet.microsoft.com/scriptcenter/Purge-Exchange-Server-2013-c2e03e72] and copy the Powershell script block. (Do not download the file in the beginning of the page as it is an older version with some issues with it.) Open notepad and past the contents and save the file as Purge-LogFiles.ps1. Put it in a custom scripts folder (like D:\Custom Exchange Scripts\) on one of your Exchange 2013 Servers. I like to do it this way so I keep my custom scripts separated from the built in ones and I guess the Cumulative Updates recreates the default scripts folder and would remove my custom ones.

Step 2: Open the script file Purge-LogFiles.ps1 in Notepad and under ‘Edit’ > ‘Find’ enter *.log and hit ‘Find Next’. Directly after *.log type ,*.blg so that the line says -Include *.log,*.blg -Recurse. The reason for adding the *.blg is to let the script also remove DailyPerformanceLogs in $env:ExchangeInstallPath\Logging\Diagnostics\DailyPerformanceLogs folder. These files are rather big, accumulates over time and quickly fills you hard drives.

Step 3: Open Task Schedular (Run > Taskschd.msc) and choose ‘Create a Basic Task’. Add the following information:

• Create a Basic Task
  Name: Delete Exchange Log Files
  Description: Deletes Exchange Diagnostic LogFiles (*.log & *.blg) older than 14 days.
• Trigger
  Daily > and in the next screen choose an appropriate start time and leave ‘Recur every:’ to 1 days.
• Action
  Start a program
  Program/script: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -command “. ‘D:\Program Files\Microsoft\Exchange Server\V15\Bin\RemoteExchange.ps1’; Connect-ExchangeServer -auto;. ‘D:\Custom Exchange Scripts\Purge-LogFiles.ps1’ -DaysToKeep 14 -Auto -SendMail -MailFrom user@domain.com -MailTo user@domain.com -MailServer localhost”(Obviously you need to alter the email addresses to your own. If you like me execute this script locally on your Exchange you can use ‘localhost’ as Mail Server.)
  Hit ‘Yes’ when prompted
• Finish
  Check ‘Open the Properties dialog for this task when I click Finish’

On the ‘General’ tab, change to ‘Run whether user is logged on or not’ and if you are using User Account Control (UAC) you’ll also need to check ‘Run with highest privileges’

Also on the ‘General’ tab, select under which credentials you’d like the script to run as. Click ‘Finish’ and supply password.

To test if everything works ok, in Task Scheduler right-click the ‘Delete Exchange Log Files’ task and choose ‘Run’.

At last we have control over the amount of log files stored on our Exchange. Remember that the files in themselves are good, but just as long as they don’t break Exchange. 😉

 

 

No DNS Servers on NIC

I recently had a customer who converted a virtual vSphare Exchange 2010 guest to a Hyper-V guest. In that process you should remove all orphaned devices on the machine. But as it happens they aren’t immideately visible. You have to tell Device Manager to show hidden devices (like the orphaned ones are). You can read more about this here: Device Management

Now on to the Exchange related issue. Even after the hidden orphaned NIC from vSphare was removed, Exchange had serious trouble emptying its queues. Error message: 451 4.4.0 DNS query failed. Okay, what gives? A look into Event Viewer Application log file revealed more information:

And attached to this Event ID we also have some information from the mothership.

Running Get-TransportServer | fl *DNSAdapter* revealed:

Well actually it revealed the GUID of bf6e0c9e-ff6f-4943-848d-8fc9944898d8 (the GUID of the no longer present vSphare NIC). I forgot to take a screen shot before changing it. This shows that even after the administrator uninstalled the old virtual NIC and made sure it didn’t show up as a hidden device any longer, Exchange still hung on to it. Even after a reboot.

A GUID of all zeroes just mean grab any DNS Server setting of any available IPv4 enabled NIC. Funny enough this setting does not work on my home lab Exchange Server on Hyper-V. On that machine I have to specify the GUID of the Hyper-V NIC, just like this blog post by Tony Redmond discusses; Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS

Obviously Exchange Server is very dependant on working DNS settings, but sometimes it feels like Exchange is a bit too sensitive in its settings. More robustness would be greatly welcomed.

Enable priority queuing

A common misunderstanding when prioritizing a message in Outlook is that it also will affect message delivery. In other words, if you mark an email as high priority it would automatically be delivered faster on a busy Exchange Server compared to a normal email message. This isn’t true. But it could be. Here’s how.

If you want this kind of behaviour you need to enable Priority Queuing in Exchange. There are lots of configuration possibillities but the one magic switch is

<add key=”PriorityQueuingEnabled” value=”true” />

inside of the EdgeTransport.exe.config file on your Mailbox Role Server in Exchange 2013. This feature is also available in Exchange 2010 but then you need to edit the file on your Hub Transport Servers instead. Actually, this feature was introduced in Exchange 2007 SP1.

More Reading:
Priority Queuing
Enable and configure priority queuing