maandag 29 november 2010

BizTalk 2010 Setup fails when Trend Micro OfficeScan is installed

When you try to install BizTalk Server on a system that has Trend Micro Officescan installed, you might run into an error.

It will do this when trying to stop windows services, as shown in this setup screen fragment:

When examining the logfile you will encounter this entry:

[2:18:33 PM Info] Action 14:18:33: StopServices. Stopping services
[2:18:37 PM Info] Detailed Log information for product E:\Msi\Microsoft BizTalk Server 2010_64.msi is available at DetailedLog
[2:18:37 PM Info] MSI installation returned 1601 - The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.

When analyzing the detaild log, you find this entry:

MSI (s) (5C:E8) [14:18:33:961]: Executing op: ServiceControl(,Name=WinMgmt,Action=2,Wait=1,)
MSI (s) (5C:E8) [14:18:37:493]: Internal Exception during install operation: 0xc00000fd at 0x000000007723A725.

Reason for this is that BizTalk Setup tries to stop and start the WMI Service. As Officescan is dependent on this, it would als need to be stopped and started and that might be disabled as a policy. As a result setup fails.

To check if this is indeed the cause, try to stop the WMI Service by hand using the services manager in Administrative Tools. If it gives a list containing the service OfficeScan NT Listener.

In order to succeed, you need have Trend services disabled by a domain administrator. I suggest installing a scanning tool that does not rely on heavily used services.

vrijdag 29 oktober 2010

Migrating BizTalk 2006R2 sources to BizTalk 2010 without (too much) pain

I ran into it. You probably did too. You tried to convert your BizTalk 2006R2 solution to BizTalk 2010 (or 2009) and found that your solution was OK, your C# libraries went just fine, but none of your BizTalk projects had been converted.

Then, when you retried this from the converted solution, or tried to load a .btproj directly, you got that dreaded message: Error converting project file. The element <BIZTALK> beneath element <VisualStudioProject> is unrecognized.

I 'blame' the BizTalk Deployment framework for this as Microsoft clearly thought noone would ever try to move away from the suggested Deployment and Development build configurations. So if you, as we did, change it to Debug and Release when we moved to the BTDF, you are in for a bit of work.

Now I have for you the best way to get going. I found it just out of sheer desperation trying to get things working the way they should.

The best part? It takes just about 5 minutes per solution, independent of the size of it!!. It has worked for all solutions I have tried so far.

Now, How to do it.(NOTE: This walkthrough demonstrates the principle. There are several optimizations possible, especially when executing text search and replace actions on files)

1) Make sure you have a backup of your solution file BEFORE trying any conversions. You need the clean 2006R2 version. (or : you can of course also use an Undo Pending Changes option of you TFS). Also, as pointed out by other users of this method, delete any .user files within the solution you want to convert.

2)Just open the solution in Visual Studio 2010 as you want to. This will prompt the upgrade wizard to do what it does best.

3)Review the loaded solution. You should have a converted solution, loaded C# libraries and unloaded BizTalk projects.

4) Close all windows in Visual Studio.

5) Right-click each unloaded project file and select Edit to open it in text mode. You now should have all files open in text mode.

6) Using basic search and replace do a replace on all open documents replacing Name = "Debug" by Name = "Development" and replacing Name = "Release" with Name = "Deployment". Each replace should give a count of items replaced equal to the number op open BizTalk projects.

7) Now the big trick: Either close your solution and put back the backed up .sln file you made earlier and then re-open your solution OR just select Undo Pending changes on your solution file (AND JUST THE SOLUTION FILE...)

8) The Migration Wizard will trigger again and now will convert your BizTalk projects as expected.

9) Now we are almost done, except that you BizTalk project has a configuration base (Deployment/Development) that has not been defined in the solution (Release/Debug).

You need to get this back in sync. To do this, unload all BizTalk projects from the solution (right-click, select unload) and once again open them in textmode (all other windows closed)

