Recently I was working to resolve an issue configuring BizTalk Server 2009 cluster on Windows Server 2008, I came across an failure when working with the Distributed Transaction Coordinator (DTC), also clustered. 

We were using DTCPing to test the connectivity to the DTC cluster.  DTCPing was reporting failure when attempting to return the “ping” data back to the client.  We made all logical attempts to resolve this issue, finally resorting to a call to Microsoft technical support. 

After testing the connectivity and correlation with DTCPing, DTCTester, WinRM and RMClient, we determined that the changes we made to the firewall and DTC client configuration had indeed solved the problem.

Additional testing and research revealed that DTCPing was not compatible with Windows Server 2008. 

To perform a more robust test we used WinRM and RMClient.  These tools operate against DTC without the requirement of SQL Server.  They allow you to test DTC regardless of the operating system on client or the host.

PLEASE don’t read this as a slight on DTCPing.  DTCPing is still THE tool for troubleshooting DTC issues in non-Windows Server 2008 environments.

I have been working with Agile/SCRUM for some time now. I am an evangelical supporter of it.

The SCRUM process provides a platform for success based on agility, accountability and team work. One of the very best aspects of SCRUM, the Sprint Retrospective, is a source of both good and evil.

The Good

The sprint retrospective allows teams to call out the things that went well during the sprint. This process outlines the positive/outstanding aspects of the sprint.

• “The team did a great job during the demo”
• “Team communication”

The second and most important part of the retro is “What can we do better?” (or “What did not go so well?”). This discussion allows teams to identify the aspects of the sprint that did not go well and should be improved or flat eliminated from future sprints.

• “Not enough time allocated to testing”
• “Stake holders not engaged enough”

The third step in the sprint retrospective is recommendations and action items. These items are generally derived from the “What can we do better?” phase of the retro. These lists are used to make future sprints more successful.

Recommendations

• “Add more testing resources”
• “Follow up more often with stake holders”

Action Items

• “Meet with testing team manager to gain more testing resources”

The Bad

The sprint retro also has an evil side.

During the “What went well?” phase of the retro, some teams can get a tad, and in some cases more than a tad, self-congratulatory, calling out items that were simply part of the sprint.

• “Tasks were completed”

In some cases, teams will glorify successes based on a previous failure.

• “We got everything done!” (Even though we had to extend the sprint)

Teams will also comment on the same “successes” in each sprint. Listing items as successful for each sprint devalues any accomplishment.

• “We had a stand up every day!”

The “What can we do better?” phase has some potential for evil too.

Calling out a specific failure of a team member is one of them. This practice should be shut-down immediately by the SCRUM master. In SCRUM, the team is a sum of its parts.

“All for one and one for all!”

Sprint retro evils are usually the product of a new team or team members that are new to the SCRUM methodology. Evils came raise their ugly heads with teams that have grown over-confident and too comfortable. The SCRUM master should control the Evils as the pop up.

The Bottom Line

The bottom line is: The sprint retrospective is a time for honesty and support. Be honest about your successes and your failures.

Pumping up successes and under reporting failures will (not can --- WILL) lead you down the path to the Dark Side.

Thanks for listening.
(Special shout out to BizTodd!  Thanks for the edit!)

Last night I attended my first Phoenix Connected Systems User Group, PCSUG.org.  I must say, I am happy that I went!

The group is run by Rick Garibay and Todd Sussman– two absolute rock stars in the .NET world.  The group meets the second Thursday of each month.  It is more that worth the time to attend one of these meetings.

The topic for this month was Client Application Systems, more specifically, the use of ASP.NET membership and roles in a windows application.  The demo also included methods for utilizing WCF and standard web services to achieve this functionality.  Lastly, the talk provided an overview of maintaining user settings, and having those settings follow the user to different computers.

Hope to see you there next month!

Thanks for listening.

When storing SQL scripts in a database project, that are not stored procedures, VS will give you some grief.

Build Error:

