Enumerating All SPWebs In SPFarm.Local Into Strongly Typed Collection

So when enumerating the SPWebs within a SPFarm to build a strongly typed SPWeb collection for whatever purpose your enumeration might look like this:


public static List WebsPreppedForIteration()
var collection = new List();
foreach (SPSite x in SPFarm.Local.Services.OfType().SelectMany
(svc => ((svc).WebApplications.Where
(webApp => !webApp.Properties.ContainsKey(“Microsoft.Office.Server.SharedResourceProvider”)).SelectMany
(webApp => webApp.Sites.Cast()))).Where
(x => !Equals(x.RootWeb.Title, “Central Administration”)))
return collection;


I saw this in a code review today. The part I am wondering about is the SPWebApplication property bag to query the key for WCAM as opposed to do a clunky string SPWeb.Title comparison. Putting the keys out to standard output hasn’t yielded anything particularly evident, and I’m getting frustrated with the under-the-hood, unnecessary foreach loop with a fancy shirt on (the second LINQ query against the Title property(,

Does anyone know the key for WCAM?


Fixing Access Denied Errors With SharePoint 2010 Timer Jobs

It is important to realize before we get started that this error was also present within SharePoint 2007. When creating timer jobs, it is important to understand the relationships between the SPSecurity.RunWithElevatedPrivileges method and the associated SPWebApplication object. When using SPSecurity.RunWithElevatedPrivileges, it will not allow modification of the SPWebApplication since it is persisted to the configuration database. However, other proxy objects are exempt from this such as SPSite ‘s and SPWeb ‘s. SPSecurity.RunWithElevatedPrivileges allows the elevation to just the content database, NOT the configuration database (which has the SPWebApplication property bag) which is generally more locked down.

The easiest way to fix this is to impersonate the user account for proxy objects (assuming you are using a current context to reference the application property) with an account that has the wss_content_application_pools database role for the config database since this will have elevated rights for stored procedures and what not. This will allow you to modify your timer jobs easily. If you want to be really lazy, just use the same account as the central admin app pool which inherently provides the required access to the configuration database.


The Infragistics SharePoint Demo Is Funny, But Depressing

So, I recently got solicited for feedback and comment from Infragistics because I was for some time heavily into using their control set. Regardless of some of the unwieldy operations to sustain the nifty functions, I think they are neat and a lot of the times clients have a pre-existing license agreements so I just use ’em.

Infragistics appears to be making a tactical move into the SharePoint space; therefore curiosity arose in me to go test out what they had recently released. Regrettably, in conventional let’s hurry up and provide a SharePoint solution format which can be vendor criterion, Infragistics wins for the most cumbersome deployment process feasible. Well, maybe not that bad, but it’s pretty damn close.  The WORST part about this situation is the code behind for the solution is fantastic (not being sarcastic, it really is pretty good!), and it’s a bummer that they dropped the ball on everything BUT managed code development. Kudos to the developer on the code though.

So, here is the page of concern:

And here is a link to the configuration guide:

Alrighty, let’s get started. Once the PDF is open, scroll down to page 10.

1) Get to step one. WTF?!?! Cmon Infragistics, you want *manual* web.config modifications? LAME. That can take forever to complete on a staging farm, and is subject to substantial human error. I mean come on; the SPWebConfigModification class exists for a reason and there are all sorts of receivers.
– Moving right along, reference point 1 for the custom configuration sections instances. Are people really supposed to copy and paste that shit?
– Manual safe control entries. HA! I like that one. No note needed on that sweetness.
– Manual CAS adjustments make me want to cry. Seriously, as someone that takes code security critically, I want to shove a pen in my eye to damn the tears up like a Bic beaver.
– Again, the session state stuff? See above.
– Could go on with the rest of em, but you get the point…
2) Creating folders at the root of the site can be automated, that’s why we have SPWebApplication, etc. objects. You can even do your permission requirements as well.
3) You want people to copy things into the 12 hive. Is there a point to that? I mean, it is breaking the fundamental principle of SharePoint Solution architecture. That’s one of the reasons WE HAVE SOLUTIONS.
4) Uploading a master page can be automated since the Master Page Gallery upload is the same as any document library. Sigh.
5) As opposed to packing .webpart or .dwp files, you are asking people to new them up out of the gallery. The extent of that laziness is immeasurable in words.
6) Well, I guess back to the 12 hive thing, again, manual Theme deployment. Word.
7) After I saw SPD, I threw up a little bit in my mouth and stopped reading.

I am not bagging on the controls, but FFS, if you are going to build a sample solution, MAKE IT EASY AND QUICK TO DEPLOY. I don’t want to spend a fucking afternoon trying to get some pie charts and random data grids into a demo site.