10) Now reverse the replace: replace "Development" with "Debug" and replace "Deployment" with "Release". Save all files, then close all files.

11) Close and reopen you solution, as for some reason, Visual Studio complains about reloading projects that are already opened under the solution if you try to reload them now. Even when they are closed...

12) Reload all BizTalk projects in the solution, save and we are done.

So. I hope this just will get you going. Any comments, as always, are appreciated to make this work better, make note of exceptions to the rule etc etc.

As an add-on: Of course it is also possible to migrate an entire collection of solutions under TFS this way. You still need to open each and every solution in between the two find/replace actions. You can use VS's find/replace in Files option when viewing your source-control page to process all .btproj files from a given location down.

woensdag 29 september 2010

Configuring the BizTalk Adapterpack 1.0 for use with BizTalk 2010 and Visual Studio 2010

I have a problem. A big monkey problem. I have been using the BizTalk Adapterpack 1.0 at my customer site to unlock precious Oracle 8.1.7 resources about 2 years ago.

No problem? Yes it is. The Oracle Client 10g is the last version to support connections to these databases. This means I cannot use Adapterpack 2.0 or the new BizTalk Adapterpack 2010. Of course, the client COULD upgrade the databases, but my guess is that these systems will be around for another year or two. They could live through one more generation if I could somehow use the Adapterpack 1.0 with BizTalk 2010.

Luckily it is not that hard to configure the Adapterpack 1.0 for use with BizTalk 2010. Here is how to do it. (NOTE: I did not describe the Oracle client dependencies. If you need those, drop me a note.)

1) Install the LOB WCF Adapter SDK 2010 for use with your platform (32 or 64 bit).
2) Install the BizTalk Adapterpack 1.0 for 32-bit and, if applicable, 64-bit.

Now normally this would be it. But since .Net 4.0 we have a new machine.config that is not known to the Adapterpack 1.0 installer. So we have to manually register the adapters to the machine.config in the %windir%\Microsoft.Net\Framework\v4.0.30319\CONFIG\machine.config

If you have a 64-bit platform you need to repeat this for the %windir%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config.

What settings do you need to copy from the 2.x machine.config. Below is a list for all the adapters in the pack. If you chose to just install the Oracle Adapter, you can ignore all the steps/lines that mention SAP or SIEBEL. Just do not copy them.

Configuring the 32-bit adapters

from <><DbProviderFactories> copy the following lines to the <><DbProviderFactories> section in the .Net 4.0 machine.config:

<add name="SiebelClient Data Provider" invariant="Microsoft.Data.SiebelClient"
description=".NET Framework Data Provider for Siebel eBusiness Applications"
type="Microsoft.Data.SiebelClient.SiebelClientFactory,Microsoft.Data.SiebelClient, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="SAPClient Data Provider" invariant="Microsoft.Data.SAPClient"
description=".NET Framework Data Provider for mySAP Business Suite"
type="Microsoft.Data.SAPClient.SAPClientFactory,Microsoft.Data.SAPClient, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

from <system.serviceModel><extensions><bindingElementExtensions> you need to copy these lines to the <system.serviceModel><extensions><bindingElementExtensions> node in the .Net 4.0 machine.config:

<add name="siebelAdapter" type="Microsoft.Adapters.Siebel.SiebelAdapterExtensionElement,Microsoft.Adapters.Siebel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapAdapter" type="Microsoft.Adapters.SAP.SAPAdapterExtensionElement,Microsoft.Adapters.SAP, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBAdapter" type="Microsoft.Adapters.OracleDB.OracleDBAdapterExtensionElement,Microsoft.Adapters.OracleDB, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

from <system.serviceModel><extensions><bindingExtensions> you need to copy these lines to the corresponding place in the .Net 4.0 machine.config:

