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”)))
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?
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.
This is probably the most nominal WebPart I have ever seen / written but I really needed it this morning. As you can guess it just uses a ServerVariables object (off the current context request) to expose the relevant environment variables, in this case just the server name.
The reason this came about was in large SharePoint farms it is notably important when doing certain types of architecture troubleshooting to know which WFE you are hitting. Andâ€¦.wellâ€¦that’s really it. At least you don’t have to put the WSP together I guess.
So this is what that WebPart does. Just install the WSP and deploy it in Central Admin (as noted in previous posts, I never automate the deployment step).
The WebPart is Feature activated. In the site collection features, locate the Server Name WebPart feature and activate it.
Once activated, you will find the WebPart under the ARB Security Solutions header in the WebPart gallery.
Add it to the page, and it will display the server name in the SharePoint farm responding.
Well I guess I should actually give a download link :)