Convert C# to PowerShell code

Yesterday I saw a link on our company's intranet linking to a colleague's blog. It proved to be a very nice read. Among the .Net Reflector addins available on CodePlex, there's one for PowerShell allowing you to convert C# code to PowerShell. That will come in handy a lot of times since I definately write C# code faster than PowerShell code. Thanks for that tip!
The only downside is that Reflector for the last year requires a license fee and I have since switched over to ILSpy. With this and the other plugins available, it's either time to switch over to Reflector again, or rewrite some of the plugins to work with ILSpy.

Dangers when upgrading the Codeplex SFTP adapter

I encountered some dangers that one can run into when upgrading the BizTalk SFTP adapter that can be found on Codeplex.

On one installation where the adapter is used did the issue of the adapter stop working frequently arise. When the issue was fixed in a subsequent version of the adapter, it was upgraded, but the problem remained.

When I looked at the server, I noticed that the adapter never had got upgraded, even though they very well installed the new version. I then replicated what I believe to be the steps taken during the upgrade in order to fully understand what had happened.

I learned that when upgrading version 1.3.3 to 1.4.0, it is necessary to completely uninstall the previous version before installing the new. This was never done during the upgrade process. The old version remained installed and the setup program for the new version reported back that the installation was successful. The BizTalk administrator never noticed the dual entries in the Add/Remove programs window nor the old timestamps in the adapter installation folder (which was how I noticed it from the beginning).

Uninstalling the two adapter entries in the control panel and then reinstalling the new version solved the issue as can be seen in the installation directory.

I then also noticed that when properly upgrading the adapter, receive locations bound to the SFTP adapter will not start unless you for each and every one open the adapter properties windows and save it. This is due to a difference in the properties that will make the bindings fail otherwise, rendering the port to shut down.

BizTalk 2010 and Dynamics AX 4.0

We just did a quick check for a client investigating the possibility to upgrade their BizTalk 2006 platform to the latest (2010) version. The main issue was whether the vast amount of integrations to their Ax 4.0 system would still work.

Some of the integrations are made using the Ax AIF adapter in BizTalk and while their is a lot of information on the web that doesn't say that BizTalk 2010 can work with the Ax 4.0 adapter, there is not a single document that explicitly says that the two are incompatible even though you more or less can assume so based on the information available. Mainly because BizTalk 2010 requires Windows Server 2008 and the adapter is not supported on this platform. The adapter is not supported on 64-bit systems at all and I doubt there is many admins looking at installing a fresh new integration platform today and not putting it on a 64-bit Windows.

We checked with Microsoft just to be sure and received the answer that BizTalk 2010 and Ax 4.0 cannot be integrated using the adapter. Not even Ax 2009 is fully supported by BizTalk 2010 as of today which is an interesting fact. Instead are we investigating the amount of work needed to change the adapter based flows to MSMQ integrations instead. The upgrade of the integration platform is more important than to keep an outdated adapter working..

BizTalk 2010 certification

I've been waiting for a new exam for BizTalk to appear since the "current" one has been for 2006r2 for quite a while. Today I took a new look and found that Exam 70-595: Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2010 is available. The old exams for 2006 and 2006r2 are set for retirement this summer.

Time to update the skills that I rarely (or never) use such as EDI and RFID and then it's off to take the test.

Recycle IIS application pools using PowerShell

I have been working on a collection of deployment scripts for BizTalk solutions using PowerShell. One functionality is installation of services hosted in the IIS. After installation, the application pool need a restart in order to properly pick up the new/updated services.

At first, I just recycled all available application pools by the following command line

& $env:windir\system32\inetsrv\appcmd list apppools /xml | & $env:windir\system32\inetsrv\appcmd recycle apppools /in

First we list all available application pools and then we pipe this list as input into the recycle command.

While nice, it is unnecessary to recycle those application pools that are unaffected by our installation.

The main finesse in my scripts are that they are picking up all information on what to do from a configuration file. This XML file includes among other things the application pool for each service to install in IIS. Based on this I updated my recycle command to recycle each and every application pool that were specified in the configuration file. In order to not restart an application pool more than once, I pipe the foreach with sort-object and get-unique.

# List to hold the apppools
$appPools = New-Object System.Collections.ArrayList

# Loop through the objects in the xml file
# and extract the apppool name and add to the list
ForEach($wcfSetup in $xmlFile.DeployConfiguration.WcfSetups.WcfSetup)
{
    [void]$appPools.Add($wcfSetup.ApplicationPool.Trim())
}

# Recycle each unique apppool in the list
foreach($appPool in $appPools | sort-object | get-unique)
{
    & $env:windir\system32\inetsrv\appcmd recycle apppool /apppool.name:"$appPool"
}