Error    6    TSD7025: Unable to identify the schema type contained in the .sql file.  A schema type of 'Procedure' was expected, based on the name of the .sql file.

 

To get around this, update the properties of the file in VS to “Not In Build”.

Thanks for listening.

I know this might sound a bit on the obvious side, but …

When using an ASP text box, with the read only setting set to True, any value in the text property (with client side JavaScript perhaps) will be ignored on post back.

Example

The following code:

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

    <title>TextBox ReadOnly Demo</title>

    <script type="text/javascript">
     
            function replaceText() {
                var tBox = document.getElementById('<%=Target.ClientID%>');
                tBox.value = 'foo';
            }
        
</script>

</head>

<body>

    <form id="form1" runat="server">

    <div>

        <asp:TextBox ID="Target" runat="server"  ReadOnly="true"/>

        <input id="htmlBtn" type="button" value="Populate TextBox" onclick="Javascript:replaceText();"  />        

        <asp:Button ID="Go" runat="server" Text="Go!" onclick="Go_Click" />

    </div>

    </form>

</body>

</html>

This will open a simple web page with two buttons and a textbox control.

The first button is an HTML input button.  It fires a JavaScript function that populates the value of the ASP textbox with ‘foo’.
The second button performs a post back that calls a method the does a ‘Response.Write’ to display the value of the text property of the ASP textbox.

protected void Go_Click(object sender, EventArgs e)

{

    Response.Write(string.Format("Returned Text: {0}", Target.Text));

}

No tricks.

When this code is run:

Click “Populate TextBox”

Click “Go!”

Result

There you have it!

Thanks for listening.

I know … I’m not supposed to blog about not blogging.  Deal with it.

I have spent the past several months getting used to a new team, in a new company.  I have been lucky enough to land in an organization that is truly “Geekville”.  My team members are among the best around.  My tools are top notch.  Running SCRUM.  It is a great place to be.

I am also lucky enough to get to work on several different platforms: BizTalk, SharePoint, SQL Server 2008, VSTS 2008 … and the list goes on.

Now that I am settled in, as much as I can be at this point, I will start hitting the blog more.

Thanks for keeping me in mind these past months.

Thanks for listening.

I guess this would be Part 2 on VBScripting – for today.

In the first post, Check Running Processes on Remote Computers with VBScript, I outlined a VBScript process to determine if a specific process was running on a remote computer on the same network.

In this post, I have a VBScript that will scan the registry of remote computers on the same network for a specific registry key.  List the remote processes script, this process utilizes a file containing a list of all machines on the network.  The registry key name is a local variable. It would not be too hard to take this script and put it into a function and pass the registry key name (and machine list file name for that matter) as a parameter.

This script also utilizes Scripting API for WMI to interrogate the remote machine.

Take a look.

' Set up some Constants

Const HKEY_LOCAL_MACHINE = &H80000002

Const ForAppending = 8

Const ForReading = 1

' Build the date tag for the log file name

sDate = right("00" & cstr(month(date())),2) & right("00" & cstr(day(date())),2) & right("200" & cstr(year(date())),4) & right("00" & cstr(hour(time)),2) & right("00" & cstr(minute(time)),2) & right("00" & cstr(second(time)),2)

' Build the full log file name

sOutFileName = "C:\Temp\reg_scan_log_" & sDate & ".txt"

' set this to the registry key to search

sKeyPath = "SYSTEM\CurrentControlSet\Services"

' Get the FSO moving

Set oFSO = CreateObject("Scripting.FileSystemObject")

' Open the file with containing all of the computers to scan (name or IP address)

Set objTextFile_List = oFSO.OpenTextFile ("C:\Temp\machineList.txt", ForReading)

' Create and open the file for logging

Set objTextFile = oFSO.OpenTextFile(sOutFileName, ForAppending, True)

' Loop through the file containing machine names/IP addresses

