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.
Subscribe to:
Posts (Atom)
