I've been interested in these forum entries because we recently experienced a 'different' problem that resulted in all of the same errors mentioned here. So this post is to share our experience with others and hopefully avert upgrade problems or downtime. One week prior to upgrading one of our CallManager clusters from 3.1(2c) to 3.1(3a) + tons of security hot fixes, our domain joined into an existing Active Directory forest. The CallManager cluster was already part of the domain, but the servers were not shutdown/restarted following the AD change. Once we completed the upgrade on the publisher last Weds., we began to receive the SQL job engine errors and major services (CCM, CTI Manager, Database Layer Monitor, and Telephony Call Dispatcher) would not start. We applied the 3.1(3aSPb) patch, since it replaces ccm.exe, but this did not fix the problem. We began working with TAC. We finally replaced the mirror drive and restored the publisher back to its 3.1(2c) state ... as I like to quote from Chef Emeril Lagasse, "It's a beautiful thing!" The following morning, although phones were working, we soon found out CFwdAll from the phones were not (gave message Database unavailable on screen). We fortunately could modify the setting from ccmadmin\ccmuser, which got us through the day. Working with TAC again and thinking we had a broken publisher computer account, we removed the publisher from the domain into a workgroup, deleted the account, then rejoined the domain following synchronization. But by the time we had completed the 3.1(3a) upgrade, we soon received the same exact errors from the night before. Again, the mirror saved the evening. We received some additional big guns support from TAC on Friday. The engineer reviewed all of our SQL settings and several tables, Windows server settings (like DNS and host file for SQL 7.0) etc. We also checked the local security policy for the publisher and here's where we finally found the real problem. The resultant policy for the publisher password setting, inherited from the Default Domain Policy, had a minimum password length of 8 characters. The subscriber had a setting of 0, with no resultant domain policy as it had not been rebooted since the move to AD. Our engineer felt confident that problems were arising during the upgrade, when the password is changed to blanks, which our domain policy would not permit. The recommendation was to remove both publisher/subscriber from the domain into a workgroup, then proceed with the upgrade. This did the trick! The upgrade was successful, no errors, and all of the services started successfully.
We are now looking into a group policy setting that will override/disable the minimum password length for the OU in which these servers should reside. Obviously the CallManager servers do not need to be part of the domain, but we'd prefer to have them be. Hope this helps :-)
