When planning a deployment of PerformancePoint Monitoring & Analytics (PPS M&A), an often overlooked component in the business solution is the ProClarity Analytics Server (PAS) application layer.  

PAS is sometimes not deployed by customers, and their analysts aren't trained in the effective use of these analytical tools. In my view, this is often a mistake.  Analytics has at least two constituencies--and all need to be considered when planning a successful BI deployment.

A sales specialist I have a great deal of respect for, Mac Hussey, once explained it this way...this isn't a direct quote but my interpretation of his ideas: PerformancePoint server M&A's native scorecards, analytic grids & views cover "Little a" (lightweight analytics), while PAS covers "Big A" (heavy analytics). 

Two A's...so what's the difference? "Little a" is flashy, cool and as easy to use as a web page--often requiring no training beyond a quick overview.  In most industrial and service industries, perhaps 85% of BI dashboard users are executives, managers and line of business users.  These users don't use analytics in their primary job function, but use analytics to support their "real" jobs. 

Even in the long-run, they may only want/need "Little a". If your organization fits this mold, it may seem that reaping the low-hanging fruit using "Little a" is really where all the value lies--and that's certainly true at first. Eventually, though, the "Little a" users want to know root causes, and analysts really need to dig and develop further insights.  That's when "Big A" is needed (ProClarity Analytics). 

"Little a" is certainly a "low hanging fruit picker" and brings in quick ROI in for any BI dashboard deployment.  Yet time spent deploying and training on "Big A" is where the game-changing ROI comes from over the mid/long-term. Currently this means deploying an additional application (PAS) and training end-users.  

Eventually I'm sure we'll see ProClarity Analytics fully integrated into PerformancePoint, and the "ProClarity" product brand will be just a fond memory. When that happens, every user will have access to both the "Big a" and "Little a", even if--as with Excel's features--they only know how to use the most common analytical capabilities offered by the product.  Until then, Microsoft BI practitioners who address the needs of users in the "here and now" will need to continue to pay close attention to the spectrum of user needs when planning BI deployments.

Microsoft’s security focus over the last few years has brought many improvements in the overall level of security.  Along with this level of security also comes an increasing number of hoops to jump through to accomplish simple tasks.

Recently I found that it became impossible to install software from network shares onto Windows 64-bit servers.  Trying to do so resulted in the error message:

“Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.”

Searching on the Internet, the most commonly suggested workaround I found was to uninstall the Internet Explorer Enhanced Security Configuration from the computer.  This actually does work, but really doesn't sound like a great solution to me. 

As it turns out, the solution is quite simple...but also a bit of a head scratcher.  You wouldn’t think accessing files on your LAN would be controlled by an Internet Explorer setting (well maybe you would, but I wouldn’t!).  Yet, changing IE settings is the easy way to solve this problem.

The solution is to add the LAN server where your install source share is to the Local Intranet zone in Internet Explorer.  I suppose adding to the Trusted Sites would probably work, but since a share location is in the intranet for most of us, I think that’s the more logical place to make this change.

Here’s how I solved it on a 64-bit Windows 2003 R2 server with SP2 and IE7:

1. In Internet explorer, select Tools/Options, then click on the Security tab
2. Select the Local Intranet icon, then press the Sites button
   
   
   
3. In the Add this website to the zone textbox, enter the name of the server in the form file://servername, then click the Add button
   
   
4. Click the Close button on the bottom of the dialog, then OK on the Internet Options dialog

With that change made, your server should now be able to run software from network locations.  No more need to copy them to a local file location first!

In this article I'll provide some basic guidelines for implementing X.509 PKI-based e-mail encryption that you can implement for free!  The goal for this article is a process you can use with your business associates and/or friends to exchange e-mail securely, with no additional software to install, and no costs to anyone in the process.  Sounds too good to be true?  Not at all!

Usually we send e-mail over public networks--via ISPs that guarantee no level of confidentiality.  We've probably all received passwords or other sensitive information via Internet e-mail at some time in the past.  Have you ever thought to yourself, "wouldn't it be great if I could easily send this e-mail in a way that only the recipient could read it?" 

Probably the most popular mechanism for sending encrypted is the proprietary--and until recently free--PGP client software.  I've long been a fan of PGP, which is not just good for e-mail privacy, but also for transmitting data securely.  But for e-mail encryption, PGP is traditionally a little nerdy to use, and I can't say I've ever had a business contact ask me to send him or her a PGP key.  The newer commercial versions of PGP clean up the clunkiness quite a bit, but installing PGP client software is a big step, may be prohibited by company policy, and even though $99/user isn't going to break the bank, a free alternative would be easier, right?

 X.509 Public Key Infrastructure (PKI) based encryption has been available for years, but in my experience is rarely implemented.  Perhaps the primary reason is complexity, low perceived need-level and/or inconvenience. 

