Skip Navigation Links
 

 Posts

20/02/2009

IE8 - IE7 compatibility mode and SharePoint

With the imminent release of IE8 (at RC1 now), Microsoft have introduced a browser compatibility mode with some interesting defaults.  They have announced that IE 8 would, by default with a DOCTYPE, render all Internet (public) pages in the strictest manner possible.  By default all intranet sites with a URL such as http://moss, would render in compatibility mode i.e. SharePoint sites.  The reason for this is IE8 in standards mode breaks SharePoint sites ex. Menus etc.  I had this issue at JohnXXIII recently.

The IE team has offered 3 modes

  1. Quirks Mode - long standing behaviour reminiscent of IE 6, and it was used when no DOCTYPE was specified.
  2. IE 7 Mode - With a DOCTYPE it rendered according to IE 7’s standards support.
  3. Standards Mode - with the inclusion of a META tag IE 8 would render in the strictest manner possible according to the DOCTYPE

The best SharePoint fit is IE 7 Mode since this comprises the largest browser population.

We have two ways to enforce IE 7 mode.

  1. If it is an intranet then we can enforce a Group Policy
  2. We can modify the SharePoint master pages in use so that they include a new meta tag to get IE8 to emulate IE7

<meta content="IE=EmulateIE7" http-equiv="X-UA-Compatible" />

I prefer the latter approach.

One of our guys, Simon Reed, has suggested as an alternative you can also add this as an HTTP Header in IIS for each site, the header would be:

X-UA-Compatible: IE=EmulateIE7

More info can be found here:

http://blogs.msdn.com/ie/archive/2008/06/10/introducing-ie-emulateie7.aspx

Posted at 8:13 AM by David Piscopo | Permalink | Email this Post | Comments (0)

29/02/2008

Background width of Hover state for drop down menus
Some of you may have noticed that the background colour for some of the shorter menu items in the top
nav bar of your SharePoint site peeks through.
 
Menu1
 
This is visually distracting and is actually a bug in the core.css stylesheet for SharePoint.  Fortunately it is very easy to fix.  All we need to do it to modify one style that relates to the flyout (ms-topNavFlyOuts).  The best way to achieve this is to create a new stylesheet with the modified .ms-topNavFlyOuts A style (relates to a link) in it.  With this style we have changed to width of the flyout from 120px to 100%
.ms-topNavFlyOuts A {
PADDING-RIGHT: 8px;
MIN-WIDTH: 120px;
width: 100%;
display : block;
PADDING-LEFT: 8px;
PADDING-BOTTOM: 4px;
COLOR: #3764a0;
PADDING-TOP: 4px
}
 
Save this file to your hard disk (call it something like CustomSite.css).  We now need save this in the Style Sheet library of the site.  Select
Site Actions -> View all Site Content (you must have the Publishing feature turned on to be able to do this), open the Style Library and upload your new CSS file.
 
We now need to apply an Alternate CSS URL and get our subsites to inherit the settings:
 
Site Settings -> Modify All Site Settings - Select Master Page from Look and Feel, Change the Alternate CSS URL
 
Check the Specify a CSS file to be used by this publishing site and all sites that inherit from it radio button and browse to your new style sheet.  Check the Reset all subsites to inherit this alternate CSS URL checkbox so that subsites inherit this setting
 
menu2
Posted at 10:28 AM by David Piscopo | Category: Bugs | Permalink | Email this Post | Comments (0)

28/02/2008

Forms Services not available
You will sometime see an error message saying the Forms Services are not available when trying to open a browser-enabled Infopath form:
 
Infopath Services Unavailable
 
This really got me scratching my head, since it was working before and I had not made any changes that would affect this.  I even went to the extent of re-running the SharePoint configuration wizard but to no avail!
 
I then noticed that a scheduled batch job that I had created for doing a backup by using stsadm was failing!  One of the things that this cmd file does is to Quiesce the farm before the backup.  So I though maybe the farm was still in a quiesced state and sure enough it was!
 
To unquiesce a SharePoint farm:
 
Go to Central Administrator->Operations->Global Configuration-> Quiesce Farm and Click ‘Reset farm’
 