Do Until objTextFile_List.AtEndOfStream

    sMachine = objTextFile_List.Readline

    Set WshShell = CreateObject("WScript.Shell")

    bPing = Not CBool(WshShell.run("ping -n 1 " & sMachine, 0, True))      

    If bPing = True Then         

        Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & sMachine & "\root\default:StdRegProv")

        ' Create an enum of the key values

        oReg.EnumValues HKEY_LOCAL_MACHINE, sKeyPath, arrValueNames, arrValueTypes

        ' duh 

        ON ERROR RESUME NEXT

        ' check the array count

        If UBound(arrValueNames) > 0 Then

            objTextFile.WriteLine(sMachine & ": " & cstr(UBound(arrValueNames)))

        End If

        ' write the error message

        If err.number > 0 Then

            objTextFile.WriteLine(sMachine & ": " & err.Description)

        End If

    Else

        ' Set the appropriate response

        objTextFile.WriteLine(sMachine & ": Not on network")

    End If

loop

Thanks for listening

When things get muddy in a small IT shop, it is time for everyone to help out!

That is how a developer gets pulled into helping the network and Help Desk folks.

That said, I created this quick (kinda) and dirty (definitely) VBScript to check for a specific process running on each of the machines on the network.  The process utilizes a file containing a list of all machines on the network.  The process name is a local variable. It would not be too hard to take this script and put it into a function and pass the process name (and machine list file name for that matter) as a parameter.

This script utilizes Scripting API for WMI to interrogate the remote machines.

Take a look.

' Set up some constants

Const ForReading = 1

Const ForAppending = 8

' get the FSO open

Set objFSO = CreateObject("Scripting.FileSystemObject")

' Process you are looking for

sProcess = "csrsc.exe"

' Build the date tag for the log file name

sDate = right("00" & cstr(month(date())),2) & right("00" & cstr(day(date())),2) & right("200" & cstr(year(date())),4) & right("00" & cstr(hour(time)),2) & right("00" & cstr(minute(time)),2) & right("00" & cstr(second(time)),2)

' Build the full log file name

sOutFileName = "C:\Temp\scan_log_" & sDate & ".txt"

' Open the file with containing all of the computers to scan (name or IP address)

Set objTextFile = objFSO.OpenTextFile ("C:\Temp\machineList.txt", ForReading)

' Create and open the file for logging

Set objTextFile_Write = objFSO.OpenTextFile(sOutFileName, ForAppending, True)

' Loop through the file containing machine names/IP addresses

Do Until objTextFile.AtEndOfStream

    ' get the machine name from the current row of the file

    sMachine = objTextFile.Readline

    ' duh

    Dim Process, sResponse, sWriteMe

    ' Default the test response

    sResponse = "No"

    ' duh

    ON ERROR RESUME NEXT

    '   Ping the machine to make sure it is on the network

    Set WshShell = CreateObject("WScript.Shell")

    bPing = Not CBool(WshShell.run("ping -n 1 " & sMachine, 0, True))      

    ' only check for the process if the machine is on the network

    If bPing = True Then

        Set objWMI = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

        Set cProcList = objWMI.ExecQuery ("Select * from Win32_Process Where Name = '" & sProcess & "'")

        ' if there are items in the collection ....

        If cProcList.Count > 0 Then

            ' Found it!

            sResponse = "Yes"

        End If

    Else

        ' Set the appropriate response

        sResponse = "Not on network"

    End If

    ' If there was an error ... Log it!    

    If err.number > 0 Then

        sResponse = err.Description

    End If

    sWriteMe = sMachine & ": " & "Running " & sProcess & " - " & sResponse

    objTextFile_Write.WriteLine(sWriteMe)

  Loop

Thanks for listening

I have been working on a SSRS report that produces financial data for a rolling 20 month period.  The SQL behind the report is pretty straight forward.  The challenge was dynamically setting each of the column names on the report to accurately reflect the month/year data presented by the SQL.

This task is made a little simpler since the column names are derived from dates, making it possible to calculate the values of the column names.

