If you want to use the Content by Query Web Part (CQWP), you may have noticed this is only available when you have the Publishing Feature enabled.
If you deal with things like evil site templates, you may not want to enable this feature. In order to successfully use this webpart without the Publishing Feature follow the following steps:
- Save the web part from a site that does have the Publishing Feature enabled
- Upload it to your new site
- Edit the page
- Go to Insert > Web Part and under the categories, you should see "Upload a Web Part"
- When you upload a web part, you should see it listed in "Imported We Parts" category.
- Once you have done this, the next step is copy the Style%20Library/XSL%20Style%20Sheets/*.xsl files from the site with the Publishing Feature enabled across to the current site
- The easiest way to do this is to open the Style Library folder with SharePoint Designer 2010 on the current site, and another copy of SharePoint Designer 2010 open with the Style Library folder from the site with Publishing Feature enabled, and then drag and drop the "XSL Style Sheets" folder from one SharePoint Designer 2010 to the other (ignore the error about needing to be checked out).
This will allow you to be able to add the Content Query Web Part to a page on your site without enabling the Publishing Feature.
||Application pools recycle when memory limits are exceeded.
||0 – Rule Execution Failure
||Access is denied.
||In the Internet Information Services Manager, uncheck any memory-based maximums set for the application pools named above. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=142692".
Another fun MSCryptic message from our good friend the SharePoint Health Analyzer. In this case, Microsoft has yet to allow us to separate out the HA rules to individual servers Unfortunately these rules tend to be an all or nothing approach, and in the case of this rule’s scope we get two choices:
So, what this means is that if we’re running a medium or large farm and we’ve gone and separated out our various application pools so that the Central Admin (CA) and the Web Front End (WFE) are on different services and are in fact isolated, then even though everything is properly set up, because it does not see certain app pools on a server that it thinks should be there it flags the SPHA rule.
Hopefully MS will someday allow us to configure the rules to run on a per-server level instead of just farm level. In the meantime, three possible solutions:
- Easiest way to make this rule go away is disable it
- second easist is to install the app pools/services it is expecting on every server in the farm. The health rule checks each application pool in the SPWebService ContentService ApplicationPools collection. If it can’t find the Application Pool on the member server is it checking, it will fail and cause this Health Analyzer (HA) item (notice the application pool name(s) are blank in the message). You can determine the potentially missing Application Pool(s) with the following PowerShell:
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.ApplicationPools | fl Name
3. Complete Hack, but you can create dummy application pools so the SPHA can find them but they don’t do anything, thus preserving your service isolation on the farm and at the same time keeping the rule intact.
EDIT: So, turns out if you reassign the web application to a generic application pool and delete the old application pools from the server, SharePoint is still expecting to see them and will throw a Health Analyzer alert if you delete them from the server since it is trying to check for them. In order to remove unused application pools from the SharePoint configuration, please review: SharePoint 2010 – Application pools recycle when memory limits are exceeded (PART 2) where I show how to remove unused application pools from the ApplicationPools collection.
Microsoft has gotten around to showing some love to those of us geeks who want to read their content on our Kindle, Nook, or iPad
Downloadable content for SharePoint Foundation 2010
If you receive:
InfoPath cannot open the following form: <url>
The file is not a valid XML document.
DTD is prohibited.
This problem occurs when the form template that was used to create the form is not available or cannot be downloaded from the site. The form template was not sent in the e-mail message, or the form template was not published to a shared location.
The resolution is to add the URL for the form template to your trusted sites or local zone and ensure that the person has ‘Contribute’, the minimum permissions required to update InfoPath forms.
Log entry for EventID 5586: Unknown SQL Exception 297 occurred.
Additional error information from SQL Server is included below.
The user does not have permission to perform this action.
This is occurring because your SQL Server has not been configured to use named pipes
Fix: Open the SQL Server Configuration Manager and browse down to SQL Server Network Configuration – Protocols and Right-click “Named Pipes” in the right pane and choose Enable.
You may need to restart the server for changes to take effect.