SharePoint: Bug or Feature? @Created not on Variation Site

As mentioned in the title, the @Created date field (or site column, depending on your terminology), the date of document creation, which is by default available to all pages and documents, is not replicated when you create a site variation. It is however *linked* to the original document from the original site itself. So if you ever decide to turn off site variation, you’ll lose the @Created date field on your site variation, and there’s absolutely no way to get it back, or at least I haven’t found a way to get it back without hacking it through code.

So be careful when you decide to create a site variation. This “feature” caught us all by surprise, especially when variation was turned off and still wanted the persisted site.

One suggestion to get around it is to create another field and set the computed value to today’s date. I’ll blog more on how we solve this problem when we actually do.

How to change the URL for SharePoint Central Administration site

I have been working on configuring high availability for SharePoint servers (MOSS or WSS), and for a little while I wasn't able to figure out the way to modify the URL for SharePoint Central Administration site. So, basically you extend the Central Administration web application (using GUI or psconfig command) to run on multiple servers, and when you click on SharePoint Central Administration icon you're still redirected to a specific SharePoint server instead of been redirected to the Load Balancing URL. Anyway, as it turns out the URL has to be changed via registry on all SharePoint servers. Weird?!

To change the URL for SharePoint Central Administration URL:

  • Open Registry editor
  • Backup the registry before making any changes!!!
  • Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS and change the value of CentralAdministrationURL to whatever you want to be


Related resources:

How to change the port number for SharePoint Central Administration site

To change a port number that SharePoint Central Administration site is running on:

  • Open Command Prompt
  • Go to BIN folder in SharePoint install directory (by default, it would be "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN")
  • To get the port number that Central Administration site is currently running on, type

    stsadm.exe -o getadminport
  • To change a port number that SharePoint Central Administration site is using, type

    stsadm.exe -o setadminport -port <portnumber>

Sharepoint Development: Enable Debugging

Note to self – Before developing on SharePoint, always enable debugging on the development machine to see a “little” more verbose error messages. Edit the web.config and change the following:

<SafeMode MaxControls="200" CallStack="false" ...> <!-- Becomes -->

<SafeMode MaxControls="200" CallStack="true" ...>

 

<customErrors mode="On" /> <!-- Becomes -->

<customErrors mode="Off" />

 

<compilation batch="false" debug="false"> <!-- Becomes -->

<compilation batch="true" debug="true">

Sharepoint Development: &amp;quot;Request failed&amp;quot; with custom page or dlls/assemblies

Note to self - If using any external assemblies that try to access Microsoft.Sharepoint assemblies, remember to change the trust level to full in the web.config.

<trust level="Full" originUrl="" />

This is only used during development.

When it comes to production, install assembly into the GAC with gacutil /i to allow external assemblies access to Microsoft.Sharepoint assemblies.

SharePoint: No easy way to deny access

For a sophisticated web application, SharePoint (WSS or MOSS) is missing a feature as simple as Deny access (Deny Read, Deny Write, Deny All). To deny access to the SharePoint for single user or a group of users, you modify Policy for Web Application in SharePoint Central Administration:

  • Open SharePoint Central Administration
  • Click on Application Management
  • Then, under Application security, click on Policy for Web Application
  • Select correct web application in the drop down
  • Click on Add Users
  • Select web application and the zone. Click Next
  • Enter the username or security group. Select Deny Write or Deny All and click on Finish

Note: This will deny access to the whole web application in SharePoint! There is no way to deny access to a specific SharePoint item (site, list, document library and so on)

Hopefully Microsoft will fix this weakness in the next service pack or so…

TechEd Developer EMEA 2008

I found out a few days ago that I've been selected to speak at TechEd EMEA in Barcelona. I'm really excited as this is not only my first time speaking outside of North America, it's my first trip to continental Europe. My session is on using ASP.NET AJAX with SharePoint 2007.

Integrating ASP.NET AJAX with SharePoint.
SharePoint provides a great infrastructure for quickly building intranet and Internet applications. ASP.NET AJAX provides a foundation for creating highly productive Web interfaces. Combined they are two great tastes that taste great together! In this session we will cover the basics of working with ASP.NET AJAX inside of SharePoint 2007. We will take a look at how to prepare a Web Application for ASP.NET AJAX and how to use various ASP.NET AJAX tools such as the JavaScript libraries, JSON-enabled Web services and UpdatePanels to build add rich interactivity to your SharePoint sites.

If you're attending the conference and find the session interesting the please feel free to go to the session list and rate it. I don't know for sure but I think that your rating and the number of people who give a rating have an effect on the scheduling of the session. I'm positive that the number of ratings you receive helps determine if your session will repeat.