Recently I took a look at using X.509 PKI keys in conjunction with Outlook 2007, and I was amazed at how simple it was to implement--at least at an informal peer-to-peer level. Although I'm using Outlook 2007, the ability to use certificates to send/receive encrypted e-mail isn't new with the 2007 version, and this basic approach will work with virtually any Microsoft e-mail client, and in fact most other e-mail clients as well.

Let's look at how to implement this solution. Setting up X.509 within Outlook 2007 has a few requirements:

1. Both the sender and receiver need public/private key pairs from a trusted Certificate Authority (CA).
2. Each party must have the private key installed on their own Windows PC
3. Each party must have the public key for the other party in his/her local certificate store 

Once everything is setup, the process is really pretty simple:

1. The sender uses the recipient's public key to encrypt the e-mail message as it's sent
2. The receiver uses his/her own private key to decrypt the message

We'll return to getting "everything setup" in a minute, but first a little bit more about why this process works... 

PKI e-mail certificates work because anyone can encrypt a message using the recipient's public key, but only the recipient's private key can reverse the process--yielding a decrypted message.  So the public key can be distributed to anybody without compromising the solution.  Only the accidental release of the private key will compromise the security of the transaction.  If this sounds like SSL (the technology used to encrypt your credit card on amazon.com), that's because it's almost exactly the same.

So, you ask, does that mean I have to buy an SSL certificate for my e-mail program--just like I do for my web servers--and all my e-mail recipients have to do the same?  Well, yes--and no.  Just as with SSL certificates, anyone can issue them.  You could create your own certificate, and your associates could create their own as well. The problem is that if you issue your own certificate (i.e. you become your own CA), you need to convince everyone you send e-mail to to trust your self-signed certificates.  Actually it's not your friends you need to convince--it's their computers. 

So, for self-signed certificates to work seamlessly, you'd have to get all your recipients to install your root certificate into their computer.  This is a reasonable thing to do if all users sending/receiving e-mail are within your company, but when it comes to external recipients, self-signed certificates may well be impractical. Just as with web site SSL certificates, it's easier to use a commercial CA that everyone else already trusts.

So, to exchange e-mail securely with external associates, the best option is to use certificates issued by a commercial, trusted CA.  These certificates are fairly inexpensive, and can even be obtained for free from Thawte and Comodo.  There are some good reasons to buy blocks of certificates from these companies and roll them out in your company.  However, for our informal solution, we'll just use free certificates from Comodo. 

OK, enough background.  Let's get this implemented.  Here's the process:

