Cisco Support Forum suggestion
Having been asked again today, I would say the sort of official recommendation is to restart your publisher server first and wait for it to fully recover. Then repeat the process with each of your subscribers. My thought was obviously to always retain as much phone service as possible by rebooting and recovering each individually, but frankly I don't know why the publisher should go first. If you have one freshly rebooted server to rehome to, what does it matter which one?
At least Cisco confirms that I'm not missing anything (see link above).
Of course something in version 8 will likely explode if you do so in the undocumented correct order ;)
Diary of technical happenstance, simple Internet accessible scratchpad, and brain dump to save myself later
Tuesday, April 27, 2010
Sunday, April 18, 2010
CUPC 7 Calendar Integration
Despite the documentation, CUPS / CUPC Outlook calendar integration WILL work while Outlook Web Access is using forms based authentication (if you see a pretty web form when logging into OWA vs. a Windows form requesting a username and password).
One problem is while setting it up and troubleshooting CUPC, the errors returned from Exchange during the CUPC / CUPS calendar communication can be based on results from OWA / IIS, and not Exchange. You may get errors that are either too general to be helpful or misleading (i.e. 440 Timeout).
By disabling FBA in Exchange (and / or IIS), you can restart the Presense engine and collect real errors rather quickly.
I found Exchange was looking for a DOMAIN\USER Presence Outlook Gateway User loggin name format (vs. simply USER, or cn=USER, ou=DOMAIN...). TAC may suggest any variation of them without really investigating the root requirements from Exchange. One mystery problem is that an incorrect authentication method CAN work for a long enough time to make you think your exhaustive list of calendar testing is complete, and then simply stop working an hour later.
Drop FBA, verify what Exchange is looking for re: loggin methods, and cross your fingers.
When you decipher the root cause of your calendar integration failure, you can re-enable FBA on OWA.
One problem is while setting it up and troubleshooting CUPC, the errors returned from Exchange during the CUPC / CUPS calendar communication can be based on results from OWA / IIS, and not Exchange. You may get errors that are either too general to be helpful or misleading (i.e. 440 Timeout).
By disabling FBA in Exchange (and / or IIS), you can restart the Presense engine and collect real errors rather quickly.
I found Exchange was looking for a DOMAIN\USER Presence Outlook Gateway User loggin name format (vs. simply USER, or cn=USER, ou=DOMAIN...). TAC may suggest any variation of them without really investigating the root requirements from Exchange. One mystery problem is that an incorrect authentication method CAN work for a long enough time to make you think your exhaustive list of calendar testing is complete, and then simply stop working an hour later.
Drop FBA, verify what Exchange is looking for re: loggin methods, and cross your fingers.
When you decipher the root cause of your calendar integration failure, you can re-enable FBA on OWA.
Subscribe to:
Posts (Atom)