So, you want to use Kerberos. During the configuration of SharePoint after installation,  in the Configuration Wizard, you will be asked to choose which security setting you want to use. If you choose Negotiate (Kerberos), and then click Next button on the wizard, you will get a prompt like the following:

What this message tells you is that you or your domain administrators must configuration Security Principal Names or SPNs in Active Directory.

In case you’re wondering, here’s a summary of my SharePoint lab environment:

• Windows 2008 Server R2 OS on all servers. AD is compatible with Windows Server 2003 features.
• Microsoft SQL Server 2008 R2
• SharePoint Server 2010

You can use use SetSPN tool to configure the SPNs for your SharePoint environment. Or, if you’re curious to see  what SPNs “look like” in Active Directory, you can use ADSIEdit. If you use ADSIEdit, login to the domain controller or use a server that has the Active Directory tools installed in it. When you open up ADSIEdit, expand the CN=Users tree and look for the domain account you want to setup SPNs for. The domain account that you want to setup SPNs for is typically the identity of the SharePoint Web site application pool. In the example below, I was adding SPNs to the “SP Web App Pool” account, which will be the service account used by the SharePoint Web site. Right-click the domain account in ADSIEdit and click Properties. In the Attribute Editor tab, look for servicePrincipalName.

Edit it and you can then add the SPNs for the domain account.  I have included a link in the Resources section on the bottom of this article to a Technet article that explains in full detail how to add SPNs in Active Directory.

In addition to adding SPNs to the service account, you must also enable delegation for the service account. Go to Active Directory and look for the service account. If you have setup SPNs for the domain account, you should see a Delegation tab on the user properties:

Check “Trust this user for delegation in specified services only”. And then select “Use any authentication protocol”. Finally, add the SPNs to the “Services to which the account can present delegated credentials” list. Links on the resources list will show you how to do this in full details.

In MOSS 2007, you have to setup SPNs for the service account and choose Kerberos as authentication mode and your SharePoint is good to go to use Kerberos. Setting up SPNs for SharePoint service accounts is nothing new. Well, in my lab environment, my SharePoint 2010 is running on Windows Server 2008 R2 with IIS7. The expected behaviour after adding SPNs was that the user (me) was prompted 3 times by the SharePoint site and only to render nothing after the 3 prompts for login. No matter how carefully I typed-in a domain account into the login prompt, I couldn’t get in!

Apparently, in IIS7, there are new settings that you have to configure in addition to setting up SPNs for the service account. You have to edit the applicationHost.config file in order to enable WindowsAuthentication. This IIS.NET article explains that IIS7 installs with windowsAuthentication disabled by default. But I have to give credit to Spence for his SharePoint article on how to enable Kerberos. Spence’s article was what actually got me moving in the right direction.

So I enabled windowsAuthentication (list of resources at the bottom of this article). When I tried to connect to the SharePoint site, I was being prompted to login!! Why?? So I typed-in domain account. On the first attempt, I was able to get into the SharePoint site.

It felt like challenge-response (NTLM) because I was prompted to login. I look at the Security Event Log of the SharePoint Web server. I see that the user logged-in using Kerberos!

So what now? Why was I still getting prompted to login? I forgot something–Internet Explorer security settings! I have to add the URL to my SharePoint 2010 portal in Intranet Zone sites. Also, you have to configure the “Custom Level” of the Intranet zone such that “Automatic logon onl in Intranet zone” is selected:

If the SharePoint site is not detected as an Intranet zone, you will notice in IE status bar:

If you have admin rights to the workstation, you can probably edit the list of sites in Intranet Zones in IE Security settings and enable automatic logon in Intranet sites Well, in my setup, the workstation–what a user can change and cannot change–is controlled by group policies.

I had to create a new group policy and link it to my domain (or you can edit the default group policy for the domain if it’s just a lab environment) When editing the GPO, the path to add SharePoint sites to Intranet Zone is:

Computer Configuration>Administrative Templates>Windows Components>Internet Explorer>Internet Control Panel>Security Page>Site to Zone Assignment List

