Free Online Training for Windows Server 2012 R2 and System Center 2012 R2

Microsoft has a couple of free online training events coming up in July:

• What's New in Windows Server 2012 R2 Jumpstart (July 10/11)
• What's New in System Center 2012 R2 Jumpstart (July 15)

After these events are over, Microsoft typically makes them available as online videos. I expect that the above links will be updated.

UnexpetectedExchagneAuthBlob

While testing mail flow before an Exchange 2007 to Exchange 2013 migration is received the following error from an Exchange 2013 server to an Exchange 2007 server:

454 4.7.0 Temporary authentication failure

Further investigation in the SMTP receive protocol log showed this error:

Inbound ExchangeAuth negotiation failed because of UnexpetectedExchagneAuthBlob

Luckily based on some quick searches I was able to identify time synchronization as the source of the issue. Active Directory authentication starts to fail when time synchronization is not within 5 minutes. In this case the time difference was 6 minutes.

In the short term, I change the time on one server and verified that mail flow started to work properly. Long run I need to identify why time what not properly synchronized and fix it.

Exchange Authentication Error

I'm just performing a migration from Exchange 2007 to Exchange 2013. After installing Exchange 2013 and configuring the certificates, my next step was to verify mail flow between the two systems. Mail flow from Exchange 2007 to Exchange 2013 was fine. However, mail flow from Exchange 2013 to Exchange 2007 was failing.

In the Queue Viewer on the Exchange 2013 server I could see the following message:

451 4.4.0 Primary target IP address responded with: "451 5.7.3 Cannot achieve Exchange Server authentication." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

This message indicates that Exchange Server authentication is failing before the message is sent. This can happen because of the following reasons:

1. A firewall between the servers strips out extended SMTP verbs that are required for Exchange Server authentication. Specifically the following SMTP verbs must be allowed: X-ANONYMOUSTLS, X-EXPS, and GSSAPI. In most cases, this is not an issue on internal networks.
2. Exchange Authentication is not enabled on the receive connector being used. This is most likely.

In my case, the receiving server had two receive connectors listening on port 25:

• Default ServerName
• Anonymous Relay for internal devices

When I reviewed the configuration of these connectors, the Default connector had Exchange Server authentication enabled. The Anonymous Relay connector did not have Exchange Server authentication enabled.

This made me suspect that the Anonymous Relay connector was being used instead of the Default connector. To confirm this I looked in the SMTP Receive protocol log in C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive. Searching the most recent log for the IP address of the Exchange 2013 server showed that the Anonymous Relay connector was being used.

