in

UCSpot

Your source for Unified Communications information.

Microsoft Exchange

  • Exchange UM connected to a PBX

     

    3/7/2008

    Exchange UM with a PBX

    When setting up exchange um some things need to be considered. on the initial setup page for the dial plan with in exchange there are sevral options. And if you are not careful and select the wrong option UM will not work. it is important to understand the options. In the URI type you have a choice for 

    telephone extension

    Telephone extension is what you want to use when connecting to a PBX directly or a sip gateway directly. this may not always be the case but if you know what it is looking for then it will help you decide. for telephone extension it is simply looking to match the extension numbers. and that is all.

    E.164 

    E.164 looks to see an e.164 number coming from the pbx or gateway. Which can be used in conjunction with a gateway that normalizes to e164 or in locations that already pass e.164 to the gateway.

    Sip URI 

    Sip URI looks to match to a sip URI. (this is usually used when setting up OCS to exchange UM)

     

    image

    So to begin with when you create a dial plan you have the ability to select the URI type. In most cases if this is direct to the pbx or to a gateway it will be Telephone extension. If you select sip URI or tel URI it is possible for you to have some problems because of the way information is passed from the pbx.

    i.e. 6554@10.1.1.1 which is how the pbx may send the information in the sip invite. with 10.1.1.1 being the address of the PBX.  if you select sip uri or sip tel uri exchange will not be able to find this extension or person because the exchange sip uri's will not have the IP of the PBX in them (or at least they should not)

    your sip  uri should be your primary email address for best practice (even though some do not follow this) and your tel uri should be an e.164 number i.e. +19139559555 or +19139559555;ext=6554. and since neither will match the previous address with the PBX IP in it. Then the exchange server will return SIP/2.0 302 Moved Temporarily.

    So for pbx to exchange you should select extension. so where does the secure verses non-secure come in.

    your next selection allows you 3 options unsecured, Sip Secure and Secured. in most cases when you are configuring exchange UM to a pbx or gateway and not through OCS this will be set to unsecured.

    image

    Realize that when you set it to secured or Sip Secured you CANNOT HAVE THIS CO-LOCATED on the cas role or hub transport.

  • Call Forking and Simultaneous ring are they the same?

    in a previous post I talked about call forking. So this week some presentations I went to started talking about simultaneous ring. Whet  I discussed this with the presenters I found that sometimes these 2 terms are synonymous. However some times they are not.

     

    from My understanding True Simultaneous ringing is where you have 2 devices with totally different numbers. When someone calls your extension or DID it comes into the PBX and then your desk phone rings and your cell phone rings near simultaneously. the big key to this is that the numbers are different.

    for Call forking it generally is referred to in situations where you have a desk phone and another device with the same phone number. i.e. desk phone and Microsoft Office Communicator. Both the desk phone and the MOC client have the same extension. The PBX forks the call to both devices at the same time and when one is picked up the other is released.

     

    Now it all depends on who you talked to as to the definition. I will try to find more detail over the next couple of days.

     

    thanks

  • Additions to the Single server migration

    One thing I left out that is very important is that the autodiscover service and some of the other services will cause certificate errors in a single server install that may have 2 seperate names and that you can not use Subject alternative names with the certificate. The best thing is to have split brain DNS setup. and then follow the steps in the article below.

    http://support.microsoft.com/default.aspx/kb/940726

     

    The biggest thing is that you have to have the split brain DNS setup. what this means is that if you have a domain name of Company.com on the internet. But your internal domain name is company.local then you need to have a zone setup on your internal DNS server for Company.com.

    If you do this be sure that any information you have out on the external DNS zone is copied to the internal zone. because your pc's will not be able to resolve any host in company.com that you have not setup.

  • Exchange 2007 Single server migration from 2003

    WOW what a week. I recently had to do an exchange 2007 single server migration from 2003 to 2007 it was great but there are some things that one must think about when doing this kind of deployment. one of the most important pieces is certificates. if you are putting multiple roles on the same server ie. mailbox/hubtransport/Clientaccess then you really need to think about certificates in depth.

    when you have a domain that is named differently then your external domain name then you may have some issues with TLS especially if you are using outlook 2007. if your internal server name is exch.domain.local and your external is webmail.domain.com then you may have an issue maintaining TLS internally for owa and for autodiscover.

    in order for outlook anywhere to work over the internet with tls the certificate has to match the website name you use. i.e. webmail.domain.com so if you purchase a public certificate they only allow subject alternative names for the same domain you are purchasing in most cases. So now when outlook tries to connect with TLS on the inside of your network. it will fail or come up with an error.

    you can turn off the use encryption for outlook 2007 and it will keep you from getting the popup. So you just need to plan your deployment well. There are many steps to a migration and I will try to list some of the got you's this week.

All content property of UCSpot.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems