ICM updateaw

Unanswered Question
Apr 7th, 2009

ICM 7.5.4

updateaw process says "attempting to connect to central controller database <sideA dbname> <sideA ipaddress> and updateaw restarts continuously. If I stop sideA logger it is able to connect to sideB logger and I am able to use the script editor and make changes...


Appreciate your suggestions...

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
joesnyde Tue, 04/07/2009 - 11:15

Would you upload the uaw log from the Distributor? What version of ICM?


Try rerunning the setup on the AW to recreate service accounts. Depending on what version of ICM their is a check box within the setup to recreate service accounts.

rafi.imran Tue, 04/07/2009 - 22:12

Pls find below the error message from updateaw process.


ICM ver. 7.5.4


Events from April 2, 2009:

17:53:51 dis-uaw Initializing Event Management System (EMS) Library.

17:53:51 dis-uaw Trace: EMS Server pipe fsblr\Distributor\uawEMSPipe enabled for fsblr\Distributor\uaw

17:53:51 dis-uaw Trace: Release 7.5.1.0 , Build 23684

17:53:51 dis-uaw Initializing Node Manager Library.

17:53:51 dis-uaw Trace: Creating worker threads.

17:53:51 dis-uaw Trace: Attempting to connect to local database "fsblr_awdb"

17:53:51 dis-uaw Trace: Connected to SQL Server 9.0.255 on server SPBLRDCSQL001.

17:53:51 dis-uaw EMS pipe: \\SPBLRDCSQL001\pipe\ICM\fsblr\Distributor\RouterA\EMSServer.

17:53:51 dis-uaw Trace: Attempting to connect to central controller database "fsblr_sideA" on server "10.111.1.5"

17:53:56 dis-uaw Trace: New notification client: ccdb on pipe 0x20c.

17:54:52 dis-uaw Trace: CExceptionHandlerEx::GenerateMiniDump -- A Mini Dump File is available at logfiles\updateaw.exe_20090402175452656.mdmp

17:54:52 dis-uaw Unhandled Exception: Exception code: C0000005 ACCESS_VIOLATION


Fault address: 111E2FD0 01:00001FD0 C:\icm\bin\UPDATELOCAL.dll




Registers:


EAX:0012FD5C


EBX:00000000


ECX:0012FD48


EDX:0012FD34


ESI:0012FE5C


EDI:0012FE1C


CS:EIP:001B:111E2FD0


SS:ESP:0023:0012FD00 EBP:00000000


DS:0023 ES:0023 FS:003B GS:0000


Flags:00010246




Call stack:


Address Frame


111E2FD0 0012FD18 CCDatabase::GetHostIPAdresses+30


111E339D 0012FDB0 CCDatabase::EMSReportEventConnectionFailure+3D


111E5323 0012FE00 ICRDatabase::Connect+C3


004065F9 0012FE38 UpdateOperation::~UpdateOperation+139


00406FCA 0012FF38 CList::RemoveAll+11A


004075DE 0012FF60 main+EE


0040A17F 0012FFC0 mainCRTStartup+143


77E6F23B 0012FFF0 ProcessIdToSessionId+209





joesnyde Wed, 04/08/2009 - 05:45

Hi


From the log it looks like we are having a problem resolving a host name.


111E2FD0 0012FD18 CCDatabase::GetHostIPAdresses+30


Can you verify that the protocol order on the Distributor/Logger SQL installation is Named Pipes first, and then TCP/IP?

Start -> Programs -> Microsoft SQL Server 2005 -> Configuration Tools ->

SQL Server Configuration Manager

SQL Native Client Configuration -> Client Protocols

Shared Memory = 1

Named Pipes = 2

TCP/IP = 3


If that is correct verify that both the logger and distributor can resolve their hostnames. If not you may want to change in both the logger and distributor setup to use only IP addresses. Or verify that DNS is working correctly, and you could create host files.


