Monday, November 28, 2011

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`""

Thursday, November 17, 2011

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.

Tuesday, November 15, 2011

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).

Wednesday, November 9, 2011

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.