I'm not going to be able to attend the PDC this year (this event and the PDC were too close together) so I'm glad there's a PDC track at TechEd. From all reports PDC is going to rock so at least I'll be able to get a taste of the content.

I'll be Twittering (http://twitter.com/rob_windsor) and hopefully blogging from the conference. If you're there feel free to look me up or better yet drop by my session.

SharePoint bug: extending web application breaks the backup process

There appears to be a bug in SharePoint (WSS or MOSS) that breaks the backup process after extending a web application. If you need to add host headers or load balancing URL to your SharePoint web application, the only way to do that is to extend your web application (SharePoint Central Administration >> Application Management >> Create or extend Web application >> Extend an existing Web application). Even though extending web application allows you to add load balancing URL and host headers, for some reason, it breaks the backup for all site collections and sites that use that web application. You could still backup SharePoint site collection using stsadm.exe command (stsadm.exe –o backup –url http://damagedWebApp/ -filename backup_damaged_webapp.bak), but built-in SharePoint backup through Central Administration wouldn't work. You will start receiving an error (Error: Object SharePoint - 80 failed in event OnPrepareBackup. For more information, see the error log located in the backup directory. KeyNotFoundException: The given key was not present in the dictionary) every time you attempt to backup modified web application using Central Administration website.

To get backup process working again you will have to perform the following steps:

  1. Backup your web application database through Microsoft SQL Server Management Studio!!!
  2. Detach the content database from the web application:
    1. Go to SharePoint Central Administration >> Application Management >> Content Databases
    2. Make sure to select damaged web application form the drop down list, otherwise you will messing with the wrong web application
    3. Click on the content database used by damaged web application
    4. Check "Remove content database" and click OK (ignore the warning). Removing the content database does not delete the database; it only removes the association of the database with the Web application. This action is analogous to detaching a database in SQL Server in that the content of the database remains intact.
  3. Delete the web application (remove SharePoint from it):
    1. Go to SharePoint Central Administration >> Application Management >> Delete Web Application
    2. Make sure to select damaged web application form the drop down list
    3. Leave "Delete Content Databases" and "Delete IIS Websites" options set to "No". You can always remove them later, right now we are only interested in removing SharePoint references to the damaged web application
  4. Create a new web application with the appropriate settings for host header, load balancing URL and so on:
    1. Go to SharePoint Central Administration >> Application Management >> Create or extend Web application >> Create new Web application
    2. Configure new web application settings. Don't forget host headers, new website and port settings, and load balancing URL (as needed) and click OK
  5. Remove content database of the newly created web application by running
    stsadm.exe -o deletecontentdb -url http://newwebapplication:port -databasename NEW_WEBAPP_DB
    Go to http://technet.microsoft.com/en-us/library/cc262449.aspx for more information on deletecontentdb operation of stsadm.exe command
  6. Attach the existing database to the new web application by running
    stsadm.exe -o addcontentdb -url http://newwebapplication:port -databasename OLD_WEBAPP_DB
    Go to http://technet.microsoft.com/en-us/library/cc263422.aspx for more information on addcontentdb operation of stsadm.exe command
  7. Make sure that host headers in IIS as well as Alternate Access Mapping is set properly and try running the full SharePoint backup again through Central Administration.

After those steps you will probably also have to configure search server setting for your content database (SharePoint Central Administration >> Application Management >> Content Databases >> Select Search Server from drop-down list) and get full crawl running to make sure that your search is up-to-date and working properly.

Now that your backup is running again, it should safe to remove:

  • the database that was created with new web application (see Step 5 above)
  • the website used by damaged web application (assuming you don't need this website for anything else)

 



Related resources:

Implementing Kerberos for SharePoint running on Windows Server 2008 and IIS7

Before I start writing how to set up Kerberos authentication in SharePoint, let me explain our set up a little bit, i.e. server names, account names and so on that will be used in this guide:

WSSSERVER1 – SharePoint web front server

WSSSERVER2 – another web front server (optional)

DBSERVER1 – database server running Microsoft SQL Server 2005 SP2

Domain\wss_srvc_account – User account used to run SharePoint services

Domain\sql_srvc_account – User account used to run SQL services on database server

Domain\wss_apppool – User account used to run SharePoint web application pool

Domain\mysite_apppool – User account used to run My Site web application pool

Domain\sspadmin_apppool – User account used to run Shared Services Provider web application pool

 

To set up a Kerberos authentication in SharePoint (WSS or MOSS) you need to do a bunch of small configuration changes:

  1. Make sure that you have host headers set up for your SharePoint sites. For example, in case of Windows SharePoint Services you will have only the main SharePoint website, whereas in case of Microsoft Office SharePoint Server 2007 you will have main SharePoint website, My Site website, and Shared Services Provider Sites. For the sake of simplicity, let's call those host headers: http://sharepoint, http://mysite, http://sspadmin respectively.
  2. Update Alternate Access Mappings to point websites to website host headers. In other words, replace http://servername:2222 entry with http://sharepoint

     

  3. Add SPN records for:
    1. Hostnames and FQDN of computer account(s) of your SharePoint server(s), for example
      Setspn.exe -A HTTP/WSSSERVER1 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER1.domain.local DOMAIN\wss_srvc_account
      Setspn.exe -A HTTP/WSSSERVER2 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER2.domain.local DOMAIN\wss_srvc_account
    2. Hostnames and FQDN of computer account of your SQL server, for example
      Setspn.exe -A MSSQLSvc /DBSERVER1:1433 DOMAIN\sql_srvc_account
      Setspn.exe -A MSSQLSvc /DBSERVER1.domain.local:1433 DOMAIN\ sql_srvc_account
    3. Host headers for your SharePoint websites, for example
      Setspn.exe -A HTTP/INTRANET DOMAIN\wss_apppool
      Setspn.exe -A HTTP/ INTRANET. domain.local DOMAIN\wss_apppool
      Setspn.exe -A HTTP/MYSITE DOMAIN\mysite_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/MYSITE. domain.local DOMAIN\mysite_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN DOMAIN\sspadmin_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN. domain.local DOMAIN\sspadmin_apppool
      (Do not apply in case of WSS)

       

    1. Configure "Trust for Delegation" on all computer accounts and user accounts used in SharePoint configuration. To configure "Trust for delegation":
      1. Open Active Directory Users and Computers management console
      2. Right click on a user or computer account that require ""Trust for Delegation" configured and click on Properties
      3. Where you find this option in the GUI depends on the Active Directory functional level. In case of Windows 2000 domain, the option is under Account tab for user accounts and General tab for computer accounts. In case of Windows 2003 domain, the option is under a separate Delegation tab. Note: Delegation tab is only visible for accounts that have SPNs registered

         

  4. Configure Component Services to allow Local Launch and Activation permissions for IIS WAMREG Admin Service for all application pool accounts used in SharePoint configuration. To configure Component Services setting go Control Panel >> Component Services >> Computers >> My Computer >> DCOM Config >> properties of the "IIS WAMReg Admin Service" >> Security tab >> edit "Launch and Activate Permissions" >> add "Local Launch" and "Local Activation" permissions for all the application pool accounts

     

  5. Because in IIS7 HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool account you're using. However, because even a single SharePoint server configuration is now considered a web farm, we should use a domain account to run SharePoint application pools. As a result we need to modify applicationhost.config file to configure the useAppPoolCredentials attribute in system.webServer/security/authentication/Windows-Authentication configuration section to true.

    <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"/>

     

     

  6. Once you have made a change to applicationhost.config file you might start getting errors 6398, 7076, 6482 in your Event Viewer. To get rid of those errors you need to apply hotfix KB946517. This hotfix is currently is available for Windows Server 2003, XP and Vista and it is under development for Windows Server 2008. I have used Vista version of the hotfix on Windows Server 2008 and it seems to have worked fine (knocking on wood...)

     

  7. Now you're ready to switch your SharePoint web applications to Kerberos authentication. Open SharePoint Central Administration >> Application Management >> Authentication Providers >> choose your web application >> change authentication to Negotiate (Kerberos)

     

     

  8. In case of MOSS, to change your Shared Services Provider web application to use Kerberos authentication run the command: stsadm.exe -o SetSharedWebServiceAuthn –negotiate. Stsadm.exe is usually placed under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin.

 

 

That's it, you should now have your web applications using more secure Kerberos authentication. You can use Fiddler (http://www.fiddlertool.com/Fiddler2/version.asp) to verify that your web application is in fact using Kerberos authentication. Here are a few links that will help you might find useful:



Related resources:

Enable Detailed Error Messages in MOSS 2007 and WSS3.0

To get more detailed messages in MOSS 2007 and WSS3.0 during development process, user can enable debugging in the web.config file for the SharePoint web application:

<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">

And:

<customErrors mode="Off" />

This should make development process so much pleasant and more efficient, by getting rid of "An unexpected error has occurred" error, which is useless to the developers.

Note: It's not recommended to have debugging enabled on the production server, if possible, please do all your debugging on the development server(s)