When you edit the Site to Zone Assignment list, you’ll be presented a dialog box. You can add the sites (typically just make it “http//*.yourFQDN” so that all sites in your lab environment are detected as Intranet sites):

After editing GPO, propagate the new policy by restarting the workstation. After the workstation restarts, I hit the SharePoint site again and no more login prompts!! Also, notice on the status bar that the SharePoint site is detected as an Intranet site:

Hopefully, this article demonstrated to you how to configure Kerberos for SharePoint 2010. Yes, claims-based authentication is supposed to be the “preferred” mode these days in SharePoint but plenty of organizations out there will stick with Kerberos (Windows integrated security) for a little while. If anything, this article serve as a jump point to other great articles out there on how to accomplish Kerberos in SharePoint. List of links below.

Resources:

• Full Technet article on how to configure Kerberos authentication for SharePoint 2010. Very comprehensive. It talks about SPNs and how to add them in Active Directory. This is a good place to start: http://technet.microsoft.com/en-us/library/gg502602.aspx
• SharePoint 2010 and Kerberos: http://www.harbar.net/archive/2010/03/31/sharepoint-2010-and-kerberos.aspx
• Using Kerberos with SharePoint on Windows Server 2008: http://www.harbar.net/archive/2008/05/18/Using-Kerberos-with-SharePoint-on-Windows-Server-2008.aspx
• Very detailed walkthrough on how to enable Kerberos for ANY Web application: http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx
• Configuring Kerberos Authentication in SharePoint 2010: http://blogs.msdn.com/b/russmax/archive/2009/10/20/configuring-kerberos-authentication-in-sharepoint-2010-part-1.aspx
• <windowsAuthentication> element in IIS 7: http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication
• How to use Group Policy to configure Internet Explorer Security Zones: http://www.grouppolicy.biz/2010/03/how-to-use-group-policy-to-configure-internet-explorer-security-zone-sites/

• Error: Startup task doesn’t exist. This is not a continuation after a restart.
• Error: This file does not exist
• Error: The tool was unable to install Hotfix for Microsoft Windows (KB976462).

I searched the Web for the errors I got and it seem that a common recommendation is to simply run prerequisiteinstaller.exe from the command-line:

• Open up a command window
• Go to your SharePoint setup location (like D:\ if running from CD drive)
• Enter “prerequisiteinstaller.exe” and then press enter
• A GUI would popup but just go ahead and proceed. It should finish installation.
• Review the log file, located in %DEFAULTUSERPROFILE%\Temp and named PrerequisiteInstaller.[datetime].log. Make sure there are no errors on the latest log file.

We start “Subsite A” like the following:

Then, we change the URL into something malformed (deliberately for this exercise). See the Web Site Address field below? We’re purposely putting in a bad value (the end-user accidentally did it in the real-world scenario).

After you click the Save button on the Title, Description, and Icon Settings Page, you get the following error on the browser:

This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying.

Trying to access the site yields HTTP 500 error:

You think maybe you can rename using SharePoint Designer. But SP Designer throws you an error message instead:

Server error: The version of the Windows SharePoint Services running on the server is more recent than the version of the SharePoint Designer you are using. You need a more recent version of the SharePoint Designer.

But the SharePoint Designer error message is misleading–the SharePoint site is MOSS 2007. It’s the bad URL causing this.

You can fix this by using STSADM renameweb command. In the screenshot below, I rename the badly-formed URL to its original URL using STSADM renameWeb:

The site owner accidentally put in a bad URL and that is why we’re using STSADM to fix it. It’s hard to mess-up the site-collection URL. But if you need to change the URL of a site-collection, you can use STSADM renamesite.

For more details on how to use these commands, visit:

• How to use the new “renamesite” operation to change the URL of a host-named site collection in Windows SharePoint Services 3.0.
• Renameweb Stsadm operation (Windows SharePoint Services)

Sequence property of the WebConfigModification can be used to figure out the uninstall order.

Unnamed sections such as connectionStrings and bindings sections, appear to have an XPATH expression that may result in duplicate matching. But, the ApplyWebConfigModifications method of the WebConfigModifications object will do it correctly as long as:

• EnsureChildNode is used as the type
• Add/Remove in order that is logical. Example: add connectionStrings section first then the add elements inside the connectionString section.
• If you are worried that de-activating a feature will obliterate the connectionStrings section because your feature created it, don’t. SharePoint will only take out the connectionStrings if there are no other entries created by the ApplyWebConfigModifications inside the connectionStrings section. If other features inserted 1 or more connection-string entries there, your feature-receiver will not remove the connectionStrings section. Now, if the connectionString section got edited manually, the SharePoint WebConfigModifcations object will not know this and it doesn’t matter how many child-nodes there are inside the  connectionString object. The root element (connectionString) in this case will be removed because in SharePoint’s perspective, there are no existing Web-config modifications inside connectionString.

Conclusion: if you are going to adopt feature-receivers to install web.config entries such as connection-strings and bindings (for Service-References), you must also adopt to policy to discourage manual insert/modification of the web.config entries. Be consistent.

http://www.sharepointsaturday.org/dc/default.aspx

If you’re around DC area and you’re an IT professional using SharePoint, I recommend you attend. And you don’t want to miss this one. The last SP Saturday DC that I attended, they intentionally banned discussions of SharePoint 2010 in the official agenda (you can talk it on the hallways and breaks but wasn’t allowed at the session topic). Looking at the current lineup of the sessions, there are going to be a lot of SharePoint 2010 sessions! So attend!

SharePoint Saturdays typically have good sessions and it’s an opportunity to meet other SharePoint folks. If you’re not from the DC area, SharePoint Saturdays are all over the country and I would recommend checking  what the closest SharePoint Saturday is.

There are still some Coldfusion developers in this organization but these Coldfusion apps are being phased out and eventually  will be converted to ASP.NET and/or SharePoint. These Coldfusion developers do not have a background on ASP.NET programming model, which is really different, closer to VB6 model if you look at it that it is closer to “classic ASP” model. “Classic ASP”, Coldfusion, and PHP are in the same category in my book—they are server-side scripting. ASP.NET and  SharePoint on the other hand are more object-oriented.

One of the Coldfusion developers asked me which topics on ASP.NET and SharePoint should they learn and in what order. They are excited to develop SharePoint stuff such as Web parts and workflows but need some guidance on where to start.

Here’s the list of high-level skills/topics I pointed out one should in order to develop SharePoint solutions:

• ASP.NET model
  • ASP.NET User Controls
  • Intrinsic Objects (HttpContext, Application, Request, Response, Server, etc.)
  • ASP.NET Page life-cycle
  • C#
  • ASP.NET Web App configuration files
  • .NET Namespaces
• Object-Oriented/Component Programming
  • Properties and Methods
  • Events
  • Delegates
  • Inheritance
  • Implementation (interfaces and abstracts)
• SharePoint Features Development
  • Visual Studio SharePoint Project Extensions/Templates
  • SharePoint Object Model
  • Deploying Features using STSADM

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!

1. Rename the wsp file to a .cab file
2. Open up the .cab file (used to be wsp) in WinZIP or something that can open a CAB file.
3. You can either: a)  extract all files in the cab file and open up the extracted manifest.xml; or b) look for manifest.xml in WinZIP and just extract that one single file.
4. Open up manifest.xml in notepad, Internet Explorer, or your preferred XML file viewer.

