Weird. Brought the old server back up and Communicator was still broken - the service wouldn't start, same error as before. After trying various things I made the LCService a Domain Admin and it started and presto Communicator works, which tells me there's a permission somewhere that broke...
I wonder if we should move off 2005 :-) -----Original Message----- From: David Lum [mailto:[email protected]] Sent: Sunday, February 19, 2012 5:45 PM To: NT System Admin Issues Subject: RE: So...we broke SMS and Lice Communcations Server 2005 I'm no longer getting backend database errors, but I still get EventID 30710 errors Looking at the LCS management console, it tells me we have no certificates as default certificate settings - does that matter if we're no federated and not accessing this server from anywhere except our own network? Sadly I have no idea what this console indicated when everything was working... At this point we're rolling the old server back and hopefully that clears everything up. Dave -----Original Message----- From: Steve Kradel [mailto:[email protected]] Sent: Sunday, February 19, 2012 5:25 PM To: NT System Admin Issues Subject: Re: So...we broke SMS and Lice Communcations Server 2005 This looks possibly relevant to your issue: <http://support.microsoft.com/kb/892372> Sadly none of the events in this thread hint at the real problem, such as a permissions problem, failure to resolve a server name, or wonky connection string. However, this detail ought to show up in the SQL Server logs, and possibly also in the SQL server machine's OS event logs. Most likely the LCS / SMS AD accounts or groups aren't mapped to server logins... your DBA should be able to check the database users and verify they have valid logins. In SQL Server parlance, a "login" is a server-level object mapped to a Windows principal or SQL Server username+password. A "user" is a database-level object that maps to the server-level "login" and can receive various database-level privileges and roles. A regular database-level backup and restore will preserve the database "users" (and also all kinds of other stuff like the database compatibility level, recovery mode, etc.) but not the "logins" if you simply restore to a new box, without using any of the Server Migration tools or taking any other special steps. --Steve On Sun, Feb 19, 2012 at 11:24 AM, David Lum <[email protected]> wrote: > FYI the new SQL server has the same name as the previous one and I > found it also has the same version of SQL. Looking at the LCS console > it gives me a red "x" for default certificate settings. I've read > somewhere that that's required but we haven't made any changes to the LCS > server. > > > > RtcSrv does not start: > > Event Type: Error > > Event Source: Service Control Manager > > Event Category: None > > Event ID: 7024 > > Date: 2/18/2012 > > Time: 10:04:00 PM > > User: N/A > > Computer: <OurLCSServer> > > Description: > > The Live Communications Server service terminated with > service-specific error 2147942487 (0x80070057). > > > > Event Type: Error > > Event Source: Live Communications Server Snap-in > > Event Category: (1004) > > Event ID: 30710 > > Date: 2/18/2012 > > Time: 9:37:42 PM > > User: N/A > > Computer: <OurLCSServer> > > Description: > > Live Communications Server Snap-in failed to start service: > > Service Name = RtcSrv > > Machine Name = <ourLCSServerFQDN> > > HRESULT = 8007042a > > Error Description = The service has returned a service-specific error code. > > > > > > Event Type: Error > > Event Source: Live Communications User Services > > Event Category: (1006) > > Event ID: 30961 > > Date: 2/17/2012 > > Time: 6:22:29 PM > > User: N/A > > Computer: <OurLCSServer> > > Description: > > Failed to connect to backend database. Live Communications Server > will continuously attempt to reconnect to the backend. While this > condition persists, incoming messages will receive error responses. > > > > Backend Server: OurSQLServer Database: LCSDb Connection string of: > > driver={SQL > Server};Trusted_Connection=yes;AutoTranslate=no;server=OurSQLServer;da > tabase=LCSDb; > > Cause: Possible issues with backend database. > > Resolution: > > Ensure the backend is functioning correctly. > > > > From: Ken Schaefer [mailto:[email protected]] > Sent: Sunday, February 19, 2012 4:27 AM > > > To: NT System Admin Issues > Subject: RE: So...we broke SMS and Lice Communcations Server 2005 > > > > SCOM doesn't require any "weird" access to SQL Server. Any access > denied is traceable via Profiler. Dunno about LCS. > > > > If you manually try to start the rtcsrv, do you get an error code back? > > > > Cheers > > Ken > > > > > > From: Steven Peck [mailto:[email protected]] > Sent: Sunday, 19 February 2012 12:42 PM > To: NT System Admin Issues > Subject: Re: So...we broke SMS and Lice Communcations Server 2005 > > > > I'd call Microsoft. However if the SQL server was updated, then make > sure things like compatibility mode are on and such (and beat the SQL > guys for not having people check app compatilibity first). > > > > In general, it LCS either works or is just broken. LCS (and SCOM) > seriously rely on weird access to SQL so they need rights most SQL > DBA's like to take away and never give back. It may be the Upgrade > broke something with permissions. > > On Sat, Feb 18, 2012 at 7:56 PM, David Lum <[email protected]> wrote: > > LCS service (rtcsrv) does not start. > > Event Type: Error > > Event Source: Live Communications Server Snap-in > > Event Category: (1004) > > Event ID: 30710 > > Date: 2/18/2012 > > Time: 4:24:55 PM > > User: N/A > > Computer: LCS > > Description: > > Live Communications Server Snap-in failed to start service: > > Service Name = RtcSrv > > Machine Name = lcs.americas.nwea.pvt > > HRESULT = 8007042a > > Error Description = The service has returned a service-specific error code. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
