Atin Agarwal's Blog

Biztalk and .NET 4.0

2009-10-28T19:51:48Z

Just wanted to point you all to http://blogs.msdn.com/biztalkcrt/archive/2009/10/28/biztalk-and-net-4-0.aspx, which says not to install .NET 4.0 on existing Biztalk installations. This is still being investigated.

Inserting parent child records with Identity column using WCF-SQL Adapter in one transaction

2009-10-05T20:47:19Z

There would be scenarios where you are inserting into a Parent table which have got an auto incrementing or an Identity field and you need to get this identity value back and use it to insert into child table records. And that too all, in a single transaction.

In Native SQL Adapter, this kind of composite operation can be achieved using updategram by capturing the value generated for the Identity field using the updg:at-identity attribute. This is documented at whitepaper: Working With BizTalk Adapter for SQL Server. But when it comes to WCF-SQL Adapter (Adapter Pack 2.0), since it would not work with updategram, only way I could figure out is to write a Stored Procedure which will do all the stuff in a single transaction and you can then call it from the Send Port. Of course, you can do the same in multiple operations without calling Stored Procedure where you first write to Parent table and get the identity value back as response and then write to child table; but this would not be a single transaction and any failures will writing to child table will not rollback the insertion into Parent table by itself.

Now, when it comes to writing Stored Procedure, if you just need to insert into one parent record and one child record, it would be simpler. But what about if there are multiple child records for a single parent record? For this, we would need to create an Xml message and pass this to the Stored Procedure as an Xml parameter. And then inside the stored procedure, we need to retrieve the values from the Xml message and insert it to our Parent and Child tables. Parsing the Xml message inside Procedure will be not an easy task if the message schema is complicated (especially for EDI Schemas :) ) and will involve good knowledge of writing Xpath Queries. But this becomes really simpler with use of Table Types and Table-Valued Parameters in SQL 2008. (Thanks to Mustansir Doctor for pointing me to this new feature of SQL 2008)

Here is an example of how we can achieve the same using Table Types and Table-Valued Parameters.

Lets say we have two tables Orders & Order Details in SQL 2008 with Primary Foreign relationship and OrderId is an auto incrementing field.

Now, first step will be to create Table Types for the above two tables:

We do not need to have OrderId field in the Table Type created as this is an incrementing field and we do not need to pass this in parameters passed to Stored Procedure.

Now, create a stored procedure to which we will pass this Table Type as parameter and inside it we will first insert into Orders table and read out the Identity value and use it to insert into OrderDetails table. Also, notice that reading out values from the Table Type objects is as simple as reading out form a Table.

Now, what all we have to do is to use Consume Adapter Service through Visual Studio to generate Schema.

It will generate two schemas TableType.dbo.xsd and TypedProcedure.dbo.xsd along with a binding file for the WCF-SQL Adapter.

TableType.dbo.xsd

TypedProcedure.dbo.xsd

TypedProcedure.dbo.xsd contains the request and response schema for WCF-SQL Adapter.

Now, only thing remaining is to construct a message of the request schema type inside the Orchestration and send it to WCF-SQL Adapter which will execute the Stored Procedure. I am not going into it more detail on how we do it inside Orchestration as it will be similar to any other operation we do using WCF-SQL Adapter.

You can see that using the Table Types simplify the things to a large extent and we do not need to write a single line of code to parse the XML.

I hope it helps.

Messages for MQSeries Adapter failing due to DTC failure

2009-09-09T01:57:48Z

If you are trying to send or receive message to MQ Server using the MQSeries Adapter, and receiving following errors in the application event log:

on BizTalk Server

Event ID: 5740
Description:
The adapter "MQSeries" raised an error message. Details "Error encountered on opening Queue Manager name = <queue manager> Reason code = 2354."

on MQ Server

Event Source: Microsoft BizTalk Server 2006 Adapter for MQSeries
Event Category: Devices
Event ID: 264
Description:
Error encountered as BizTalk attempts to retrive a message from MQSeries, description = Error encountered on opening Queue Manager name = <queue manager> Reason code = 2354. hresult = 0XC0C11007. This error will also be reported on the BizTalk server.

Most probably, this issue arises due to lack of DTC connectivity between the BizTalk and MQ Server.

