sharepoint.H@ck

Went to a customer who had setup Kerberos but the RSS Viewer Web Part was still throwing the “does not support authenticated lists” message, even though Kerberos was setup 100% correctly.

Turns out the issue was with the FQDN of the sites, they had http://portal.company.co.za as their default mapping which RSS does not seem to like, once I added an internal default mapping to point to http://portal the RSS Viewer worked 100%. So the customer still access SharePoint using http://portal.company.co.za but SharePoint communicates with http://portal.

Not sure what the exact issue is with the FQDN, suspect if might be something to do with communication between servers; will let you know when I find out.

Regards,

Doug “bobTheBuilder” McCusker

*insert spooky music*

Ok so here is one that truly shows that I have no social life: a customer once asked me “why can we specify 1 – 30 usage log files, when configuring usage analysis processing?”, the answer to which at that time was “not entirely sure, but I know if you hit 30 it will stop recording usage data" – at least that is what the docs say :)

So, I left it for a while but then a mate asked the same question and days of working with WSS 2.0 started itching in my brain, this is what I found and it is still relevant:

Taken from the following document: http://office.microsoft.com/download/afile.aspx?AssetID=AM102437481033 (modified to be relevant to WSS 3.0 / MOSS 2007):

“

Inside this folder is a folder for every virtual server named using the Windows SharePoint Services virtual server globally unique identifier (GUID), and under those folders, a different folder for each day will be generated. The path of these folders cannot be modified.

You can configure the limit of logs to be created on a daily basis, with a maximum number of 30 log files. If you set a maximum number of n log files, this applies to each virtual server. This means that the log folders of each of the virtual servers (web applications) will contain at most n log files. In other words, if this number is set to 1 there will be 1 log file for each virtual server. Having many virtual servers (web applications) and having many log files might reduce performance during logging. You should consider increasing the number of log files if a front-end Web server (standalone or member of a Web farm) has log files with more than a million entries.

The front-end Web server might not have enough memory to memory-map a really large log file, which leads to a situation in which the log file might not get processed. Each hit that a front-end Web server receives uses approximately 200 bytes (B) in a log file. As a result, approximately 200 megabytes (MB) of RAM are used to memory-map a log file that contains a million hits. Memory mapping occurs only for several minutes during usage processing. Because log files are processed serially, when you have several log files, a smaller memory footprint results when a log file is processed. 

Windows SharePoint Services logs HTTP 2.x information to the log files and does not log HTTP 3.x or HTTP 4.x information to the log file. When you use multiple log files, the log files are created at the same time, and all hits from one website are contained in the same log file. Usage data for a website is updated one time each day.

The number of requests that are sent to the back-end server during usage processing is proportional to the number of websites on the server. However, the memory footprint on the back-end server is not affected by the number of websites. The additional load that usage processing generates does not significantly affect the performance of the back-end servers on the server farm.

”

Regards,

Doug “bobTheBuilder” McCusker

The other day I ran into an issue where the admins were seeing an Event ID in the application log that indicated that a content deployment job had failed. Well the actual details were something like this: content was copied successfully to the destination server, but could not find the web app to import into.

Now, content deployment jobs in this scenario had been stopped and deleted a few months back and the admins did not know why this was happening, what I found was the following:

• There was still a content deployment file in the content deployment folder of the destination server.
• Even though content deployment is turned off, if there is a file in the folder SharePoint will try and try to import the contents.
• The error was always after the default admin app pool recycle period.

Just though you would be interested. Remember to delete this file when cancelling content deployment jobs!

A couple of things I have been noticing is that a lot of content ends up in the TEMP directory of the MOSS service accounts (think content deployment, workflow etc.)

We all know that the default TEMP directory (if unchanged) is in the %userprofile%\AppData\Local\Temp directory which lies on the %system% directory, what I have been doing during setup of MOSS is to ensure that this variable is changed so that any TEMP data is stored on a separate disk.

You will be surprised at how big the TEMP directory can get!

Regards,

Doug “bobTheBuilder” McCusker

Here is an interesting little issue I came across the other day while setting up Kerberos on Windows Server 2008 R2: Everything went fine until I wanted to allow local activation permissions on the DCOM objects for the SharePoint service accounts, much to my surprise everything was disabled; it did not matter what account I was running with.

Turns out you need to make a registry change to enable you to change DCOM permissions:

• Open RegEdit and locate: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{CLSID} (the CLSID can be found in the DCOM error message)
• Right Click and select Permissions
• Select Advanced and then select take ownership
• Close the registry editor and then restart the server
• Now you can make the changes.

Sweet.

So got another interesting issue where a mate of mine said that after installing SharePoint 2007 on Windows Server 2008 R2 that they were unable to see the CA site. The interesting part is that there were no errors and viewing the source of the site showed ony beginning and ending HTML tags.

