After installing some Windows updates and uninstalling some Britestore stuff on our Win2003 exchange 2003 / BES Express server, our BES Server will not start... seems the dispatcher service wont start judging by the log file below...
[30000] (11/21 19:28:52.068):{0x840} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Dispatcher DOUGEXCH (Application Event Log on DOUGEXCH) | 11/21/2007 19:28:50 (6FFFC39B) -> Starting BlackBerry Dispatcher DOUGEXCH - Version 4.1.3.16
[30000] (11/21 19:28:52.068):{0x748} Alarm::ThreadProc: Received an alarm message
[30000] (11/21 19:28:52.068):{0x840} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Dispatcher DOUGEXCH (Application Event Log on DOUGEXCH) | 11/21/2007 19:28:52 (AFFF50B3) -> VerifySchema: COM exception
[30000] (11/21 19:28:52.068):{0x748} Alarm::ThreadProc: Received an alarm message
[30000] (11/21 19:28:52.082):{0x840} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Dispatcher DOUGEXCH (Application Event Log on DOUGEXCH) | 11/21/2007 19:28:52 (AFFF50A1) -> COM Error 0x46DD10 in VerifySchema - Error 70010, severity 10, state 1 was raised, but no message with that error number was found in sys.messages. If error is larger than 50000, make sure the user-defined message is added using sp_addmessage. - IDispatch error #3092
[30000] (11/21 19:28:52.082):{0x748} Alarm::ThreadProc: Received an alarm message
[30000] (11/21 19:28:52.082):{0x840} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Dispatcher DOUGEXCH (Application Event Log on DOUGEXCH) | 11/21/2007 19:28:52 (AFFF50A2) -> Database error in VerifySchema (err=0x80040E14, native err=18054) - Error 70010, severity 10, state 1 was raised, but no message with that error number was found in sys.messages. If error is larger than 50000, make sure the user-defined message is added using sp_addmessage.
[30000] (11/21 19:28:52.082):{0x748} Alarm::ThreadProc: Received an alarm message
[30000] (11/21 19:28:52.082):{0x840} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Dispatcher DOUGEXCH (Application Event Log on DOUGEXCH) | 11/21/2007 19:28:52 (6FFFC3B9) -> Stopping BlackBerry Dispatcher
[30000] (11/21 19:28:52.082):{0x840} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Dispatcher DOUGEXCH (Application Event Log on DOUGEXCH) | 11/21/2007 19:28:52 (6FFFC3BC) -> Dispatcher Database connection dropped
[30000] (11/21 19:28:52.082):{0x840} [Alarm::ActivateAlarm] Queuing alarm: <N/A> | BlackBerry Dispatcher DOUGEXCH (Application Event Log on DOUGEXCH) | 11/21/2007 19:28:52 (6FFFC3B3) -> BlackBerry Dispatcher Shutdown complete
[30000] (11/21 19:28:52.082):{0x748} Alarm::ThreadProc: Received an alarm message
Cheers Dark Water pointed me in the right direction cheers.... basically down to moving the SQL DB from one server to another last week... worked fine at the time but reared its head after a reboot that the DB creation routine alters master sql db ... so had to unattach BESMgmt db, run the db creation routine then delete new & reattach original db and hey presto ... sorted!!!
I am having this same issue, though I've gone through KB03112 and KB03322 front to back already. I tried detaching the config database, attaching on the new server, then running the createdb command with the action set to "Upgrade" in the config file, and I've also tried wiping out the config db on the new server, running createdb with the action set to "Install", then removing the db it creates and replacing it with the db from the old server.... no luck. The command does complete each time with no errors, fyi.
Do you know if it makes a difference what account you run the createdb command as? I used my personal account on the SQL server, then changed the dbo to be our BESAdmin account (which has sysadmin, serveradmin, & dbcreator rights on the SQL server as the docs say it needs).
Also, the other thing I'm a little worried about is the fact that the new SQL server is a cluster, and after a little searching I found KB13474, which says that clusters aren't supported. I've read several people on here say that their config db is on a cluster and it works fine, so I think I should be able to get it work, but I'm concerned that RIM may not want to help me if I end up having to call them for support.
oookkk.... well, it looks like I'm all fixed up. The KB articles don't say anything about needing a reboot so I hadn't been after making the change up to this point. I moved the DB again and rebooted the BES and lo and behold, it works now.
The only reason I hadn't already tried rebooting before now was that they're crazy about minimizing downtime around here, so I was given a 10 minute downtime window, which really wouldn't accomodate a reboot.
oh well.... I guess a reboot really does fix everything in the world of Windows...