To resolve it, we have to make sure the DTC communication between two computers is fine. Make sure that the MSDTC security settings on both BizTalk as well as MQ Server looks like in the below screen shot.

Also, DTC communication can usually fail if the name resolution or RPC communication between two computers is failing. To test it, we can use a small but useful tool named as DTCPing.

DTCPing Download: http://www.microsoft.com/downloads/details.aspx?FamilyID=5e325025-4dcd-4658-a549-1d549ac17644&DisplayLang=en

Troubleshooting MSDTC issues with the DTCPing tool: http://blogs.msdn.com/distributedservices/archive/2008/11/12/troubleshooting-msdtc-issues-with-the-dtcping-tool.aspx

I hope it helps!

Error due to missing HIPPA Schema Trigger Field Annotations

2009-07-31T02:45:17Z

Recently, I was working on a support incident where the customer have modified 837I HIPPA schema by adding a child node under DTP segment. But, while we tried to validate an instance against the schema at both design time and run time, we will get error “Object reference not set to an instance of an object”.

Below is the error thrown by EDIReceive pipeline at run time.

Event Type: Error
Event Source: BizTalk Server 2009 EDI
Event Category: None
Event ID: 4097
Description:
Fatal error encountered in EDI Disassembler, error information is Object reference not set to an instance of an object.

The issue would not happen if we were using the default 837I HIPPA schema which comes out of the box with BizTalk. Now, it means that something going wrong with the node which we have added to schema and the error is also of not much help here. Also, if we remove the data from the input instance corresponding to the node added in the schema, it would get successfully parse.

After we did a thorough examination of schema (all thanks to Farida for this), we found that the child node added under DTP segment in the schema was missing the HIPPA Schema Trigger Field Annotations. First learn what are HIPPA Schema Trigger Field Annotations, for that click here. Here it was happening that, for DTP segment, we had other default child nodes which have got their Trigger Field Annotations specifying what their qualifier values (or trigger values) are. Now when the EDI Disassembler encounters DTP segment followed by the qualifier value, it should be able to resolve it to the corresponding XML child node under DTP segment. But when it encountered DTP segment for the child node added to the schema, it was not able to resolve the qualifier value to any node since there is no child node matching that qualifier value and hence the error.

Once we added the Trigger Field Annotations to the node added manually, it resolved the error. Note that, for adding the trigger info, we have to open the schema in a text editor.

Call orchestration with ref parameter in a loop

2009-06-19T00:28:31Z

Sometime back I worked on a case where the spool would go very high and I have been thinking to blog this for some time now and today I decided I will process this awaiting queued item in my mind.

I had a customer who was seeing a surge in the spool count whenever an orchestration instance started and spool would go back to its original count only once this instance get completed. As we all know, the high count of spool impact Biztalk processing, the customer was too worried about it.

Looking into the orchestration, they have got a loop shape which could loop up to 40K times or even more. In this loop, they were calling an orchestration with Biztalk message being passed as ref parameter.

We found that with REF we need to keep messages around until the orchestration completes, so that is why the spool count keeps growing till the loop completes and once the orchestration instance completes, Biztalk jobs would clean up messages from spool. This is by design.

To demonstrate this, we got a simple orchestration with a loop inside. This will loop for 50 times only.

Inside the loop, we are making a call to another orchestration and passing Biztalk messages as REF parameter.

If we test it, and monitor the spool count in perfmon, we will see that spool keeps growing until the loop completes and once the orchestration instance completes, Biztalk jobs are quick to clear the spool.

As a workaround for REF parameter, if we pass a message as IN parameter and have one more OUT parameter of the same type in the called orchestration to return the result, I see that spool growth is lower than while using REF parameter, but still for very large loops spool count can grow substantially.

Also, if possible we can try using variables instead - which can be reused as opposed to message.

So moral of the story is we have to avoid large loops with call orchestration shape passing ref parameter. We would suggest using smaller loop, or removing the call structure by using expression Shape or custom object etc.

BAM tracking data gone missing

2009-04-15T00:56:20Z

Recently, I worked on a BAM issue and I wanted to share with you all some interesting facts which I found while researching on this.

Customer implemented BAM Activities with Event Streams. They were using OrchestrationEventStreams within Orchestrations.

This is how their flow looks like in short:

