Search
Twitter

Entries in Miscellaneous (3)

Thursday
Jul042013

Resources for Installing and Configuring BI with SharePoint 2013 and SQL Server 2012

I’m embarking on a new project to build a brand new squeaky clean VM environment from the ground up, including SharePoint 2013, SQL Server 2012, and Office 2013.  This will serve as my new “on-premises” environment for use with Hyper-V.

image                   image                               image

Below is a list of resources I’ve found so far relating to installing and configuring BI with SharePoint 2013, Office 2013, and SQL Server 2012.

Blogs & Articles

MSDN – Install SQL Server 2012 Business Intelligence Features   <--There’s a ton of sub-pages here with checklists & info

Koen Verbeek – 10-Part Series on Building a SharePoint 2013 BI Demo Environment  <—Really good stuff here!

MSDN - Content Roadmap: Set up and configure SharePoint and SQL Server BI

Bhavik Merchant – Setting Up a SharePoint 2013 BI Demo VM

Simon Lidberg – Installing the BI Features of SharePoint 2013

Lydia Bronze – Step-by-Step Guide to Installing SharePoint with SQL 2012 PowerPivot, Power View, and Reporting Services

Kay Unkroth – Microsoft BI Authentication and Identity Delegation

James Beresford – Build Your Own SQL 2012 Demo Machine

Anthony Sammartino – SharePoint 2013 Installation and Configuration for Power View

James Serra – SQL Server 2012 and SharePoint 2013: Installing on a Virtual Machine

Videos

MSBI Academy Videos – 23-Part SharePoint Deployment Crash Course      <—Definitely worth a look

Dave Wickert – Deploying and Managing a PowerPivot for SharePoint Infrastructure Using Microsoft SQL Server 2012

Chuck Heinzelman – Configuring Kerberos for Microsoft SharePoint 2010 BI in 7 Steps (SQL Server 2012) 

Lee Graber – 4-Part Series on PowerPivot for SharePoint Architecture

Know of other great articles or videos?  Please leave a comment so I can add it to the list.

 

Sunday
Dec182011

How to Perfect the Resolution of a Remote Desktop Session

Overview:  A quick tip about how to get the resolution of a Remote Desktop session just right for your monitor, so you don’t have to deal with scrollbars. 

Level:  Familiarity with Remote Desktop is assumed.

The screen shots shown below are from a Windows 7 machine.

Remote Desktop Connection Settings

When you launch Remote Desktop, you are initially presented with a very simple window:

     image

To get to all the good stuff, we need to expand the Options.  Now 6 tabs are displayed:

     SNAGHTML75baf86

On the Display tab, you find the standard screen resolution settings.  This is great, but sometimes you need a screen resolution that’s just a little bit different than what’s offered on the slider.  For now, just select the resolution that is closest to what you want:

     image

Let’s do one more thing that’s not related to screen resolution before we finish.  On the Local Resources tab, choose to have your Printers, Clipboard and Drives available.  Under Keyboard, you can also control whether an ALT+TAB works on your primary machine or the remote desktop session (boy did that drive me nuts till I discovered that setting a while back!).

     image

I usually don’t change anything on the Programs, Experience, or Advanced tabs.

Creating an RDP File

Let’s return to the General tab.  Note the Save and Save As buttons:

     image

The Save As button will prompt you for the location of a RDP (Remote Desktop Protocol) file.  I find that using the Desktop is a perfect location for this file – because you’ll actually launch Remote Desktop from this file after it’s set up.  Note in the following screen shot that I put “Home_Monitor” in the name:

     image

Editing the Screen Resolution Size Within the RDP File

Go find the file you just saved; right-click it and choose to open with Notepad (or the text editor of your choice).

     image

After you open the file in Notepad, see the screen resolution settings near the top (which came from the Display tab).  Here’s the fun part – you can adjust the “desktopwidth” and “desktopheight” to the precise pixel settings you want.  For example, I have one RDP file I like to use which is set to 1890x1000.

     image

On my desktop currently, I have two RDP files which connect to Client ABC:  one file which is set to my optimal laptop resolution, and another file which works better with my extra monitor at home.  Depending on how & where I want to work at the time, I use the appropriate RDP shortcut on the desktop to launch the Remote Desktop session.  Note that the file is specific to one connection.

Here’s to no more scrollbars!

Sunday
Oct242010

Using the Agile Framework for BI Development

I’ve become a huge fan of agile development.  Why?  Because we are committed to deliver working functionality every 30 days, and that is rewarding.  In this post I discuss our agile practices and why I believe they work extremely well.  This post is from the perspective of a developer on a team of 10.

What Is Agile?

First, what does agile really mean?  It’s not considered a methodology, a process, or even a set of procedures.  It’s more of a conceptual development framework which allows our team to iteratively prioritize & plan the work, perform the work, and review the work.  As opposed to the classic waterfall approach, agile acknowledges that we don’t have all the answers at the start of a project. 

