Unity Server 4.0(4) doesn't start after reboot, manually need to start.

[rsamtani]

Hi,

I have a new Unity Install 4.0(4) with Unified Messaging. The customer has exchange 2000 server. After the install the Unity server worked, but it fails after a reboot. I can go and manually start Unity and it comes up without an issue. In the event viewer, I see this error.

No windows NT or Windows 2000 Doamin Controller is available for domain CENTRAL.

The following error occured: There are currently no logon servers available to service the logon request.

AvcsMgr failed to start due to logon issue.

Any help would be appreciated. I have reinstalled and it still gives the same issue.

Thanks -

Rakesh

[kechambe]

Since it isn't a problem with Unity you probably won't get an answer out here. Your best bet is to look on support.microsoft.com and groups.google.com for a solution. Either that or contact Microsoft for support or whoever supports the customers Windows infrastructure.

Check out this URL as well:

http://support.microsoft.com/default.aspx?scid=kb;en-us;244474

Thanks,

Keith

[chrisb]

I had the same problem. In my case, and sounds like your case too, it is a Microsoft issue. If I followed your issue correctly, you reboot Unity and service fails to start. Something about the password for the service account being incorrect, right? You can retype the exact password and the service starts correctly. Does this sound about right?

[rsamtani]

Yes! Sounds like a similiar issue. What did you do to resolve it. If I make Unity as the domain controller it comes up without any issues after a reboot. As a member of a domain, it fails to start up, to begin with it gives a Netlogon failure, cannot find domain controller and then AvcsMgr fails to start because of logon/password issues.

[Ginger Dillon]

Hi -

I have seen this same problem (same symptoms) in a lab environment where a Default Domain Policy GPO was being tested. The Unity services were losing their Log on as a service right. On your Unity server, from a command line, run gpresult. This will tell you what policies are being applied. Another way to tell from the Unity server is to check Administrative Tools - Local Security Policy. Under Security Settings, drill down to Local Policies, User Rights Assignment - then check the settings for Log On as a service. The effective policy setting is what gets applied at the domain, higher level than Local Security, and will be grayed out. If that is true, you will need to investigate at the Domain controller level and get the Unity accounts rights updated there.

Ginger

[kechambe]

What Ginger is describing is a pretty big case generator for TAC. A domain level (domain/OU/site) GPO will always override a local GPO are they aren't cumulative. The permissions wizard sets the 'logon as a service', 'logon as a batch job' and 'act as part of the OS' locally. So if any of these policies get set at the domain level, at next reboot Unity will fail to start. A lot of times people will get really confused on this one too because the GPO might have been changed weeks earlier but the Unity services will continue to run just fine until a reboot.

When the 'logon as a service' right has been set at the domain level and the Unity service account are not defined, if you try to change the password on the service you will see that the 'logon as a service' right has been granted. Pretty much whenever you see this message you know that a domain level GPO has been set. So even after you do password change and you are granted the right for the moment, once you reboot Unity will fail to start again.

The solution to the domain level GPO issue is to define the Unity service accounts in the GPO.

But in this particular cusotmer's case it isn't GPO related. Windows is stating that there isn't a DC available for authentication, not that the account running the service doesn't have the rights required to start. The customer opened a case with Microsoft and Cisco, and we are working to get them to resolution.

But now that I think about it we should probably have a tech tip covering the whole domain level GPO issue since we see it so often.

Thanks everybody for the great responses!

Keith

[chrisb]

No problem. Let me dig through my notes and I'll respond with the solution I used.

[rsamtani]

Hey Guyz,

I do appreciate all the info! I was speculating to change the Ip address of the Unity server to put it in the same subnet as Exchange server.

Just for test purposes, to make sure there is no network issue. Any issues with changing IP address on Unity.

Thanks -

Rakesh

[lindborg]

No problem changing the IP address - Unity doesn't care. As long as name resolution for your Exchange servers and such still flies, the ip on the local box doesn't matter at all.

[rsamtani]

I am reinstalling the box with an IP address in the same subnet as the AD servers. Will keep everyone posted !

Thanks -

Rakesh

[chrisb]

Wait!! Did you already start??? I found my notes.

[rsamtani]

What did you find? I would certainly want to know.

Thanks-

Rakesh

[chrisb]

Try this. This is a registry change, so be careful. Anyhow, after you make the change, you need to restart Unity.

Localmachine/system/currentcontrolset/services/netbt/parameters

New Dword

MaxDgramBuffering

Change value to 60000 (hex)

[rsamtani]

I reinstalled the system with an IP address in the data subnet, and that worked. I am not sure what would be different.