I then looked in the configuration of the Anonymous Relay connector on the Network tab. There were a large number of remote IP addresses listed as allowed to use the Anonymous Relay connector (probably more than there should be, but that's an issue for another day). The entire subnet that the Exchange 2013 was located on was listed.

Exchange Server chooses a receive connector to use based on how specific the remote IP addresses listed in the connector are. The subnet listed in the Anonymous Relay connector was more specific that the 0.0.0.0-255.255.255.255 listed in the Default connector. Therefore the Anonymous Relay connector was being used.

To fix this problem, I added the individual IP addresses of the Exchange 2013 servers to the Default connector on the Exchange 2007 server. This was then more specific than the subnet in the Anonymous Relay connector. After this was complete, the Default connector was used.

Viewing the Exchange 2010 Anti-Spam Logs

In most cases, you should have anti-spam filtering for Exchange 2010 that is provided by software other than Exchange 2010. Exchange 2010 has some basic anti-spam filtering features but they are not as nice or easy to work with as online filtering services (such as ForeFront Online for Exchange) or on-premises services (such as Barracuda devices or Symantec Mail security).

Note: SBS2011 enables the built-in anti-spam filtering capabilities of Exchange 2010 by default.

If you select to use the spam filtering in Exchange 2010 (or do so by accident) it's pretty awkward to view the logs. The only interface provided by Exchange 2010 is the Get-Agent log cmdlet. This cmdlet only gives parameters to display by start date and end date. You'll need to filter down the output of Get-AgentLog to see only what you want.

To make life easier for you, here are the list of properties supplied for each message that you can filter based-on:

• RunspaceId - Not useful
• Timestamp - But you'd use the start and end date with Get-AgentLog to filter this instead
• SessionId - Not useful
• IPAddress - The mail server sending the message
• MessageId - Generally not useful unless the sender provides this information to help you search for it
• P1FromAddress
• P2FromAddresses
• Recipients
• Agent - Indicates which anti-spam filter caught the spam
• Event - When the filtering was applied (OnEndOfData is typical)
• Action - Look for RejectMessage when identifying spam that is filtered
• SmtpResponse - The SMTP code that was provided to the sender (5.7.1 is a spam rejection)
• Reason - Provides a summarized reason as to why the message was blocked
• ReasonData - When blocked because of a high SCL, this displays the SCL value
• Diagnostics - Codes that don't look useful to me

An example of filtering for rejected messages for a specific user:

Get-AgentLog -StartDate "06/11/2013 9:00:00 AM" | Where-Object {($_.Recipients -like "*username*") -and ($_.Action -eq "RejectMessage")}

The above example uses Get-AgentLog to list all messages in the log after 9am on June 11, 2013. The list of messages is piped to Where-Object for filtering.

The filter looks for recipients that contain the test username. You could use -eq and search for a specific full email address, but I find it easier to just search for the user portion of the email address. The list of recipients is an array and -eq may force you to put in all email addresses to match properly.

The filter also looks for messages that have an action of RejectMessage. I am only interested in viewing the rejected messages to verify is a sender is being blocked.

New DirSync Does Not Require ADFS for O365

On June 3rd, Microsoft released a new version of DirSync (Windows Azure Directory Sync Tool) that can synchronize on-premises password up to Office 365. With the addition of this functionality, you can have users log on to Office 365 without the requirement to configure Active Directory Federation Services (AD FS). Let me give a fairly long explanation as to why this is a good thing. First, how did it look with AD FS.

O365 Authentication with AD FS
A traditional configuration of O365 with single sign-on allows users to authenticate to O365 by using their corporate username and password. To enable this process, two components needed to be in place:

• DirSync. This component replicates information from the on-premises AD to O365. This allows on-premises user accounts to be automatically created in the cloud.
• AD FS. This component is a service that provides authentication for external services that use the on-premises AD as a source for user accounts.  For example, when you authenticate to O365, the credentials you provide are passed to AD FS in your organization for authentication. If AD FS indicates that your username and password are correct, then you are given access to your O365 account. Basically, it allows authentication to be outsourced from the location hosting the application.

There were two main issues with using AD FS:

1. If AD FS is not available, you could not authenticate to O365. So, if the corporate internet connection was down or if AD FS experienced any issues at all, your access to O365 was in jeopardy. When a selling feature of cloud-based services is high availability, this makes AD FS a major weak point.
2. AD FS is relatively complex to setup and configure if you want it to be highly available. At minimum, the recommended solution requires two AD FS servers and two AD FS proxies combined with load balancing for each level.

How Does the New DirSync Help
The new version of DirSync has an option to synchronize passwords from the on-premises AD to O365. Once the password has been synchronized, you authenticate only within O365. This can be used with hybrid deployments of Exchange Server.

To me this provides two big benefits:

1. The complexity and cost of AD FS is avoided.
2. O365 accounts can be authenticated even when the on-premises network is unavailable.

Things to Think About
Nothing is a completely free ride. So, there are things that you need to consider when selecting password synchronization over AD FS:

1. How paranoid are you? Your AD password information being replicated into the O365. This is done by replicating the hash value of the password, not the actual password, but if someone got the hash value, they could run a brute force attack on the hash and might be able to get the password.
2. Users will be prompted for credentials. AD FS provides single sign-on. For domain joined computers, this meant that access to O365 could be made seamless by passing workstation credentials to O365 for authentication. When you use password synchronization, users will be prompted for a password when starting Outlook. At least until you save the credentials during logon to O365.
3.  Password synchronization from AD to O365 is not immediate. Password synchronization takes place outside the standard 3 hour interval for synchronization. Typically, password synchronization is complete within a few minutes, but it is not immediate.
4. This tool has apparently been available on the eduction side of O365 for a while. So, it's not completely new. That makes me feel better about looking at implementing it sooner rather than later.
5. You can convert from an AD FS federated domain to using password synchronization fairly easily by using Convert-MsolDomainToStandard.

Additional Resources
Here are some additional resources that will help you evaluate whether password synchronization is right for your organization:

• New Azure Active Directory Sync tool with Password Sync is now available
  http://blogs.technet.com/b/educloud/archive/2013/06/03/new-azure-active-directory-sync-tool-with-password-sync-is-now-available.aspx
• Implement Password Synchronization
  http://technet.microsoft.com/en-us/library/dn246918.aspx
• Install or upgrade the Directory Sync tool
  http://technet.microsoft.com/en-us/library/jj151800.aspx