Archive

Archive for September, 2010

What Future for ProClarity Analytics?

September 14, 2010 5 comments

So PerformancePoint Services within SharePoint 2010 has brought across more views and features from the ProClarity Analytics Server (PAS) application, including the trademark Decomposition Tree in a new stylish Silverlight front end great!

But what about the remaining ProClarity features and views? Can you continue to run PAS after upgrading/moving to SharePoint 2010? When does support for PAS retire? Can any existing PAS views/reports be migrated over to PerformancePoint Services 2010?

All of the above, burning questions in my head and through much resourcing, and conversations with Microsoft PPS Product Team and Technical Advisory Service, I thought I would consolidate and share the information I have and the deductions I made from it…

Background

ProClarity Corp was acquired in 2006 by Microsoft to help accelerate Microsoft’s position in the Business Intelligence space.

The ProClarity Suite of products comprises the following:

Component Description
ProClarity Analytics Server (PAS) Server component which stores authored reports/dashboards, controls connections to data sources and renders dashboards.
ProClarity Dashboard Server Additional server component to store and control the dashboard design and layout.
ProClarity Dashboard Studio Client tool used to author dashboard designs and import views from PAS.
KPI Designer Add on to PAS which allows authors to create KPIs directly in PAS using a wizard driven environment.
ProClarity Desktop Rich client desktop authoring tool.
ProClarity Web Professional Thin client web based authoring tool.
ProClarity SharePoint Viewer A SharePoint web part for displaying views direct from PAS.

Microsoft Support for the ProClarity Suite

There is a firm support timeframe for version 6.3 of the ProClarity suite of software available at the Microsoft Support Website. This basically provides clear dates for end of support:

Mainstream Support Retires: 10/07/2012

Extended Support Retires: 10/07/2017

Support for ProClarity in a SharePoint 2010 Farm

ProClarity is a separate product from SharePoint and PerformancePoint Services, with an entirely different architecture.  So much so, that ProClarity remains a 32-bit application only, whereas its posh offspring is now 64-bit only.

However, IIS7 supports a mix of 32-bit & 64-bit web applications on the same Web Server, and Microsoft supports having ProClarity installed on your SP2010 Web Servers – but is this wise?

In my view, if you wish to keep ProClarity Analytics Server running alongside your SharePoint 2010 Farm in order to access the features and richer designer plus your existing PAS content, you should keep PAS running on its own WFE server and well away from your SharePoint WFEs.  My reasons for this are as follows:

1. Microsoft advises this 

2. Treat ProClarity as if it were another substantial SharePoint Service Application.  It will consume resources, so scale out, and place this on its own server.

3. There are a number of configuration changes required to get the 32-bit ProClarity web server to run alongside your 64-bit SharePoint web applications.  Obviously you do not need to make risky changes to your farm if this thing gets pushed out to its own server.

Migration Path for PAS Content

There is currently no migration path for PAS content to PerformancePoint 2010. There are also no publicised plans to create this migration path. Therefore, when mainstream support expires in 2012, you would be left with a set of views/reports/dashboards with only an unsupported product to view them through and maintain them, and with no way of moving them off here other than manually recreating in PerformancePoint where possible.

In Summary

In light of the above, my advice would be to only persist with installing/configuring ProClarity alongside your SharePoint 2010 farm if you already have legacy ProClarity dashboards/views and you wish to continue to support these. 

I would advise against using ProClarity because of a business need to use a view which doesn’t exist in PerformancePoint.  It is likely that the view can be created using one of the other tools at your disposal e.g. Visio Services, SSRS, Excel Services…

If you do continue to use and create ProClarity views, just be aware that in under two years time, you could be unsupported and with no way of escaping it!

Categories: Uncategorized

Dedicated SharePoint Installation Account

September 10, 2010 1 comment

The conversation about installing SharePoint Server using a dedicated installation account, and the principle of ‘least privileges’ is not a new one and I refer to an article written by Spence Harbar many moons ago which still applies today.

However I still come across many situations where a dedicated install account is never considered, and (more worryingly) even quite a few situations where installing using the Farm Account (also known as the DBA Account) is considered!

You should absolutely 100% NOT be installing SharePoint using the Farm account or any other service account, for the following reasons:

– It’s a service account and therefore should not have any logon rights at all.

– It should only have the permissions assigned to it by the configuration wizard.  None should be assigned manually before or after.

The Dedicated SharePoint Installation Account

A dedicated account should be used to Install SharePoint and any Service Packs/Hotfixes, run the Configuration Wizard, and run any STSADM/Powershell scripts on the farm.  This is because:

1) It is granted the highest permissions of any of the SharePoint server accounts, and you don’t want these privileges assigned to your service accounts:

Local Administrator on each SharePoint Server

SQL Server Roles: dbcreate + securityadmin

2) It has no influence on the running of the farm so if it gets locked out (because someone keyed in the test farm password three times for example) it has zero consequence.  It is even recommended it is disabled when not in use.

3) It also keeps things nice and tidy and prevents giving high permissions to Tom Cobley and all to perform farm admin. Yes, you may not be able to identify culprits who make mistakes, but you shouldn’t be giving this account out on a whim either.

This hangs over from MOSS 2007 and the best practise is pretty much identical.  Yes, there is a known bug with the User Profile service where admin rights must be temporarily raised on the farm account (but then rescinded), but this is no reason to do run any of the installation as MOSS Farm!

The only exception is when configuring a DEV machine, but if you train bad habits you’ll end up executing them for real!

Categories: Uncategorized