Orch1: Start Orch1 –> BeginActivity –> UpdateActivity –> Enable Continuation –> Send message to Orch2 so that it gets instantiated and passing Continuation Token to it --> End Activity
Orch2: Start Orch2 --> Update Activity with Continuation Token --> End Activity with Continuation Token

Customer observed that sometimes there is a row in the BAM Active table with ActivityId set to ContinuationToken and IsVisible set to NULL. This tracked BAM data is sitting idle in the active table and would not go to Completed table. Also, since the IsVisible is set to NULL, it would mean that it is not going to be shown through BAM view or BAM Portal, unless you write a custom query.

Researching on this, I found that if IsVisible is NULL, this would mean that BeginActivity was never called. So, what was happening in the customer case that that BAM events from Orch2 were getting processed and reaching BAMPrimaryImportDB while the BAM events from Orch1 never make up or they got stuck somewhere in between. Now, the question was how come the events from Orch1 were not getting processed though the events from Orch2, which got instantiated after Orch1, were getting processed. Also, keeping in mind, that the issue is intermittent.

Lets now understand how do the OrchesetrationEventStream(OES) API works. OES API’s are asynchronous. This means that API stores tracking data first in the BizTalk MessageBox database. Periodically the data is processed and persisted to the BAMPrimaryImport database by the Tracking Data Decode Service (TDDS). There are four tables inside the MessageBox database which stores BAM Tracking data before it gets moved to BAMPrimaryImportDB i.e trackingdata_0_0, trackingdata_0_1, trackingdata_0_2, trackingdata_0_3 (note: the other four tables trackingdata_1_x store the tracking data for BiztalkDTADB). For a particular Orchestration instance, OES uses the Orchestration ID as the StreamID and all the events are written to the same table by the OES and TDDS can guarantee that the events are processed in the same order. http://msdn.microsoft.com/en-us/library/microsoft.biztalk.bam.eventobservation.bufferedeventstream.streamid.aspx

But since we have two different Orchestrations here, it would mean that all the BAM tracking data could go to different Tracking tables inside MsgBox and then we cannot guarantee that it would be processed in sequence. But since we are using Continuations, BAM guarantee that the end result after all the events gets processed (no matter what the sequence is), we should see correct result in the BAM Completed table. That’s the magic with BAM.

Now we queried on the four trackingdata tables inside MsgBox DB and found that the table trackingdata_0_0 has more than 50000 rows which keeps moving in the upward fashion and never decreased. It seems that somehow BAM data stored at this table is stuck there and TDDS is not able to move it to BAMPrimaryImport DB. It now clearly makes sense why we sometimes see BAM events from Orch2 inside BAMPrimaryImport DB and not from Orch1 as the events from Orch2 might have been stored at table other than trackingdata_0_0 and got successfully processed by TDDS. It also explains the intermittent nature of problem as other times the BAM events from Orch1 and Orch2 got written to table other than trackingdata_0_0. Also, sometimes both the events from Orch1 and Orch2 could get written to trackingdata_0_0 table and we would see no BAM data getting tracking in BAMPrimaryImport.

Later, on more digging, the issue was found external to Biztalk. The issue was all related to network and firewall between the Biztalk and SQL servers. After those issues were fixed, all data from trackingtable_0_0 table moved to the BAMPrimaryImportDB correctly.

Message for the File Send Adapter remains in active state

2009-04-02T13:15:00Z

This was an interesting issue on which I worked with Shaheer (Biztalk Escalation Engineer) for 2 customers, so I thought I would share it with all.

Customer is using File Adapter at Send Port to write files to a file server. Sometimes, the send message stuck inside in Biztalk with active status and a 0 Kb file is created on the share on the file server. The message remains in active state until we restart the host instance, and then the message is written to the file share.

We took the Biztalk traces and although we did not see anything for the send port other than them being stuck, at the same time that the send ports were stuck, we could see the receive locations hitting the same file server were throwing error 0x800703E5 and Win32 Error = 56 in the traces and even sometimes 80070038

[filelistener]Network connection to location (\\<fileshare>) is down. Error = 80070038

--- 0x80070038 means:
ERROR_TOO_MANY_CMDS winerror.h
# The network BIOS command limit has been reached.

--- 0x800703E5 means:
ERROR_IO_PENDING winerror.h
Overlapped I/O operation is in progress.