I recalled that this environment was installed using "Least Privileged" account mode (no local admin access being one section). So away I go and boot my 2008 R2 VM, configure the same security setting, and what do you know: a blank CA site.

Through the use of process monitor (monitored the w3wp.exe) and some digging I found that the issue had to do with the Application Pool account for CA not being to execute with impersonation. Seems like the default local policy on Windows Server 2008 removed the IIS_IUSRS group (used by IIS7 and above) from the list of accounts / groups allowed to run with impersonation.

Adding the IIS_IUSRS group / the CA app pool account fixed this issue.

To get the the right policy permission: Start -> Programs -> Administrative Tools -> Local Policy -> Security Settings -> User Rights Assignment (Note: you need domain admin rights to modify this).

Oh, this was due to Group Policy changes and not by default design!

Wow, what a day for Windows Server 2008 and Kerberos. There is a new step now that needs to be performed in order to get Kerberos working correctly.

One of the major changes incorporated into IIS 7.0 is that Kernel mode authentication for Windows Authentication is performed by default. So what does this mean? Well, HTTP.sys (which by default runs as the local system account) is now being used to handle the authentication, this essentially means that application pool account used for your SharePoint web application is being ignored.

NB: this only seems to be happening if you are using A records in DNS, if you are using CNAME records (which is not recommended) then you will not have this issue, this is also true if you are not using host headers. UPDATE: if you are using CNAME records, then ignore this.

In order to overcome this, I highly recommend adding the attribute useAppPoolCredentials="true" to the applicationHost.config file located in Windows\system32\inetsrv\config directory.

Example:

• You have a web application called "Company-A"
• Browse to the directory: Windows\System32\InetSrv\Config
• Open the "ApplicationHost.config" file in Notepad.
  Search for the following tag: <local path="Company-A"
• Now locate the following: <security><authentication>
• Directly below this tag is where you want to add your attribute, by default you should see this tag: <windowsAuthentication enabled="true">
• Now change this so it reads as follows: <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true">

NB: do this on a web application basis and you will need to do this on all servers in the farm running the web application service!!

As far as I can see there is no "better" way to do this at the moment, but I will post about it if once becomes available.

Thought I would create a little "Reporting Services" checklist for DPM, not much but covers some common issues.

• Must be installed on the remote SQL machine where the DPM databases are.

• If the DPM database is not on the same server that DPM is installed on (referred to as the “remote” server), you MUST have run sqlprep.msi from the install folder of DPM on DPM server BEFORE installing DPM.

• Script, Read and Write access must be enabled for the DPM Reporting Server virtual directories (httpHandlers in IIS 7.0).

Regards,

Doug "bobTheBuilder" McCusker

Seems like a day for Reporting Services.

Here are the brief steps to get Reporting Services 2008 to work with SharePoint 2007:

• Install Reporting Services on a computer that it is already part of the SharePoint Farm / or setup a new machine, install MOSS connect to farm and then install RS.
• Create and configure the SSRS database in SharePoint integrated mode using Reporting Services Configuration Manager.
• Install SQL Server 2008 Reporting Services Add-in for SharePoint Technologies, now this is IMPORTANT; install it using the rsSharePoint.msi SKIPCA=1 command on all your SharePoint  servers that are part of the Farm and have the Windows SharePoint Services Web Application on them (this means WFEs and Central Admin).
• On the server running Central Admin execute the rsCustomAction.exe /i command (this file is copied to your computer by SharePoint Reporting Services Add-In and is generally located in the Temp directory (if you can’t find it there, do a computer search for the file).  Do not run the rsCustomAction.exe command a second time on any other server as it will basically remove the feature.
• Grant database access and configure the Reporting Services via in Central Administration.
• Enable the Report Server Integration site collection feature on sites you want to use the web parts / integration on

Happy days :)

Regards,

Doug "bobTheBuilder" McCusker

Currently at the 2009 SharePoint Conference, watch this blog as I will be posting new content about SharePoint 2010, mostly around how to do things I did in 2007 in 2010 :)

Woohoo! So here was a weird one (I love these).

I recently came across an issue where all the images for SharePoint 2007 were not being displayed (little ‘x’ instead of image).

After much investigation it turned out that the problem was with the IIS Metabase file, what had happened was that the web application pool for the web application had been changed (not just the account) and although the metabase.xml file was updated with the new web application pool not ALL of the settings in the metabase.xml file were updated; specifically the account that was specified to have access to the _layouts folder and the _layouts/images folders.

So, a quick edit of the metabase file to update the old web application pool with the new web application pool resolved the issue.

If this helps you then my work is done :)

Note: Obviously if you change the web application through the CA site then you would not have this issue ;)