Easiest might be to run through setup on both distributor/logger and be sure that the setup is using IP addresses for router/logger/distributor and not hostnames.


rafi.imran Wed, 04/08/2009 - 07:49

HI joesnyde,


When I ping the hostname of the loggerA it gives me the ipaddress.

I have used only ipaddresses in logger/aw setup

I have even added the host file entries for both loggerA and loggerB

SQL config has namedpipes as 1 and tcp/ip as 2 and i have disabled shared mem at all sites.

I have the network binding order as private first and visible network as secondary


updateaw works fine with sideB which is in WAN but it does not work for sideA which is in the same location of AW...

Quiet intriguing...


joesnyde Wed, 04/08/2009 - 07:54

I have to assume that both these AWs are primaries. Can you check to see if both AWs are pointing to the same side or are they pointing to side a and side b as below.


AW1 -> SideA

AW2 -> SideB


Their may be some contention if both are pointing to the same side.


I am also wondering if shared mem disabled may be causing an issue. Can you enable this for a test?


Check also the speed/duplex on the NICs, logger/dis, should be set to 100mb full duplex including the switch port. If gig is being used set to AUTO on NIC and switch port.


Maybe flush the DNS cache? Open a command prompt and C:\>ipconfig /flushdns


I am running out of ideas.

rafi.imran Wed, 04/08/2009 - 08:23

I have only 1 aw at sideA location.


All servers are in 100mb full duplex including the switch port..


shared mem is also disabled in loggerb but aw works fine with loggerb

david.macias Fri, 04/10/2009 - 05:19

try this. connect to both AWs and re run setup. then compare each screen and ensure your configurations are correct.


david

joesnyde Wed, 04/15/2009 - 05:31

Hi


For a test, can you change the hostnames in the AW setup to IP addresses to see if you still get the same errors?

rafi.imran Wed, 04/15/2009 - 09:28

I dont have hostnames configured in setup. Its all ipaddress which I have referred in aw/logger setups.

joesnyde Wed, 04/15/2009 - 11:03

My apologies, I think you mentioned that before. How about changing the IP to hostname is the same issue still present?

Hiep Tran Wed, 04/15/2009 - 22:01

Rafi


I noticed you said that you have Private first and Visible network as secondary. If this is a dedicated (not collocated with a PG or Central Controller component) AW/HDS you shouldn't have a need for a NIC dedicated to the private network. I would disable all NIC's that are not needed. Also, your visible network should be the first in your binding order in any case.

joesnyde Thu, 04/16/2009 - 07:01

Good catch hieptran1998. Did not see that before. Change the NIC binding order on your loggers, pgs, and router so that the Visible is first and private second.

sufle Sun, 01/01/2012 - 15:56

Hi all,


Sorry for reviving such an old thread. but I have a very similar error message.


It's a lab environment:


Server 1 -> Rogger (Router, Logger)

hostname: win3k2

Private IP: 10.0.0.71

Public IP: 10.0.1.71


Server 2 -> AW/HDS

hostname: win3k4

IP: 10.0.0.73


updateaw process on the AW/HDS server has the following error:

Connection to central controller database failed!! host name: win3k4, IP: 10.0.0.73


If you notice it tries to connect to itself, for some reason thinks that the central controller is on win3k4 (10.0.0.73), but it should be on win3k2 (10.0.0.71)


In the configuration, Router and Logger IPs both are set to: 10.0.0.71

I've tried to set hostnames already, that did not work.


Please let me know what could this be?


Thanks a lot,

sufle Mon, 01/02/2012 - 07:07

Hi,


Finally figured out what it was and fixed it.


It was not the actual IPCC elements configuration problem. it was SQL Database configuration problem.


I had it on Windows Authentication, and for some reason it was failing. even with SQL Analyzer I could not connect from one server to the other, it was saying there was some trust problem.


I changed to Mixed authentication and now everything works fine.


Thanks everyone for reading,

Actions

This Discussion