Let's run an experiment. :)
The next time it happens, run these 3 commands:
Vssadmin list writers
Vssadmin list providers
Vssadmin list shadows
It has to be from an elevated session I believe. See if the word "error" is in
either of the first two (I'm guessing yes) and whether or not you have a
current shadow copy from the third (I'm also guessing yes).
But these are just guesses.
Oh, let's also run "vssadmin list volumes".
Let's also look in Task Scheduler and see when the defrag is scheduled to run
and how often.
I'm aware of issues in 2010 SP2 with RPC Client Access crashing - but not it
consuming lots of proc time. I'm not saying there isn't an issue - I just don't
know of one. I do know that lots of weirdness shows up with VSS in 2008 and
2008 R2.
I can't imagine a link between RPC Client Access and Search. But regardless of
that, depending on the size of your databases, it can take a couple of days to
rebuild a search index. I know that users at my clients would be pretty
irritated to not have search for a couple of days. So much so that I probably
wouldn't re-create a new search index, but instead create a new mailbox
database and move all the users to that (the search index is built as part of
the move mailbox process).
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Maglinger, Paul
Sent: Wednesday, October 14, 2015 7:34 PM
To: <[email protected]>
Subject: Re: [Exchange] RE: Microsoft Exchange RPC Client Access runaway
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