The other challenge with this process is that the report can be run for any specific date.  The obvious solution, and the one I used, is to pass a date parameter to a SQL stored procedure (You could have used straight SQL in SSRS and used the parameter as part of the WHERE clause – I just prefer to use stored procedures).  The fun part of this getting SQL Server and SSRS to play nice together (I know this sounds obvious and should be straight forward.)

Steps

1. Create the stored procedure allowing for an input parameter to accept the date.

USE someDB

GO

IF OBJECT_ID('someDB.dbo.uspSampleProc') IS NOT NULL

    DROP PROCEDURE uspSampleProc

GO

CREATE PROCEDURE [dbo].[uspSampleProc]

    ( @BaseDate        DATETIME

    )

AS

...

2. Create the report template in SSRS

3. Create the report parameter and associate with the SQL parameter.

To get there:

1. Go to the Data page for the report
2. Click the ellipse (“…”) next to the Dataset Drop down
    
3. Then select the Parameters tab in the Dataset dialog box

5. Edit the expression in the column heading text box(es) to reflect the rolling month/year indicated by the report data.

=RIGHT("0" & CSTR(Month(DateAdd("M", 1,Parameters!BaseDate.Value))),2) & "-" & YEAR(DateAdd("M", 1, Parameters!BaseDate.Value))

What’s going on here?

The above example would be used in the second column header label on the report.

Using the report date parameter as the base, it is possible to calculate the text value for the column headers.

The column name will show the month and the year that the column represents. EX: 01-2008

To ensure that the month and year displayed are in synch with the rolling monthly data, two separate string functions are combined to form the final text.

The “Month” part

The first string function determines the month indicator.  For this report, the month indicator needs to show with two characters.  As the “Month” function in SSRS does not do this for us, it is necessary to add a leading “0” to the numeric identifier for months January through September. 

To do this:

1. Append a “0” to the left side of the numeric value that represents the month.
2. Use the “Right” string function to pull the two right most characters from the string.

The second part of this string function determines the appropriate month to report.  This is done using the “DateAdd” function.  This function allows you to add or subtract from a date value to get anther date (more info on the DateAdd function here: MSDN SSRS DateAdd Function).  The example shows that the BaseDate report parameter will be incremented by one month.

The “Year” Part

This string function determines the year that corresponds to the rolling month value.  It utilizes the same “DateAdd” functionality as the “Month” string function.  The only difference is that the year is extracted from the new date value using the “Year” function.

HEY!  This expression will need to be applied to each column.  Each implementation of this expression will need to be updated to correlate to the appropriate rolling month.  Meaning: The units parameter of the DateAdd function will need to be updated to reflect the correct value. For Example, The third column header on the report, you would enter “3” for the units parameter of the DateAdd.

Done!

Thanks for listening.

I have been working on a solution for my current client that would allow the uses to access the Citrix web interface through their SharePoint home page.

There are a few ways to do this:

1. Add a link to the SP home page that opens up the Citrix Web Portal
2. Add a Page Viewer web part to the SP page, opening the Citrix Web Portal
3. Install Citrix Web Interface for SharePoint 2007 (WISP 2007), and utilize the supplies Citrix specific web parts

Each of these solutions has it’s pros and cons.

1. Adding a link to the home page is quick and easy, but not the most elegant way of doing things.
2. Adding the Page Viewer web part to the front page offers a more intuitive solution.  This provides the users with an obvious place to login to the Citrix server and will also present their available applications in a familiar environment.
3. The most robust solution is to install WISP 2007.  This solution provides an integrated solution to presenting the user with their Citrix application options.  This tool integrates Single Sign On, SharePoint and core Citrix functionality very nicely.

My client opted for solution #2: Add a Page Viewer web part to the home page.

To do this:

1. Add a Page Viewer web part to the page

2. Edit the web part properties to add the URL for the Citrix Web Portal

HEY! In order for the Citrix Web Portal to function properly, the full domain will need to be added as a trusted domain on the client.

 

3. After the domain is trusted by the client, the users will be presented with the familiar login interface of the Citrix Web Portal

Thanks for listening.