SPListItem provided is not compatible with a Publishing Page

I have been hitting my head against a wall lately with a custom master page and some custom sites. There appears to be an incompatibility between the 2. Since they come from separate sources, finding out where to point the finger is a little tricky. My custom master page makes use of Publishing, Feature Stapling, among other things.

The behaviour is that when I edit a community page and then click publish, it would throw an exception

System.ArgumentException: Invalid SPListItem. The SPListItem provided is not compatible with a Publishing Page.   
 at Microsoft.SharePoint.Publishing.PublishingPage.GetPublishingPage(SPListItem sourceListItem)    
 at Microsoft.SharePoint.Publishing.Internal.WebControls.PublishingPagePublishHandler.RaisePostBackEvent(String eventArgument)    
 at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)    
 at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

I have yet to figure out what is going on here. However here are some other observations

$web = Get-SPWeb <SPWeb URL>
[Microsoft.SharePoint.Publishing.PublishingWeb]::IsPublishingWeb($web)

This returns false despite the Publishing tab being there and the SharePoint Server Publishing site feature is activated.


So, ignoring the False, I continue with this:
$publishingweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web)
$publishingpages = $publishingweb.GetPublishingPages()

This throws an exception:

Exception calling "GetPublishingPages" with "0" argument(s): "The site is not valid. The 'Pages' document library is missing."
At line:1 char:53
+ $publishingpages = $publishingweb.GetPublishingPages <<<< ()
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

... but the Pages document library does indeed exist and I do have administrative rights on it.


I also try the following:

$pages = $web.Lists | Where-Object {$_.Title -eq "Pages"}
$page = $pages.Items | Where-Object {$_.Name -eq "default.aspx"}
[Microsoft.SharePoint.Publishing.PublishingPage]::IsPublishingPage($page)

... and get False which I would expect given the results from above. What doesn’t make sense is that this default.aspx page does have a Publish tab on it.

I then decided to try the IsPublishingWeb again, but without the custom master page. This is still giving me False. So, I guess I will start pointing the finger towards my custom site ...

Blog spammers, get lost

I got a few spam comments lately that appear to be either attempts to link to questionable sites or attempts to do some SEO on their own site.

The latest is crafted to semi legitimate
Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again

In general, I prefer openness, but will not tolerate this kind of activity. As a result, I have changed my comment settings. Hopefully, these buggers will go away. 

Trying to configure FAST search and SharePoint Search to work on the same web application

I have been trying to run FAST search for my content and standard SharePoint Search for people search. I know FAST can do people search, but a third party application is forcing my hand.
I believe I have run into a wall as it appears that the OOTB search web parts do not allow you to pick one search over the other and the Configure Service Application Associations only lets you pick down to the granularity of the service application.
Incidentally, if I do not have FAST Search Query Service Application set as default in my Configure Service Application Associations, my FAST Search Center will return an error "The search request was unable to connect to the Search Service"

Oh well, time to give up and move on.

ec2-describe-instances filter definitions must have format 'name=value'

I wanted to get a list of my Amazon instances with a particular filter, so I tried something simple as suggested in the ec2-describe-instances documentation: 

ec2-describe-instances --filter "instance-type=m1.small"

However, this returns the following error:

Filter definitions must have format 'name=value', but found 'instance-type'

After a bit of frustration, I finally realized that you have to pass in the quotes in the argument. This means that you need to escape the quotes in Powershell like so:

ec2-describe-instances --filter "`"instance-type=m1.small`""




PostSetupConfigurationTaskException - Failed to upgrade SharePoint Products

I just upgraded a SharePoint 2010 site from the RTM load to SP1 (KB2460045) + June 2011 CU (KB2536599). Running the Products Configuration Wizard (psconfig) ended with the following error:
Task upgrade has failed with a PostSetupConfigurationTaskException An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown.  Additional exception information: Failed to upgrade SharePoint Products.

File that under useless error message.

Then I found this post: http://sharepoint.stackexchange.com/questions/16104/sharepoint-server-2010-sp1-psconfig-issue/21031#21031 which suggested to Run As Administrator on the Products Configuration Wizard. That worked.

Access is denied when crawling despite account having access - using basic authentication

I had just set up a content source and ran a full crawl of one of my sites. However, this is what I got in the crawl log:

Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled

I doublechecked that my Default Content Access Account indeed has rights to the entire site by logging in from the server as that account and browsing around. I also had DisableLoopbackCheck set (don't worry, this is not a production machine).

So, I looked at the IIS logs to see what is going on. However, there were no access attempts recorded. Given that the machine is accessible I concluded that this was an authentication issue.

Then I came across this Crawl Rule configuration. If you go into Crawl Rules under your search service application's management screen you can set Crawl Configuration to "Include all items in this path". Then, the Specify Authentication section will become available. Pick "Specify a different content access account" and you can specify different login credentials, but can also uncheck "Do not allow Basic Authentication" (which was my problem).

(Oh, and if you go back to reading the error message, it does suggest creating a crawl rule).

PSSecurityException AuthorizationManager check failed on FAST installation

I just came across the following error when running the configuration wizard of the FAST installation:
Script execution failed System.Management.Automation.PSSecurityException: AuthorizationManager check failed.
It turns out that I had my Powershell ExecutionPolicy set to AllSigned instead of RemoteSigned.
Just the following simple command did the trick
Set-ExecutionPolicy RemoteSigned
Then I reran the wizard.