none
Exchange 2010 SP1 - Add SIP Address to E-mail Address Policy

    Question

  • In the process of rolling out Cisco Unified Presence and Personal Communicator to my users, and in order to make it compatible with Outlook's Presence status, Cisco requires me to add a custom address of SIP:user@domain.com.

    I have been successful doing this individually by going to the user's properties box, clicking the E-mail Addresses tab, and adding Custom Type with the appropriate details. This works perfectly. Unfortunately, I have to do this in bulk, and since I have multiple e-mail address policies in place, I can't use "Set-Mailbox -EmailAddresses" since I won't be able to programmatically determine what their existing addresses are.

    So I thought, no problem-- I'll go to the e-mail address policies and add a custom type there. I went to Organization > Hub Transport > E-mail Address Policies. I selected one of my policies to test with, and navigated through the policy. I clicked Add > Custom Address, set the address as @domain.com and the type as SIP. I proceed through the wizard but upon processing it fails with the following error:

    The following error occurred during validation in agent 'Rus Agent': 'Failed to valid the proxy address template "SIP:@domain.com". Additional information: Failed to find the address type object in Active Directory for address type "SIP:AMD64".'

    I've done a lot of searching around and found an article elsewhere that in ADSIEdit > Configuration > Organization > Services > Exchange > Organization > Addressing > Address-Types, there is a list of attributes there that can be used, but SIP isn't one of them.

    The question I have is-- how can I make this happen? Is it possible to override it and force it to work, or to more appropriately add the SIP address type? This seems to be something that is becoming more and more common with the implementation of Lync Server and Unified Presence.

    Thanks for any assistance provided!

    Sunday, February 06, 2011 2:29 PM

