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:

[csharp]

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”)))
{
collection.AddRange(x.RootWeb.Webs.Cast());
}
return collection;
}

[/csharp]

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?

Share

SharePoint 2010 Service Application Design Best Practices

Through SharePoint 2010, there is an improvement of the services infrastructure that was previously introduced in an earlier version. This infrastructure also hosts services for the SharePoint Foundation 2010. The configuration of services offered is very flexible. This allows the individual services to be configured independent of each other. It also makes it possible for 3rd party companies to be able to add services to that platform. The configuration of services aren’t exclusive to SharePoint Server. The services aren’t restricted to Shared Services Providers.

When service applications are deployed from a farm there are a couple of different methods that can be used.
They include the use of Windows PowerShell, adding services one at a time through the Manage Service Applications page, and choosing services for running the SharePoint Products Configuration Wizard.

The infrastructure of the services has been updated so that there is more control over the types of services that have been deployed. There is also control over the types of service applications that have been shared. Only the service applications that are necessary for a farm can be deployed. The various web applications can be configured so that they only use certain service applications. This is better than them using all of the various services that have been deployed. Service applications can be shared across various web applications that are within the same farm. All of the service applications that are included in a default group will remain unless you change them. There are settings for service applications that can be created. You can add or remove service applications in that default group any time you want to.

The creation of web applications allow you to select the default group you want or to create one that is customized. If you want to customize your service applications you can do by selecting those that you want to be part of the web application. When custom groups are created in Central Administration, they can’t be used for all of your web applications. When you select custom to create a web application you will limit them to only that specific web application you happen to be using. Each of the service applications has a single Internet Information Services website. This is the default setting and you won’t be able to change it. However, you do have the option of customizing how it is configured for various application groups.

There are several characteristics of a farm that you need to be familiar with. Web applications will connect to the default group or a custom group of service applications. All of the service applications will be found within the same Internet Information Services website. Service applications are in a group as defaults or customized. However, not all of the service applications have to be placed into one of those groups. They can be used by a single web application if you wish.

It is possible for service applications to be deployed to different applications pools. This results in process isolation occurring. If you want to optimize how your farm performs then it is recommended that you deploy service applications to only one application pool. In order for that isolation to occur with a service application, you need to create a new application for the pool service application.

While creating a service application there is a connection for the service application that is being created at the same time. There is a connection that is a virtual entity for connecting to web applications. With Windows PowerShell these connections are known as proxies. A proxy will be at the end of the type description for a connection which is through the Manage Service Application in Central Administration. Some of these connections may include settings that you can modify. This includes the Managed Metadata service application, Term Store Administrators, and Default Language.

When you directly manage service applications in Central Administration you can manage and monitor them from a remote location. They can also be managed and scripted through Windows PowerShell. There are some service applications that are shared among many farms. Others though can only be shared in a singular fashion with a given farm server.

Computing intense service applications that operate within a central farm. This is done to minimize the overhead costs relating to administration. This is also to help keep everything operating efficiently, even as the requirements of the farm grow. If you use service applications to support sharing across farms, they should be controlled by a central farm. Then they can be consumed from that core location. For each of the web applications that will be configured, use service applications from different farms.

Share

SharePoint Security And Authentication Part 1 – Understanding Authentication In SharePoint 2010

There are numerous authentication methods that are supported by SharePoint Server 2010. Through authentication the identity of a user can be validated. Once that occurs the process of authorization will also determine which sites, what types of content, and which of the features available a given user has authority to access. SharePoint Server 2010 can be considered a type of distributed application. There are three tiers that it is divided into which are all important to consider when determining your authentication strategy:

  • Application server
  • Back end database
  • Front end web server

Each of these tiers offers a sub-system and corresponding authentication. A user has to be authorized before they can go from one tier to the next. The provider has control over what levels of access each user has. Those providers offer various software elements that are used to support a specific method of authentication. With SharePoint 2010 you can use a classic mode of authentication or a claims based method. If you are upgrading from Microsoft Office SharePoint Server 2007 Microsoft documentation will recommended you use the classic mode, personally I think it's advisable to just go claims since you can use the identity generation service to generate Windows identities. If you plan to use a forms based authentication or one that is SAML token based you should use the claims based method. This is because the classic mode authentication will only support Windows authentication.

There are several methods of authentication that can be supported by SharePoint Server 2010. As you explore the basics of them you can decide what will work best for your organization. There are three:

Windows

This is the standard method of authentication. There are many methods that fall into this particular category. They include:

  • Anonymous This allows users to find and access resources from public areas of websites. They don’t have to provide any credentials for authentication to do so.
  • Basic This requires a user to have account credentials that have been assigned ala Windows. There is a web browser that is enabled to provide such credentials when someone makes a request. The credentials of users aren’t encrypted but sent across the network as clear-text. Therefore it isn’t recommended for the use of basic authentication to be used on any connection that isn’t secure. Always use SSL encrypting for additional security.
  • Digest This type of authentication is very similar in function to basic authentication. However, it offers a much higher level of security with it. The credentials are encrypted as they are sent across a network. The username and password can’t be deciphered along the way. Valid credentials must be given by a user that belong to the secret password string.
  • Certificates This offers an exchange of the public key certifications. The use of SSL encryption is used. These certificates are issued by a Certificate Authority. They have to fit the Public Key Infrastructure. This can be done by selecting Windows authentication in the Central Administration area. Once SSL is enabled then the configured certification can be obtained from Certificate Authority.
  • NTLM This is a requirement for any network that receives requests for authentication from client computers which don’t support Kerberos authentication. NTLM is secure and it allows for credentials of users to be encrypted before they are transmitted. Windows NT Server, Windows 2003 Server WorkGroup, and Active Directory use NTLM authentication. It may be the default and need to be disabled if you don’t want to use it.
  • Negotiate With negotiate authentication for either NTLM or Kerberos, they client has to choose one of them. The default is Kerberos. The client application has to provide a Service Principal Name and a User Principal Name for the account. When such information can’t be offered then NTLM has to be used for authentication.

Forms Based

This type of authentication offers support for management systems that need to make identifications. They aren’t based on Windows because they make it possible to work with identity management systems. These use the MembershipProvider interface. This includes:

  • Custom membership providers
  • Lightweight Directory Access Protocol
  • SQL Database

This based on ASP.NET as well as role provider authentication. With SharePoint 2010 it is only able to be used when claims based authentication is used. Forms Based Authentication can be used to be able to authenticate other user accounts too when connected to Microsoft SQL Server database. You need to register the membership provider in the Web.config file in order to use this type of authentication.

SAML Token Based

This type of authentication is claims based. It is created to support a Windows Identity Foundation. This is a set of .NET framework entities used for the implementation of claims based identity. They include:

  • 3rd Party identity providers
  • Active Directory Federation Services 2.0
  • Windows Live ID

Next, we are going to be talking about user management in this SharePoint security series.

Share