Exchange 2010 Management Pack Woes...

-
We've had quite severe performance issues on our Exchange 2010 implementation since roll out.  Basically we ran out of CPU.  Not nice.

The replication service on both mailbox servers slowly ramped CPU usage so that the server went up to 100% which then caused all manner of nasty failures.

Through-out our troubled times we have
  • Looked at the Exchange 2010 configuration with a fine toothed comb
  • Had 3 "Exchange Experts" come in and check things out
  • Raised PSS call with Microsoft
  • Raise call with VMWare (the servers are all virtual)
  • Increased RAM and CPU to ESX limits (almost - we only have 96GB in our hosts)
  • Tweaked registry settings
  • Moved to use pvSCSI instead of vSAS and back again (pvSCSI has issues in high IO environments!! We need new pvSCSI drivers)
  • Rebuilt a second set of Mailbox servers
None of these things has shown us the cause or indeed fixed an unknown cause.  Until we made a configuration mistake.

The guys who rebuilt the environment failed to install the SCOM agent (at first).  These boxes showed no signs of CPU creep.  Once they realised the missing SCOM agent they quickly installed it.  Suddenly we saw CPU ramping up albeit slowly over a period of 2-3weeks.

So we turned off the agent and the CPU settles back down.

We are now looking at removing the Exchange 2010 management pack from our environment to see if this is the cause rather than the SCOM agent.

More news when I know.

20/07/2012

Ok so now we have an Exchange environment with NO live mailboxes only a handful of test mailboxes.  With the SCOM agent installed we see the rising CPU.  Uninstall the SCOM agent and no rise.

Current situation is that we are not using SCOM to monitor our Exchange production servers.  Not good.  Microsoft don't seem to know what is going on either.




Comments

  1. Anonymous6 May 2014 at 10:48

    We are getting this on 2 of our production Exchange 2010 boxes. Both are configured identically to servers in another site (VMWare, same configs). It's definitely the SCOM agent. Did you ever get to the bottom of this?

    ReplyDelete
  2. AK15 May 2014 at 09:52

    No. Sorry. I wish I had. I have since changed jobs so do not know if this is now fixed but when I left (2013) they were still running without SCOM monitoring Exchange 2010.

    ReplyDelete

Post a Comment

Popular posts from this blog

PXE booting, MDT and 802.1x

-
Image
Oh dear. We implemented site wide 802.1x when we moved. This has caused numerous issues which we are still tracking down and killing with fire. Again "only-when-we-needed-it" struck as we had a new starter and need to build a machine. Ah.   No PXE.  However thankfully we were able to make a bootable USB using 802.1x and get our build working again from MDT in our 802.1 environment. Here's how we did it.   Caveats:  I'm assuming you know MDT and how PXE works. We use Computer certificates as the 8021x auth method. 802.1x is working in our environment GPO is used to start the wired 802.1x service on built machines. GPO is used to configure the network profile to use 802.1x What you need Get a USB stick to take your WinPE 4GB may be enough Make sure you are running an up to date working MDT installation! Create a machine certificate which has a long expiry date, you don't want to be making USB WinPE images every month!! Export the machine
Read more

Intune installation requires a wire...or does it?

-
If you are using Intune (great!) it assumes you have a wired connection (not great) - this is more of an issue as some machine now no longer have built in ethernet ports. It is possible to connect to your wireless - albeit in a slightly awkward way.....here's how During the OOBE hit SHIFT+F10 to get a command window and type either; start ms-settings: To get the settings window or start ms-availablenetworks: To see the network fly outs. Thanks to  Using a wireless network connection with Windows Autopilot white glove – Out of Office Hours (oofhours.com)
Read more

Security Policy 1001

-
We had an annoying warning showing every 5 minutes on our Read Only Domain Controllers.  This didn't affect service but meant we were losing our logs of important events (should the have occurred) "Security policy cannot be propagated. Security Configuration Server (in services.exe) is not ready. This is probably in system reboot. Policy will be tried again in the next propagation." Source: SceCli Event: ID 101 We tracked this down to a GPO which was populating the local Administrators group. Obviously a Domain Controller has no local users or groups so this was causing the issue. Ensuring that the GPO did not apply to the Domain Controllers - yes the GPO was linked at the root! fixed the issue. It is strange that we did not see the warnings on our main Domain Controllers only on the Read Only DC's as this would have affected all DCs the same (I would have thought)
Read more