All replies

  • The Cisco tools do not automatically create the sip addresses for you when you provision an account for presence?

     

     

     

    Sunday, February 06, 2011 2:55 PM
  • Not so far as I can tell. Wouldn't that have been great? :)

    UPDATE: It seems to be that it would provision it properly if I were properly using LDAP integration. Unfortunately, I can't do this in my environment, because my Exchange environment is a Resource Forest with linked mailboxes with authentication taking place on 3 alternate domains. Integrating with the Exchange domain wouldn't work because the user accounts are disabled.

    Sunday, February 06, 2011 3:00 PM
  • OK, for now , I am able to accomplish the goal using the information learned from this post on the Scripting forum.

    However, I still believe that the better approach is using e-mail address policies to manage this, and I find it incredibly shocking that SIP isn't a recognized address-type. Hopefully this thread can be pushed to the Exchange team for resolution in an upcoming Rollup or Service Pack.

    Is there a good way to submit this as a feature request to the Exchange team?

    Sunday, February 06, 2011 8:44 PM
  • On Sun, 6 Feb 2011 20:44:11 +0000, GoodThings2Life™ wrote:
     
    >
    >
    >OK, for now , I am able to accomplish the goal using the information learned from this post on the Scripting forum. However, I still believe that the better approach is using e-mail address policies to manage this, and I find it incredibly shocking that SIP isn't a recognized address-type. Hopefully this thread can be pushed to the Exchange team for resolution in an upcoming Rollup or Service Pack.
    >
    >Is there a good way to submit this as a feature request to the Exchange team?
     
    Why not push it back to Cisco? SIP isn't a protocol used by Exchange,
    so why should it be asked to generate the addresses used by another
    product? SIP, as an address type, works just fine when using OCS
    (which updates the proxyaddresses AD property, and the SIP address
    type shows up in the EMC and EMS).
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, February 06, 2011 10:25 PM
  • Rich,

    Thanks for the feedback. That's a fair question, and I'll give you three reasons:

    1. It's not Cisco's product that causes the issue. In fact, as I stated above, I'm pretty sure that Cisco Unified Presence-- just like Lync-- will update the property when properly LDAP/AD integrated. I'm not setup where either product can directly integrate, however, because I'm setup as a resource forest, and it would create challenges with authentication.

    2. SIP *is* used by Exchange. It's used in Unified Messaging to connect to phone systems and fax solutions. It's used in Outlook to provide Presence from both Cisco and/or Lync or other products, and it has the potential to be used by other communications products as part of a dominant standard.

    3. I can add *any* custom address type I want through user properties dialog or PowerShell script, including SIP or THINGAMABOB, and yet I can't elsewhere in the product.

    I want to note, here, that this isn't some snarky criticism of Microsoft or Exchange. I've been an Exchange administrator since 5.5 was first released. I think Microsoft makes absolutely wonderful products which is why I've always standardized my IT operations on those products. That doesn't mean there aren't problems to fix or, in this case, worthwhile features to add.

    This isn't even something that should be an issue. Someone on the Exchange team could literally copy the code for SMTP addresses, replacing SMTP with SIP, because the formatting and operations would essentially be the same. They already have the functionality for NOTES:, X.400, X.500, and CC:. My guess is that it was something that was simply an oversight, or at the time something that wasn't really used.

    For now, I have a suitable work-around, and that will satisfy my expectation, but I am raising awareness about an issue that has the potential to escalate as more customers are implementing Presence products in multi-domain environments.

    Sunday, February 06, 2011 11:50 PM
  • On Sun, 6 Feb 2011 23:50:02 +0000, GoodThings2Life™ wrote:
     
    >Thanks for the feedback. That's a fair question, and I'll give you three reasons:
    >
    >1. It's not Cisco's product that causes the issue.
     
    No, it's not. It's Cisco's failure to provide the necessary address
    generator that's the problem. If they (or you) expect Exchange to
    generate the addresses then there needs to be an address generator
    software to do so.
     
    >In fact, as I stated above, I'm pretty sure that Cisco Unified Presence-- just like Lync-- will update the property when properly LDAP/AD integrated. I'm not setup where either product can directly integrate, however, because I'm setup as a resource forest, and it would create challenges with authentication.
     
    >2. SIP *is* used by Exchange. It's used in Unified Messaging
     
    And the UM product generates the SIP address.
     
    >to connect to phone systems and fax solutions. It's used in Outlook to provide Presence from both Cisco and/or Lync or other products, and it has the potential to be used by other communications products as part of a dominant standard.
     
    The point isn't whether the SIP address type can appear in the
    proxyAddresses property, it's /how/ the address type is created. To
    have Exchange add the address type it's necessary to have an address
    generator.
     
    You say Cisco can, and will, generate the necessary address type but
    your AD design is a problem -- that's another problem, but easily
    solved if Cisco provided the address gnerator.
     
    >3. I can add *any* custom address type I want through user properties dialog or PowerShell script, including SIP or THINGAMABOB, and yet I can't elsewhere in the product.
     
    So if you used Fenestrae's FAX product you'd expect Microsoft to
    provide an address geneator for the "DIR" address type. If you used
    RightFAX you'd expect MS to provide an address generator for the
    "RFAX" address type? Keep in mind that the "SIP", "DIR", "RFAX" are
    not cast in stone. If you have competing products that want to use the
    same address type identifier (e.g. two different FAX products) both of
    them can't use the same address type.
     
    >I want to note, here, that this isn't some snarky criticism of Microsoft or Exchange. I've been an Exchange administrator since 5.5 was first released.
     
    Newbie. ;-)
     
    >I think Microsoft makes absolutely wonderful products which is why I've always standardized my IT operations on those products. That doesn't mean there aren't problems to fix or, in this case, worthwhile features to add.
     
    I'm not sure that this is one of those. The onus is on the OEM to
    provide the integration. MS provides the platform.
     
    But I'm not MS. Don't work for them and these are my opinions. If you
    want to suggest changes in the product your account rep (or TAM)
    should be able to direct you to the right place to make your case for
    a DCR.
     
    >This isn't even something that should be an issue. Someone on the Exchange team could literally copy the code for SMTP addresses, replacing SMTP with SIP, because the formatting and operations would essentially be the same. They already have the functionality for NOTES:, X.400, X.500, and CC:. My guess is that it was something that was simply an oversight, or at the time something that wasn't really used.
    >
    >For now, I have a suitable work-around, and that will satisfy my expectation, but I am raising awareness about an issue that has the potential to escalate as more customers are implementing Presence products in multi-domain environments.
     
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Monday, February 07, 2011 2:34 AM
  • Rich, I appreciate your feedback. I don't disagree on any one point, although your tone and referring to me as a "newbie" (didn't realize 20 years in IT was still "newbie" status) is a little off-putting. I don't take offense though, I'm here to solve an issue, not get into a conflict.

    All of your points-- while valid-- still don't change the fact that when I go to E-mail Address Policies (regardless of purpose) and attempt to add a "Custom Address" in a free-form manner (which is the clear intention of the UI design they created), it generates an ERROR message upon processing. So yes, it is definitely something that should be dealt with in some capacity. The documentation on Technet suggests that I should be able to do it and mentions no limitations on the use (perhaps a link I missed along the way, however). The dialog allows me to input SIP:@domain.com, so yeah, I don't think it's unreasonable to assume that it should be supported.

    Thanks again for the discussion! :)

    Monday, February 07, 2011 2:50 AM
  • On Mon, 7 Feb 2011 02:50:35 +0000, GoodThings2Life™ wrote:
     
    >Rich, I appreciate your feedback. I don't disagree on any one point, although your tone and referring to me as a "newbie" (didn't realize 20 years in IT was still "newbie" status) is a little off-putting.
     
    What I typed was "Newbie. ;-) ". Note the "winking" smilie?
     
    I started working in "IT" before it was ever called that -- 1969.
    Punch cards, wire panels, card sorters, etc. The only thing missing
    were vacuum tubes (and they may have been there, out of sight).
     
    >I don't take offense though,
     
    None was intended.
     
    >I'm here to solve an issue, not get into a conflict.
    >
    >All of your points-- while valid-- still don't change the fact that when I go to E-mail Address Policies (regardless of purpose) and attempt to add a "Custom Address" in a free-form manner (which is the clear intention of the UI design they created), it generates an ERROR message upon processing. So yes, it is definitely something that should be dealt with in some capacity. The documentation on Technet suggests that I should be able to do it and mentions no limitations on the use (perhaps a link I missed along the way, however). The dialog allows me to input SIP:@domain.com, so yeah, I don't think it's unreasonable to assume that it should be supported.
    >
    >Thanks again for the discussion! :)
     
    As I said, those are my opinions, not those of MS.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Monday, February 07, 2011 3:16 AM
  • Ok, whatever... bantering at it's best.

    The main purpose of this discussion was that this feature SIP needs to be added.  And I strongly agree there are many other reasons, especially working with OFFICE 365 and a HYBRID environment.  It is NOT handled and it is NOT tied into every infrastructure.

    Let's see about adding a needed feature and quit dismissing something simple as a SIP type.  I am sure we have many people who wish to have this simple, quick solution added.

    BTW, I love ANCIENT old posts that are still relevant and come up FIRST in Google.  And we wonder why Microsoft keeps losing market shares.  Welcome to 2014.

    Thursday, August 07, 2014 2:11 PM
  • Powershell can easily accomplish the task of adding custom addresses to mail- or mailbox-enabled AD objects. What was being discussed was the use of Email Address Policies.

    Assuming that there's no on-boarding process in place that handles the task of managing proxy addresses, a simple scheduled task to check for AD objects meeting the criteria for needing a SIP address type, yet lacking one, would seem to meet the requirements. That same code could also verify whether the assigned IP address needed alteration (e.g. a change in object's "mailnickname" property).

    Use this as an example (it took only a few seconds to compose the query in a search engine):

    http://elderec.org/2013/05/powershell-adding-cisco-sip-address-to-the-proxyaddresses-field-in-active-directory/

    The real problem here is that the original poster thinks he has an integration problem:

    "I'm not setup where either product can directly integrate, however, because I'm setup as a resource forest, and it would create challenges with authentication."

    So, if the ACCOUNT forest can be updated then it should be only a minor problem to include the replication of properties from the account forest to the resource forest -- the same thing that needs to be done for other properties that Exchange populates in its GAL/OAB data. E.g. how are telephone number changes propagated from the account forest to the resource forest?


    --- Rich Matheisen MCSE&I, Exchange MVP

    Thursday, August 07, 2014 3:00 PM