|
The IE team has offered 3 modes
- Quirks Mode - long standing behaviour reminiscent of IE 6, and it was used when no DOCTYPE was specified.
- IE 7 Mode - With a DOCTYPE it rendered according to IE 7’s standards support.
- 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.
- If it is an intranet then we can enforce a Group Policy
- 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 Last time I gave a brief overview of why we set out to re-develop the Publishing features in MOSS 2007 for WSS. Our customer had a particular scenario which meant WSS was a preferred option and they needed to publish content from a single source out to their internal "Extranet" (this is not a spelling mistake - their business is federated and therefore their extranet is running on an internal network). This post will start to address the how, albeit at a fairly high-level to start with. To re-cap quickly (skip this paragraph if you read the last post). - Customer needed to publishing content from MOSS 2007 (Intranet) to a WSS 3.0 (Extranet)
- The publishing experience needed to be as close as possible to the current MOSS publishing feature.
- Build a publishing feature to be compatible across MOSS 2007 and WSS 3.0 – this would allow pages to flow between the 2 environments.
Our approach - “lowest common denominator”
When we consider that the destination Extranet server will be running a sub-set of SharePoint functionality currently available in the Intranet MOSS environment, it’s imperative to reduce/remove the dependencies on MOSS components without losing the MOSS functionality.
An example of this is the Content Publishing features of MOSS. These features are key to how content is managed on the Intranet, however, we can simulate these on the Extranet without imposing a MOSS licensing cost.
It is also possible to deliver similar Content Publishing components without imposing a licensing cost (like Content Query web part). We achieve this through development and customisation; specifically replacing Microsoft built-in components with “freeware” components built within the SharePoint community.
Bringing the MOSS Intranet back to a “lowest common denominator” (and not using the Publishing feature) facilitates a simpler content migration path. In effect, we simulate and replace as many MOSS features as possible without using MOSS features.
In fact, we have a situation now where MOSS would be in question as needed for their Intranet except for the fact that Forms Services and People Search are required.
The following components are required to be replaced or augmented in Intranet for a possible synchronisation of content with the WSS v3.0 Extranet site.
- Turn off the Content Publishing features in MOSS. The list below represents Publishing features affected:
- Libraries (Site Collection Documents, Site Collection Images, Style Library – these are global libraries that can be re-created.)
- Lists (Content and Structure Reports, Reusable Content, Workflow tasks, - these lists can be re-created.)
- Administrative links (These are links to the Site Settings page, including the ability to manage Master Pages, Navigation, Searchable columns, Content and Structure, Content and Structure Logs, Variations and Translatable columns. These will need to be re-created or replicated.)
- Additional Master Pages and default Page Layouts are stored in the Master Page Gallery (This needs customisation to support the current master page and layouts)
- Content Types and Site Columns (These are global components that are either not used or are easily re-created)
- Web Parts (Content Query Web Part (CQWP), Summary Links, Table of Content. These will be replaced (if needed) by functionally similar Web Parts.)
- SharePoint Groups (The following SharePoint Groups are created and can be re-created if needed: Approvers, Designers, Hierarchy Managers, Quick Deploy Users, Restricted Readers and Style Resource Readers, and although I do not find some of these groups useful in non-publishing site, there are some that will need to be recreated, such as the Approvers SharePoint Group.)
- Personalised Views (The personalise option is installed as part of Publishing feature, only Shared View is supported without the Publishing feature). This will not affect the viewing of Extranet content by anonymous users. For Intranet users, adding personal views and web parts will not be possible as this is a Publishing feature and we have not scoped including this.
- Workflows for content approval; simulate/replace content publishing workflows and port these to Visual Studio workflows.
- Base the custom site templates on a collaboration portal templates rather than publishing templates
- Replace the Breadcrumb navigation with custom control to cater for different location of page content.
- Build our own navigation provider for the top-level navigation.
- Setting of the Master Pages and Welcome pages in WSS.
- Custom layouts and the Pages library (although our solution supports publishing pages to any library, not just the Pages library.
- Editing toolbar – this was a major component in making the editing process seamless.
- Implement the “free” Telerik RADEditor control/web part to assist with the Content Editing process.
Compare “features” set – align as much as possible
We needed to align features across the MOSS Intranet and WSS Extranet as much as possible. Most content migration issues relate to there being a mismatch in “features” between the source site template and the destination site template. When the base or underlying site templates are different or have different features installed, it is likely that the migration will fail.
All features installed and activated are to be the same across the MOSS Intranet site and the Extranet site, these include: - Web parts
- Custom content types
- Custom features
- Custom workflows – like the moderation approval and cross-site content publishing.
Custom layouts and master pages –getting these into WSSv3.0
The Content Publishing features of the MOSS Intranet supports the ability for pages to be created and moderated. When pages are created, users have the option of selecting a custom layout (which defines content placeholder areas).
It is imperative to simulate the multiple layout support and custom master page support for the Extranet. This will ensure pages are supported and can load without error.
The synchronisation of the custom layouts and custom master pages is a customisation as WSSv3 doesn’t support Content Publishing out-of-the-box.
Replicating the Editing toolbar –its works for MOSS & WSSv3.0
Our aim with the Content Publishing feature was to minimise the usabilty impact of implementing a replacement publishing feature. Our Editing toolbar is exactly the same as the editing toolbar in MOSS and apart from some styling attributes most seasoned MOSS users would find it difficult to pick the difference.
Don’t under estimate the necessity of the editing toolbar, given it drives the editing process, it, along with the selection of layouts and master pages, they are the “killer” features of content publishing.
Content Synchronisation Options
As with most things, there is always more than one way to achieve the same result. MOSS and WSS has a very rich content deployment and migration application programming interface (API). There are many built-in options using this API to make content migration and deployment easy for MOSS administrators.
Content Deployment – not a viable option
MOSS has various content migration features built-in as part of the Content Publishing and Management features. However, when looking to synchronised content with a separate WSS v3.0 farm, most of the built-in options either do not work or impose a licensing cost.
The built-in content migration services as part of MOSS attracts a license overhead. However, this is not the reason it is discounted as an option – the reason for discounting this as an option is because it does not work across farms, only within the same farm – intra-farm not inter-farm.
The other issue with this is that the destination or Extranet WSS v3.0 needs to accept the “right to receive” content from a source MOSS server and this is not supported in WSS v3.0 .
Finally, using this method, the entire site collection is replicated – this does not allow for an opt-in, only replicate tagged content model.
Other content synchronisation options
There are three other methods of getting content from one farm to another, these include: - Export/import of sites, libraries and lists. The STSADM utility is used to complete this task and it can be batched or scheduled to update entire sub-sites; or individual lists. It replaces the entire site/list and there’s no ability to opt content in or out.
- Backup and restore site collection. The STSADM utility is used to complete this task it can be batched or scheduled. It backs up and replaces the entire site collection and therefore, as with import/export option, there’s no way to opt content in or out of the synchronisation process.
- Custom Workflow – this is the preferred option and is discussed in detail below.
Custom workflow – the preferred content synchronisation option
The Custom Approval workflow is the preferred content synchronisation option. These workflows are customisation to SharePoint that action any business rule built into the workflow (via source code). Content can be opted in or out using metadata and migrated optionally on approval or without approval if needed. It leverages the SharePoint Content Deployment and Migration API which is an extremely rich and functional API.
Search
General Search
General Search for the Extranet allows users to search across group-wide published content active/published on the Extranet. Search crawls all sub-site content and indexes the site content.
We implemented Microsoft’s Search Server Express 2008 as there was no licensing overhead. This integrated with the Extranet WSS v3.0 Central Admin site very nicely, once you sort out the correct install process.
People Search
People Search or a personnel directory search in the Extranet needed to be created from the ground up – its not supported in Search Server Express 2008 or WSS v3.0.
With regards to MOSS people search, we couldn't use it because: - It had a licensing cost associated with it
- The subsidiary business users where only “contacts” in the corporate AD (and not accounts), the OU structure for these contact made the LDAP query unusable and therefore were not able to import into the user profile database.
Regardless, it wasn’t relevant to put these contact in the User Profile database as the subsidiary contact would never require secure access to the corporate Intranet - this woiuld have poluted the user profile database with +200K users – they were Anonymous users using the WSS v3.0 Extranet.
With another hurdle to jump over, we had to “stand-up” a separate/stand-alone people search for the group (including subsidiary business contacts); these contacts were synchronised with various sources to obtain a complete list of the corporations business employees.
A separate SQL database was used to host the contact People search; three main components accompanied this: - A timer job to run daily (configurable) that imported contacts using LDAP queries to the various OUs to build the SQL people search database tables.
- A SQL web service – this returned the results set based on a query passed in - directly from SQL server
- A search web part and a results web part. The results part was able to use the same XLST as the MOSS people search.
Next post I’ll cover the things to watch out for, this goes into a little more depth as to the discrete problems you may encounter tackling a project like this.
We just finished writing a publishing feature that installs in WSS 3.0 and works like the MOSS 2007 Publishing feature.
You might ask, "Are you crazy? Why?"
This was a very bold undertaking; to re-write the publishing features in MOSS 2007 and implement them on WSS 3.0; after all, MOSS has a working and “good enough” publishing feature.
One of our customers needed to move content from a MOSS farm to a WSS farm whilst retaining the goodness of MOSS publishing (like welcome page, master pages, custom layouts, editing toolbar, and approval workflow). So we set about writing a MOSS-like Publishing feature that worked in WSS 3.0, once we had this we knew it would also work in MOSS.
Customer scenario
Our customer’s business is structured as a federated set of businesses; the “Corporate Office” sits above a set of subsidiary businesses, each run autonomously.
The “Corporate Office” has a MOSS intranet to service their employees (“Intranet”). They also have a requirement to host a central web site for the subsidiaries businesses (“Extranet”) to reference information from the parent company’s corporate functions (e.g. group treasury, group risk etc). Content is authored by corporate office users in the Intranet with the option to publish the content to the Extranet via a custom workflow.
The problem
Using MOSS as their Extranet (accessible by their subsidiary businesses) was costly. Under the current Microsoft Product Use Rights (PUR) (for a product like MOSS), any subsidiary business employee accessing a MOSS web site requires a SharePoint CAL (albeit anonymously).
Please note: Anonymous access is NO way of getting around the PUR conditions in this scenario.
In costing this out, the “Corporate Office” determined that a MOSS Extranet would have to cover licensing for ALL subsidiary business employees - combined number is over 200,000 employees. The Internet Connector license is not applicable in this situation as the “Extranet” is on the internal network and servicing subsidiary businesses, not on the Internet.
The answer
We needed a way to allow the small corporate office to utilise MOSS internally (Intranet), whilst having the ability to easily publish to a separate anonymous Extranet (WSS). The customer needed to seamlessly synchronise and publish content from the Intranet (MOSS) server to the Extranet server (WSS v3.0) via workflow and tagging content as “Extranet Applicable”.
Turning the MOSS Publishing feature on and publishing these pages to WSS would not work.
The challenge was to have an environment where Intranet users could publish information in MOSS (just like the out-of-box Publishing features), tag it as “extranet ready” and for this content to be available on the Extranet portal in an automated way. We wanted the newly created Publishing feature to map as closely as possible to the MOSS OOB features, as this would minimise the training impact for users already using MOSS Publishing.
In addition to mirroring the MOSS Publishing features, the requirements for the Extranet were as follows:
- Support an Extranet platform using WSS v3.0 with anonymous access to all published content. This would resolve the SharePoint CAL issue for all subsidary business users.
- Ensure Intranet content was able to be tagged as “extranet ready”, and once approved;
- Support synchronisation or push of “extranet ready” approved content from the Intranet to the WSS v3.0 Extranet portal, under the same site taxonomy.
In coming posts, I’ll cover our design, approach and the component we built to deliver publishing on WSS.
Ever get the situation where you go to deploy a solution and the solution never deploys?
1. The status of the deployed solution is deploying and now amount of STSADM commands fixes the problem.
2. The way I fixed this is by checking the Timezone setting for the web site currently deploying into and the Central Admin site. From Central Administration | Application Management | SharePoint Web Application Management, select the Web application general settings.
3. If after selecting the web site the solution is deployed to, you notice that there is NO timezone set, (as indicated below)
4. Set the timezone and go back to Central Administration | Operations | Global Configuration | Solution Management and all going well the status of the solution in question should be “Deployed”. If this doesn’t work, check that the Central Admin site (using step 2) has the timezone set.
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.
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
You will sometime see an error message saying the Forms Services are not available when trying to open a browser-enabled Infopath form:
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.
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:
- Go to the Search Center of your SharePoint Site, and search for something that will return a small set of search results.
- Click the Site Actions link, and then click Edit Page.
- 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.
- Click Data Form Web Part to display the XSL Editor node.
- 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.
- 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.
- 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.
- From within Visual Studio, open the SearchOld.xslt that we saved previously and save it as SearchNew.xslt.
- 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.
- 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.
-
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:
- add ?contents=1 as a parameter to the search results page,
- select checkout
- Check the checkbox next to the Core Search Results web part
- Click the close action
- 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 < 1"> <img src="/Helper Images/0starrating.gif" alt="0 stars" /> </xsl:when> <xsl:when test="$mrank < 201"> <img src="/Helper Images/1starrating.gif" alt="1 stars" /> </xsl:when> <xsl:when test="$mrank < 401"> <img src="/Helper Images/2starrating.gif" alt="2 stars" /> </xsl:when> <xsl:when test="$mrank < 601"> <img src="/Helper Images/3starrating.gif" alt="3 stars" /> </xsl:when> <xsl:when test="$mrank < 801"> <img src="/Helper Images/4starrating.gif" alt="4 stars" /> </xsl:when> <xsl:when test="$mrank > 800"> <img src="/Helper Images/5starrating.gif" alt="5 stars" /> </xsl:when> </xsl:choose> </xsl:template>
When attempting to add content to a List you get the following error "Exception from HRESULT: 0x80040E14".
Possible Resolution
Check the SharePoint log files for the following error.
{date|time} OWSTIMER.EXE (0x05B8) 0x0934 Windows SharePoint Services Database 6f8g Unexpected Unexpected query execution failure, error code 9002. Additional error information from SQL Server is included below. "The transaction log for database 'SharePoint_Config_xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases" Query text (if available): "{?=call proc_StartTimerRunningJob(?,?,?,?,?,?)}"
As the error states, the Transaction Log database is full or there is insufficient disk space. Trimming this DB or allocating more disk will should resolve the “Exception from HRESULT: 0x80040E14” error. You should not need to restart – it should just come good.
Cheers,
Rick Rosato
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! |
Thanks to everyone who made it down to the Perth SharePoint User Group this evening for the session on workflow. As promised I've uploaded the slides here. Hope to see you all again next month - I heard a rumour David might be presenting on My Sites.
Here are some links to a few of the resources mentioned in the presentation:
Ever had the situation where search drop down was missing or empty even though the search settings for the site collection were configured to use the scopes from the Search Center site?
This happened to me at a customer site, and to remedy the problem I did the following:
-
From "Site Action>Site Settings>Modify Site Settings>Search scopes". You must be positioned at the root site or site collection root.
-
As you can see by the screen, the display group for "Search Dropdown" is missing.
-
Select "New Display Group" and set the Title to "Search Dropdown". This seems to be an internal display name used by the search control. Select the scopes you'd like to associate with the display group.
-
You should end up with something similar to this.
-
Return back to the root site or site collection root and the search scope drop down should be populated with the scopes allocated above.
|
 |
|