The IT Crownd

I recently found out why our MOSS 2007 FEW which was hosted on a Windows 2008 R2 server was unable to provide MOSS sites. Whilst this was not a service impacting issue, we have plenty of other SharePoint 2007 FEWs so one less didn't matter plus this one was really just doing the Report Service bit in any case. However after a couple of weeks of getting annoyed at this I decided to look for a solution.  A quick trawl of Google later and I found this site which explains things nicely. http://sharepointspot.blogspot.co.uk/2008/12/sharepoint-kerberos-on-windows-2008.html Basically this is due to Windows 2008 R2 doing kerberos in the kernal and as such it ignore any SPN you may have in place and uses the computer object.  In principle this is a great thing, no more SPNs needed!  However poor old MOSS needs SPNs as all the website applicaiton pool MUST run using identities if you are using kerberos. Quick change to the C:\Windows\System32\inetsrv\config\applicationHos...

Nothing is every easy. Last week I installed the SCOM agent on our shiny new TMG array.  I followed the instructions from Microsoft and everything went smoothly.  Until I attempted to approve the last member of the array within SCOM Management Console.  An error occured which ditched my console.  I didn't worry too much and I thought nothing of it till the next day when the last server wasn't appearing in SCOM. The console however no longer showed the server as pending - infact the console didn't show the server at all. I found some powershell lying around on the internet which allowed me to approve/reject and list computers in "pending management" there was my server!  I duely approved the pending operation and bingo back in business. Gotta love Powershell.  Just a shame that they don't use powershell to populate to console! To list pending agents...(oh yeah you need to run the Operation Manager Shell - not just Powershell you knew that...

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 in...

Grrr....pulling my hair out on this one. We have SCOM 2007 R2 (which I love) and we are running the excellent management pack for Exchange 2010. If you read an earlier post I finally figured out that the Agent Proxy needs ticking to make discovery work so we are humming along now. Except for one thing. My Public Folder server. We have one mailbox server dedicated to public folders.  The problem here is that this server is never healthy.  KHI: Failed to execute Troubleshoot-DatabaseSpace.ps1 fails. Looking into this script I see that this script uses the Get-MailBoxDatase this will not work on a public folder.  Further investigation leads me to believe that all the scripts within the Exchange 2010 Management Pack are not Public Folder compatible.  Now whether this is because a discovery which isnt running in my environment I don't know...*grrrr*

Bleeding edge?  So you will proboably know what PVSCSI is all about We had two days of worry - our Exchange 2010 Mailbo server was showing events of having a corrupt database.  The event description pointed at the storage.  ESE 482: Thus ensued a witch hunt for the actual culprit.  Storage logs reported all fine...the issue came and went.  Unfortunately when it came the databases failed over to the other node of the DAG. We found a page on VMWare's site detailing that a high IO server could have issues when using PVSCSI and that updates to the driver are required.  The driver updates pre-requiste was of course a patch to ESX 4 too.  Not something we can do on a whim, change management anyone? See here: http://longwhiteclouds.com/2012/03/14/win-2k8-with-pvscsi-critical-issue/#more-801 and here: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009144 So we had to remove the PV...

Bit of a fool on this one! Spent a couple of days wondering why our new Exchange 2010 boxes weren't appearing in SCOM only to remember (with a hint from a Google search) that Agent Proxy needs enabling.  Flush Health Service State and Cache. Bingo. d'Oh! Note to self...read the manual!!

From the title you can guess that we have Exchange 2010 (SP1 CU6 - with Hotfix for EVault) and we are using NetScaler VPX to load balance the services.  I used the excellent document from Citrix to configure the NetScalers (we have two in active/active - sort of using VMACs to split the traffic RPC to one, HTTP(S) and SMTP to the other). However I found a document from Microsoft which points out that there is "significant performance penalty" if we configure incorrect persistence for EAS.  The Microsoft document is here: http://technet.microsoft.com/en-us/library/ff625248.aspx This put us in a pickle and no mistake.  This is because in a NetScaler persistence is per vServer.  We have one vServer for HTTPS as we have one IP address for all HTTP traffic.  This vServer would then deal with all HTTPS traffic including OWA,ECP,EWS,RPC over HTTPS and EAS.  OWA requires cookie based persistence, this is also the method the Citrix doc...