Is Your SenderID/SPF or DKIM Record Correctly Configured

Posted on Leave a commentPosted in DNS, domain, exchange, exchange online, IAmMEC, MX, Office 365, spam

With Microsoft having just announced that DKIM is coming to Office 365 soon (release notes here) and SenderID is already available, I thought this is a good time to write a blog on the use of DMARC to show if your records are correct.

DMARC is a protocol that allows you to see the effect of your SenderID/SPF records from the viewpoint of the recipient – as long as the recipient is one of the larger email receivers in the world, but that should be enough to help you validate your SenderID/SPF records. DMARC is currently in use at Outlook.com/Hotmail, Gmail, Facebook, Yahoo and Twitter to name some of the larger users of it.

To receive the results of a DMARC report you need to add your DMARC policy as a new TXT record to DNS. It looks something like this:

_dmarc IN TXT “v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com”

This TXT record for “_dmarc” at the root of your domain tells the receiver to report back to you all (pct=100) SenderID/SPF failures. They also report DKIM failures as well. If you send lots of email you might want to report on a smaller number of overall failures, say pct=20! The record says who to send the report to (rua=email address).

Finally, and one of the most useful bits of DMARC is that you can tell the receiver what to do with failures in your SenderID/SFP or DKIM record. For example in SenderID/SPF you can set the modifier “-all” to the end. This says that anything not covered in the rest of the record is to fail SenderID. The recipient then decides what to do with your email (as it might be your email, as you might have got your SPF or DKIM record wrong). In the example above you tell the recipient email system you would like them to reject (p=) the email. The policy could be quarantine or none. The policy p=none means accept the message, but report it back to the rua email address in the DMARC record.

p=none allows you to introduce SPF/DKIM and ensure no rejection of your messages at the recipient end, but get reporting back on the IP addresses from which your emails (or spoofed emails) are coming from.

Once you are sure your SPF/DKIM records are correct change your policy to p=quarantine and then when you are finally sure, change it to p=reject.

An example of creating a DMARC policy on your domain is shown below. The below example is AWS Route 53 DNS, but any DNS management console that support TXT records should work:

image

Finally, as this is just a quick intro to DMARC, you can use the ruf= qualifier to set the email address of per message failure reports.

Highly Available Geo Redundancy with Outbound Send Connectors in Exchange 2003 and Later

Posted on 6 CommentsPosted in 2003, 2007, 2010, cloud, DNS, domain, door, exchange, exchange online, load balancer, loadbalancer, mcm, microsoft, MX, Office 365, smarthost

This is something I’ve been meaning to write down for a while. I wrote an answer for this question to LinkedIn about a week ago and I’ve just emailed a MCM Exchange consultant with this – so here we go…

If you configure a Send Connector (Exchange 2007 and 2010) or Exchange 2003 SMTP Connector with multiple smarthosts for delivery to, then Exchange will round-robin across them all equally. This gives high availability, as if a smarthost is unavailable then Exchange will pick the next one and mail will get delivered, but it does not give redundancy across sites. If you add a smarthost in a remote site to the send connector Exchange will use it in turn equally.

So how can get get geographical redundancy with outbound smarthosts? Quite easily it appears, and it all uses a feature of Exchange that’s been around for a while. But first these important points:

  • This works for smarthost delivery and not MX (i.e. DNS) delivery.
  • This is only useful for companies with multiple sites, internet connections in these sites and smarthosts in those sites.
  • This is typically done on your internet send connectors, the ones using the * address space.

You do this by creating a fake domain in DNS. Lets say smarthost.local and then creating A records in this zone for each SMTP smarthost (i.e. mail.oxford.smarthost.local). Then create an MX record for your first site (oxford.smarthost.local MX 10 mail.oxford.smarthost.local). Repeat for each site, where oxford is the site name of the first site in this example.

Then you create second MX records, lower priority, in any site but use the A record of a smarthost in a different site (oxford.smarthost.local MX 20 mail.cambridge.smarthost.local).

Then add oxford.smarthost.local as the target smarthost in the send connector. Exchange will look up the address in DNS as MX first, A record second, IP address last), so it will find the MX record and resolve the A records for the highest priority for the domain and then round-robin across these A records.

If you have more than one smarthost in a site, add more than one MX 10 record, one per smarthost. Exchange will round-robin across the 10’s. When all the 10’s are offline then Exchange will automatically route to mail.cambridge.smarthost.local (MX priority 20 for the oxford site) without needing to disable the connector and retry the queues.

If you used servernames and not MX’s then it would round-robin amongst all entries, and so equally sent email to Cambridge for delivery. The MX option keeps mail in site for delivery until it cannot and then sends it automatically to the failover site.

Starting Exchange When You Have Active Directory Issues

Posted on Leave a commentPosted in 2010, active directory, domain, exchange, windows 2003, windows 2008

I had a call the other day from a company who had Exchange issues. One investigation it turned out they had a very suspect Active Directory and no-one would admit to what they had actually done to get it in such a state!

One server (DC1) would not talk to the other DC’s (Kerberos issues and replication issues) and the other DC’s where missing the Microsoft Exchange Security Groups OU and contained groups as well as other Exchange related stuff – though the schema and configuration was present!

