AAM & Exchange Integration Issues

[ATI2ner]

Is there a better instruction guide than the one Avaya provides? There are many sections that just say "Enter the required information." We have no clue what that means...

Recent upgrade to CM 6.3 with AAM 6.3.3 and want to use the Unified Communication feature to listen to voicemails in Outlook, and have them deleted when deleted in Outlook. We have created the Service Account with impersonation privileges, and have set up the exchange server as a message storage server. We can get a copy of the voicemail in email, and listen to it, but it does not delete the message when the email is deleted, or turn off the MWI when listened to. We have to be missing something basic, but the instructions are no help at all.

Any help is greatly appreciated.

 

[kyle555]

Sounds like the whole IMAP/impersonation permissions part is not setup correctly. You've basically just got SMTP forwarding working. There might be knowledge base articles to help.

Otherwise, I sometimes find it helpfulfor me to understand what's going on to do everything unencrypted and take a wireshark and watch the packet flow. It's helped me find quirky things like where an LDAP wants user names as "DOMAIN\user" or "user@domain" or "cn=user, dc=company, dc=com

 

[ZeroZeroOne]

If you want messages to show up in the normal Inbox, you'll definitely need that Service Account with all the right permissions.

In AAM under Administration / Messaging / Messaging System (Storage)

You'll see

Microsoft Exchange
Enable (Check Box)
Service account: (use the format "account@company.com")
Password:
Domain: (company.com)
Use Autodiscover service (Check box)
Autodiscover:
Use SSL to access Global Catalog
Use predefined Global Catalog server
Global Catalog FQDN:

If Autodiscover is enabled for Exchange then magic* should occur.

You will probably need the IP Address and FQDN for email access set up as an External Host. Something like "webmail.company.com" as if you were accessing email from your browser.

Then go to the subscriber and change the Storage Destination from Avaya Message Store to Microsoft Exchange. Enter the Exchange email address "user@company.com"
Hopefully, you won't see any errors.

Now leave a test message and see what happens in Outlook. You should see an email with the message as an attachment. Marking the email as "read" should turn off MWI.
There may be some delay in that process.

I went through this a few years ago and haven't really touched it since so my memory may be a bit off.

 

[ATI2ner]

Thanks all for the responses.

ZeroZeroOne- you have hit on the very heart of our problem. We are an extremely HUGE international company, and the only piece of this we even know anything about is the voice system. So can you please provide a bit more detail about the specifics of these statements:

If Autodiscover is enabled for Exchange I assume our people that handles exchange need to give us this autodiscover information? It will be a URL??? And what do we do if our company does not use autodiscover?

You will probably need the IP Address and FQDN for email access set up as an External Host. Where do external hosts get set up? In AAM or Exchange? As far as webmail type of access, we can only get to our emails while on the company network. There is a webpage type of interface for my work email, so I assume there would be one for the services account as well, if that is what is needed.

As you can tell, we are way over our heads here. Our lines of business want this functionality, but we don't know enough about it to even begin to tell the exchange people what we need.

 

[ZeroZeroOne]

Yeah... When I worked for that company the "voice", "network", and "systems" teams didn't play well together. I'm not bitter.

I'll try to answer as well as I can but I'm sure there are others who know far more.

Autodiscover is a feature on Exchange and can be set up by those folks. A web search for "Exchange Autodiscover" will provide some info but you'll definitely need help from that team. Basically, it allows software such as Outlook or AAM to find the appropriate email servers just by the user and domain name.

External Hosts are set up in AAM under Administration / Messaging / Server Settings (Storage) / External Hosts. You need the IP Address and FQDN. An "alias" is available if you want to use a shorter name internally to AAM but isn't required.

If you can get to your email via a browser then that is what you want. Even if it is only available on the internal network, that's fine.

Anyone who actually knows Exchange will probably be laughing at my feeble explanations but I hope you at least have a little better idea what questions to ask when you have a meeting with your Exchange experts. I do recommend having a sit-down meeting with them to discuss the project and your requirements.

Speaking of requirements, look up the "Administering Avaya Aura Messaging" document. There's more details in there when talking about Exchange.

 

[kyle555]

Now that you're all jogging my memory... lookup something about forms based authentication for exchange web services.

Something something the difference between getting a login page vs a pop up box for logging in. AAM wants to use one but not the other

 

[kyle555]

Actually, it was basic authentication, not forms based
....
Messaging supports the following authentication types:
- Basic Authentication
- NTLM (NT LAN Manager) Authentication

 

[ZeroZeroOne]

Kyle555,

Is that where you set up a second account in Outlook that treats AAM as an email server? Messages are stored on AAM but you access them through a second "Inbox" in Outlook.

It's different from what I've used before, where Exchange is the storage server and users see voice messages mixed in with all other new emails in the one "Inbox".

 

[kyle555]

Not exactly. Its a configuration on Exchange Web Services that permits logging in in a certain way - through a web page, or with a pop up box. That's how you're reading the state of mailboxes with that user you set up with impersonation permissions.

Obviously if you've set up the account/user/pass right, then it's not the credentials, so I'm thinking you should check the authentication mechanism that Exchange is permitting. That's what I was referring to in my previous post.

 

[ZeroZeroOne]

Not exactly" Ha! It's NOTHING like I was thinking! You're too kind.

Thanks for clarifying. That's one of those steps where I had to rely on the Exchange team for our implementation.

 

[kyle555]

That's why I'm saying maybe wireshark it from AAM if you can, if its not encrypted authentication, you might see the exchange and why its failing.