Ensuring Email Delivery Security with Exchange 2013

Posted on 4 CommentsPosted in 2007, 2010, 2013, encryption, exchange, IAmMEC, TLS, transport

To force Exchange 2013 to guarantee the secure delivery of a message can be done a few different ways. In this version of the product and in previous versions it was possible to create a send connector for a given domain and enable Mutual TLS on the connector. Then all messages to the domain(s) that this connector serviced would need to travel over a TLS connection where the certificate at both ends was completely valid (i.e. valid regards the date, had the correct subject or SAN for the domain, was issued by a trusted certificate authority etc.). In previous versions (2007 to 2010 again) it was possible to enable Domain Secure and add another level of checks to the Mutual TLS session. Domain Secure does not work in Exchange 2013.

And great though these methods of transport security are, they are limited in that they are difficult to set up (require good knowledge of certificates) and needs to be properly configured at both ends of the connection. They are also limited in that they will only secure email to the selected domains. If you need to send a “top secret” email to someone, you don’t really want to have to configure a connector at both ends and force all email for that domain down the same path.

So, in Exchange 2013 you can create a transport rule to force the connection to use TLS, and if TLS fails then have the message queue on the sender until it retries and eventually expires. If TLS is never available, the message never goes out of Exchange – or so it would be if all you read was the description in the documentation!

The RouteMessageOutboundRequireTLS transport rule action (or the Secure the message with > TLS encryption option in the ECP transport rules wizard) allows you to craft a rule for any condition (for example the subject or body contains any of these words: top secret) which will require the email to use an encrypted session for the delivery outside of Exchange Server. Note that for this to work the TLS session does not need to be protected by a given certificate or valid etc., it just needs the receiving SMTP Server to offer STARTTLS and for the encryption to work.

And it needs a source server for sending the message in every Active Directory site within the organization. Currently (as of CU2 for Exchange 2013) if you send a message from a site that does not contain a send connector that can handle the message to the internet then Exchange will pass it to a site that can, but the source transport server will now not enforce the TLS requirement and will send the message unprotected if STARTTLS is not offered.

So if you want to guarantee the use of TLS for certain types of message use the RouteMessageOutboundRequireTLS transport rule condition and ensure that you do not need to do cross site delivery of messages to reach a send connector source server to delivery the message to the internet.

Moving Exchange Online Protection Junk Mail to the Junk Email Folder

Posted on Leave a commentPosted in 2007, 2010, 2013, active directory, cloud, Edge, EOP, exchange, exchange online, FOPE, mcm, mcsm, spam, transport

If you use Exchange Online Protection (EOP) to filter your email in the cloud and to remove spam and malware before onward delivery to you, and if you use Exchange 2007 or later on-premises, then you need to configure Exchange to move detected spam to the Junk Email folder in Outlook.

By default EOP detects two levels of spam (malware is automatically removed) and tags them. In Exchange, you need to use Transport Rules to move these emails to the users Junk Email folder. If you wish for EOP throw away junk emails of either detection level (i.e. high junk is discarded) then you still need to configure these transport rules to move the remaining detected junk email into the Junk Email folder in Outlook. If you place all EOP detected spam in the quarantine or throw it away, you should still create these transport rules as it means they are in place for any future changes you make at EOP.

If you use Exchange Online (part of Office 365) then you do not need to create these rules as they already exist (though you cannot see them in any admin tools you have).

The Transport Rules To Create

The following four transport rules need to be created on your Exchange organization. These four rules get created with the highest priority, moving all existing rules below them. They set the Spam Confidence Level of the message to 6 in these examples, though this should be set to a value that exceeds the SCLJunkThreshold organization wide setting for your Exchange Organization, as any email that exceeds this value is placed into the Junk Email folder upon delivery to the users mailbox.

New-TransportRule "Move EOP Detected Spam (SFV:SPM) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SPM" -SetSCL 6 -Priority 0

New-TransportRule "Move EOP Detected Spam (SFV:SKS) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKS" -SetSCL 6 -Priority 1

New-TransportRule "Move Personal Block List Spam (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKB" -SetSCL 6 -Priority 2

New-TransportRule "Move Bulk Email (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SRV:BULK" -SetSCL 6 -Priority 3

Once these four rules are run, AD replication will need to be allowed to happen and then all Exchange Servers will action this rule for any email that EOP thinks is spam. The default value for SCLJunkThreshold is 4, so as long as the rules set the SCL value to greater than this value it should work. Use Get-OrganizationConfig | FL SCLJunkThreshold to get this value for your organization.

What the EOP Message Tags Mean

The X-Forefront-Antispam-Report header in the email contains many values. See http://technet.microsoft.com/en-us/library/dn205071(v=exchg.150).aspx for what EOP thinks about the spam rating of the message.

  • SFV – means Spam Filtering Verdict
  • SFV:SFE – Originated from a Safe Sender (EOP learns Outlook safe senders due to Windows Azure Directory Sync)
  • SFV:BLK – Originated from a Blocked Sender
  • SFV:SPM – Spam
  • SFV:SKB – Emails where the sender is on the users personal block list as configured in OWA or Outlook Junk Email settings
  • SFV:SKS – (SKIP) The message was marked as spam prior to being processed by the spam filter. This includes messages where the message matched a Transport rule to automatically mark it as spam and bypass all additional filtering
  • SFV:NSPM – Not Spam

Article updated in June 2016 to include new headers and go from two rules to four

Removing Edge Subscription When Exchange 2013 Installed

Posted on 6 CommentsPosted in 2007, 2010, 2013, Edge, exchange, federation, IAmMEC, mcm, mcsm, smarthost, transport

Exchange 2013 does not have an Edge role (at the time of writing – Aug 2013). It is possible to use Exchange 2010 SP3 and install the Edge role should you need one.

There is a problem though when it comes to removing the Edge Subscription between an organization that contains Exchange 2013 servers and the Exchange 2010 Edge Server. To remove the subscription on the Edge server role you run Remove-EdgeSubscription servername and this removes both the subscription and any subscribed objects from the local AD LDS database on that Edge Server. But if any of these subscribed objects where created on Exchange 2013 after it was installed, then they will have an ExchangeVersion equal to 0.20 (15.0.0.0). The Exchange 2010 SP3 Remove-EdgeSubscription cannot process this object and so fails with:

Remove-EdgeSubscription : Can’t make this change because the object’s ExchangeVersion property is 0.20 (15.0.0.0), which is not supported by the current version 0.1 (8.0.535.0). You will need a newer version of Exchange to make this change. Property Name: ExchangeVersion
At line:1 char:24
+ Remove-EdgeSubscription <<<<  edge2 -Verbose
+ CategoryInfo          : NotSpecified: (0:Int32) [Remove-EdgeSubscription], DataValidationException
+ FullyQualifiedErrorId : D8A49A14,Microsoft.Exchange.Management.SystemConfigurationTasks.RemoveEdgeSubscription

