In a server administrator’s never-ending battle with log clutter, DCOM errors have proven to be some of the most persistent and poorly-understood events – especially with SharePoint. Our community has been building up remedial practices for the most common of these errors, but changes to the number and complexity of these fixes over the last few years call for a deeper look at what we’re changing, and the effects of these changes beyond a reduction in red and yellow icons in the event logs. In this post I’ll talk about some of the fundamental concepts from a Systems dude’s perspective and along the way I hope to convey a better understanding of Windows itself.
My colleague Anthony Clegg and I have recently been working on a project together, for which I’ve designed and delivered the infrastructure, while he’s been delivering the solution. As part of my design, I extended the SharePoint Web Applications from the default HTTPS zones to new HTTP zones, exclusively for crawling. This approach has been around for some time, but there’s a new wrinkle on the SharePoint 2010 Enterprise Search Centre People Search results page, which I’ll discuss here:
I’m presently running some quite methodical SharePoint 2010 development environment performance tests, as we’re finding that the Dell XPS M1330 we’ve been using for the last few years doesn’t really cut it in some scenarios. This has been an on-going issue for some time where I work, but it’s only recently been prioritised at the top of my workload. That it is now my top priority should give some indication how important these issues are for any company that spends significant time customising SharePoint. I’ll be discussing this wider project in more detail once I’ve finished my testing in the next couple of weeks, but for now I wanted to share a provisional finding about connecting Web Applications to the User Profile Service Application.