--- Win32 Error = 56 means:
Network Bios Command limit has been reached.

This means the network bios command limit has been reached between the Biztalk Sever and the file server. This can happen when there is a very high load of SMB traffic between Windows servers since the default network bios command limit may not be high enough to handle this load. This will effect any SMB traffic between BTS & that file server so even though the error in trace was happening for receive location, it would apply to send port hitting same file server also.

Now comes the resolution part:

Need to follow the below steps as per KB 810886 to increase command limit by setting BOTH of the following registry keys on all the Biztalk Servers AND the File server AND any other file server that you may have problems with:
1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters
3. In the right pane, double-click the MaxCmds value and in the Value data box change the value to decimal 5000. (If the MaxCmds value does not exist, create it as a new REG_DWORD value of decimal 5000)
4. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
5. In the right-pane, double-click the MaxMpxCt value and in the Value data box change the value to decimal 5000. (If the MaxMpxCt value does not exist, create it as a new REG_DWORD value of decimal 5000)
6. Quit Registry Editor.
7. Reboot the computer

We have said above value 5000, taking less cautious route to start with a high value and work your way down. If we want to be cautious, we can start by increasing it to 1000 and then see if we still have the problem and if so, increase it again. In a very high load environment, even 5000 may not be enough and the value would have to be increased further. Only thing we could think with high value even as high as 50,000 is that we may run into high cpu on file server if it can't handle the load.

[Note: The maximum number of simultaneous, active requests between an SMB client and the server is determined when a client/server session is negotiated. The maximum number of requests that a client supports is determined by the MaxCmds registry value. The maximum number of requests that a server supports is determined by the MaxMpxCt registry value. For a particular client and server pair, the number of simultaneous, active requests is the lesser of these two values. This is documented at KB 810886.]

EDI pipeline with character set Extended

2009-03-19T02:36:56Z

Receiving German Characters in the EDI message received by Biztalk 2006 R2. We have set the character set to "Extended" in the receive pipeline but it still fails in the receive pipeline.

Solution:

Found that the char set ‘Extended’ does not include the complete iso8859-1. It implements subset of the 8859-1 . The following is the list of characters in integers that we support/consider under `Extended` 32-93, 95, 97-126, 161, 191-194, 196, 199-202, 204-206, 209-212, 214, 217-220, 224-226, 228, 231-239, 241-244, 246, 249-252. The list of characters that we support under `Extended` are clearly a subset of ISO8859-1. For all chars outside of this list, we should use UTF8. We found that the messages received by Biztalk was not proper UTF8 as it was missing BOM headers. Once we added the BOM headers it worked with character set UTF8.

UTF encoded message failing in Biztalk 2006

2009-03-18T17:51:40Z

Receiving following error at the Receive Pipeline while using MSMQ adapter in Biztalk 2006: A message received by adapter "MSMQ" on receive location "xxxxxxxxxxx" with URI "xxxxxxxxxxx" is suspended. Error details: There was a failure executing the receive pipeline: "xxxxxxxxxxx"
Source: "XML Disassembler" Receive Port: "xxxxxxxxxxx" URI: "xxxxxxxxxxx" Reason: No Disassemble stage components can recognize the data.

Also, the Biztalk 2004 accepted the message and processed it with no errors. The migrated it to Biztalk 2006. The issue started occurring after migrating to Biztalk 2006. Also, the same message would work with File Adapter in Biztalk 2006.

Solution:

Found that the messages are UTF-16 encoded but do not contain BOM header. It's stated that UTF-encoded messages need to have BOM and the solution is to have UTF-encoded messages with BOM. This is a standard and this check have been added from BTS2006 onwards. So that explains why it works in BTS2004 and fails in BTS2006.

Either we has to use custom pipeline component to add BOM headers or has to modify the application to add BOM headers before sending message to Biztalk. Also, if you receive a UTF-encoded message without BOM header using a File Adapter, it will also fail. Usually what happens if we copy the message to a notepad and then save it, the encoding gets changed to ANSI, therefore it works. If it is not possible to change the application sending message, then a workaround is to create a custom pipeline component and use it in the receive pipeline to add the BOM header.