The way to fix this is to find and manually remove the object with an ExchangeVersion of 0.20 (15.0.0.0) from the AD LDS database and then repeat the Remove-EdgeSubscription cmdlet – as that should now work (unless you have two or more objects with the higher version number to locate and delete).

  1. To find objects with an ExchangeVersion greater than “0.1 (8.0.535.0)”, which is the version Exchange 2010 will process, open ADSIEdit on the Edge server.
  2. Right-click the ADSI Edit node at the top of the window and choose Connect to…
    image
  3. In the Connection Settings dialog (shown above), change the Select a well known Naming Context to Configuration and type the local server name and the AD LDS port in the Select or type a domain or server field. The server:port value should be EDGESERVERNAME:50389
    image
  4. Expand the tree view until you reach CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,CN={AD258B4D-CCB4-4125-80C1-7B73CE066341}
    image
  5. You now need to look at each object, starting with those you remember having created since 2013 was installed, for an object who’s msExchVersion value is not 4535486012416. For example, in the below screenshot I have an accepted domain made due to Federation in Exchange 2013. This object (under CN=Accepted Domains,CN=Transport Settings,…) has a value of 88218628259840.
    image
  6. To validate that this is the correct object to manually delete, from the Exchange Management Shell on the Edge server, enter Get-Object | FT name,ExchangeVersion where Object is the cmdlet that you are looking to query – in my case it would be Get-AcceptedDomain.
    image
  7. As you can see, this object has a newer ExchangeVersion and so it is (at least) this object that is stopping Exchange EdgeSync from being removed.
  8. Manually delete this object in ADSI Edit (it is safe to do this as it will resync from the Exchange organization if you recreate Edge Subscription later). Do not delete it from the Active Directory with ADSI Edit – just from AD LDS. Take care to only delete this object and not the parent object.
  9. Once this object is gone, try Remove-EdgeSubscription servername again. If this is the only object, then the Edge Subscription will be removed in the Edge Server

You can now carry on with whatever it was that you were doing that required a removal of the Edge Subscription.

Domain Secure and Edge Servers

Posted on Leave a commentPosted in 2007, 2010, 2013, certificates, cloud, exchange, firewall, smarthost, smtp, transport

I was asked a question recently on the Microsoft Certified Master course for Exchange 2010 and was told that the answer was not clearly written up on the internet. So I thought I would write this blog post. The question was based on the idea that Domain Secure worked from a Hub Transport server in the classroom lab but not when mail flow went via an Edge server.

Domain Secure is end to end security, it cannot have anything in the middle – i.e. it cannot go via an Exchange Edge server, an Exchange 2013 Frontend Server or a third party SMTP relay.

The SMTP client in the connection (the send connector host) needs to connect to the SMTP server (the receive connector host) and swap certificates and prove the other side is who the other side say they are – i.e. mutual authentication. Also the domains must match the TLS list in TransportConfig (TLSSendDomainSecureList and TLSReceiveDomainSecureList). Therefore anything in the middle will offer a different certificate and so Domain Secure fails.

If there is a middle party and you want to do mutual authentication (i.e. swap certs to prove who you are), with one party offering their cert and not the cert of the final recipient domain (i.e. mail.messaging.microsoft.com or postini.com etc.) then use TLSAuthLevel and the DomainValidation option on the send connector (an SP1 addition to Exchange 2010). No green ticky ticky though.

Edge can do Domain Secure though. But Edge needs to be the starting point, i.e. the host of the send connector. So configure Domain Secure on the Edge (i.e. set the certificates and correct firewall settings) and ensure that the send connector for Domain Secure has the Edge server as the source. Ensure Edge Domain Secure receive connector is the target for inbound as well if you want it to work both ways. And of course you need working EdgeSync so hubs can deliver to Edge so that Edge can deliver emails for you.

Forefront Online Protection for Exchange Spam Filtering to Outlook’s Junk E-Mail Folder

Posted on Leave a commentPosted in 2007, 2010, 2013, cloud, dirsync, EOP, exchange, exchange online, FOPE, hosting

Forefront Online Protection for Exchange (FOPE) is a cloud hosted email anti-spam and antivirus filtering system. Amongst the options to filter away your spam, one of the options to to allow the email to be flagged and sent on into your on-premises email system, and then managing it there.

If you have Exchange 2007 or later it is possible to write Exchange Transport Rules to process this flagged email and move it directly to the Junk E-Mail folder in your mailbox. This allows users to have their probable spam in a different location from their inbox email, but not in a different system accessed external to their email client, for which they might need a second login account or a delay before receiving the notification email. This works for probable spam as much obvious spam is filtered out at the edge of FOPE and so cannot make it to a place where users can see it.

An additional benefit of this filtering inside Outlook or OWA to the Junk E-Mail folder is that users can mark messages as safe or blocked in the client and this is picked up by Exchange and can be sent automatically to FOPE, which means FOPE flags it as spam before it reaches the Exchange organization.

To configure this you need to set FOPE to flag spam with a X-Header. This is documented at various places online, but misses out one vital piece of information which I wrote this blog to document. The missing info is what the value of the X-Header is so that you can actually write a transport rule to process it.

In FOPE, select your email domain (under Domains) and on the domain page click Edit next to Spam Action under Service Settings. Change the Spam Action to Add X-Header and type the header name that you want to use:

image

On your Exchange organization create a transport rule (these pictures are from Exchange 2007, but 2010 or 2013 are technically the same though visibly different). The transport rule is set to apply to messages when a message header contains specific words and the name of the header is the value set in FOPE previously (X-MoveTo-JunkEmail in this example). The value of the header will always read “This message appears to be spam.”.

image

It is possible to use the when the message header contains text patterns and use the RegEx expression \w* to find emails with your header in it and containing a value (\w* means any letter or digit repeated), but as we know the value for the header is always “This message appears to be spam.” then using regular expression filtering is adding un-needed CPU cycles to the Exchange Server – only use RegEx when the value can vary.

Office 365 use this process to place your probable spam in Junk E-Mail. In their case the header is X-FOSE-spam.

The transport rule continues to set the spam confidence level to a high value of your choosing, and higher than the value we will set in OrganizationConfig below.

So this rule will take all emails the FOPE marks as spam and changes the spam confidence level (SCL) value to 9 (in this example). Finally we need to set the SCLJunkThreshold property of OrganizationConfig to a value below the value in the transport rule. Exchange will place all email that exceeds this threshold into the Junk E-Mail folder in Outlook:

Set-OrganizationConfig -SCLJunkThreshold 4

If you are running the Content Filter hygiene agent then you will also want to check the Get-ContentFilterConfig values for SCLRejectEnabled, SCLDeleteEnabled and SCLQuarantineEnabled are all set to false. This ensures that SCL values that are are high are not rejected or deleted, or sent to quarantine. As all your email should be filtered by FOPE if you are using it, and the firewalls at your company or receive connectors on Exchange should be blocking email not sent from the FOPE datacenters (in FOPE admin pages click Information tab and then the Configuration link to get the list of IP addresses). The content filtering agent can be used as a second filter on-premises but if you don’t want to throw away or reject spam at this second level (recommended in this scenario) then ensure that the filter rejection, delete and quarantine settings are disabled. If you want to delete probable spam then set the transport rule to 5 and the SCLDeleteEnabled to $true and the SCLDeleteThreshold value to 9. Don’t reject or use the on-premises quarantine features when using FOPE (the transport rule cannot process the quarantined messages for a start).

