A former colleague of mine recently showed me a YouTube video which had been posted by Google. They posed the question "What is a browser?" to the general public in New York...
The results are very interesting - most of the respondants do not differentiate between the browser they use, and the applications they browse, with the majority of people having very little idea of the difference. A lot of people actually confused the Google search engine with the browser itself...
I'm sure others will have differing opinions, and I'm not sure this way the point exactly, but to me it says the browser needs to just get out of the way... As far as I'm concerned (and the people in the above video as well...), it's the applications and content ON the internet that I'm interested in - the browser is nothing more than a window into those applications. Loading it up with features, buttons and toolbars doesn't help me, it just gets in the way.
To be honest, I'm not surprised people don't really know what a browser is, because when it comes down to it, why the heck should I care? As long as it shows me the stuff I want, what's the difference?
Saturday, June 20, 2009
Thursday, June 18, 2009
Issues Connecting to Analysis Services using PWA
As part of my inheritance of a SharePoint / PWA implementation, I've discovered lots of little bits and pieces which are not working as they should. Overall the implementation was, as far as I can tell, rushed and not particularly well architected.
I came across an issue the other day with some SSAS reports which are supposed to show an overview of all the projects we have on the go – the problem being, it never returns any data, just an error.
Upon enquiring as to why this might be, I was told “Oh, that’s never worked… it works on the server, but not on any clients”. Oh dear…
As it turns out, the reports would show on any of the servers in the farm, but on NO clients. Armed with a very consistent scenario such as this, troubleshooting should be fairly straight forward. The first thing that sprang to mind was authentication and the infamous “double-hop” issue - I had no real evidence of this, but it did provide a reasonable starting point…
After skimming a tech net article on connection issues with SSAS 2005 (http://technet.microsoft.com/en-au/library/cc917670.aspx#ECAA), I attempted to test connectivity from the clients into SSAS. To do this, create an empty text file and rename the .txt extension to .udl. Now when you double click on this udl file, you’ll get the data connection properties window. In the provider tab, select the type of data you’re connecting to (in this case Microsoft OLE DB Provider for Analysis Services 9.0 as we’re connecting to SSAS 2005). In the connection tab, enter the server’s name, and hit “test connection”. A very interesting thing happened; when using integrated authentication, the test failed with a “transport error”, if I specified an account on the SSAS server which I knew had access, the test would succeed. A quick look at the security log on the SSAS server confirmed that using integrated security, a failure audit would be generated and the connection would be blocked.
I came across an issue the other day with some SSAS reports which are supposed to show an overview of all the projects we have on the go – the problem being, it never returns any data, just an error.
Upon enquiring as to why this might be, I was told “Oh, that’s never worked… it works on the server, but not on any clients”. Oh dear…
As it turns out, the reports would show on any of the servers in the farm, but on NO clients. Armed with a very consistent scenario such as this, troubleshooting should be fairly straight forward. The first thing that sprang to mind was authentication and the infamous “double-hop” issue - I had no real evidence of this, but it did provide a reasonable starting point…
After skimming a tech net article on connection issues with SSAS 2005 (http://technet.microsoft.com/en-au/library/cc917670.aspx#ECAA), I attempted to test connectivity from the clients into SSAS. To do this, create an empty text file and rename the .txt extension to .udl. Now when you double click on this udl file, you’ll get the data connection properties window. In the provider tab, select the type of data you’re connecting to (in this case Microsoft OLE DB Provider for Analysis Services 9.0 as we’re connecting to SSAS 2005). In the connection tab, enter the server’s name, and hit “test connection”. A very interesting thing happened; when using integrated authentication, the test failed with a “transport error”, if I specified an account on the SSAS server which I knew had access, the test would succeed. A quick look at the security log on the SSAS server confirmed that using integrated security, a failure audit would be generated and the connection would be blocked.
According to the tech net article, this is usually due to insufficient permissions… However, with my account (or anyone elses), using the server, I could access the reports just fine…
Turns out when PWA / MOSS was implemented, since the implementation wasn’t company wide and since the enterprise doesn’t actually use AD, a brand new AD domain was created for our department, and users were provisioned into this domain as needed. Log-in for the actual client machine the user was accessing MOSS from is completely independent – I’m not a big fan, but it could work, IF done properly. One tiny, but crucial thing was never done though - the domain that MOSS resides in does not trust the domain that users are logged in to. No client can ever access SSAS because their machine can never authenticate…
Creating a workaround is simple – provision a local account on the SSAS box for each user who needs access to the report, which has the same username and password they’re using to log onto their computer. Then add this account to a role in SSAS. Obviously that solution is not security best practice, and would completely unmanageable with a large number of users.
The permanent solution is to create a trust relationship between the 2 domains – this requires the domain admin to create, which is going to take weeks *sigh*, but hence the workaround for the time being. I’m of the opinion that a properly implemented SSO solution would go a long way to solving this too, but fixing SSO is a beast of an issue for another day…
Turns out when PWA / MOSS was implemented, since the implementation wasn’t company wide and since the enterprise doesn’t actually use AD, a brand new AD domain was created for our department, and users were provisioned into this domain as needed. Log-in for the actual client machine the user was accessing MOSS from is completely independent – I’m not a big fan, but it could work, IF done properly. One tiny, but crucial thing was never done though - the domain that MOSS resides in does not trust the domain that users are logged in to. No client can ever access SSAS because their machine can never authenticate…
Creating a workaround is simple – provision a local account on the SSAS box for each user who needs access to the report, which has the same username and password they’re using to log onto their computer. Then add this account to a role in SSAS. Obviously that solution is not security best practice, and would completely unmanageable with a large number of users.
The permanent solution is to create a trust relationship between the 2 domains – this requires the domain admin to create, which is going to take weeks *sigh*, but hence the workaround for the time being. I’m of the opinion that a properly implemented SSO solution would go a long way to solving this too, but fixing SSO is a beast of an issue for another day…
Thursday, June 11, 2009
Search Center – Excessive Delay in Switching Results Pages
Recently I began working for a large government department – and unfortunately, I’ve inherited a SharePoint implementation that was rushed, and is full of holes. Getting my head around how it all hangs together, and even who is responsible for what is going to be a huge task, but already I’ve been able to find some really obvious mis-configuration, that has been relatively easy to fix. Little quick wins earns me time!!
One of the project managers came to me this morning with some issues about search “not being what was advertised”. As is fairly standard, they were promised a great search experience, however, short of defining some crawl sources, nothing in this area had been configured.
I created the search center, and configured it for the site collection – all good. Then I noticed one little problem… Whenever I would run a search, the first page of results would show up fine – any subsequent switching to another page would take 30+ seconds, and not show any progress along the way… I tested a few scenarios – both of the default templates for search center (with tabs and without) suffered the issue, however, the default WSS results page did not. Since nothing had really been customised, my suspicion turned to the added functionality in the infrastructure update, and specifically, federated results. A quick search turned up Sourav Dutta’s blog which seemed to indicate similar behaviour. By following this advice, and effectively disabling federated search, the issue resolved itself.
In this case, I’m thinking the root cause of the issue is proxy related – to do with some fairly heavy restrictions on which accounts can and cannot access the outside world. Similar issues can happen with the RSS viewer web part. When I have time, I’ll work out 100% what is causing the issue… for now, I have “real” search, custom scopes, and I’m working on conditionally customising the results returned to make more sense for the business.
Monday, February 23, 2009
Problems with external access...
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 :)
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 :)
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)
