In the Jabber for Windows Admin guide, it states that in order for presence integration between Jabber and MS Office to work that the "proxyAddress" AD attribute needs to contain SIP:user@cupdomain.
I've heard conflicting statements on whether this is actually required or not.
Can anyone confirm?
Can you point me to the differing scouces of information.
In the meantime I will investigate and update you as soon as possible,
It was mentioned by the presenter at the UC 9x beta conference during a Jabber session that there is no work required to allow the presence buttons in MS Office to light up.
The deployment guide says differently:
In this only required in specific environments? For specific functionality?
If you do indeed need to modify an attribute for every AD user object, this would not be considered a trivial task in my opinion.
Thanks for looking into it.
"proxyAddress" AD attribute is indeed manadatory in order to enable Jabber for Windows integration with MS office applications. Please note that no component of Jabber for Windows ever reads the proxyAddresses attribute. It is only required and used by Outlook (or Sharepoint).
To bulk update proxyAddress attribute, you can use Cisco AD Wizard. Cisco AD Wizard is a bulk update tool for setting proxyAddress (It can be downloaded from Jabber admin pack on cisco.com)
Should the proxyAddress attribute be username@domain or email@domain?
For instance my username would be User Name@domain but email is user.name@domain.
The Cisco AD tool wants to set the attribute at SIP:email@domain
Sent from Cisco Technical Support Android App
For now you should set it to SIP:email@domain. This may change in the future. It will be documented whenever the change happens.
Thanks for your reply, I let the Cisco tool scan and add the proxyAddress attribute to Active Directory and presence information is working perfectly in MS Outlook. Thanks!
Looking at the documentation for Jabber 9.1.x server setup, it looks like the change has been documented if I am reading this correctly.
Since I am working on moving from CUPC to Jabber, it looks like I will need to modify my proxyaddresses entry for all of my users? Does the Cisco AD Wizard provided with Jabber 9.1.1 update/add the proxyaddresses as SIP:userlogin@cupdomain?
Testing has been intermittent with status being correct. For example: some users show status OK with the SIP:firstname.lastname@example.org, while others do not show any status. I am just not sure if I am missing some other configurations that jabber needs, that was different in the CUPC world.
Maybe I am not understanding this concept but the whole reason this is needed I thought was when the CUP domain didn't match the corporate domain. Regardless I thought you would put the JID as the Proxy but you are mentioning the other way. So if by corporate domain is abc.com and jabber id is email@example.com shouldnt we be putting firstname.lastname@example.org in the proxy attribute for the user in essence matching the JID. In the above example I got the impression that JID is username@domain but emai@domain is what you mentioned to set it
Also attaching screen shot
Thanks so based on that doesn't the response from Maqsood conflict where he mentions the proxy should be set to email domain. That was the source of my confusion. See his post above
"For now you should set it to SIP:email@domain. This may change in the future. It will be documented whenever the change happens."
Yeah I was also confused. Our CUP 8.6 server CUP domain, are not the same as our email domain. Therefore we are seeing some lookup and presence issues in Office 201. TAC claims that best practice is if the CUP domain is identic to our email domain.
The ADwzard tool adds proxyAddress with email domain.
I will change our CUP domain so it’s identic to our email domain, at our next maintenance window. This should hopefully resolve our lookup and presence issues in Office 2010.
I will get back with the results.
we've experienced different issues. Starting at showing no presence state to showing it in one mail but not in the other for the same contact or showing the state delayed (from 5 sec. to 1 or 2 minutes delay).
After we've set this attribute sip:email@example.com (not sip:firstname.lastname@example.org or SIP:mainSMTP@domain.com) to all of our users and rebooted the CTI Service on our CUCM the presence state was shown directly and more important correctly.
Actual Config: CUCM 9.1. CUPS:9.1.