<add name="siebelBinding" type="Microsoft.Adapters.Siebel.SiebelAdapterBindingSection,Microsoft.Adapters.Siebel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapBinding" type="Microsoft.Adapters.SAP.SAPAdapterBindingSection,Microsoft.Adapters.SAP, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBBinding" type="Microsoft.Adapters.OracleDB.OracleDBAdapterBindingSection,Microsoft.Adapters.OracleDB, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

from <system.serviceModel><client> you need to copy these lines:

<endpoint binding="siebelBinding" contract="IMetadataExchange"
name="siebel" />
<endpoint binding="sapBinding" contract="IMetadataExchange" name="sap" />
<endpoint binding="oracleDBBinding" contract="IMetadataExchange"
name="oracledb" />

Configuring the 64-bit adapters
You have to copy the exact same entries on a 64-bit machine to the %windir%\Microsoft.Net\Framework64\v4.0.30319\CONFIG\machine.config with one exception: the Siebel adapter does not have a 64-bit version.

The catch to this is the following: You cannot use the Adapterpack 1.0 with other versions side-by-side due to dependencies.

If you really need the functionality of different packs, I guess you could have a dedicated host, only to run on a dedicated BizTalk node in the group which has an other (or this) version installed. Configuring this, however, is a problem as you need to manage the group from two different(!) machines which also have these adapterpacks installed this way... better (not) try it.

dinsdag 28 september 2010

BizTalk 2010 Setup fails at SSO Install.

While installing the recently released BizTalk 2010 Developer Edition, I ran into an unexpected installation error.

The Enterprise Single Sign-On installation failed complaining that it was unable to 'find the path specified'.

Manually installing ENT SSO from the \BT Server\Platform\SSO64 did not do me much good; the installation failed as stand-alone also.

In the end I found that the problem was that I was installing from a network location, even though it was mapped to a drive letter.

To be exact: I was installing onto a VMWare Windows 2008R2 64-bit image, mapping a shared folder on the host holding the installation files.

I have found that there are two ways that will get you out of this:
1) Create an ISO and mount it from the VMWare image as CD.
2) Copy it to a virtual disk local to the VMWare image.

Problem solved.

vrijdag 12 februari 2010

Speeding up the BizTalk Administrator MMC

I reached a patience limit when the BizTalk administrator took over 2 minutes from launch to showing me my application resources on my (rather slow) VM. I could not remember this ever taking that much time. Of course, BTA console never was a real fastloader, but this was getting excessive.

When I asked a co-worker to logon to the same machine and try the same actions, I was astonished see him do the same job on the same machine in less than 30 seconds. Clearly it was user, and thus, profile related.

I created a clean profile for myself to test this and was proven right. It took less than 30 seconds to get the app running and the resources loaded.

I then started to replace original content from my old profile and tested until I, again, reached a 2 minute+ loading time. Problem recreated, cause found.

It appears there is a settings file that controls, amongst others, the window and grid layout of the management console. Over time this file has grown in size from a mere 2kb default to over 600kb. Loading this file seemed to take too much resources and caused a delay that went to 2 minutes.

I simply deleted the file and things went back to normal. Here is the guilty party:

You can find it in C:\Documents and Settings\-your account here-\Local Settings\Application Data\Microsoft Corporation\Microsoft BizTalk Server 2006\

donderdag 4 februari 2010

Problem: BizTalk makes full backup every 15 minutes

We recently encountered a problem where the BizTalk SQL Agent job that executes the backup procedure resulted in a full backup every run in stead of once every day.

We became aware of the issue when disk space events were fired by our monitoring software.

We found the problem when we looked into the table adm_BackupHistory in de BizTalkMgmtDb. For some reason someone had felt the need to manually execute the backup job and somehow managed to enter a date in the future as the last-run entry.

In stead of february 3rd, march 2nd was entered (European dd-mm-yyyy vs US mm-dd-yyyy mix-up.) A classic by al means.

This caused the backup's job logic to determine if it was time for a full backup to fail and always return true.

Once this part of the history was corrected, the Backup Job went back to normal operation.