cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
543
Views
0
Helpful
12
Replies

Cluster delivery problem

spodonnell
Level 1
Level 1

We have a new install this weekend of Unity 3.12b, in testing we can not get Unity to deliver voicemail to mailboxes homed on a Active-Passive cluster. If we move the<br>mailbox to a non-cluster machine, it works fine. <br><br>We get this message in the event viewer when we try to leave<br>voicemail for a cluster mailbox.<br>CreateSubscriberMsg returned a NULL pointer on line 4621 of file e:\views\cs_ue3.1.0.68\un_Conv2\AvConvPhoneHandler\AvConvPHGreetingSvr\AvSPlayGreeting.cpp<br><br>The voicemail is in the "UMR", if we try to retrieve messages for a mailbox on the cluster, unity says the email server is down but we can retrieve voicemail that was left but undeliverable.<br><br>Normal email flows through all the exchange servers without error.<br><br>TAC has been very little help due to what seems to be very<br>limited exchange knowledge.<br><br>What the heck is going on?<br>Any help is very much appreciated.<br><br>Scott<br><br><br>

12 Replies 12

Not applicable

That's an odd one... the null pointer would indicate the Exchange server we're talking to (the one you picked during configuration setup) is telling us the Directory ID we pass it for lookup is returning no match found I think. Which is kinda weird.

Each message in the UMR directory should come in pairs of files. A WAV file with the message and a small text file that has some delivery/routing details in it. This will include the directory ID we are asking the local Exchange server to deliver to. Can you snag one of the text files for a messages sitting in the UMR that failed to deliver to a user homed on the cluster? We should probably start there. The next step will be to lookup users with that string manually (i.e. using ADSI edit queries) and see if for some reason when they're on the cluster they're not found vs. when they're not... kind of a reach but I'm not sure what else to look for right off the bat.


Jeff Lindborg
Unity Technical Lead/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

We are experiencing exactly the same problem. We are currently running 3.1(4).

We have three non-clustered exchange 2000 servers and are in the process of consolidating onto a pair of clustered Exch2k servers. New subscriber mailboxes created on the active\passive cluster can be imported successfully into Unity however will not receive v-mail messages to their mailbox... existing subscriber mailboxes display exactly the same symptoms. Effected subscribers are informed that their Email server is offline.

Can you be a little more specific on what ADSI query you would like preformed? Here is one of the text files you asked the previous individual for.

RecipientAlias:mariop

To:

Subject:Message from 3002

Priority:1

Sensitivity:0

Date:1035322502

X-AvMailHandlerId:=?unicode?b?AQAHADAAMwA6AHsAMAA1ADAAQQAxAEEAQwAzAC0ANQA2ADEARQAtADQAQgBEADYALQA5AEMANAA2AC0AMQBEAEIANQAxAEUAMQBFADgARQBBAEYAfQAAAA==?=

Any Help would be appreciated...

Out of curiosity, what account is the AvUMRSyncSvr running as? LocalSystem or a Domain account?

Our AvUMRSyncSvr is running under LocalSystem.

I think that may be the issue. The UMR service is probably having issues authenitcating with the E2K cluster. I'm pretty sure (but don't quote me on this) that with E2K clusters and W2K Domain Controllers SP2 and below, NTLM is the authentication that's being used and the LocalSystem account won't work too well for that.

The workaround is to use a Domain account to run the service. If Unity is connected to an off-box E2K server, other services such as the AvCsMgr and the AvCsGateway might already be running as a Domain account. If that is the case, the simplest thing to do is run the UMR as the same Domain account.

If those other services mentioned are not running as a Domain account, you could try creating one, and add that account to the Exchange Domain Servers group and to the local Administrators (local to the Unity box) group.

Here is some current info... and an update... Thanks for the Reply

Our environment consists of one tree with two domains involved with Exchange, NetBIOS "DOM1" and NetBIOS "DOM2"

We are currently running AD controllers with Windows SP3 and Exchange 2k servers running either Windows SP 2 or 3.

The Exchange 2k cluster is running Exchange SP3 while the other four three Exchange Servers are running either Exchange SP2 or SP3.

All of the Exchange servers are members of the DOM2 domain.

The Unity services are currently configured with the following Service Login IDs...

Service LogOnAs

------------------- ----------------------

AvCsGateway LocalSystem

AvCsMgr LocalSystem

AvDirChangeWriter LocalSystem

AvDSAD DOM2\UnitySvc

