I assumed that the VSS errors were caused by the RPC service chewing up the CPU. You're thinking the RPC utilization was caused by a problem with VSS?
> On Oct 14, 2015, at 5:08 PM, Michael B. Smith <[email protected]> wrote: > > There are a couple of VSS rollups available for Server 2008 R2. They weren't > available on WU/MU so you may not have them installed. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Maglinger, Paul > Sent: Wednesday, October 14, 2015 5:52 PM > To: '[email protected]' > Subject: [Exchange] RE: Microsoft Exchange RPC Client Access runaway > > Veritas BackupExec 2014 R2 to tape. > Windows 2008 R2 Enterprise. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Michael B. Smith > Sent: Wednesday, October 14, 2015 4:44 PM > To: [email protected] > Subject: [Exchange] RE: Microsoft Exchange RPC Client Access runaway > > How are you doing backups? What OS? > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Maglinger, Paul > Sent: Wednesday, October 14, 2015 11:25 AM > To: New Exchange List ([email protected]) > Subject: [Exchange] Microsoft Exchange RPC Client Access runaway > > I'm hoping someone can give me some insight on this. > Running Update Rollup 6 Exchange Server 2010 SP2 on the mailbox servers set > up as a DAG. > For the past couple of weeks I'm arriving in the morning (usually on > Wednesdays and Fridays) seeing the Microsoft Exchange RPC Client Access > service with 80+ cpu utilization. This generally starts sometime between 4 > and 4:30am. I'm not showing any problems in the event logs during that time. > The only going on around that time is the database health checks at around > 4:44am and they all are passing. When people start showing up and logging at > around 7:30am I start getting: > > Log Name: Application > Source: VSS > Date: 10/14/2015 7:20:06 AM > Event ID: 11 > Task Category: None > Level: Error > Keywords: Classic > User: N/A > Computer: COMSTAR1.scvl.com > Description: > Volume Shadow Copy Service information: The COM Server with CLSID > {e579ab5f-1cc4-44b4-bed9-de0991ff0623} and name IVssCoordinatorEx2 cannot be > started. Most likely the CPU is under heavy load. [0x80080005, Server > execution failed] > > Log Name: Application > Source: VSS > Date: 10/14/2015 7:20:07 AM > Event ID: 8193 > Task Category: None > Level: Error > Keywords: Classic > User: N/A > Computer: COMSTAR1.scvl.com > Description: > Volume Shadow Copy Service error: Unexpected error calling routine > CoCreateInstance. hr = 0x80080005, Server execution failed. > > That's obvious. And later on, and I believe because the RPC service is > banging the CPU so hard, I start getting these for each of the databases: > > Log Name: Application > Source: MSExchangeRepl > Date: 10/14/2015 8:03:23 AM > Event ID: 2153 > Task Category: Service > Level: Error > Keywords: Classic > User: N/A > Computer: COMSTAR1.scvl.com > Description: > The log copier was unable to communicate with server 'COMSTAR2.scvl.com'. The > copy of database 'HQMBDB\COMSTAR1' is in a disconnected state. The > communication error was: An error occurred while communicating with server > 'COMSTAR2.scvl.com'. Error: Unable to read data from the transport > connection: An existing connection was forcibly closed by the remote host. > The copier will automatically retry after a short delay. > > And these for various RPC counters when I stop the service: > > Log Name: Application > Source: MSExchange Common > Date: 10/14/2015 8:14:13 AM > Event ID: 106 > Task Category: General > Level: Error > Keywords: Classic > User: N/A > Computer: COMSTAR1.scvl.com > Description: > Performance counter updating error. Counter name is Client: Foreground RPCs > succeeded, category name is MSExchange RpcClientAccess. Optional code: 3. > Exception: The exception thrown is : System.InvalidOperationException: The > requested Performance Counter is not a custom counter, it has to be > initialized as ReadOnly. > > After restarting the service everything is fine. > Backups start at 7:00pm and finish up by 10pm. The only scheduled tasks that > run anywhere near that time is the AitAgent at 2:30am. > The first time it happened I did some Googling and ran a > PublicFolderDatabaseRepairRequest and MailboxRepairRequest. They found > issues on the public folders and I corrected them. Nothing was found with > the mailboxes. I ran the checks again today and can't find anything wrong. > > Additional searching came up with stopping and placing the Exchange Search > Indexer and Search services in manual, rebooting the server and see if the > problem occurs again. If not, delete and rebuild the catalog index. The > article I found said that they ran without the search services for several > days and the users couldn't use search, and they were okay with that. Not > sure how much flak I'd get for doing this, so before going down this road I > wanted to get some input from you guys. Anyone run across this and care to > share past experience, or offer another suggestion? > > Thanks, > > Paul > > > > > > > > > >