For example, starting from SDK (c:\program files\Microsoft BizTalk Server 2006\SDK\Samples\Pipelines\CustomComponent\FixMsg) sample with following suggested changes:
In the file FixMsg.cs Change: Byte[ ] prependByteData = ConverToBytes(prependData);
With: byte[] prependByteData = new byte[]{239,187, 191}; //UTF8 Byte Order Mark
In the file FixMsg.cs Change: Byte[ ] prependByteData = ConverToBytes(prependData);
With: byte[] prependByteData = new byte[] {255,254}; // UTF16 Byte Order Mark

Deadlock occurring between bts_InsertTrackingData and TDDS_GetTrackingRecord

2009-01-03T01:08:17Z

Recently, I saw an issue where we were observing deadlocks between the stored procedures 'bts_InsertTrackingData' and 'TDDS_GetTrackingRecord' and this happens when there is a huge load for BizTalk to process.

What we found that Tracking was enabled on multiple hosts. We disabled tracking on hosts such that we have only one tracking host and this resolved our issue. Pretty easy...This is what we always suggest to our customer to have a dedicated tracking host on production systems and especially where we expect high load as there it is expected that lot of tracking data will be generated. Using a dedicated tracking host also allows you to stop other BizTalk hosts without interfering with BizTalk Server tracking.

Configuring a Dedicated Tracking Host: http://msdn.microsoft.com/en-us/library/cc296633.aspx

Also, by default, track events (like Orchestration start and end, Shape start and end) are enabled for Orchestration. We would recommend to disable these events especially the Shape start and end in Production. Mostly we require these data in development stage to troubleshoot Orchestration using Orchestration Debugger and not in production. You can disable it by going to Orchestration properties in BizTalk Admin Console.

Important : If you do not require tracking data at all, better to turn off Global Tracking.

Messages not appearing in the dropdown box of Transform configuration

2008-10-21T17:34:00Z

If we are using Multi-part Message inside Orchestration and we have any part which is of simple type, then we cannot directly access any message part of this Multi-part Message from the transform shape inside Orchestration.

This is a limitation with the Multi-part Message type object. If the Multi-part Message type contains ONLY schema types, then only it can be directly accessed in a transform shape, otherwise we will not be able to access any of the parts from the transform shape. This is common when we try referencing a WSDL that contains both simple and complex type’s message parts, the resulting parts of the Multi-part Message type are not available for selection in the transform configuration of the orchestration.

Let’s say we referred to a WSDL file and the resulting Multi-part Message Type contains parts both simple and schema types. In the below figure, the Multi-part message type contains 2 parts which are simple types (outlined in red) and 1 part which is schema type (outlined in green).

Now, create a message of this Web Message Type.

If we drop a transform shape in the orchestration, we will not see any message in the drop down box. It means that we cannot directly access any part of this Multi-part message from the transform shape.

So now the question is how do we construct this Multi-part Message so that we can call our web-service? Lets figure it out.

The workaround is first create a message in the Orchestration View for the schema type part of multi-part message.

Then, we can now select this message in the transform configuration. Now we can easily construct this part of the multi-part message in the transform shape.

Now, only thing remaining is to construct the Multi-part message. Once we have construct the schema type parts, we can easily construct the Multi-part message using Message Assignment Shape as shown in below figure. Here we have directly assigned values to the simple type parts and assigned the above create schema type message to the schema part of Multi-part message.

So, this is how my orchestration looks like.

Please let me know if you got any comments or questions.

I hope it helps!

BAM SSIS package BAM_DM_ not archiving data

2008-09-23T23:31:22Z

Ever wondered why the BAM SSIS packages for archiving (BAM_DM_<activity_name>) is not archiving the data from BAMPrimaryImport DB to BAMArchive DB though we see that the package executes successfully.

Ok. This may be the reason.

The BAM SSIS packages for archiving (BAM_DM_<ActivityName>) are a two step process. They handle partitioning and archiving. During each run, the activity tables are partitioned, meaning a new set of tables are created in the BAM Primary Import DB for the Completed Instances and Completed Relationships table of that BAM activity. Next the package will check if there are any partition tables where the creation time of the partition table falls out of the online window. We need to check the bam_Metadata_Partitions table which maintains a row for each partition per activity including when the partition was created. Data is moved to Archive DB based on the partition falling outside of the online time window.