AvDSGlobalCatalog DOM2\UnitySvc

AvGaenSvr LocalSystem

AvRepDirSvrSvc LocalSystem

AvTtsSvr LocalSystem

AvUMRSyncSvr LocalSystem

The Service account is a member of the DOM2 domain and has the following group memberships...

DOM2\UnitySvc

MemberOf DOM2\Domain Admins

DOM2\Domain Users

For reference the Exchange Domain Servers group has the following members...

DOM1\Exchange Domain Servers

Members DOM1\Administrator

As the current Service account is not in the same domain as the Exchange Domain Servers group I can't add it to the group... I have tried changing the AvUMRSyncSvr account to run as DOM2\UnitySvc without much luck (received many App Eventlog errors and no mail was able to be delivered to any Exchange server so we are again running as LocalSystem).

Local System isn't going to cut it on the cluster. The directory facing account isn’t going to have the permission you need to access the cluster either.

Sounds like you need to follow these steps:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity31/inst/inst31/inst_020.htm#13041

Keith

Yeah, Keith's probably right about the localsystem account. Supposively, Exchange SP3 fixes the authentiaction issue with the localsystem account, but we haven't been able to verify it with Unity. The fact that there is some Exchange SP3 out there, is probably why the Unity server seems to be half-way working.

It might help to think of the accounts and services this way...

The services that need to get into or interact with Exchange are...

AvCsMgr, AvCsGatway, AvUMRSyncSvr, AvGaenSvr (and if 3.1.5 or higher, AvMsgStoreMonitorSvr). More often that not, when Unity's E2K connected server is an off-box server, we'll want to run those aforementioned accounts as a Domain account (to ensure proper authentication). That account will need the following...

To be in the Exchange Domain Servers group for all Exchange servers the Unity has subscribers on. If these Exchange servers span mutilple Domains (or are in different Domains that the Unity server), the easiest thing to do is put that account into the Exchange Enterprise Servers group. If this service account is in the Domain Admins or Enterprise Admins group, that will actually cause problems.

It will also need to be in the local Adminstrators group if the Unity server is a member server. It will also need the user rights of "logging on as a service" and "acting as part of the OS" in the local security policy if the Unity server is a member server. This is also detailed in the link that Keith provided.

So this is relevant to the accounts listed above. The directory facing accounts don't really need the same rights and permissions. They don't need to get into the Exchange server unless the Exchange server is also the DC or GC. These accounts are the AvDSAD and the AvDSGlobalCatalog services. These services need to be able to search for, modify, and create new accounts in the Domains that are intended for Unity subscribers. If Unity is only going to work with subscribers in a single Domain, being a member of the Domain Admins group is usually enough. If it is going to work with subscribers in multiple Domains (and Domains other than where the Unity server is), the easiest thing to do is add it to the Enterprise Admins Group.

In short, to be on the safe side, use a service account for the AvCsMgr, AvCsGatway, AvUMRSyncSvr, AvGaenSvr (and if 3.1.5 or higher, AvMsgStoreMonitorSvr) that can get into Exchange, and use a separate service account for the AvDSAD and AvDSGlobalCatalaog accounts.

The link that Keith provided will help with the Exchange permissions/rights.

I just tested this out in the SJ TAC lab. These are the steps I took:

I upgraded the Exchange 2000 cluster (2 node Active/Passive) to SP3. Unity couldn't authenticate with local system. Then I upgrade the DC to Windows 2000 SP3. Unity couldn't authenticate with local system. Then I upgraded the cluster and Unity servers to Windows 2000 SP3. Unity still couldn't authenticate with local system.

From my testing I would have to conclude that even with Exchange 2000 SP3 and Windows 2000 SP3, the Unity services need to run as a domain account to authenticate.

Keith

Just out of curiosity, what were the error messages?

Applied the changes as suggested and things seem to be working... :)

Today will be the first day of heavy use since the changes. Will update later today... I'll include some of those error messages for you at that time. Thanks again.

Everything seems to be running fine... no complaints from clients... One App eventlog entry concerns me though:

Event Type: Information

Event Source: AvCsServices_MC

Event Category: Warning

Event ID: 1077

Date: 11/5/2002

Time: 7:55:28 AM

User: N/A

Computer: SIERRA

Description:

Gateway FindCsComponents failed [DOM2\Unity_SIERRA, 0x80070005] (caller is denied access).

Any thoughts?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: