Consolidating Application Pools

I had a need to consolidate application pools for several MOSS 2007 sites I had created on my development machine. I had been so stupid that I just created a new application pool each time I created a site. Since Sharepoint Search crawls every site, a new work process (w3wp.exe) was created for each site – even though I didn’t use them. No need to say that this eats valuable memory in my VPC…

This was what I did:

  • Make sure all sites use the same application pool acount in Central Administation > Operations > Service Accounts. I use Network Service for simplicity
  • Make sure authentication providers use NTLM in Central Administration > Application Management > Authentication Providers
  • Do a IISRESET and test that all sites works OK. If something doesn’t work now, it’s easy to go back if you remembered to make a note of previous settings for the first two steps
  • Go to IIS Manager
  • Create a new Application Pool:
    • Call it something reasonable, like “Sharepoint Shared App Pool”
    • Set Identity to the same identity as you used in the first step
  • Configure Application Pool for each web site under Web Sites that you want to colsolidate
    • Right click root of web site and select Properties
    • Under Home Directory, change Application pool to the newly created application pool
    • Expand the _layouts-folder under root and change the application pool for both images and inc
  • Do a IISRESET and test that all sites works OK
  • Delete the application pools you no longer use (when testet that everything works ok!)
Advertisements

Enable debug information in Sharepoint

Just a reminder for myself:

 

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<configuration>
  <configSections>
    <sectionGroup name=”SharePoint”>
      <section name=”SafeMode” type=”Microsoft.SharePoint.ApplicationRuntime.SafeModeConfigurationHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />
    </sectionGroup>
  </configSections>

  <SharePoint>
    <SafeMode MaxControls=”200″ CallStack=”true” DirectFileDependencies=”10″ TotalFileDependencies=”50″ AllowPageLevelTrace=”false” />
  </SharePoint>

  <system.web>

    <customErrors mode=”Off” />

    <compilation batch=”false” debug=”true” />

  </system.net>
</configuration>

Kerberos 101 – Love, Hate, Love

Update: Read the Kerberos-page linked to on the right side as it is more updated.

Firstly – I assume you already know what Kerberos is and which problems it is intending to solve. This posting will not teach you this – but this might…

Even though I have tried to follow much of the available information out there, I was stuck on an issue involving an ASP.net frontend, WCF webservice and CRM backend. The reason was off course just ignorance and lack of better knowledge — as often is the case when dealing with something you don’t need to use often.

This is just a summary of my experience that might act as an checklist for others:

  • Use separate domain accounts for each individual service / IIS application pool. This makes registering SPN’s cleaner.
  • Use hostname’s (intranet.company.com, crm.company.com etc) for all IIS web applications and never refer to servername in calling applications.
  • Register all hostname’s with A-records in DNS. Don’t use CNAME! And off course make sure the server is set up with static IP or DHCP record.
  • Set up Kerberos Service Principle Names (SPN) correctly:
    • Register SPN for hostname’s only (HTTP/intranet.company.com) as SPN for web applications.
    • Don’t register HTTP/NETBIOS-name and HTTP/Fully-qualified-domain-name as many suggests.
    • Don’t delete HOST/SERVERNAME SPN’s registered on the computer account (domain\SERVERNAME$) or else you will get into trouble. I discovered it the hard way trying to clean up my SPN’s after doing a lot of testing. They can easily be re-created.
  • Enable Kerberos logging: HKLM\Software\CurrentControlSet\System\Lsa\Kerberos\Paremeters\LogLevel = 1 (DWORD
  • Enforce Kerberos to use TCP instead of UDP: HKLM\System\CurrentControlSet\Lsa\Kerberos\Parameters\MaxPacketSize = 1 (DWORD) to get rid of some Kerberos error messages
  • Use DelegConfig to test Kerberos:
    • Make test-user member of  Local Admin group of server
    • Extract files to C:\Kerberos
    • Add virtual directory in IIS web application you need to test with Kerberos as Alias, C:\Kerberos as Path and and Read and Execute permission
    • On server in question, log in as test-user and go to HTTP://intranet.company.com/Kerberos) – pray to God for all green checkboxes
  • When nothing of this helped – you’re on your own

How to switch between Kerberos and NTLM in Sharepoint

If you have chosen wrong authentication method in Sharepoint, you can manually change this.

To see what is set:

cd C:\inetpub\adminscripts
cscript adsutil.vbs get w3svc/##/root/NTAuthenticationProviders

To set Kerberos:

cd C:\inetpub\adminscripts
cscript adsutil.vbs set w3svc/##/root/NTAuthenticationProviders "Negotiate,NTLM">iisreset

To set NTLM:

cd C:\inetpub\adminscripts
cscript adsutil.vbs set w3svc/##/root/NTAuthenticationProviders "NTLM"
iisreset

## is the virtual server ID number. The virtual server ID number of the Default Web site in IIS is 1.

More info: http://support.microsoft.com/?id=832769