Re: SQLServerAgent Job Engine

amylinit · ‎02-28-2002

I am getting Event ID:208 Warnings

SQL Server Scheduled Job 'Api-Cm-1-Ccm0300-Ccm0300-Api-Cm-2-Ccm0300- 0' (0xBCDB3839D7D06F42B2EB7E866AF0DA24) - Status: Failed - Invoked on: 2/28/2002 3:11:00 PM - Message: The job failed. The Job was invoked by Schedule 3 (Replication Agent Schedule.). The last step to run was step 1 (Run agent.).

and Event ID:203 Information

SubSystem Message - Job 'Api-Cm-1-Ccm0300-Ccm0300-Api-Cm-2-Ccm0300- 0' (0xBCDB3839D7D06F42B2EB7E866AF0DA24), step 1 - The process could not connect to Distributor 'Api-Cm-1'.

On my Subscriber server. As far as I can tell the Subscriber is communicating with the Publisher, in fact if I bring the Publisher down I can operate phones from the Subscriber.

Is this something I need to worry about?

Jim

mimckee · ‎02-28-2002

If you look in the in SQL enterprise manager on the publisher drill down until you see the databases folder. How many CCM030X databases do you see? If you see more than one then CCM0300 is probably not the current database. So this should not be anything to worry about.

Thank you,

-Mckee

amylinit · ‎03-01-2002

There is only one, and it is CCM0300. It's creation date is listed as 2/24/2002, which I should note is when I had to do a reinstall and restore of the publisher after a failed attempt at upgrading to 3.2.

- Jim

mimckee · ‎03-01-2002

On the publisher if you look at the CCM0300 database and then click the plus sign beside it. Then click the plus sign beside publications. Then click on the CCM0300 pulication. You should see the name of your subscriber does this say active or does it say pending. Now look on the subscriber. Go to databases then make sure you have a CCM0300 database. Then click the plus sign beside the CCM0300. Then highlight the pull subscription. Does it says succeeded or running or do you have some other error message. What verion of Cisco CallManager are you running? Let me know what you find and I will help you get this resolved.

Thank you,

-Mckee

vimoreno · ‎03-01-2002

You may want to open a TAC case and provide access to the engineer. They can run these checks in a little while. Probably more time effective for both parties.

amylinit · ‎03-01-2002

From the publisher, it says the subscriber pull status is Active

On the Subscriber, there is a CCM0300 database. In the Pull subscription area, it says the status is "Retrying" and the the last action was "The process could not connect to Distributer API-CM-1"

You can email me directly

jrichardson@amylin.com

or call

858-642-7018

mimckee · ‎03-01-2002

Have you changed the SQLSvc users passwords on either server. This account is used to get the initial snapshot. I have seen this error when the passwords have changed. If you did change the passwords let me know before you try to correct it yourself. You could make things much worse. If you have not changed the passwords for the SQLSvc user. Try the link below for reestablishing the subscription.

http://www.cisco.com/warp/public/788/AVVID/recreate_subscribe_database.html

If you don't think you changed the password and this link does not help you please let me know and I will try and help you.

Thank you,

-Mckee

amylinit · ‎03-01-2002

I did have to change the passwords as part of the failed upgrade attempt. Each server is using it's own local SQLSvc account, the passwords are the same though.

Do you think I should attempt the procedure?

mimckee · ‎03-01-2002

Can you just verify that the passwords are the same. I usually log into CCMAdmin as the SQLSvc user on both servers using what I think the password is. If the SQLSvc passwords are not the same on all systems in the cluster the initial snapshot of the replication will fail and you usually see the message you are getting. The only reason I say to try redoing the subscription is that you mentioned something about rebuilding the publisher. The later version of the restore are suppose to rebuild the subscriptions, but I can't remember what version they put that into. Can you elaborate on the rebuild of the pub did you rebuild the sub after the restore? If you look at the services make sure the SQL Sever Agent service is loging on as the .\SQLSvc for each server. Verify the passwords on both and let me know what you find.

Thank you,

-Mckee

amylinit · ‎03-01-2002

Well, I'm not sure how it happened but the publisher has a different password that what I expect it to be. I can change it tonight and try bringing the services back up using the new password (when I changed it before, I followed the 21 step procedure that is in the release notes "performing Post-installation tasks").

As for rebuilding the publisher, it was because I had a failed upgrade to 3.2 and did not have a broken mirror drive to revert back to. The upgrade failure was pretty bad in that my DBL was completely gone. TAC had me reinstall from CD then restore the previously unupgraded publisher DB.

I have learned my lesson on pulling the drive before the upgrade.

mimckee · ‎03-01-2002

Well that is what is causing the replication issues. If the passwords are different. I am not sure what doc you are talking about but, here is what I do when I change these passwords. Right-click on my computer and click manage. Then go to users and groups and right click on the SQLSvc user and do set password. Then go to start -> programs -> administrative tools -> component services. Then click the plus sign beside component services. Then drill down to you get to the DBL service. Right-click on DBL and go to properties. Click on the idenity tab and make sure the user is SQLSvc and set the password to what you changed it to. Then go to start -> programs -> administrative tools -> services and make sure all the services logging on as SQLSvc reflect the new password. Then just reboot the box and you should be okay.

The replication should start working at that point. If you rebuilt the box the password would have gotten reset.

Did you reset the SQLSvc password after that?

Let me know if this helps,

-Mckee

amylinit · ‎03-02-2002

Ahhhh,

Life is good...Reset the password for .\SQLSvc on the Publisher and all is well again. No more error messages on the Subscriber the Enterprise Manager on each system has the correct "status".

I was referring to the procedure in the install guide:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_1/install/cm313ins.htm#xtocid14

it's a handy tool to follow to insure you hit all the right places. I did notice though that on my servers the MOH and TFTP services also use the .\SqlSvc account and need to be cleaned up when you change the password. The strange thing is that I did this to both the Publisher and the Subscriber "after" I restored the Publisher from backup which is why I don't understand how it subsequently lost it.

Now that I'm synched up again I plan on attempting the 3.2 upgrade again this weekend, I guess I'm just a glutton for punishment.

Thanks a lot for your insight, it was incredibly helpful,

- Jim

mimckee · ‎03-02-2002

I am gald that you got it working. If you have any problems with the 3.2 upgrade start another post and we will see what we can do to help. Do you have a 7835 or 7825 or some ohter server?

Thank you,

-Mckee

amylinit · ‎03-03-2002

Just did the upgrade, all went smooth.

Publisher is a 7835, Subscriber is a Compaq DL 320 (which is a 7825 without gray paint).

- Jim

mimckee · ‎03-03-2002

That sounds good to me. The only reason I asked the server models if you have the 7835 like you do for the publisher you can pull a drive so it something went really wrong you could just revert back to the spare drive. It is not really an issue now but you can keep it for future reference. I know this procedure is outlined in the readme1st.pdf that you can get when downloaded the upgrades.

Thank you,

-Mckee