After much experimenting on the SharePoint 2010 server, following tips on the "Claims to Windows Tokens Service" and the settings of the SecurityTokenServiceApplication web service site, finally found that the 8306 error being frequently logged was due to Forms Authentication being enabled in the SecurityTokenServiceApplication web service site. Disabling Forms Authentication removed the issue on the Secure Store Service Application management page in Central Admin
To check this setting, open IIS Admin, browse in the left-hand pane to Sites > SharePoint Web Services > SecurityTokenService Application, and in the IIS section in the right-hand pane open the "Authentication" settings. Only "Anonymous Authentication" and "Windows Authentication" should be enabled.
The 8306 error in the event log was : "An exception occurred when trying to issue security tokens". Thanks to the threads at http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/49508c3a-e44b-4b3a-ad94-0e9957b9e025/ and http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/580a6e7a-e26e-47aa-a6d8-51563b7d27de/ for the final bit of assistance in tracing this one.
Thursday, August 11, 2011
Monday, June 20, 2011
Watch your Ports When Configuring AAMs
Found (the hard way) that SharePoint 2010 is not happy when an Alternate Access Mapping is configured with a port on the public URL that is different than the port on the corresponding Internal URLs.
For an extranet I was creating using SharePoint Foundation 2010, we were using port 80 on the external-facing side of the firewall. The firewall was redirecting those calls to port 81 on an internal IP address. So I had setup the extranet zone in AAM to have [some site]:80 as the public URL, and [some internal ip address]:81 as an Internal URL in that same zone.
[Various reasons for not using host headers in this instance, and for using port 81 for the SharePoint web app!]
Could access the site inside the firewall, but failed to get to the SharePoint pages from outside. Much analysis using Fiddler and the MS Network Monitor 3.4 (great tool, that one - really easy parsing of results) revealed that something was redirecting the client from [some site]:80 to [some site]:81 for the external calls. Still don't know whether IIS or SharePoint was responsible for this - just know that by changing the firewall to pass through on port 81, and calling [some site]:81 from outside, then all was well again.
So what I learnt today - don't mix ports across AAM internal and external URLs
For an extranet I was creating using SharePoint Foundation 2010, we were using port 80 on the external-facing side of the firewall. The firewall was redirecting those calls to port 81 on an internal IP address. So I had setup the extranet zone in AAM to have [some site]:80 as the public URL, and [some internal ip address]:81 as an Internal URL in that same zone.
[Various reasons for not using host headers in this instance, and for using port 81 for the SharePoint web app!]
Could access the site inside the firewall, but failed to get to the SharePoint pages from outside. Much analysis using Fiddler and the MS Network Monitor 3.4 (great tool, that one - really easy parsing of results) revealed that something was redirecting the client from [some site]:80 to [some site]:81 for the external calls. Still don't know whether IIS or SharePoint was responsible for this - just know that by changing the firewall to pass through on port 81, and calling [some site]:81 from outside, then all was well again.
So what I learnt today - don't mix ports across AAM internal and external URLs
Wednesday, June 1, 2011
Refinement Filtering in the SharePoint Search URL
The refinement filter querystring is the "r" term in a search result page URL. An example of its use is
The value of the “r” term in the querystring decodes to
Some documentation (and the links generated by the refiner web part) use a “=” character, but in my experimentation it seemed that only the “:” character would return results. Further research has shown that the “:” (%3A) character denotes a “contains” comparison whereas “=”(%3D) not surprisingly means “equals” (and yet the “equals” operation does not seem to retrieve any results in my trials)
http://intranet/search/pages/phonelist.aspx?k=christchurch&r=department%3a%22Human%20Resources%22
The value of the “r” term in the querystring decodes to
Department:”Human Resources”
Some documentation (and the links generated by the refiner web part) use a “=” character, but in my experimentation it seemed that only the “:” character would return results. Further research has shown that the “:” (%3A) character denotes a “contains” comparison whereas “=”(%3D) not surprisingly means “equals” (and yet the “equals” operation does not seem to retrieve any results in my trials)
Sunday, April 10, 2011
Finding the SharePoint Site Collection URL on the Client
Little tip - if your client-side code needs to know the URL of the site collection hosting a SharePoint page, have a look at the properties of the _spPageContextInfo object in the HTML source of the page.
This JavaScript object is written into each page, and contains useful information about that page. For my requirement, the _spPageContextInfo.siteServerRelativeUrl property contains the value I needed.
Simple Glossary App (Beta) for SharePoint Released
Have just published details of a new simple glossary/theasaurus application for SharePoint - OneStride Define. The idea behind this, and other layers planned for the framework, is to offer a way to layer interactivity and information on top of existing SharePoint pages.
No need to modify pages that already refer to a word that needs to be clearly defined - just add that word to a dedicated list in SharePoint, and any occurrence of that word in published pages or text fields in lists will be linked to the definition. Nice n' simple.
An additional benefit is that the framework and this first "layer" are supplied as sandboxed solutions, meaning that they can be deployed through the browser, run isolated from the rest of SharePoint and are suitable for use in hosted SharePoint (Office 365 here we come!).
This beta will be available until the end of May 2011. Have a look and let me know what you think!
No need to modify pages that already refer to a word that needs to be clearly defined - just add that word to a dedicated list in SharePoint, and any occurrence of that word in published pages or text fields in lists will be linked to the definition. Nice n' simple.
An additional benefit is that the framework and this first "layer" are supplied as sandboxed solutions, meaning that they can be deployed through the browser, run isolated from the rest of SharePoint and are suitable for use in hosted SharePoint (Office 365 here we come!).
This beta will be available until the end of May 2011. Have a look and let me know what you think!
Wednesday, March 2, 2011
Help for Businesses in Quake-striken Christchurch, NZ
Am gathering links to sites and pages dedicated to assisting businesses in recovering and rebuilding in Christchurch, New Zealand - the page is at http://www.smallsteps.co.nz/restart.aspx . If you find any other sites that are of value to our businesses, please let me know through a comment to this post.
If you are interested in seeing Twitter in action in an event like this, search for tweets containing #eqnz.
If you are interested in seeing Twitter in action in an event like this, search for tweets containing #eqnz.
Monday, December 20, 2010
JSON, jQuery, IE, OData and a Parsererror
Quite a collection of technologies and approaches in that combination being used on a single page in SharePoint - mostly worked fine until I had deployed to a site using IE7. Suddenly my jQuery calls to $.getJSON() would silently fail, and with no error callback on the getJSON method, I resorted to an $.ajax call instead.
Experimenting in the error callback, found that even though the response status was success, there was an error - the error text was "parsererror". Seems that IE7's native parsing of JSON does behave too well for jQuery 1.4.2. Finally wrote some code in the error callback to detect when the err was parsererror, and in that instance to create a new JSON object using eval, similar to this:
$.ajax({
type: 'GET',
url: serviceUrl,
contentType: 'application/json: charset=utf-8',
dataType: "json",
success: ProcessResults,
error: function (xhr, textStatus, errThrown) {
if (textStatus == 'parsererror') {
var json;
try { json = eval('(' + xhr.responseText + ')'); }
catch (e) { }
ProcessResults(json);
}
}
});
After working out this fix, I found some information on stackoverflow suggesting that IE has problems with leading new line characters at the start of the JSON in the HTTP response body.
Experimenting in the error callback, found that even though the response status was success, there was an error - the error text was "parsererror". Seems that IE7's native parsing of JSON does behave too well for jQuery 1.4.2. Finally wrote some code in the error callback to detect when the err was parsererror, and in that instance to create a new JSON object using eval, similar to this:
$.ajax({
type: 'GET',
url: serviceUrl,
contentType: 'application/json: charset=utf-8',
dataType: "json",
success: ProcessResults,
error: function (xhr, textStatus, errThrown) {
if (textStatus == 'parsererror') {
var json;
try { json = eval('(' + xhr.responseText + ')'); }
catch (e) { }
ProcessResults(json);
}
}
});
After working out this fix, I found some information on stackoverflow suggesting that IE has problems with leading new line characters at the start of the JSON in the HTTP response body.
Subscribe to:
Posts (Atom)
