Recently, when exposing a SharePoint instance to the outside world using ISA server, I came arocss some very strange behaviour.
Basically, whenever doing things like adding a new item to a list, I would be presented with a HTTP error saying "Error Code: 500 Internal Server Error. The request was rejected by the HTTP Security filter." Interestingly, by shortening the URL (or so I thought), I would be able to access whatever resource I was trying to get to.
The issue turned out to be very simple. I noticed that by shortening the URL, I was actually removing special characters (I was cutting off things like &Source=.... &RootFolder=....). It turns out ISA blocks "high-bit characters" by default as a security measure, but this default setting messes up WSS / MOSS publishing as it uses these high-bit characters all the time.
The proceedure for turning this off is described in KB837865.
Hope this helps someone else from allot of headscratching :)
Monday, February 23, 2009
Friday, February 20, 2009
SharePoint functional consultants - a response
I've been reading a very interesting blog by Kristian Kalsing this morning which weighs further into the debate around "on time and on budget" delivery of SharePoint projects... Kristian arguers that the SharePoint world could benefit from the breaking up and designating of different tasks / industries to a greater number of more specialised consultants, in the same way as SAP deployments are done.
The only issue I can think of is the "target market" for each product. Typically only a really large organisation would consider implementing full-blown SAP, and with that come the resources to pay for it to be done properly, as well as the motivation that "near enough is not good enough".Organisations implementing MOSS would range from Small/medium right up to the very large - with only the large really having the resources to "implement it properly" in the way you describe (and I DO believe that the 'functional consultant' route is a fantastic idea for getting it done properly).
I think the distinction should be made between these 2 - for large deployments, I totally agree with what Kristian is saying. Each aspect of the "whole" should be planned and executed independently of one-another (but bearing in mind that which has been done before) and each should be driven by someone of significant expertise in the specific business problem being solved. The actual install / infrastructure side of it should be very separate to the guys doing the config, and the config should be separate to the guys doing the customisation/dev. Mixing of the 2 gives far too much opportunity for corner cutting and therefore problems.
I also think there will always be a need for "generalist" in SharePoint land for those small/medium deployments. The blurring of the lines between to two, and the inclination of organisations to opt for the lower quote will unfortunately tend to put the brakes on any consultancy using a larger number of far more specialised people to achieve what a client sees as the same final solution.
The only issue I can think of is the "target market" for each product. Typically only a really large organisation would consider implementing full-blown SAP, and with that come the resources to pay for it to be done properly, as well as the motivation that "near enough is not good enough".Organisations implementing MOSS would range from Small/medium right up to the very large - with only the large really having the resources to "implement it properly" in the way you describe (and I DO believe that the 'functional consultant' route is a fantastic idea for getting it done properly).
I think the distinction should be made between these 2 - for large deployments, I totally agree with what Kristian is saying. Each aspect of the "whole" should be planned and executed independently of one-another (but bearing in mind that which has been done before) and each should be driven by someone of significant expertise in the specific business problem being solved. The actual install / infrastructure side of it should be very separate to the guys doing the config, and the config should be separate to the guys doing the customisation/dev. Mixing of the 2 gives far too much opportunity for corner cutting and therefore problems.
I also think there will always be a need for "generalist" in SharePoint land for those small/medium deployments. The blurring of the lines between to two, and the inclination of organisations to opt for the lower quote will unfortunately tend to put the brakes on any consultancy using a larger number of far more specialised people to achieve what a client sees as the same final solution.
Thursday, February 19, 2009
People column and the dataview webpart
A quick one for my first Blogspot blog!
So, I've been playing around allot with the dataview webpart lately - it has so many uses.
The most obvious use is to bring any document library to any page within the same site collection, and in doing so, maintain most of the flexibility and ease of use of the normal document library webparts. Obvisouly as a consultant / configuration guy there's a little more to it, because you need to fiddle around in SharePoint designer with the XSL, but it's fairly straight forward. The other use, which is even more powerful is to use it as a quick and easy way to get some simple business intelligence and live reporting onto a SharePoint page.
Over the coming weeks, I hope to get down a number of "how tos" and "gotchas" for the above 2 scenarios.
My first one is the way a dataview handels a "person or group" column from a list of library.
The first thing to remember is that when you select a person from a person or group column (or indeed the automatically assigned ones such as Modified by and Created by), SharePoint likes to keep a whole bunch of extra data. This data is used to give the name a link to their profile in SharePoint, pressence awareness with communicator etc. etc. BUT it gets in the way when you're trying to play with the data in a dataview...
Firstly, when you display your dataview, you might get a column full of text like this;
So, I've been playing around allot with the dataview webpart lately - it has so many uses.
The most obvious use is to bring any document library to any page within the same site collection, and in doing so, maintain most of the flexibility and ease of use of the normal document library webparts. Obvisouly as a consultant / configuration guy there's a little more to it, because you need to fiddle around in SharePoint designer with the XSL, but it's fairly straight forward. The other use, which is even more powerful is to use it as a quick and easy way to get some simple business intelligence and live reporting onto a SharePoint page.
Over the coming weeks, I hope to get down a number of "how tos" and "gotchas" for the above 2 scenarios.
My first one is the way a dataview handels a "person or group" column from a list of library.
The first thing to remember is that when you select a person from a person or group column (or indeed the automatically assigned ones such as Modified by and Created by), SharePoint likes to keep a whole bunch of extra data. This data is used to give the name a link to their profile in SharePoint, pressence awareness with communicator etc. etc. BUT it gets in the way when you're trying to play with the data in a dataview...
Firstly, when you display your dataview, you might get a column full of text like this;
Why is this? Well, this is obviously text with mark-up (you can see the person's name in there, a link to their profile, the image indicating their presence and a bunch of other lovely stuff.
Making your dataview actually show you the name with presence is pretty simple, you can change the field type to "rich text" which will parse the mark-up;
Or, you can change it in code - simply go to the for that field, and add disable-output-escaping="yes".
Easy peasy.
Next post I'll go through doing a look-up on these field types. How can we compair someones name against this field with all the extra guff it contains?
Subscribe to:
Posts (Atom)