One approach to agile is the scrum approach, which is discussed here.  Extreme programming is another approach to agile.

 

 

Sprints

The work of a project is divided into sprints.  I have been working in 30 day sprints for the past 9 months, and I believe that iteration works really well for our team size and project size.  A sprint begins with a Sprint Planning session, and it ends with a Sprint Review and a Sprint Retrospective.  We usually work on a calendar 30 day period, although we’ve been flexible a couple of times due to holidays or major milestones.

Working in fixed 30 day periods really prevents scope creep.  Sometimes we can fit in that extra little something, and we do, but sometimes it would jeopardize completing our commitments on time.  Since I can be guilty of scope creep (with good intentions of course!), having the structure of a sprint works extremely well for me.

 

Sprint Planning

At the beginning of each sprint, we take 2-4 hours to go through Sprint Planning.  This is where each member of the team helps plan and prioritize the next 30 days of work.  We each form our own estimates and our fantastic project manager makes adjustments and brings the entire plan together.  The idea is to deliver working functionality at the end of the period, without any heroic efforts.

Because we conduct the task level planning each sprint period, we can adapt to evolving requirements fairly readily.  Of course, our project manager gets to balance what’s acceptable evolution in requirements versus scope creep.  Because things can be a bit vague at the beginning of a sprint, team members need to be willing to accept some ambiguity and embrace change.  However, once the sprint begins the priorities need to remain the same throughout the entire sprint for this process to really work effectively.

 

Daily Scrum Meeting

Every morning we have a scrum meeting.  This is each person’s chance to explain what they are working on, if they need assistance from anyone else on the team, and if they have any impediments.  Although there are some days this is just a rote exercise, there are other days when the lines of communication get opened up because a topic came up that someone otherwise wouldn’t have known about, or someone happens to have valuable information but wouldn’t have thought to ask.  The daily scrum is particularly valuable when there are intra-sprint dependencies between persons (ex: person A needs person B to finish something before they can begin some work).

We’ve changed the scrum format a bit over time to try to ensure the entire team gets benefit from it.  For example, when it used to literally be a stand-up meeting some folks felt such a short discussion was of little use.  With mixed feelings, our scrum master (aka project manager) now allows the team to sit down and take a little longer.  We are not strictly time-boxed to 15 minutes, but we rarely exceed 20 to 30 minutes.

The time of the scrum has been a compromise, considering some of the team members arrive early and some arrive later.  We hold ours at 9:00 a.m.

 

Sprint Review

The sprint review, conducted at the end of each sprint, is fun.  Our product owners attend, and each member of the team literally shows off what they did.  Not only do we really appreciate what our teammates are doing, but the stakeholders are able to see progress firsthand as well.  This is a rewarding time of each sprint.

In the BI and Data Warehousing world, the sprint reviews get more tangible as the project progresses.  At the beginning, the data foundation and ETL is being constructed which is difficult to demo.  As the project progresses, visual components such as portals, reports, and scorecards evolve which are easier to demonstrate working functionality.  Even when most of the airtime goes to visualization in a sprint review, our project manager always makes sure the ETL team and other behind the scenes work gets noticed and appreciated.

 

Sprint Retrospective

The Sprint Retrospective is conducted at the end of the sprint.  In our team room, there are 3 large white sheets:  What Went Well, What Went Wrong, and New Approaches to Consider.  This is basically the “lessons learned” time of a sprint.  All team members get a pack of sticky notes and we go to work filling up those three sheets.  The first one, What Went Well, is just what you think.  We compliment each other & their work.

The second one, What Went Wrong, is our time to constructively discuss what we could have done better during the sprint.  Sometimes we learn valuable information on how something affected a coworker that we wouldn’t have otherwise known. 

The last sheet covers New Approaches to Consider, which is our chance to provide suggestions or opinions on how we might do things differently.  These suggestions cover a wide spectrum, and sometimes are related to the What Went Wrong sheet.  The change in scrum, discussed above, originated from a Sprint Retrospective suggestion.

The Sprint Retrospective is documented and kept for later reference.  The Sprint Retrospective is a really useful way for the team to reflect on how things went and then adjust accordingly.  To be successful, this practice needs a team of people that are really engaged.

Conclusion

One of the basic tenants to working in an agile fashion is we value working functionality over documentation.  While I agree with that philosophy entirely, getting documentation done alongside the work does tend to suffer.  Also, it’s clear the entire process works much more seamlessly when the entire team is devoted 100% to the project.

The above discussion is a bit of an Agile 101 discussion from the perspective of a BI developer.  There’s a lot more to know about agile:  all of the roles, how to handle backlog items, and so on.  We also have a sprint celebration lunch on occasion, to celebrate the particularly larger milestones.  This type of working environment is very collaborative, and it builds trust among the team.  It’s become my preferred development framework.

I’d enjoy hearing other experiences and thoughts about agile development in the comments.