DC1’s event logs where full of errors going back about six days (to when the issue started, though I only got a call a day before we had it fixed). But if I looked back in the log more than six days the event log showed only stuff from almost a year ago. I suspect a snapshot of the server was restored – but as I said, the only thing anyone claimed to have done was attempted to restore a user from a backup!

So the first step was to see if we could isolate DC1 from Exchange and do a setup /PrepareAD to replace the missing items in the domain naming context.

This requires limiting Exchange to DC2 with Set-ExchangeServer Exchange Management Shell cmdlet, but the shell would not start due to AD errors, so out with the registry editor.

To hard code Exchange to selected DC’s you need to visit HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ services\ MSExchange ADAccess and create a new key called Instance0. Inside \Instance0 create a String called ConfigDCHostName that has a value of the FQDN of DC to use.

Then create a Profiles key under HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ services\ MSExchange ADAccess\, which is the same location as before. Under Profiles create a subkey called Default. For Exchange 2010 create a DWORD called MinUserDC and a value of 1 and under Default key create two more keys called UserDC1 and UserGC1. MinUserDN is in a different location for Exchange 2007.

Inside UserDC1 key add a string called HostName (the value being the FQDN of the domain controller server to use) and a DWORD called IsGC with a value of 0.

Inside UserGC1 key add a string called HostName (the value being the FQDN of the global catalog server to use) and a DWORD called IsGC with a value of 1.

An example is shown in the picture for clarity:

image

Restart the Microsoft Exchange ADTopology Service to see if it can now connect to the correct server (the MinUserDC value stops Exchange attempting to connect to the PDC emulator as well as the listed domain controllers). In my clients issues, the PDC Emulator was DC1 that was effectively unreachable.

If you can get Exchange online now, great! Time to fix the issues with DC1. But if you can’t (and in my example I could not) then time for more troubleshooting – its sort of just like the MCM Qual Lab, just with real customer data!

To cut a long story short, in my example I decided that DC1 was the more accurate DC and that an authoritative restore of it to the last available AD backup (one month old!) might fix up the issues that had crept in since the abortive work done by the client earlier in the week. In this clients case, I used ntdsutil on DC2 to remove DC1 and then used dcpromo to demote all the DC’s so that they returned to member servers and standalone machines. Then I used ntdsutil to remove DC2 etc from the copy of AD on DC1 so that I was left with an almost up to date copy of AD on DC1. Then I rejoined DC2 etc. to the DC1 replica so I was back where the client thought they were with a number of DC’s but all replicating and Exchange objects all present. I needed to rejoin the servers to the domain, but once that was done I had a working Exchange environment. It was only six and a half days since the outage, and the clients email cloud filtering company held email for seven days – so no loss of email! Just about!

All in a days work for a Microsoft Certified Master | Exchange Server 2010.

Domain Redirection and BPOS to Office 365 Migration

Posted on Leave a commentPosted in bpos, DNS, domain, exchange, exchange online, Office 365

With Microsoft Exchange Online via BPOS (the precursor to Office 365) you were able to configure a simple CNAME redirection to make access to OWA easier for your users.

For example, you could create a CNAME in DNS for mail.fabrikam.com (where fabrikam.com is your domain in BPOS) which pointed to go.domains.live.com and then when users accessed mail.fabrikam.com they would be redirected to the correct login page for BPOS. Note that this is also possible by setting the CNAME target to outlook.com.

A problem here though is that if you use go.domains.live.com then once you complete migration from BPOS to Office 365 the redirection stops working and when your users visit mail.fabrikam.com they get go.domains.live.com and not OWA!

So before you start your migration make sure you have changed your CNAME to outlook.com rather than go.domains.live.com and when users visit http://mail.fabrikam.com they get OWA both before and after the migration.

This recommendation also applies to academic organisations moving from Live@Edu to Office 365 for Education.

Hosting Exchange 2010 and Issues With Duplicate Contacts

Posted on 1 CommentPosted in 2007, 2010, active directory, adsiedit, domain, exchange, hosting, hybrid, policy

When you are creating a hosted Exchange system using the Exchange 2010 On Premises product (not the /hosting version of the product) it is likely that if two or more of your customers create a mail contact in the global address list (GAL) for the same external email recipient they will see some issues with email addressing.

For example, you are hosting Exchange for northwind.com and fineartschool.net within one Exchange organization. Both these companies have a professional relationship with greg@fabrikam.com and so want to create a contact for him in the GAL. The first of your clients to create the contact will be successful, but any future client receives the following error when they attempt to create the contact:

New-MailContact -Name “Greg (Fabrikam)” -ExternalEmailAddress greg@fabrikam.com -OrganizationalUnit FineArtSchool
The proxy address “SMTP:greg@fabrikam.com” is already being used by “isp.corp/Hosted/Northwind/Greg (Fabrikam)”. Please choose another proxy address.
    + CategoryInfo          : NotSpecified: (…) :ADObjectId) [New-MailContact], ProxyAddressExistsException
    + FullyQualifiedErrorId : B333D21C,Microsoft.Exchange.Management.Recipient
   Tasks.NewMailContact