Finally for administrators, consider a Message Retention Management or Retention Policy to delete without recovery email in Junk E-Mail folder after 21 days. Also consider the FOPE Directory Sync tool to push the user lists to FOPE as this upload also includes the pushing of the safe senders information as well.

Now for your users, all probable spam is managed in their email client, integrated with safe sender lists and without resorting to another application to view and deliver false positives and spam they want to read!

Exchange 2013 Transport Agents

Posted on 3 CommentsPosted in 2007, 2010, 2013, agent, exchange, sdk, smtp, visual studio

Earlier today I posted http://blog.c7solutions.com/2012/10/creating-simple-exchange-server.html on how to create a transport agent in Exchange, and though the steps cover some of the detail for Exchange Server 2013 they do not cover some of the detail, so I’ve added that to this post below:

  • Use .NET Framework 4.0 for Exchange 2013 though it is possible to write the agents using earlier versions of the .NET Framework. If you do use earlier versions then you need to update some of the config files on the server to state the version levels that you support and Enable Support for Legacy Transport Agents on Technet lists the steps for this.
  • The Front End Transport role (which is installed on the CAS Server role) can support SMTP agents bound to events up to, but not including OnEndOfData.
  • The Hub Transport role (which is installed on the Mailbox Server role) can support all SMTP agents except for those that bind to the OnConnect event.
  • The Hub Transport role also support routing agents and delivery agents. The CAS role supports neither of these agent types.
  • The Exchange 2013 Edge Transport Server role (expected with Exchange 2013 SP1) will support agents at the OnConnect event.
  • To install a transport agent on a multi-role server (CAS and Mailbox on the same machine) then you need to use can use -TransportService Hub to the Install-TransportAgent cmdlet shown in the earlier blog if you want to bind the agent to the Hub Transport events. If you want to use the Front End Transport events (OnMailFrom to OnEndOfHeaders) then use –TransportService FrontEnd instead (updated 2 Oct from Philippe comment below).
  • To install a transport agent on a CAS only server role you need to use local PowerShell and load the Exchange Management Shell snap-in with Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
  • Finally, to view the agents in a given service, always state the service name or you will get back the Hub Transport service by default. For example Get-TransportAgent –TransportService FrontEnd for the agents bound to the Front End Transport service. Other values are Hub, Edge and MailboxSubmission and MailboxDelivery (though the last two don’t seem to work in the pre-release version on Exchange Server 2013.

Creating a Simple Exchange Server Transport Agent

Posted on 5 CommentsPosted in 2007, 2010, 2013, agent, exchange, mcm, sdk, smtp, transport agent, visual studio

This blog post follows a session that I delivered at the MEC 2012 conference in Orlando. If you attended the conference the slides are available on http://mymec.mecisback.com for the rest of 2012.

Part of the transport agents session was writing a new transport agent, and the example agent was to do add a form of catch-all functionality. The example code below (which purposefully needs editing to work, as its designed to be a learning tool) takes an email in the form of alias_tag@domain.com where the final recipient is alias@domain.com and the subject line is changed to read [tag] Original Subject. Therefore email addresses can be given out that are an adjusted form of your real address, and on receipt of the email the correct recipient address is determined in code (the value before the _ appended to the domain name) so that you do not need to add lots of aliases to your user account in Active Directory. The subject is then changed to indicate the email came from this alternative original address. For example, an email to bill_linkedin@microsoft.com would go to bill@microsoft.com and have [linkedin] added to the start of the subject.

As this partial catch all transport agent needs access to the recipient information and the subject, the agent needs to be bound to OnEndOfHeaders or OnEndOfData in the SMTP stack. It could also be bound to OnSubmittedMessage as a routing agent (rather than an SMTP agent) but could not be bound to OnResolvedMessage as recipient resolution has already happened by this point.

Writing the Transport Agent

To create the transport agent you need Visual Studio – the basic version of Visual Studio are sufficient and you need to copy the two DLL’s from Program Files\Microsoft\Exchange Server\V14\Public (or the V15 folder for Exchange 2013) to a folder on your development machine. You need a copy of these DLL’s for every version/service pack/update rollup of Exchange that you will run your agent on, as the DLL’s might change between these versions, and if you have the wrong version you will not be able to install your agent on a new server or if the server is updated, the transport service will fail as it will not be able to load the agent.

In Visual Studio, create a .NET 2 or 3.5 Class Library (for Visual Basic if using the below code) for Exchange 2010 or .NET 4.0 Class Library for Exchange 2013. For the project name enter something descriptive for what you are going to create (rather then ClassLibrary1). For example MECDemoPartialCatchAll.

image

Copy and paste the following code into the class.vb file, replacing the template text.

   1: Imports System

   2: Imports System.Collections.Generic

   3: Imports System.Text

   4: Imports Microsoft.Exchange.Data.Transport

   5: Imports Microsoft.Exchange.Data.Transport.Smtp

   6:

   7: Namespace XXXXX REM Change This

   8:

   9:     NotInheritable Class YYYYYY REM Change This

  10:         Inherits SmtpReceiveAgentFactory

  11:

  12:         Public Overrides Function CreateAgent(ByVal server As SmtpServer) As SmtpReceiveAgent

  13:             Return New ZZZZZ REM Change This

  14:         End Function

  15:

  16:     End Class

  17:

  18:     Public Class ZZZZZ REM Change This

  19:         Inherits SmtpReceiveAgent

  20:

  21:         Private Sub MyEndOfDataHandler(ByVal source As ReceiveMessageEventSource, ByVal e As EndOfDataEventArgs) Handles Me REM Change This

  22:             ' Get and change the recipient from alias_tag to alias (only doing for 1 recipient for simplicity)

  23:             If e.MailItem.Recipients.Count = 1 And InStr(e.MailItem.Recipients.Item(0).Address, "_") > 1 Then

  24:                 Dim Recipient() As String = Split(e.MailItem.Recipients.Item(0).Address, "@", 2)

  25:                 Dim EmailAlias() As String = Split(Recipient(0), "_", 2)

  26:                 'EmailAlias(0) = alias to send email to

  27:                 'EmailAlias(1) = tag for subject line

  28:                 'Recipient(1) = domain

  29:

  30:                 ' The following line prepends [tag] to the subject of the message.

  31: REM Change This                 "[" + EmailAlias(1).ToString + "] " + e.MailItem.Message.Subject

  32:

  33:                 'the following drops the current recipient

  34:                 e.MailItem.Recipients.Remove(e.MailItem.Recipients.Item(0).Address)

  35:

  36:                 'the following adds the recipient back again, this time using the alias without the tag

  37:                 e.MailItem.Recipients.Add(New RoutingAddress(EmailAlias(0).ToString + "@" + Recipient(1).ToString))

  38:             End If

  39:         End Sub

  40:

  41:     End Class

  42:

  43: End Namespace

Download this code

The remaining steps on creating the agent will be to modify the lines above that are marked with REM statements and then to add the reference DLL’s you copied from your Exchange Server and finally build your DLL.

Visual Studio can tell you when your code contains errors before you build your code, but to do so you need to reference the DLL’s that you obtained from your Exchange Server earlier in this blog. To do this you need to have copied the two DLL’s to a unique folder on your computer. I use c:\temp\Agent Authoring\Dll\E14-SP2-RU4 to store the DLL’s from Exchange 2010, SP2, RU4. Then when RU5 is released, if the DLL’s have changed I will place them in an E14-SP2-RU5 folder and update the references in my project. If I keep using the same folder then Visual Studio does not refresh the DLL but uses an existing cached copy.

To add the DLL’s right-click the project name to the right of the Visual Studio window and choose Properties (or press Alt+Enter):

image

Change to the Reference’s tab and click Add > Browse to find and add these two DLL’s.

image

You should see the two DLL’s listed as well as the default references for DLL’s included in the class library template that you used in Visual Studio.

Back on the code, its time to make the changes. Each of the changes and why it is needed are detailed based on the line numbers above

Line 7 – Namespace

This value of the namespace for the transport agent. Standard conventions indicate that this should be your company name. Therefore in your code change XXXXX to C7Solutions

Line 9 – NotInheritable Class

This value, YYYYYY, is the class that you are creating. This class inherits all the functionality of the Microsoft.Exchange.Data.Transport.Smtp.SmtpReceiveAgentFactory class. For this partial catch-all agent, a good name would be PartialCatchAllFactory.

Line 13 and 18 – Public Class

The Public Class contains the code to execute when the agent is called. This class has a name (ZZZZZ in the sample code above) and should be given a name that represents what the code does. This name in this example can be PartialCatchAll and it needs to be used in Line 13 (inside the PartialCatchAllFactory code to indicate the code to call instead of SmtpReceiveAgentFactory. And of course it is needed on line 18 to name the actual block of code. The name to use for this example will be PartialCatchAll

Line 21 – Handler

This line is missing the end of the code. Its a line that says run the code in this subroutine if the OnEndOfData event is called. Change the end of the line to read Me.OnEndOfData. This value should be one of the suggestions in the drop down list if you have done everything correct so far:

image

This subroutine also returns e as a pointer to the email message (i.e. you can modify e.MailItem.DeliveryPriority and many other properties) and source as a reference to the SMTP connection (i.e. with source.Disconnect you would close the SMTP session).

In this code lines 34 and 37 change the recipient. Line 34 removes the first recipient and then line 37 adds a new recipient that matches the alias + the domain.

Line 31 – Modify Subject

Finally, this code is missing the start of line 31. You need to enter e.MailItem.Message.Subject =  at the start of the line so that they subject becomes [tag] + original subject.

Building the Transport Agent DLL

The Errors List at the bottom of the Visual Studio screen should be empty by now. So time to build the project. If you have not saved this project in Visual Studio, the DLL will be created in the %temp% directory, so best recommendation is to save the project before building the DLL.

To save the project click File >  Save All and enter a suitable name for the project.

image

The project name becomes the solution name by default and then click Save.

The final thing to check before you build the DLL is the Root namespace value. This should be set to the name of the class library and can be set during creation of the library. If you have written your library in VB.Net then you will need this value to register the DLL. If you used C# then you will not need this value. As we have used VB.Net above, we need to check the root namespace value. This can be found on the project properties page.

image

If your DLL is ready to release (i.e. you have build and tested it already) then choose Build > Configuration Manager menu. Change the Active solution configuration to Release and click Close. If you do not make this change then the DLL will be created in the project_name\bin\debug folder and its possible that Visual Studio does not compile all the optimizations to the code that it can. For production items that perform at as good a speed as you can write optimal code, you should change this to Release for the Configuration value. The DLL will be created in project_folder\bin\release.

To build your DLL (debug or release) select the Build > Build RootNamespaceValue menu. This will create a DLL in project_name\bin\debug or project_name\bin\release.  A working version for Exchange 2010 SP2, RU4 can be downloaded from here.

Installing the Transport Agent

Copy the DLL to all your Exchange Servers that have the hub transport role installed on them (or if this should only apply to emails inbound from the internet, then just the servers that are listed on your MX records or the first servers connected to for inbound emails). Place the file in a directory (say C:\C7Agents) and run the following five lines from Exchange Management Shell:

Install-TransportAgent -Name “C7PartialCatchAll” -AssemblyPath “C:\C7Agents\MECDemoPartialCatchAll.dll”
-TransportAgentFactory “MECDemoPartialCatchAll.C7Solutions.PartialCatchAllFactory”

Enable-TransportAgent “C7CatchAll”

Restart-Service MSExchangeTransport

IISRESET

# Recommend closing EMS window now

Note that this restarts the transport service (required) and IIS (which will effect OWA and other CAS roles on the same machine). Remote Powershell (an IIS resource) will lock the DLL open, and so if you need to delete the DLL after uninstalling it, you need to have reset IIS and closed the Powershell window.

Finally, send an email to name_value@yourdomain.com where name is the part of your email address before the @ in Exchange and yourdomain.com is your domain. The value in “value” will be added to the subject as [value]. You get get an email in this form you know your agent has worked.

Transport Agents and Exchange 2013

I’ve also written an additional blog post on the changes for Exchange Server 2013 and transport agents. This covers the things to consider that are different with regards to Exchange 2007/2010 and the new Exchange.

Installing and Configuring AD RMS and Exchange Server

Posted on 4 CommentsPosted in 2007, 2008 R2, 2010, active directory, certificates, exchange, exchange online, microsoft, networking, Office 365, organization relationships, owa, rms, server administrator

Earlier this week at the Microsoft Exchange Conference (MEC 2012) I led a session titled Configuring Rights Management Server for Office 365 and Exchange On-Premises [E14.314]. This blog shows three videos covering installation, configuration and integration of RMS with Exchange 2010 and Office 365. For Exchange 2013, the steps are mostly identical.

Installing AD RMS

This video looks at the steps to install AD RMS. For the purposes of the demonstration, this is a single server lab deployment running Windows Server 2008 R2, Exchange Server 2010 (Mailbox, CAS and Hub roles) and is the domain controller for the domain. As it is a domain controller, a few of the install steps are slightly different (those that are to do with user accounts) and these changes are pointed out in the video, as the recommendation is to install AD RMS on its own server or set of servers behind a IP load balancer.

Configuring AD RMS for Exchange 2010

The second video looks at the configuration of AD RMS for use in Exchange. For the purposes of the demonstration, this is a single server lab deployment running Windows Server 2008 R2, Exchange Server 2010 (Mailbox, CAS and Hub roles) and is the domain controller for the domain. This video looks at the default ‘Do Not Forward’ restriction as well as creating new templates for use in Exchange Server (OWA and Transport Rules) and then publishing these templates so they can be used in Outlook and other Microsoft Office products.

 

Integrating AD RMS with Office 365

The third video looks at the steps needed to ensure that your Office 365 mailboxes can use the RMS server on premises. The steps include exporting and importing the Trusted Publishing Domain (the TPD) and then marking the templates as distributed (i.e. available for use). The video finishes with a demo of the templates in action.

Create Shadow Redundancy Cross Forest in Exchange 2010

Posted on Leave a commentPosted in 2010, IAmMEC, mcm, transport

 

Send connector cross forest shadow redundancy

New-SendConnector ToTailspin -AddressSpaces SMTP:tailspin.com -SmartHosts mail.tailspin.com -ProtocolLoggingLevel verbose -DNSRoutingEnabled $False -SmartHostAuthMechanism ExternalAuthoritative
Get-SendConnector ToTailspin | Add-ADPermission -user "MS Exchange\Externally Secured Servers" -ExtendedRights ms-Exch-SMTP-Send-XShadow

Receive connector cross forest shadow redundancy

New-ReceiveConnector FromFabrikam -RemoteIPRanges 192.168.100.1 -Bindings 0.0.0.0:25 -ProtocolLoggingLevel verbose -Banner "220 Tailspin XShadow SMTP Server" -AuthMechanism ExternalAuthoritative 
Get-ReceiveConnector FromFabrikam | Add-ADPermission -user "MS Exchange\Externally Secured Servers" -ExtendedRights ms-Exch-SMTP-Accept-XShadow

How To Speed Up Exchange Server Transport Logging

Posted on 1 CommentPosted in 2007, 2010, 2013, exchange, mcm, microsoft, transport

In Exchange 2010 SP1 and later any writing to the transport log files for activity logging (not the transaction logging on the mail.que database) is cached in RAM and written to disk every five minutes.

In a lab environment you might be impacted by this as you might have sent an email and want to check the logs for the information they contain for diagnostic reasons. The problem is you might need to wait five minutes to get this information.

Exchange 2010

To reduce the memory cache time to 30 seconds set the following two entries in the Edge.Transport.exe.config file (found in \Program Files\Microsoft\Exchange Server\v14\bin) within the AppSettings area:

<add key="SmtpSendLogFlushInterval" value="0:00:30" />
<add key="SmtpRecvLogFlushInterval" value="0:00:30" />

The two values above control different log files. Each transport log file has a different setting – so its possible to set Receive Connector protocol logging to a different value from Send Connector protocol logging if you wanted to. Once you make your changes to Edge.Transport.exe.config you need to restart the Microsoft Exchange Transport service for the changes to be picked up.

Here is a list of the properties that I know about that can be changed:

  • SmtpSendLogFlushInterval – Timespan value on how often to write the Send Connector protocol logging log to disk
  • SmtpRecvLogFlushInterval – Timespan value on how often to write the Receive Connector protocol logging log to disk
  • ConnectivityLogFlushInterval – Timespan value on how often the Connectivity log is written to disk.

In addition to the above, which are all timespan values for how often to write to disk, if the memory buffer that contains the log entries fills up then it will be written to disk as well. The default memory buffers are 1MB. So on a very busy server you might find that the log writing is not every five minutes exactly but of a more “random” nature as the buffer is filled. The following settings control the size of the buffer for the above timespans:

  • SmtpSendLogBufferSize
  • SmtpRecvLogBufferSize
  • ConnectivityLogBufferSize

Exchange 2013 CU1 and Later

The process for this version of Exchange is similar, just different log files because of the different services in use.

In Exchange 2013 you have transport services for mailbox (submission and delivery), transport core and CAS (frontend transport). The config files for these services are:

  • EdgeTransport.exe.config (transport core)
  • MSExchangeFrontEndTransport.exe.config (Frontend Transport on the CAS role)
  • MSExchangeDelivery.exe.config (for mailbox delivery on the Mailbox role)
  • MSExchangeSubmission.exe.config (for mailbox submission on the Mailbox role)

You will find these config files in \Program Files\Microsoft\Exchange Server\v15\bin.

 

Configuring Exchange Server 2013 Unified Messaging With 3CX and Not AsteriskNOW

Posted on 11 CommentsPosted in 2010, 2013, asterisk, asterisknow, exchange, pbx, unified messaging, voicemail, voip

This article is an addendum to my blog series on configuring Exchange Server 2010 and Exchange Server 2013 with AsteriskNOW. AsteriskNOW is a easy to install version of Asterisk 1.8 in that it includes the underlying OS and the FreePBX software. The problem with Asterisk 1.8 is that it does not work well with the correct process of connecting to Exchange Server unified messaging servers.

Asterisk and Issues with Exchange Server and SIP Diversion

Exchange Server runs two unified messaging services, umservice.exe (on Exchange 2010 and Exchange Server 2013 Mailbox Servers) or Microsoft.Exchange.UM.CallRouter.exe (on Exchange Server 2013 Client Access Servers) that listens on TCP 5060 and UMWorkerProcess.exe (both versions of Exchange Server) that listens on TCP 5065 or TCP 5067. The correct process for connecting to Exchange Server unified messaging is to connect to TCP port 5060 and get back a SIP Redirect to either port TCP 5065 or TCP 5067. The reason for the redirect is that Exchange Server starts listening on 5065 and after a week starts a second process listening on 5067 and once the process on 5065 has finished all its call handling it will stop the process listening on 5065. This way Exchange Server manages the process, memory management, etc. without needing to restart the process if it goes bad – it just starts a process on the other port from the current process and directs all new calls at the new process.

The problem with Asterisk 1.8 is that is looses the caller ID during this redirect. Therefore all the posts you will see on the internet for Exchange and Asterisk use port 5065 directly and a few (very few) deal with the issue that this only works for a week before they need to change to port 5067 and so on.

On Exchange Server 2010, as both the umservice and the UMWorkerProcess are on the same machine, you can just connect to 5065&5067 at the same time and Asterisk will complete the call down the channel that answers.

Like Exchange Server 2010, the 2013 version allows you to direct voicemails at any unified messaging server and have them turn up in your inbox. You do not need to connect to that actual server your mailbox is located on – but ideally you would, as that will spread any load caused by voice across all the servers that store mailboxes. If you are connecting to a server in one location, your mailbox could be in another and so ideally you would connect to a mailbox server local to your mailbox, but as Asterisk does not manage the diversion correctly this will not happen.

On of the headline features of Exchange Server 2013 is the load-balancing without needing layer 7 hardware. This not going to work for Exchange Server 2013 and Asterisk as you will always get sent to the IP address of the trunk as configured in Asterisk and not the server your mailbox is located on.

The connectivity flow for Exchange UM is that the CAS role runs the Microsoft.Exchange.UM.CallRouter.exe process (port 5060) and the Mailbox role runs the umservice.exe (port 5062) and the UMWorkerProcess.exe (port 5065 or 5067)*. Therefore your PBX needs to talk to a CAS server on port 5060 (and can do this via a Layer 4 load balancer if they wish) and then the SIP call is redirected to the correct mailbox server for that user at that time. The following screenshot shows the error state in action:

image

From the above Asterisk console session you can see the following steps caused when the user at extension 8001 picks up the phone and calls the subscriber access number for the dialplan (8500):

  • Called SIP/TrunkName/8500
  • Got SIP response 302 “Moved Temporarily” back from CAS_Server_IP:5060
  • Now forwarding SIP/Call-ID to ‘SIP/8500::::TCP@mailboxserver_fqdn:5062’ (thanks to SIP/TrunkName-CallID)

The connection has been routed from the CAS server to the Mailbox server that holds the users mailbox and to the umservice.exe on that mailbox server. It is this service that knows the current port the UMWorkerProcess is running on on (5065 or 5067). So the connection flow continues with:

  • Got SIP response 302 “Moved Temporarily” back from mailbox_server_IP:5062
  • Now forwarding SIP/Call-ID to ‘SIP/8500::::TCP@mailboxserver_fqdn:5065’ (thanks to SIP/mailbox_server_fqdn:5062-CallID)
  • SIP/mailbox_server_fqdn:5065-CallID is ringing
  • SIP/mailbox_server_fqdn:5065-CallID answered SIP/8001-CallID

Exchange then answers with “Sorry, the person you are trying to reach does not have a valid voice mailbox on our system. Goodbye”. This is because in all the diversions (SIP 302) Asterisk looses the From: header which shows which phone the user is calling from and replaces it with the subscriber access number. Configure Asterisk to connect directly to 5065&5067 on a mailbox server and it all works fine, but latency for offsite mailboxes is not catered for, nor is any degree of HA.

So, as Asterisk has issues doing an Exchange Server 2013 multi server deployment that it could do with Exchange 2010, I have added this article to the blog series to explain why this is so and the steps for another IP PBX to solve the issue. Therefore we will look at configuring 3CX instead as an example IPPBX. 3CX with Exchange Server support is a paid for product, but at the time of writing you get a 2 call demo licence when you register to get a download – and a two concurrent call licence is enough for a lab.

Configuring 3CX for Exchange Server 2013

As the process for installation of 3CX is well documented, all I am going to do here is call out the steps that you need to do to get the system working with Exchange Server.

  • Download the free version
  • You will get an email with a licence key for 2 concurrent calls
  • Install the free version on a Windows Server, but not on any of the Exchange Server 2013 machines as both Exchange and 3CX will want to open port 5060.
  • During installation I choose to go for IIS as the web server.
  • Create two extensions during installation. I went for 5001 and 5002, one for each of my SIP phones. Note that if you configure your phones at the same time as you create the extensions they will not register with the server until after installation is complete.
  • Ensure that you enable voicemail for the extension.
  • Activate the software with the demo licence key you have (Settings > Activate Licence)
  • Configure your VoIP Provider settings including an Outbound Rule for sending calls to this provider.
  • Configure Exchange dialplan and UM gateway and UM enable mailboxes with the same extension number as used in 3CX
  • On Settings > Advanced choose the Exchange Server tab and enter the IP address of your Exchange CAS Server or CAS server load-balanced virtual IP. Set the port to 5060 and tick the box to use voicemail on your Exchange Server

You should now be able to place calls between your handsets and have the call forwarded to Exchange for voicemail.

 

 

* Note that if you are using TLS protected SIP (SIP Secure) then the port numbers in the above article are incorrect and are all +1. Therefore Microsoft.Exchange.UM.CallRouter.exe listens on 5061, umservice.exe on 5063 and UMWorkerProcess.exe listens on 5066 or 5068.

Building An Exchange Unified Messaging Lab (Part 8)

Posted on 6 CommentsPosted in 2010, 2013, asterisk, asterisknow, exchange, pbx, unified messaging, voicemail, voip

In the extended series of blog posts we are looking at creating a unified messaging lab for Exchange Server. So far we have looked at installing a software PBX (AsteriskNOW) and configuring Exchange Server (both 2010 and 2013) to accept calls from our PBX. We have also looked and configuring our PBX to send and receive calls to a SIP provider on the internet.

In this post we will configure our PBX to forward calls for our voicemail access number (8000 and 8500 in the blog series) to the Exchange Servers in the lab. Dialling 8000 will call my Exchange Server 2010 lab and dialling 8500 will call my Exchange Server 2013 lab. If you only have one lab environment, then you only need one set of trunks configured.

Configuring SIP Trunks To Exchange Server 2010 from Asterisk

Login to your FreePBX website and click Connectivity > Trunks and click Add SIP Trunk.

imageThis trunk will be configured with the settings of your Exchange Server unified messaging server and have a name such as “ToExchangeUM5065” for both Trunk Name fields (at the top of the screen and under Outgoing Settings). There are no settings needed under Incoming Settings or Registration. Note that the name of this trunk must match the name you selected when configuring the config file in the previous post. If you set the voicemail macro in Asterisk to use the wrong name it will not be able to forward the call anywhere.

The main part of the settings for the trunk is the PEER Details field. For my lab this reads as follows:

host=w.x.y.z ;IP address of the Exchange UM Server
type=peer
transport=tcp
port=5065
context=from-internal
qualify=yes

This creates a trunk with the IP address of the Exchange UM server, using TCP, over one of the ports that the UMWorkerProcess on Exchange listens on and has the qualify=yes setting to tell Asterisk to check if the server is up and running by connecting to it occasionally and sending an SIP OPTIONS header.

Once your first trunk is created you need to create a second trunk. This trunk has a different name and port. The name (following the above example) can be “ToExchangeUM5067” and the port value reads port=5067. All the other settings are the same.

imageOnce the trunks are complete you need to make the Outbound Routes that will be used to forward calls down this trunk. Click Connectivity > Outbound routes and provide a Route Name and a Dial Pattern and finally the Trunk Sequence for Matched Routes value.

For the Dial Pattern you just need to enter the number that users will call to access their voicemail and for the Trunk Sequence you just need to select the two Exchange trunks that you made earlier. Finally, click Apply Config to have all the changes submitted to the Asterisk config files and to have Asterisk reloaded.

As Asterisk does not do Diversion headers correctly (it looses the caller ID during diversion) I have an another article in this series looks an using 3CX. This different IPPBX does the diversion correctly.

Testing Your Unified Messaging Lab

You should now be able to call another extension, wait or reject that call at the destination, and be routed to Exchange Server voicemail. Once the message has been left the recipient of the call should receive an email with your message. If they click the Play on Phone option in Outlook, then their phone should ring and the message be played to them.

If you get an errors or unexpected results then make your calls whilst watching the server console. Run asterisk -Rv from the console and then make calls. You should see many messages and scrolling back through them, using screen before running asterisk –Rv and CTRL+A and [ to access the screen log, will show you messages containing “SIP/ext is ringing”, “Got SIP response 486 Busy Here”, and many lines further on “Executing [s-BUSY@macro-vm:4] Dial(‘SIP/ext-callID’,’SIP/xxxx&SIP/yyyy’) in new stack”. Either trunk xxxx or yyyy will answer with “SIP/yyyy-CallID answered SIP/ext-CallID”. Four or five more lines should take you to the end of the call log.

My final post in this series looks at doing all the same again, but using a different IP PBX – a commercial one called 3CX, but one that has a fully functioning demo licence for two concurrent calls and so is ideal for building labs with. This is covered in Using 3CX and Not Asterisk and Exchange Server.

Building An Exchange Unified Messaging Lab (Part 7)

Posted on Leave a commentPosted in 2008, 2010, 2013, asterisknow, exchange, rtp, sip, unified messaging, voicemail

In this series of blog posts I am looking at creating a Unified Messaging lab for Exchange Server 2010 (and 2013). Earlier posts have looked at the installation of the PBX (AsteriskNOW) and the configuration of the Exchange Server.

This post will look at the configuration of the user’s settings. For each user there are two settings to configure. The first are the related settings on the telephone and the second is the configuration of the unified messaging properties on the Exchange mailbox.

The first set of settings are covered in detail in Part 4 of the blog but in brief they involve choosing a unique extension number that has the same number of digits as the dialplan (all extensions must be unique within the dialplan) and creating this extension within the PBX and configuring a phone to use this extension. Once you have done the steps in Part 4 of the blog you should be able to ring any of your extensions and pickup the call.

If you ignore the call or press any “reject” button on the handset you will find that Asterisk voicemail answers the phone. So this part of the blog series will go into the steps to configure Asterisk to forward voicemail to Exchange Server (and this is the same for Exchange Server 2010 or 2013).

Configuring Unified Messaging Mailboxes in Exchange Server

For each user you need to associate their mailbox in Exchange with their extension number. You can do with the Enable-UMMailbox cmdlet or the Enable Unified Messaging wizard in the Exchange Management Console.

For the wizard, right-click the mailbox under Recipient Configuration and select the Unified Messaging Mailbox Policy that you created earlier. Then either choose a PIN or have the system generate on for the user automatically. The user will get an email informing them of their PIN either way. Click Next.

imageIf the user already has the Business Phone attribute (or Telephone number attribute on the General tab in Active Directory Users and Computers) populated in Active Directory then the option to automatically generate the mailbox extension will be available, and the extension will be shown (greyed out) in the field to the right. If this is incorrect, or a full phone number was not specified, then only the manual option will be available.

The Exchange Management Shell cmdlet to do the same is:

Enable-UMMailbox username -PinExpired $false -UMMailboxPolicy 'policy_name'

 

 

or, if you want to specify the extension number:

 

Enable-UMMailbox username -PinExpired $false -UMMailboxPolicy 'policy_name' -Extensions '8001'

 

 

As each mailbox is enabled for unified messaging, the mailbox will get an email telling them the access numbers for voicemail (the dialplan subscriber numbers), their number (which should be the same as their telephone extension number) and their PIN.

 

On the mailbox, if you look on the E-mail Addresses tab you will see the EUM address, and this should read ext;phone-content=policy. You can add additional extensions (EUM addresses) here manually if you wish.

 

Configuring and Using Outlook Voice Access

 

Now that you have the extension configured on a phone, the same extension configured against the mailbox, a dialplan with subscriber access number configured, SIP trunks to Exchange and an Outbound Route for the subscriber access number you should be able to ring the subscriber access number from your physical handset.

 

Upon dialling from the phone configured with your extension number you will hear the Exchange chimes and be asked to setup your Outlook Voice Access for the first time. You will need your PIN number to complete this, and this will have been emailed to the mailbox at the time the mailbox was configured for UM.

 

Configure Asterisk to Forward Calls to Exchange Unified Messaging for Voicemail

 

Asterisk defaults to forwarding calls to its own voicemail extensions and so edits need to be made to extensions.conf (or linked files if using FreePBX) to route calls to Exchange Server for voicemail.

 

In this blog series we have FreePBX installed, so we need to edit /etc/asterisk/extensions_override_freepbx.conf rather than extensions.conf. The first change is to copy the [macro-vm] section from /etc/asterisk/extensions_additional.conf into /etc/asterisk/extensions_override_freepbx.conf. [macro-vm] is approx 150 lines long and ends with “;–== end of [macro-vm] ==–;”.

 

Then we need to make some changes and additions to the macro-vm section. The first set of changes will comment out the code the directs calls to Asterisk voicemail and the additional lines will dial the Exchange Server trunks and add SIP Diversion headers so that Exchange knows which mailbox to answer the call for.

 

So first, locate the following lines and comment them out. The numbers in brackets at the start are the approx. location in extensions_override_freepbx.conf where you will find the line:

(86) exten => s-BUSY,n,VoiceMail(${MEXTEN}@${VMCONTEXT},${VM_OPTS}b${VMGAIN})
(92) exten => s-NOMESSAGE,n,VoiceMail(${MEXTEN}@${VMCONTEXT},s${VM_OPTS}${VMGAIN})
(97) exten => s-DIRECTDIAL,n,VoiceMail(${MEXTEN}@${VMCONTEXT},${VM_OPTS}${VM_DDTYPE}${VMGAIN})

 

Each of the above lines can be commented out by placing a semi-colon (;) at the start of the line.

 

Return to the s-BUSY block (starting at line 84) and add the following after the line that you just commented out:

exten => s-BUSY,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-BUSY,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-BUSY,n,Hangup

 

This code adds the Diversion header to read tel:extension. Note that the tel:ext block is surrounded by greater and less than signed (triangle brackets if you will) which have a habit of not being displayed on web pages.

 

Also note that you need to use the names of your two trunks connecting to Exchange that you will make in the final part of this blog series (Part 8). You will make one trunk connecting to port 5065 and the other to port 5067. The Dial() command tells Asterisk to dial both trunks at the same time and direct the call to whichever answers first. Therefore if Exchange is listening on 5065 or 5067 the connection will work. For ease of configuration, if you pick the names for the two trunks now you can add them to the config file here and then when you create the trunk in Part 8 you just need to use the same names. I used ToExchangeUM5065 and ToExchangeUM5067 in my lab. Then I replace xxxx with ToExchangeUM5065 and yyyy with ToExchangeUM5067.

 

The s-NOMESSAGE block (at line 92) needs the following added after the line that has been commented out:

exten => s-NOMESSAGE,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-NOMESSAGE,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-NOMESSAGE,n,Hangup

 

Again, change xxxx and yyyy for your two different trunk names that you create in the next part of this blog and make sure that the Diversion: header includes triangle brackets around tel:ext.

 

Next you need to do the same for the s-DIRECTDIAL block:

exten => s-DIRECTDIAL,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-DIRECTDIAL,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-DIRECTDIAL,n,Hangup

 

As you can see, the three blocks of inserted code are all the same apart from the s-WORD value at the start of each.

 

One block of code is missing through from the FreePBX defaults. If you call an extension and it is busy Asterisk runs the code starting s-BUSY, but if the call is ignored then Asterisk attempts to find and run code starting s-NOANSWER and as this is missing it will route ignored calls to Asterisk voicemail. To route ignored calls to Exchange Server add the following block of text:

exten => s-NOANSWER,1,Noop(NOANSWER voicemail - Exchange UM)
exten => s-NOANSWER,n,Macro(get-vmcontext,${MEXTEN})
exten => s-NOANSWER,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-NOANSWER,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-NOANSWER,n,Hangup
exten => s-NOANSWER,n,Goto(exit-${VMSTATUS},1)

 

This new block is again a copy of s-BUSY (or the other two) and just the s-WORD bit changed to s-NOANSWER. For completion the Noop line (line 1 above) is also changed to NOANSWER so that the correct text is written to the Asterisk console and log files.

 

No other changes are needed in extensions_override_freepbx.conf. So save the file and restart Asterisk by using amportal restart from the console.

 

There is now one more thing to do. That is to create the SIP Trunks to Exchange Server. This is detailed in Part 8, and once you have a way to connect to Exchange Server you are able to route voicemail requests to Exchange and complete your unified messaging lab.

Building An Exchange Unified Messaging Lab (Part 6)

Posted on Leave a commentPosted in 2010, 2013, asterisk, asterisknow, exchange, pbx, unified messaging, voicemail, voip

Earlier parts in this blog have talked about VoIP, configured AsteriskNOW software PBX and configured inbound and outbound calls via the PBX. Now it is time to configure voicemail to be provided by Exchange Server 2013 and for the telephone users to be able to call Exchange an listen to their voicemail. In addition to listening to voicemail, when a user logs into Exchange Server via their telephone handset Exchange can read and the user change items in their mailbox (i.e. delete email, change calendar bookings) and direct calls to other users.

This blog article will look specifically at Exchange Server 2013. The preceding article repeats the steps here, but for Exchange Server 2010. So lets start by configuring all the required pieces on the Exchange Server.

Configuring Exchange Server 2013 Unified Messaging

The first thing to set up in Exchange Server 2013 with regards to Unified Messaging is the mailbox server role. Unified Messaging is automatically installed on the mailbox role. Once the role is installed go to the Voice area of Exchange Control Panel.

image

By default Exchange is installed with the United States language pack. Download and install the correct unified messaging language packs for your country before you proceed further or Exchange will answer you in the wrong language. 

The first thing that you need to create is the UM Dial Plan with the correct number of digits (four in the case of this blog), set Unsecured for VoIP Security, enter your Country/Region code (for example 44 for the UK) and choose the language you want the server to answer callers in. Unlike Exchange Server 2010 you do not associate dial plans with servers unless you are using Lync Server as the PBX.

On the UM IP Gateways screen add a gateway for the IP address of your PBX.  Exchange requires TCP support and we covered the steps for configuring Asterisk in Step 3 to support SIP over TCP.

image

If you are using a PBX that supports custom ports for SIP over TCP (Asterisk 1.8 does not support changing the TCP port for SIP) then remember to adjust the port in Exchange Server. You set the port if different from 5060 using Exchange Management Shell: Set-UMIPGateway –identity BlogGateway -Port 5065 for example.

You also need to select the dial plan you just created and a display name for the UM Gateway.

Unlike Exchange 2010, there will be nothing in the Event Viewer upon successful creating an IP Gateway. Also you are not required to associated the dial plan with a UM Server. The PBX should be configured to forward all calls to the front-end CAS array and CAS redirects the call to the Mailbox server that holds the users mailbox for answering by the Unified Messaging service.

Now that you have the initial configuration complete, go back to the UM Dial Plans screen and open the dial plan that you created earlier. You will need to associate a subscriber access number with this dial plan. This is the number that users will call to listen to their voicemail. Exchange Server will be informed of the dialled number when the PBX forwards the call to it, and so the number called must be associated with a mailbox or be the subscriber number. In other PBX systems, this number is often called the Pilot Number. In the lab we are building here, with a four digit dial plan, the chosen subscriber number is 8500.

To add the subscriber number click the configure UM dial plan button on the UM Dial Plan properties screen and change to Outlook Voice Access tab

image

Change any of the the remaining properties as required before saving your changes.

Back on the UM Dial Plan screen edit the default UM Mailbox Policy as required. I would suggest for a lab environment that you have a 4 digit PIN and no requirement to reset it.

image

For the purposes of the lab we are not going to configure the UM Auto Attendants and we will just use the default hunt group created.

The previous blog post covered these same settings for Exchange Server 2010. The next part, Part 7 will look at configuring users (mailboxes) to have valid unified messaging settings and then Part 8 will look at the configuration on the PBX to create a trunk to reach your Exchange Server and the settings to forward voicemail messages to the Exchange Server. These following posts look at the configuration mainly from an Exchange 2010 viewpoint, but will work for Exchange Server 2013.

Building An Exchange Unified Messaging Lab (Part 5)

Posted on Leave a commentPosted in 2010, asterisk, asterisknow, exchange, unified messaging, voicemail, voip

Earlier parts in this blog have talked about VoIP, configured AsteriskNOW software PBX and configured inbound and outbound calls via the PBX. Now it is time to configure voicemail to be provided by Exchange Server and for the telephone users to be able to call Exchange an listen to their voicemail. In addition to listening to voicemail, when a user logs into Exchange via their telephone handset Exchange can read and the user change items in their mailbox (i.e. delete email, change calendar bookings) and direct calls to other users.

This blog article will look specifically at Exchange Server 2010. The following article will repeat the steps here, but for Exchange Server 2013. So lets start by configuring all the required pieces on the Exchange Server.

Configuring Exchange Server 2010 Unified Messaging

The first thing to set up in Exchange Server 2010 is to ensure that you have the Unified Messaging role installed on at least one Exchange Server. This role can be shared with any other role apart from the Edge Server role is you need to. Once the role is installed go to the Unified Messaging area under Organization Configuration in EMC.

By default Exchange is installed with the United States language pack. Download and install the correct unified messaging language packs for your country. These are service pack dependent, so install the correct one.

For Exchange 2010 create a UM Dial Plan with the correct number of digits (four in the case of this blog), set Unsecured for VoIP Security and enter your Country/Region code (44 for the UK).

image

Click Next and associate the server on which you installed the UM role with this dialplan.

In the UM IP Gateways dialog add a gateway for the IP address of your PBX. Exchange requires TCP support and we covered the steps for configuring Asterisk in Step 3 to support SIP over TCP.

image_thumb3

If you are using a PBX that supports custom ports for SIP over TCP (Asterisk 1.8 does not support this for TCP) then remember to adjust the port in Exchange Server. You set the port if different from 5060 using Exchange Management Shell: Set-UMIPGateway –identity BlogGateway -Port 5065 for example.

The application event log will show if there are errors in the IP Gateway configuration. If there are no errors and Exchange is able to communicate successfully with your PBX over TCP then it will report Event ID 1401

The following UM IP gateways responded promptly to a SIP OPTIONS request.
Transport = TCP, Address = 192.168.5.100, Port = 5060, Response Code = 200, Message = OK

If you change your view to the UM Mailbox Policies tab then you can see the default mailbox policy that has been created for you. You might want to change this, but at the very least you need to check its settings. For a lab environment I suggest a 4 character PIN, no PIN lifetime and 1 previous PINs to disallow.

image

For now you do not need to create a UM Auto Attendant and so we will skip this section of the configuration for you to return to in your own time later.

Now that you have the initial configuration complete, go back to the UM Dial Plans tab and open the dial plan that you created earlier. You will need to associated a subscriber access number with this dial plan. This is the number that users will call to listen to their voicemail. Exchange Server will be informed of the dialled number when the PBX forwards the call to it, and so the number called must be associated with a mailbox or be the subscriber number. In other PBX systems, this number is often called the Pilot Number. In the lab we are building here, with a four digit dial plan, the chosen subscriber number is 8000:

image

Finish the remaining tabs in this dialog by entering valid Dial Codes and other options as you need to:

image

Change to Server Configuration > Unified Messaging in the Exchange Management Console and double-click your unified messaging server. Ensure the UM Settings properties reads TCP for startup mode and if you change this ensure that you restart the Microsoft Exchange Unified Messaging service.

The next blog post will cover these settings for Exchange Server 2013 and then the two following will look at the mailbox configuration and the configuration on the PBX to create the trunks to reach Exchange Server and the settings to forward voicemail messages to the Exchange Server.