Forms services should be available straight away.
Posted at 4:36 PM by David Piscopo | Category: Blog | Permalink | Email this Post | Comments (0)

24/01/2008

Enhancing SharePoint Search

SharePoint search is very flexible.  Learn how to enrich your clients Search Experience.

Attachments for this post: Star Ratings

SharePoint search is a wonderful thing. It allows us to find relevant documents and information very quickly, but sometimes we want to present the core results a little differently than the standard output. This blog entry shows you how to do this. The Search Core Results Web Part XSLT Transformation (XSLT) is used to transform the search results appear on search results pages.

Before you begin to modify the XSLT for the Search Core Results Web Part, you will need to get a hold of Visual Studio 2005 so that you can easily look at XML as well as debug XSLT. So the first thing we need to do is to get a copy of the what the results XML data contains as well as the XSLT that is used to transform this XML into HTML. To achieve this do the following:

  1. Go to the Search Center of your SharePoint Site, and search for something that will return a small set of search results.
  2. Click the Site Actions link, and then click Edit Page.
  3. In the Search Core Results Web Part, click the edit down arrow to display the Web Part menu, and then click Modify Shared Web Part. This opens the Search Core Results Web Part tool pane.
  4. Click Data Form Web Part to display the XSL Editor node.
  5. Click the Source Editor button.

This opens the Text Entry window for the Web Part's XSL property. You can modify the XSLT directly in this window; however, you may find it easier to copy the code to a file. You can then edit that file using an application such as Visual Studio 2005. After you have finished editing the file, you can copy the modified code back into the Text Entry window and save your changes to the Search Core Results Web Part. So copy the contents of the Edit Window and from within Visual Studio, create a new XSLT file and paste the contents of the clipboard into the new file. Save a copy of this file to your local hard disk. Call it something like SearchOld.xslt.

  1. To dump the xml results so we can use it later on to debug our XSLT, replace the default XSLT with the following:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xsl:copy-of select="*"/>
</xsl:template>
</xsl:stylesheet>

This XSLT does not perform any actual transformation, so the search results will display the raw XML data.

  1. Click OK to save the changes to the Web Part.

The search results are rendered again without the formatting provided by the XSLT. Select the XML results and again from within Visual Studio, create a new XML file and paste the clipboard contents after the starting <?xml ...> tag of the new file. Save this new file to your hard disk. Call it something like SearchCoreResults.xml.

 

  1. From within Visual Studio, open the SearchOld.xslt that we saved previously and save it as SearchNew.xslt.
  2. Open the properties window of the file (F4) and browse to the SearchCoreResult.xml from the input property. This tells Visual Studio that we are going to use the XML that we saved previously as a source for our XSLT.
  3. We can now debug the XSLT, by selecting Debug XSLT from the XML menu. This allows us to step through, inspect 'variables' etc. more or less in the traditional way.
  1. Once you have made the required changes to your new XSLT, you can copy and paste the contents of the file into Search Core Results XSLT property of your search page. If it doesn't work then you can revert back to the old XSLT (SearchOld.xslt) or close the Core Results web part from the contents page:
  1. add ?contents=1 as a parameter to the search results page,
  2. select checkout
  3. Check the checkbox next to the Core Search Results web part
  4. Click the close action
  5. Go back to the search results page and add another core search results web part.

The ins and outs of XSLT as well as the structure of the Core Search Results web part are a little beyond the scope of this blog, but this should give you some idea on what needs to be done.

Attached is a ZIP file which contains an XSLT used to generate the results as show in the screen cap below (to further enhance the search results I have downloaded and installed faceted search from the www.codeplex.com web site). The ZIP file also contains a few images used to display the ranking stars. Rank is a search property that is returned to score the relevance of a search item. The value is usually ranges from 0 to 1000. I have taken advantage of this to generate a star rating. To use this create a picture library called Helper Images referenced from the home page (/Helper Images). Upload the star images to this picture library.

