A couple of months ago I was happily building a client’s SharePoint Server 2010 farm when I stumbled at Search. The Service Application provisioned fine, but when I pushed out topology changes I started to have problems. Later, these problems returned in different forms, but the root cause appears to have been consistent. In this post I will review the symptoms, the single fix and the reason why this issue emerged in this environment. I’ll also look at some unexpected permission changes that occur when new servers receive Search Service Instances.
In my last post I discussed how the Product Version Job timer job uses the Windows Installer Service to query the installed state of SharePoint 2010 servers and how the Manage Patch Status page in Central Administration displays this information. I also touched on my reservations about what we can infer from this data. In this post, I’m diving a bit deeper in to that question.
Continue reading “Testing Manage Patch Status”
Back in August, I stumbled across a new type of DCOM 10016 error in SharePoint 2010, caused by the Product Version Job timer job. When I found the error, I was primarily concerned with keeping my event logs clean. Since then, the inelegance of my original work-around and the incomplete picture I contented myself with at the time began to nag at me, but I only recently started digging deeper, prompted largely by the fact that this topic has generated more traffic to my blog in the last quarter than any other.
I finally tested the SharePoint Server 2010 December 2010 CU package over the last couple of nights. The good news is that it actually worked (I’ve had trouble with August and October) and it has a load of fixes, particularly for the User Profile Service Application. The bad news is that it’s known to require restarting the User Profile Synchronisation Service after it completes. In my tests, I also had to temporarily re-add the Farm account as Local Admin and reboot before re-starting the service, after running the installer and the Products Configuration Wizard. It failed when I just tried to temporarily add the Farm account as local admin and log off/on again, so the reboot before re-starting the service is likely to be necessary.
UPDATE 19/2/2011: I got a comment from Spencer Harbar today (below) noting that restarting the SPTimer service is sufficient after temporarily adding the farm account as local admin. The reboot isn’t necessary to acquire the new rights although in my test I did need to reboot after running the installer.
I’ve recently been involved in a somewhat unusual client engagement, in that I was designing and delivering the infrastructure without knowing the shape of the IA or solution architecture. Obviously, this imposed some restrictions on what we could define, but it also meant that I had to handle some aspects of the engagement that would normally be taken care of by other colleagues. To that end, I suppose some of these considerations aren’t purely infrastructure-specific, but they could be in an engagement like this one and they’re things that infrastructure people should understand. Hopefully it’ll be useful for solutions people as well.
Drum roll please! At long last, I bring you the results of a great deal of testing. Here’s the background:
- SharePoint Development Productivity and Virtualisation Technologies
- SharePoint 2010 Development Environment Performance Tests
I’ve said my preamble in those posts, so I’ll cut to the chase here.
As I indicated in my last post, I’ve been plundering the depths of SharePoint development productivity in recent months. Understanding the context established in that post is pretty essential to understanding what follows here. In a nutshell, I’m trying to improve system performance for current users of our SharePoint development environment. This is not as simple as examining the Windows Experience Index on a number of laptop models. I needed to consult with our users to identify which tasks are slow for them and devise tests that would allow me to measure system performance on different physical and virtual systems. In this post I will describe the systems, the tests and the testing process before reviewing the results.
The 21 tests that we settled on were the result of discussions with a number of the core developers, consultants and architects at Content and Code, plus a few tests that I threw in to confirm/disconfirm some of my suppositions, such as the impact of the User Profile Service Connection on first page load time. All 21 tests were run three times for each permutation of hardware candidate and virtualisation technology. We also tested on Amazon EC2. I will discuss the testing process in more detail in a moment.
In the near future, I’ll be discussing the results of the SharePoint Development productivity testing that I’ve been working on for some time. A key part of the background to that story is a choice to virtualise SharePoint, and within that, a choice of virtualisation technology. In this post I’ll be reviewing the problem in advance of a more detailed discussion of the productivity gains and losses with some of these technologies/approaches.
For clarity, I will quickly state the problem as I see it. SharePoint 2010 system requirements and practitioner mobility requirements are inherently at odds. What guidance exists for this unique problem space tends to regurgitate preferences/allegiances rather than comparing technologies and ratifying assumptions with real-world tests. At best, you get system performance indices for a single laptop model, but these results may vary when any hardware component is changed.
In the previous posts in this series I’ve discussed the AWS platform and took a closer look at storage, snapshots and provisioning, looked at networking and cloning and then reviewed administration, delegation and licensing. In this post I will analyse cost, which is probably the most important factor when considering a move to the cloud.
In the first part of this series on SharePoint 2010 infrastructure considerations for Amazon EC2, I introduced the AWS platform and took a closer look at storage, snapshots and provisioning. In the second post I moved on to networking and cloning. In this third post I will discuss administration, delegation and licensing.