That’s it!

Several of my upcoming posts will be on how to create solution packages. Stay tuned!

Most objects in ASP.NET Framework are allocated/deallocated in memory automatically. However, there are objects that inherit from the IDisposable. You have to explicitly dispose objects that implement the IDisposable interface or you will run the risk of memory leaks. Some examples of ASP.NET objects that implement IDisposable include Connection, Command, Adapater, and Reader objects (in the System.Data namespace). You can perform any of the following to dispose these objects properly:

SQLConnection connection = new SQLConnection(connectionString);

//use the connection object here

connection.Dispose();

Or, you can using the using statement:

using(SQLConnection connection = new SQLConnection(connectionString))

{

                //use connection object here

} // don't have to call Dispose(); the using statement will dispose connection correctly

When working with SharePoint API (SharePoint .NET libraries and not the SharePoint Web services), it is important to know when and when not to dispose SharePoint objects. If you do not dispose objects in SharePoint, your server will run the risk of memory leaks which can lead to performance issues. If you dispose objects that you’re not supposed to call Dispose() on, you might inadvertently kill the SharePoint application! For example, the following code will definitely kill the SharePoint Web application:

SPContext.Current.Web.Dispose(); // expect calls to your help-desk with this line in your code!

If you are the custodian of the SharePoint farm, you might want to use the SP Dispose Checker Tool to ensure that the custom .NET assemblies being installed on your farm will not cause memory leaks.