<xsl:template name="Rating">
<xsl:param name="mrank" />
<xsl:text> </xsl:text>
<xsl:choose>
<xsl:when test="$mrank &lt; 1">
<img src="/Helper Images/0starrating.gif" alt="0 stars" />
</xsl:when>
<xsl:when test="$mrank &lt; 201">
<img src="/Helper Images/1starrating.gif" alt="1 stars" />
</xsl:when>
<xsl:when test="$mrank &lt; 401">
<img src="/Helper Images/2starrating.gif" alt="2 stars" />
</xsl:when>
<xsl:when test="$mrank &lt; 601">
<img src="/Helper Images/3starrating.gif" alt="3 stars" />
</xsl:when>
<xsl:when test="$mrank &lt; 801">
<img src="/Helper Images/4starrating.gif" alt="4 stars" />
</xsl:when>
<xsl:when test="$mrank &gt; 800">
<img src="/Helper Images/5starrating.gif" alt="5 stars" />
</xsl:when>
</xsl:choose>
</xsl:template>
Results

Posted at 1:32 PM by David Piscopo | Category: Customisations | Permalink | Email this Post | Comments (0)

24/07/2007

403 errors on MySite settings for normal users

Recently, whilst doing some work for a customer, I came across an authentication issue which generated a 403 error which was hard to track down because there seemed to be no pattern, other than the issue seemed to revolve around permissions for users.  It also seemed to happen at a certain time of day (first thing in the morning).  The MOSS service account did not have this problem!

 

A recent email message from Daren Kovacevic from Co-operative Bulk Handling, in Perth gave me the clue as to what might be causing the problem.  He was having a similar issue that he had resolved.  It revolved around the Recycling of the IIS worker process.  This setting is in IIS on the App Pool properties.  For the default web it always set to 1:43 am.  Daren’s theory was that the App Pool was recycled requiring the MOSS service account to re-authenticate.  Normal users could not do this!

 

Armed with this new information I did a bit of experimentation.  I found that I could duplicate the problem at will by doing the following:

  • Recycle the IIS App pool for the SharePoint web by using IIS manager (removing the Recycle worker process time, clicking Apply and then re-adding the Recycle setting i.e. set to recycle at 1:43am)
  • Sign in to INTRANET using a normal user account
  • Click on the users’ MySite link
  • Clicking on Site Settings for the MySite generates a 403 error!
  • I then restart the browser and login to SharePoint Site using the application pool account.
  • I click on MySite
  • I Click on Site Settings.  No error!
  • I then go back to the SharePoint site and login as the normal SharePoint user.
  • I click on MySIte
  • I click on Site Settings and lo and behold no error!

To get a bit more information to try to resolve the issue, I then turned on SharePoint Verbose Logging:

  • Start SharePoint Central Admin -> Operations -> Diagnostic Logging (Logging and Reporting).
  • Select the All category in Event Throttling.
  • Set Least Critical for the event log to NONE
  • Set Least Critical for the TRACE log to VERBOSE.
  • Click OK to apply the settings.

Remember to set things back to the way they were, since the log files grow very quickly!  I have also found that there is a bug in this area, in that if you reset the settings back to normal, they do not take effect until you do an IISRESET  (be warned!).

 

I then went through the procedure above to generate the error.  I turned off the verbose logging, and then made a copy of the most recent SharePoint log (remember they get recycled) and then did an IISRESET.

 

Looking at the log I noticed that an Access Denied was being generated when trying to access the layouts.sitemap file which is found in the _app_bin folder of the SharePoint web site.

 

Ex.

Application error when access /_layouts/people.aspx, Error=Access to the path 'C:\Inetpub\wwwroot\wss\VirtualDirectories\intranet80\_app_bin\layouts.sitemap' is denied.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights,

Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options,

SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)

at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)

at System.Web.Hosting.MapPathBasedVirtualFile.Open()

at System.Web.XmlSiteMapProvider.BuildSiteMap()      

 

I then looked at the security on this file.  It had READ ACCESS for the WSS_WPS localgroup which includes the app pool account.  I deduced that Authenticated Users needed Read Access to the file.  Once I did this, the problem went away.  Happy days!

Posted at 1:08 PM by David C. Piscopo | Category: WSS | Permalink | Email this Post | Comments (0)

 ‭(Hidden)‬ Admin Links