The work around is to specify a unique proxy address, as the default proxy address (the contacts actual email address) is already being used:

New-MailContact -Name “Greg (Fabrikam)” -ExternalEmailAddress greg@fabrikam.com -OrganizationalUnit FineArtSchool -PrimarySmtpAddress greg@fineartschool.net

Of course Greg’s email address is greg@fabrikam.com (his external email address) and not greg@fineartschool.net (his proxy or primary SMTP address so far as Fine Art School have configured) and if this client sends an email to Greg and they select Greg from the GAL it will go to his external email address but will look like it has gone to his proxy address. That is, Greg will receive the email but if he looks at the address it was sent to it will say greg@fineartschool.net.

Send an email to two people in external organizations, one being greg@fabrikam.com, and hit Reply All and Greg will appear as greg@proxyaddress and not greg@fabrikam.com. Emails in reply will go to Greg via the hosting company and not direct to Greg. This also has the side affect of showing presence (from Microsoft Lync) as being unavailable as the email is using the wrong email address.

The underlying problem is that though the email is being delivered to the external address (targetAddress attribute in Active Directory) it is being stamped with the primary SMTP address (proxyAddresses in Active Directory) in the P2 header. The P2 header is used to generate the Reply address.

So how do you fix this? The obvious way at first glance is to modify active directory and change the proxyAddresses value back to the correct value – but this does not work (as two objects cannot have the same proxy address). Regardless of the fact that the two mail contacts both have the same targetAddress and proxyAddresses, Exchange Transport detects a problem and reports the error “More than one Active Directory object is configured with the recipient address greg@fabrikam.com. Messages to this recipient will be deferred until the configuration is corrected in Active Directory” in the event log on the first Hub Transport server that sees the message.

So without writing your own transport agent, you need to route all outbound email via an Edge Transport server and configure the Address Rewriting agent. You need to create an address rewrite rule for every contact that is created within your hosted organization once the second contact is created. So in your mail contact provisioning application you need to trap the duplicate proxy address error above, reissue the mail contact creation step, this time with a unique primary SMTP address in the hosted clients domain and then at the same time make an address rewrite rule on your Edge Transport server.

New-AddressRewriteEntry -Name “Greg – Fabrikam – HosterFineArtSchool” -InternalAddress greg@fineartschool.net -ExternalAddress greg@fabrikam.com -OutboundOnly $true

Note that rewrite rules are cached for four hours, so unless you restart the MSExchangeTransport service your rewrite rules will not take effect until four hours have gone by.

Exchange Log Truncation Failure in a DAG

Posted on 2 CommentsPosted in 2010, backup, domain, exchange, networking, windows 2008, x64

Today I visited a client who had noticed that no log files had ever been removed after any backup within Exchange 2010 SP1. It was fortuitous that they had enough log disk space for about eight months of log generations. The disadvantage was that we were four months into this time period, so it was a ticking clock, and that the nightly incremental backups were taking longer and longer.

They were getting the following error in their backup datacentre:

image

Unable to communicate with the Microsoft Exchange Information Store service to coordinate log truncation for database ‘name’ due to an RPC communication failure. Error 3355379671 Extended Error: 0 and Event ID 2136 for the MSExchangeRepl service in the Application event log.

What the error does not clearly say is that the Microsoft Exchange Replication service (MSExchangeRepl) on the server in the DR site (a passive node in the DAG) needs to communicate via RPC to the Microsoft Exchange Information Store service on the server holding the active node of the database.

In the case of my client, the Exchange team is not the same people as the network team or indeed the firewall team, and these teams are in different countries. In the case of the network for this client, the Replication network for the DAG had been opened to allow RPC traffic, but the MAPI (Client) network had not.

When Exchange in the DR site needed to check which logs it could truncate (a process it performs every 15 minutes), it needs to talk to the Microsoft Exchange Information Store service on the server holding the active copy of the database, and name resolution was returning (as expected) the IP address of the server on the MAPI/Client network. This network blocked RPC between servers and so (as one of the many issues they now attribute to this problem) logs could not be truncated and Event ID 2136 was posted once per database on the passive node in the DR site. The two servers in the primary site could RPC each other, so this log is not repeated in the primary site.

To solve this log growth problem without waiting for a response from the firewall team, we added a record to the hosts file on the passive server to override DNS name resolution, and within 15 minutes 2TB of log files instantly disappeared on all servers. Name resolution was reverted to DNS and the firewall team contacted.

How to Clear Password Policy on workstation after removing it from domain

Posted on Leave a commentPosted in domain, password, policy, workstation, xp

I needed to set up a few machines for a client in an internet cafe type scenario, but the client provided me with computers that had been added to the domain. The domain had a password requirement which meant I could not configure the default login on the cafe machines to have no password.
To reset the domain policy without adding the computer back into the domain and actually changing the policy for a short while you can reset the security settings on an XP computer to that at install time using the following command:

 secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

This resets lots of settings back to the default installation configuration, but meant that I did not need to reinstall the operating system.
For full details on the limitations of the above command see http://support.microsoft.com/default.aspx?scid=kb;en-us;313222