For complete guidance on when and how to dispose SharePoint objects, you can read the SP Dispose Team blog.

Solution Explorer in VS 2008

In order to see the manifest.xml or feature.xml file, you have to look at the “WSP View“. WSP View can be accessed by going to the menu and hitting View–>Other Windows–>WSP View. The WSP View looks like the following:

WSP View

The manifest.xml file doesn’t contain “product description” type information. The manifest.xml contains assemblies and features information. The feature.xml file, that on the other hand, start containing “description” type data. Here’s what the feature.xml contents typically look like:

<?xml version="1.0" encoding="utf-8"?>

<Feature Id="cfc5cfdd-62cf-4d98-aeba-e1b38ec6f64f"

             Title="HelloPart"

             Description="A Web part that wants to say hello to you."

             Scope="Site" Version="1.0.0.0" Hidden="FALSE"

             DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/">

  <ElementManifests>

    <ElementManifest Location="HelloPart\HelloPart.xml" />

    <ElementFile Location="HelloPart\HelloPart.webpart" />

  </ElementManifests>

</Feature>

See that Title and Description attributes inside the Feature element? They will get displayed in the Site Features Gallery: 

WP Title and Description in the Features Gallery

What about the Web part file (in the example I’m using above, the filename is HelloPart.webpart)? What information can be customized and modified here? First, let’s take a look at the contents of the webpart file:

<?xml version="1.0" encoding="utf-8"?>

<webParts>

  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">

    <metaData>

      <!--

      The following Guid is used as a reference to the web part class,

      and it will be automatically replaced with actual type name at deployment time.

      -->

      <type name="247ef4d4-489d-46d1-a628-8d8daa6267a3" />

      <importErrorMessage>Cannot import HelloPart Web Part.</importErrorMessage>

    </metaData>

    <data>

      <properties>

        <property name="Title" type="string">Gabe's Hello Web Part</property>

        <property name="Description" type="string">HelloPart is a user-friendly Web part....</property>

      </properties>

    </data>

  </webPart>

</webParts>

Inside webPart–>data–>properties section, there are property elements. The first one is the “Title” and the other is the “Description“. The values for “Title” and “Description” contained in the webpart file are what gets displayed in the Web part catalog:

WP Title and Desription in the WP Catalog

Finally, let’s take a look at the Web part XML file (in the example I used above, the filename is HelloPart.xml). The Web part XML file contains the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

    <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary" />

  </Module>

</Elements>

See how the File element doesn’t have any children? We can put a Property element as a child of the File element. This Property element will contain the “Group” the Web part appears in the catalog. By default, like the in the Web part XML file example above, the Group is not specified and therefore, the Web part gets listed under Miscellaneous Group in the Web Part catalog. If you want the Web part to appear in a group other than Miscellaneous, transform the Web part XML file from the above example to the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

        <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary">

              <Property Name="Group" Value="My Stuff"/>

        </File>

  </Module>

</Elements>

We added the Property element below the File element. The Name attribute of the Property element should have a value of “Group” and the Value attribute is the group name you want the Web part to appear in the catalog. In the example above, after the Web part gets deployed, the Web part appears in a category called “My Stuff“:

Web Part appearing on specified Group