[HKEY_CLASSES_ROOT\MIME\Database\Content Type\text/json]
"CLSID"="{25336920-03F9-11cf-8FD0-00AA00686F13}"
"encoding"=dword:00080000

I wanted the Remote Server Administration Tools for Windows 7 on my laptop running 64 bit Win 7 SP1. However, the download page says, “This software CANNOT BE INSTALLED on computers that are running Windows 7 with Service Pack 1… first install Remote Server Administration Tools, and then upgrade to Service Pack 1.“

I already had the service pack installed and pieced together the following workaround:

1. I have an Intel i7 and was a little disturbed by the “amd64″ prefix on the file name, but (after a little research) I downloaded amd64fre_GRMRSATX_MSU.msu from Microsoft Download Center – Remote Server Administration Tools for Windows 7.

2. In the same folder I downloaded the MSU file into, I ran a batch file with the following commands:

MD C:\RSAT
expand -f:* "%~dp0amd64fre_GRMRSATX_MSU.msu" C:\RSAT
CD\RSAT
pkgmgr.exe /n:C:\RSAT\Windows6.1-KB958830-x64.xml
pause


3. After installing the MSU file contents, I went to Control Panel | Programs | Programs and Features | Turn Windows features on or off and checked all the items I wanted under the Remote Server Administration Tools node.

At Pro Teck, we recently researched and developed a NoSQL focused project using Mongo DB to manage and persist a large number (one-million-ish) of big PDF documents (10MB). Our proof-of-concept with Mongo DB did not pan out and the NoSQL document management project was canceled. However, I have been on the lookout for a document database that better meets our requirements.

I’m excited because, at first glance, Raven looks like a viable new player in the NoSQL space!

 > .NET Framework 4 Training Kit

At Pro Teck we use NServiceBus Pub/Sub for most (75%) of our SOA architecture and we have successfully used WCF’s implementation of REST for synchronous services.

My painful experience with SOAP and WS* drove me to become a proponent REST several years ago. For those interested in getting a quick and through intro to REST, I highly recommend Martin Fowler’s posting titled Richardson Maturity Model: steps toward the glory of REST.

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <runtime>
    <loadFromRemoteSources enabled=”true”/>
  </runtime>
</configuration>

Also, after downloading NServiceBus, remember to “Unblock” each DLL in the Windows 7 file properties window.

Microsoft Visual Studio Scrum (MVSS) 1.0 is a new TFS process template for teams practicing Scrum…this article provided a good first look at Scrum on TFS 2010.”

Getting Started

Make a decision about the length of your sprints… most teams choose a length of time between a week and 30 days. The actual length is less important, but what is important is that items pulled from the Product Backlog can be delivered within the sprint boundaries. After creating a new project with the MVSS 1.0 template, projects are pre-populated with 24 sprints (six sprints across four releases).

From Team Explorer navigate to the All Sprints query. Each sprint work item returned in this query is mapped directly to an iteration value in TFS. Open the first few sprint work items and enter dates for the first sprints: “…it’s good to add what you know so that your team can begin to get a feel for the product schedule.”

Product Backlog

The Product Backlog query is a prioritized list of requirements for a project. It’s defined as all PBIs and Bugs assigned to the root iteration path of a project that haven’t been completed. Requirements are captured as a PBI (Product Backlog Item) work item; Title, Backlog Priority, Description and Business Value fields are the core of the PBI.

Each PBI moves through a series of four states used to track a requirement’s lifecycle:

• New: The starting point for all items on the Product Backlog. As new PBIs are entered they are assigned a default Backlog Priority of 1,000 to ensure they are pushed to the bottom of  the list.

• Approved: The PBI is clearly defined and ready to be brought to the team to be estimated. Most of the time, items near the top of the Product Backlog are in the Approved state, while items toward the middle and bottom of the list are in the New state.

• Committed: The team will complete the PBI in a sprint; After the team commits to implementing a PBI during the Sprint Planning Meeting, the state of the PBI is changed to Committed.

• Done: The team has completed all associated Tasks and the Product Owner agrees the PBI is implemented according to the Acceptance Criteria.

Acceptance Criteria

Acceptance Criteria is what “Done” means for each PBI. Acceptance Criteria is critical to the success of a Scrum team. It becomes the handshake between the Product Owner and the team and helps define what the team is committing to build.

Some of the best interactions happen as the Product Owner and the team review the Acceptance Criteria for each item on the backlog. What emerges is a shared understanding of what “Done” means for each item: “There’s no outstanding work, including testing, documentation, setup and so on.” There are many good formats for writing Acceptance Criteria, but in the end, all Acceptance Criteria should be simple and understandable by everyone involved.