1. Go to Comodo's web site, and obtain a free secure e-mail certificate.  Just follow the instructions (which I won't go through completely here).  At the end of the process, the certificate will be installed in the certificate store on your Windows PC. 
2. Have the intended recipient(s) of your encrypted e-mail also obtain secure e-mail certificates.  It doesn't matter whether everyone uses the same provider (Thawte, Comodo, Verisign, etc.).
3. Send each of your intended recipient(s) a signed e-mail.  This is easy to do--just click the "Digitally Sign" button in the Outlook 2007 Options ribbon bar section.  Your recipient(s) should also send you a signed e-mail button.
4. Sending the signed e-mail messages is just a way to exchange public keys (remember, you need to have the recipient's public key to encrypt a message before sending it to him/her).
5. When you receive a Digitally Signed e-mail, right click on the 'From:' e-mail address, and add the contact to Outlook.  If your recipient's contact information is already in Outlook, accept Outlook's warning and let it update contact information. This will add the public key to the existing contact record.  Your recipient should do the same with your signed e-mail so he/she can encrypt e-mails for you.

Now that you have your recipient's public key, and your associate(s) have yours, all you have to do is click on the "Encrypt" button in the Outlook 2007 Options ribbon bar section before you send the e-mail.

That's it! Now you and your associates can send encrypted e-mail to each other anytime you want.  In fact, it's so seamless you probably won't even be aware that the e-mail you receive is encrypted--Outlook will automatically decrypt e-mail for you as you read it.  If you want to verify that the process is actually working (and of course you do!), there are two simple ways to know a received e-mail is encrypted:

First, the e-mail reading window will have one or two icons: the first looks like a padlock, and indicates the message is encrypted.  The second looks like a 4-H ribbon, and indicates the message is signed.  These are the same icons used in the Outlook tool-bar.

The second clue that a message is encrypted is that Outlook can't display it in the preview pane:

Now that your certificate is installed, whenever you have a request to send or receive encrypted e-mail with an external associate, simply exchange public keys (by sending digitally signed messages to each other), and you're on your way! 

Analysis Services cubes for OLAP analysis have improved substantially between SQL Server 2000 and 2005.  Still, there's always room for improvement.  The recent CTP (Community Technology Preview) editions of the upcoming SQL Server 2008 product shows that the product continues to improve, and that improvements align very well with what customers and developers want and need.

Some of my favorite new capabilities and features with SSAS 2008:

• Read-only cubes and SAN-based scale-out - improving scalability
• Resource monitoring - helping operations staff manage production solutions
• Improved dimension design environment - helping developers build performant cubes from the beginning

The dimension design improvements will be especially helpful for those new to AS cube development.  The current tools are excellent, and the available wizards do a great job getting new developers going in the right general direction.  Yet, as with many tools, the initial feeling of confidence can be misleading as a generic, wizard-driven design begins to crack under the strain of production data volumes and usage patterns.

The new dimension designer enhancements are meant to address this situation, with the goal to help designers make performant cubes from the very beginning.  Of course, there are things that can be done even in the 2005 release to improve the quality of designs.  The easiest to use tool is BIDS Helper, a freeware set of add-ins for BIDS.

Where BIDS Helper will give good advice, and should be part of the tool-box for most OLAP developers using SSAS, only a thorough understanding of what's happening under the hood will help achieve the best design and performance.  One of the best sources for this info is the Microsoft SQL Server 2005 Analysis Services Performance Guide provided by Microsoft.  A must-read for any serious SSAS OLAP developer.

Business Intelligence is a broad topic, spanning a set of technologies and business improvements spanning from enterprise reporting to analytics to performance management.  One of the more interesting areas is in data exploration and visualization.

State-of-the art BI tools enable a level of exploration and data visualization beyond our wildest imagination when I started in BI 15 years ago.  At that time, to achieve acceptable performance virtually everything deployed to a broad audience had to be pre-designed, and with only a limited amount of “ad-hoc” direction by the end-user. The value was still huge—pulling together multiple data sources into a cohesive reporting environment was a jump to light-speed (many companies are still trying to make that jump today).

One of my favorite data visualization tools is the Decomposition Tree.  I love the Decomp Tree because it’s super-intuitive…everyone “gets it” right away. 

The Decomp tree is powerful not just because it can “break down numbers”—we’ve been doing that with hyperlinks on reports for years.  The real power is that it allows users to select his/her own breakdown path, then easily explore that new path, tweak it, and cross-drill across dimension members.

In the screen print above, we started with Geography and switched to fiscal year, then switched to product.  The Decomp tree makes it easy to let the user go in any direction in any order—all very easily. No need for the report designer to anticipate every permutation the user might need!

By delivering this type of visualization to users, everyone wins.  The users win—they get the information they need quickly. Information at your fingertips – delivered! For IT, tools like the Decomp Tree let users access information in the format they need it, rather than prompting yet another custom reporting request.

Francois Ajenstat wrote in a recent blog posting that Microsoft will release a SP3 for SQL Server 2005.  There has been a groundswell of support in the user community for this, and it's a relief to know it's on the way.

This is especially great news for those of us deploying and supporting PerformancePoint on the SQL 2005 platform.  Currently, the system requirements for PerformancePoint planning server require build 3186 of SQL Server 2005, which is a "hot-fixed" version of SQL Server 2005.  It has seemed a bit strange that the production version of PerformancePoint Planning server requires a hot-fix version that's only available through special request to Product Support Services.  It's nice to see that will change soon.

While on the subject of build version numbers, keeping all the build numbers straight can be a real challenge sometimes.  One handy SQL statement to pickup the service pack level if you don't recall version numbers well:

SELECT 'SQL Server ' 
+ CAST(SERVERPROPERTY('productversion') AS VARCHAR) + ' - ' 
+ CAST(SERVERPROPERTY('productlevel') AS VARCHAR) + ' (' 
+ CAST(SERVERPROPERTY('edition') AS VARCHAR) + ')'

Also, aspfaq.com hosts the following pages that have complete references on build numbers:

SQL Server 2005 build number matrix

SQL Server 2000 build number matrix

In my work helping clients create their BI application architecture, one area that creates a great deal of uncertainty and confusion is what applications and tools to use.  Part of this confusion is brought on by an overwhelming array of choices.  Even in the Microsoft “stack” where I specialize, there are many overlaps in BI function between applications.

When I first started with Microsoft BI, I compiled a list of ways to build a dashboard with Microsoft tools.  I came up with around 10 different approaches!  Should a dashboard be built with BSM? SharePoint KPI lists? Reporting Services? ProClarity Dashboard? In my work with clients I’ve seen many approaches—most creating functional dashboards (with varying levels of extensibility and usability).

An eye-opening analysis I work through with clients is to back up even further and “segment” the user population,  then match “BI products” to each segment.  It’s a lot like market segmentation in the marketing process, and if BI deliverables are treated like “products”, I’ve found it helps clear up confusion about what “tools” to use to deliver BI.

Different groups of users have different needs.  Of course we all know this intuitively, but often with BI implementation it’s forgotten.  Many implementations take a “one size fits all” approach.  For example, rolling out Reporting Services reports to everyone (even though executives rarely have time to slog through conventional reports).  Or, on the other hand, giving scorecards to field staff who really need account or order details at their fingertips to solve tactical problems minute-by-minute.

Most effective BI solutions use an array of products, just as most product and service companies have tiered offerings to meet their customers' varying needs and demands. The following diagram is a tool I use to segment users and target the right products to their needs.  Are there other approaches you've found effective?