In one of a customer scenario, the online window for the activity was set to 90 days and we found out from the bam_Metadata_Partitions table that the oldest partition was around 1 month old only (i.e.the DM SSIS package was run for the first time 1 month before). It means that this partition will be archived once the duration specified for online window completes (i.e. after 2 months from now). If we want to wish to archive the data sooner, only way is to reduce the online window duration using ‘bm.exe set-activitywindow’ command and re-run the SSIS package.

I hope it helps!

KB Article on maintenance of Biztalk databases

2008-09-12T20:14:56Z

Yesterday, KB 952555 got published which talks about how to maintain and troubleshoot Biztalk Server databases. This is a very useful article and must to be followed if you want Biztalk to be in good shape specially if performance is a key factor.

Thank you, Mandi, for writing this wonderful article.

How to join two schemas in a map when they contain namespaces

2008-08-26T21:01:00Z

Problem Statement: I will be receiving two different messages (Message1 and Message2) inside orchestration each with multiple records. Now, I have to join these messages in a map inside orchestration based on TRANID and PROCID. So basically, I have to get the value of TRANID from Message1 and look for the record inside Message2 where value of PROCID matches to value of TRANID and get the value of SUM element and populate it in the output message and this process have to be repeated for every TRAN record of Message1.

Input Message1

Input Message2

Output Message

Solution: There is already a very good solution for this and I found it at this blog <http://geekswithblogs.net/synboogaloo/archive/2005/04/22/37335.aspx>. But only thing is that in my case, input schema contains namespace which complicates the XPATH Query used in XSLT Call Template. Let us figure it out later, how to quickly build XPATH query using namespaces in this scenario.

1) First, create the schema for the three messages.

2) Now create orchestration like below. It will receive these two input messages, constructs the output message using map inside Transform shape and then sends the output to a file location. Since we have to receive two different messages using File adapter and we do not have any unique identifier for correlation purpose, I used BTS.ReceivePortName for correlation. Though, this may not be very practical, I just want to demonstrate joining of two schemas when they have got namespace. But yes, make sure that both the receive locations are in the same Receive Port.

3) In the transform shape, select the msgInput1 and msgInput2 as Inputs and msgOutput as Output. Open the map now.

4) In the map, put a looping functoid as in the figure below. Link TRANID and DESC from input to output. The main thing remaining is to retrieve value of SUM from INPUT2 when TRANID matches to PROCID. Now drop a scripting functoid to the map and connect it to TRANID as Input and SUM as Output. It should look something like below.

5) Now, for the scripting functoid, things would have been something like below if the schema does not have the namespaces. But here, this XPATH query inside the ‘Inline XSLT Call Template’ will give us only blank results.

6) So we need to use the namespaces prefix in out query to get the desired output. Now we need to find out the namespace prefix being used in map for INPUT 2 schema. To find it out, we need to view the XSLT of the map. Therefore, we have to validate the map file first. So, right click the map file and say validate map. Now in the output, we will get a link to the map XSLT. Open this XSL file. Now in this XSL file, we can find the prefix used for the namespace “http:\\Input2” and that is ‘s1’.

7) Now, use the prefix "s1" inside the XPATH Query as below. There could be other ways to use XPATH Query but this was the best I could figure out.

8) Deploy the solution and test it. That’s all.

You can download my Biztalk project and try it. If you got a better solution than this, please let me know. I would really be interested in knowing that.

I hope this post helps!

Simple things causing BIG things

2008-07-24T10:27:00Z

Recently, I was working on an interesting case where we were not able to configure Biztalk Rules Engine in Biztalk Server 2006. All the other components got configured sucesfully but BRE was failing with error "Rule Engine Update Service is not a valid Win32 application" in the event logs. Now, it was getting pretty urgent for customer.

Now, the thing was looking simple with KB 812486 but as the configuration wizard fails, it deletes the
RuleEngineUpdateService and the associated registry as well. So we do not get a chance to modify the image path in the registry.

Next thing we looked for a folder with name 'Program' under the root drive (i.e. C:\) as per KB 812486 and could
not find any such folder . Now, it was after sometime only, that it strike our mind that it could be a file with the name 'Program' and that was it. After removing this file, BRE got configured succesfully.

The question here is how did this file 'Program' got created under root drive. We can't answer this. :)

I hope it helps! (atleast to few) Rest, we are always here :)