Planning Your First Sprint

After the Product Backlog is created and prioritized, a team is ready to begin its first sprint. The team gathers for the Sprint Planning Meeting, where everyone agrees on a goal for the sprint. The goal for the sprint is captured in the Goal field on the Sprint work item. The highest-priority PBIs and Bugs on the Product Backlog along with associated Acceptance Criteria are reviewed and the team begins to gain an understanding of what it’s being asked to build.

After the team has had adequate discussion about the items being considered, it’s time to estimate each item. A common practice for Agile teams today is to use an estimation technique like Planning Poker. The goal is not to arrive at a precise estimate; rather, it’s to spark conversations that lead to a shared understanding of what “Done” means for each item. The team eventually arrives at a consensus estimate and this value is entered into the Effort field of the PBI or Bug work item.

This process repeats for each of the items until the team believes they have enough work to achieve the sprint goal. The next step is for the team to break down each item into Task work items. Tasks represent the actual work that the team will perform and should encompass all the work involved including testing, documentation, interface design and so on.

To add a Task to a PBI or Bug, switch to the Tasks tab on the work item itself and click the New Linked Work Item icon. Tasks are added as children of their parent PBI or Bug and begin in the To Do state. They can be tracked on the Tasks tab of both PBIs and Bugs.

After all the Tasks have been created, the final step is for the team to make a commitment to the work. This is done by setting each PBI or Bug work item to the Committed state, indicating that the team is committing to complete the item during the upcoming sprint.

The result of the Sprint Planning Meeting is:

1. An agreement between the Product Owner and the team on what items from the Product Backlog are to be accomplished during the sprint.
2. A list of all the Tasks necessary to complete the items selected by the Product Owner and the team.

The ultimate success of the sprint will be determined at the end of the sprint during the Sprint Review Meeting.

Tracking Your First Sprint

Now that the sprint is planned, the team is ready to get working. Ideally, the team works together on a backlog item until all the Tasks are completed before moving on to the next item. This helps minimize the risk of reaching the end of the sprint with everything 90 percent completed but nothing actually being “Done.”

Members of the team select the Tasks that they’ll work on first.  Team members record daily the number of remaining hours left for each Task they’re working on by updating the Remaining Work field. Ideally, each team member only has one In Progress task at a time, so as to minimize the risk of work being left unfinished or partially completed. As team members complete Tasks, the state of each Task is changed from In Progress to Done, and progress is reported at the daily standup.

During the sprint, the team tracks progress toward completing all the work using the Sprint Burndown chart. The chart clearly indicates the team’s progress toward burning down the hours committed to the sprint, as well as tracking the amount of work the team has In Progress. The Sprint Burndown is reviewed at the daily standup. Additionally, the team can use the Unfinished Work query to track the sprint.

Sprint Review and Retrospective

At the end of the sprint, the team holds a Sprint Review meeting to show what they accomplished during the sprint. A demo is held and stakeholders beyond the Product Owner are invited to participate. Sprint Review meetings should be informal and should feel like a natural end to the sprint.

The final step is a Sprint Retrospective, where the team discusses what worked and what could be improved in the next sprint. This is an opportunity for the team to take a hard look at where they stumbled and have an honest conversation about what will be done differently to improve the next sprint.

For more information on the Microsoft Visual Studio Scrum 1.0 template, see the process guidance on MSDN.

Enable Remoting in PowerShell 2.0

From the server we want to connect to, open a PowerShell window as an administrator and check for PowerShell providers…

Enable-PSRemoting
Get-PsProvider

We should see WSMan name in the list.  Next check WSMan config settings and TrustedHosts…

cd wsman:
cd localhost\client
dir

Please note: cd wsman will fail, we need that colon!

From the localhost\client folder of the WSMan namespace…

Set-Item TrustedHosts *
Restart-Service winrm

Enter-PSSession [IP Address] or [fully.quallified.domain.name]

What is WinRM 

• WinRM is short for Windows Remote Management.
• Based on the Web Services for Management (WS-Management) standards.
• WinRM 2.0 on Windows 2008 R2 and Windows 7 use port 5985 by default and 5986 for SSL.
• WinRM leverages WMI database to perform many tasks.

An Intro to WinRM Basics

• WinRM requires Windows Firewall to be enabled.
• From a command prompt run winrm quickconfig
  1. Starts the WinRM service;
  2. Sets WinRM service to auto start;
  3. Creates a listener to accept requests on any IP address;
  4. Enables firewall exception for WS-Management via http.
• Access WMI data VIA: 
  • GET
  • PUT
  • ENUMERATION
  • INVOKE