Biztalk e dintorni....

WCF-SQL Adapter Hangs in Active State

2014-11-17T06:42:00.000-08:00

Check the Ordered Delivery option. If it is on, the Send port instance will work as a Singleton application. It will be started by first message and lives forever.

Error while inserting NULL value to Oracle database table using BizTalk 2010

2012-05-03T05:53:00.001-07:00

The scenario:
Consume Adapter Service to generate the schema structure. The Schema elements have Nillable = True, Min Occurs =0. error:

When there is no value to a particular element, Microsoft.ServiceModel.Channels.Common.XmlReaderParsingException: The value for field "XXX ELEMENT" is invalid. or Microsoft.ServiceModel.Channels.Common.XmlReaderParsingException: The value for field "XXX ELEMENT" is invalid.System.ArgumentNullException: Value cannot be null. Parameter name: numStr

environment is BizTalk Server 2010 with cu 4 and cu 2 for adapter!

the solution: When make the map for instance the message , for each element NILLABLE add to map the functoid NIL VALUE (in advanced funtoids) and set the input parameter and the output parameter.

With this funtoid, the Oracle Database adapter interprets a null value in a record to mean that the column should be excluded from the Insert/update operation

Adapter Pack 2 Cumulative update

2012-05-03T03:02:00.002-07:00

BizTalk Adapter Pack 2.0Cumulative Update

BizTalk Adapter Pack 2.0 CU5Version: 3.5.5326.0
Release date: January 20, 2012

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2649848 Cumulative update package 5 for BizTalk Adapter Pack 2.0

BizTalk Adapter Pack 2.0 CU4Version: 3.5.5325.0
Release date: November 1, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2604327 Cumulative update package 4 for BizTalk Adapter Pack 2.0

BizTalk Adapter Pack 2.0 CU3Version: 3.5.5324.0
Release date: August 1, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2557150 Cumulative update package 3 for BizTalk Adapter Pack 2.0

BizTalk Adapter Pack 2.0 CU2

Version: 3.5.5320.0
Release date: April 30, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2531605 Cumulative update package 2 for BizTalk Adapter Pack 2.0

BizTalk Adapter Pack 2.0 CU1

Version: 3.5.5314.0
Release date: December 8, 2010

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2444952 Cumulative update package 1 for BizTalk Adapter Pack 2.0

Biztalk 2010 Cumulative Updates for Adapter

2012-05-03T03:01:00.002-07:00

BizTalk Adapter Pack 2010

Cumulative Update

BizTalk Adapter Pack 2010 CU2
Version: 3.5.6537.0
Release date: August 31, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2572999 Cumulative update package 2 for BizTalk Adapter Pack 2010

BizTalk Adapter Pack 2010 CU1

Version: 3.5.6534.0
Release date: May 6, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2539794 Cumulative update package 1 for BizTalk Adapter Pack 2010

Biztalk 2006 updates & SP

2012-05-03T03:00:00.003-07:00

BizTalk Server 2006 R2

Cumulative Update

BizTalk Server 2006 R2 Service Pack 1 CU4

Version: 3.6.2237.12
Release date: March 30, 2012

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2682056 Cumulative update package 4 for BizTalk Server 2006 R2 Service Pack 1

BizTalk Server 2006 R2 Service Pack 1 CU3

Version: 3.6.2224.12
Release date: August 30, 2010

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2286501 Cumulative update package 3 for BizTalk Server 2006 R2 Service Pack 1

BizTalk Server 2006 R2 Service Pack 1 CU2

Version: 3.6.2217.12
Release date: June 24, 2010

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2211420 Cumulative update package 2 for BizTalk Server 2006 R2 Service Pack 1

BizTalk Server 2006 R2 Service Pack 1 CU1

Version: 3.6.2210.12
Release date: April 12, 2010

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

982061 Cumulative update package 1 for BizTalk Server 2006 R2 Service Pack 1

Service Pack

BizTalk Server 2006 R2 SP1

Version: 3.6.2149.10
Release date: January 27, 2010

For more information about the hotfixes that are included in Microsoft BizTalk Server 2006 R2 Service Pack 1, click the following article number to view the article in the Microsoft Knowledge Base:

974563 List of Microsoft BizTalk Server hotfixes that are included in BizTalk Server 2006 R2 Service Pack 1

Biztalk 2009 all cumulative update

2012-05-03T02:59:00.002-07:00

BizTalk Server 2009

Cumulative Update

BizTalk Server 2009 CU6
Version: 3.8.477.2

Release date: April 27, 2012

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2689457 Cumulative update package 6 for BizTalk Server 2009

BizTalk Server 2009 CU5
Version: 3.8.475.2

Release date: January 20, 2012

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2649852 Cumulative update package 5 for BizTalk Server 2009

BizTalk Server 2009 CU4

Version: 3.8.473.2

Release date: November 1, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2604321 Cumulative update package 4 for BizTalk Server 2009

BizTalk Server 2009 CU3

Version: 3.8.469.2

Release date: August 1, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2557149Cumulative update package 3 for BizTalk Server 2009

BizTalk Server 2009 CU2

Version: 3.8.463.2

Release date: March 17, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2497794 Cumulative update package 2 for BizTalk Server 2009

BizTalk Server 2009 CU1

Version: 3.8.454.2
Release date: December 8, 2010

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2429050 Cumulative update package 1 for BizTalk Server 2009

Biztalk 2010 cumulative update 1

2012-05-03T02:58:00.006-07:00

BizTalk Server 2010 CU1

Version: 3.9.522.2
Release date: May 21, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2497789 Cumulative update package 1 for BizTalk Server 2010

Biztalk 2010 cumulative update 2

2012-05-03T02:58:00.003-07:00

BizTalk Server 2010 CU2
Version: 3.9.530.2
Release date: August 31, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2573000 Cumulative update package 2 for BizTalk Server 2010

Biztalk 2010 cumulative update 3

2012-05-03T02:57:00.003-07:00

BizTalk Server 2010 CU3
Version: 3.9.542.2
Release date: November 30, 2011

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2617149 Cumulative update package 3 for BizTalk Server 2010

Biztalk 2010 cumulative update 4

2012-05-03T02:57:00.000-07:00

BizTalk Server 2010

Cumulative Update

BizTalk Server 2010 CU4
Version: 3.9.545.2
Release date: February 28, 2012

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2667310 Cumulative update package 4 for BizTalk Server 2010

BizTalk: Database ‘BizTalkDTADb’ is full

2012-01-12T03:05:00.000-08:00

Error:

The transaction log for database ‘BizTalkDTADb’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases (.Net SqlClient Data Provider)

Solution:

sp_helpdb ‘BizTalkDTADb’

ALTER DATABASE BiztalkDTADb

SET RECOVERY SIMPLE;

DBCC SHRINKFILE (BiztalkDTADb_log, 1);

sp_helpdb ‘BizTalkDTADb’

ALTER DATABASE BiztalkDTADb

SET RECOVERY FULL

BizTalk: Database ‘BizTalkMsgBoxDb’ is full

2012-01-12T03:03:00.001-08:00

Error:

The transaction log for database ‘BizTalkMsgBoxDb’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases (.Net SqlClient Data Provider)

Solution:

sp_helpdb ‘BizTalkMsgBoxDb’

ALTER DATABASE BiztalkMsgBoxDb

SET RECOVERY SIMPLE;

DBCC SHRINKFILE (BiztalkMsgBoxDb_log, 1);

sp_helpdb ‘BizTalkMsgBoxDb’

ALTER DATABASE BiztalkMsgBoxDb

SET RECOVERY FULL

BizTalk Terminator Download & Install Info

2011-11-03T06:00:00.001-07:00

We're very excited to announce that - as of 5/16/2011 - BizTalk Terminator is an official Microsoft tool and is hosted at the Microsoft Download Center!
Go here to download it.

Important info about Terminator:

Terminator ClickOnce Deployment is no longer available now that we have moved to the Microsoft Download Center
Terminator doesn’t care about the Windows version as long as the .NET framework is available
Terminator requires a minimum of .NET 2.0
Just because you’re logged in as a BTS Admin doesn’t mean all Terminator functionality will work for you. You need rights to read from registry on BTS box, make WMI calls, and make certain changes in BTS DBs that a BTS Admin can’t do. If you want to be sure you won’t run into any permissions issues, you may want to also be a local Admin on the BTS box and a SysAdmin within SQL.
Terminator recognizes and has tasks for BTS2004, BTS2006, BTS2006 R2, BTS2009, and BTS2010
Terminator supports and has been tested with SQL2000, SQL2005, SQL2008, and SQL2008 R2
If you try to run a task that uses WMI with Terminator remote to BTS when SQL is also remote to BTS, you’ll run into a double hop issue and get an error like the following: “WMIAccess::workOnInstances: Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.” This is a known issue and is due to WMI limitations and the fact that the BTS WMI namespace will only be installed on the BTS box. So if you plan on using a WMI task, you will need to run Terminator on the BTS box itself when SQL is remote to BTS.
BTS2004 runs on .NET 1.1 and you need a minimum of BTS2004 SP2 to safely install .NET 2.0 on the box so most BTS2004 users run Terminator remotely (as mentioned above, the only caveat is the WMI tab that needs to be run on the BTS box if SQL is remote)
To ensure that someone doesn’t download Terminator and continue to run the same version forever, the tool has a built-in timebomb that will disable the tool and ask the user to download the newer version. If you get the “Terminator is out of date. Please download a newer version” error when trying to run Terminator, simply go download the latest build and you’ll be back up and running. Normally, it’s not such a big deal to make sure you have the latest version of a tool but since Terminator does directly make changes to your BTS databases – potentially production DBs – we do place more stress on using the latest build of the tool.
BE CAREFUL with this tool. If you are unsure about what a task does or if it’s right for your situation, thoroughly read the task documentation displayed when a task is selected. If you’re still unsure, don’t run it – contact MS support.
If you want more info on how/when to use Terminator, take a look athttp://blogs.msdn.com/biztalkcpr/pages/using-biztalk-terminator-to-resolve-issues-identified-by-biztalk-msgboxviewer.aspx

Working with BizTalk Adapter for Oracle Database Binding Properties

2011-11-03T05:57:00.000-07:00

The Microsoft BizTalk Adapter for Oracle Database surfaces several binding properties. By setting these properties, you can control some of the adapter's behavior. This section describes the Oracle Database adapter binding properties. It also shows how you can access them by using .NET programming or by setting properties on a BizTalk Server physical port binding.

Here:
The Adapter Binding Properties

BizTalk Environment Maintenance from a DBA perspective

2011-11-03T03:56:00.000-07:00

from saravana's article:

This is one of the common challenges we see in many enterprises. SQL servers will always be owned by a dedicated database team. The bigger the organisation, the partition between the BizTalk support team and database team will increase. One of the biggest challenges with this setup is, from DBA's perspective they wanted to follow all the best practices, they normally follow as a standard for all the SQL Servers/Databases in the organisation. These may include things like standard backup procedures, indexing procedures, standard recovery model, their own SQL bookkeeping jobs etc.

This situation is a real red alert, BizTalk databases are special databases. A typical BizTalk installation at the minimum will have 4 databases BizTalkMsgBoxDb, BizTalkMgmtDb, BizTalkTrackingDb, SSODB. They are designed to work as a single group. There are certain dependencies between them. Example: Some of the SQL jobs are designed to move data from BizTalk message box to tracking DB, the Tracking subservice will also do similar thing to move data from message box. There are lot of chances for distributed transactions spanning across these databases. So, the general rule of thumb is

"Do not treat your BizTalk databases as your standard database. It's just a black box and you are not allowed to make any changes (there are few exceptions)"

BizTalk server by default comes with all the weapons required to maintain/protect its databases. The product is designed in a way to self maintain. The main challenge here is SQL DBAs are not fully aware of the BizTalk capabilities. In this article we will see some of the routine jobs SQL DBA's must be aware of when maintaining a BizTalk environment related databases.

1.    Know how to use Message Box Viewer/Terminator
2.    One time settings
3.    Make sure SQL Agent is running
4.    Procedures to rebuild indexes for BizTalk databases
5.    Monitor the growth of certain tables
6.    Monitor the size of databases
7.    Monitor transaction log sizes
8.    BizTalk 2010 Monitor BizTalk Server Job

Know how to use Message Box Viewer/Terminator
Message box viewer and Terminator tool are the two tools the DBA's maintaining the BizTalk environment should be completely aware of. MBV is designed to identify all potential problems in the BizTalk environment that could be critical or need attention and present them in a nice report. Most of the BizTalk environment issues will come down to poorly maintained database(s); MBV is extremely good at picking them up. Full Q&A can be found here
http://blogs.technet.com/b/jpierauc/archive/2008/07/22/msgboxviewer-mbv-q-a.aspx

In earlier days people executed MBV, identified the issues and manually corrected the problems. But with latest version of MBV (10.3 and above), MBV produce a cleanup script, which can then be used with another tool called Terminator to fix the database issues either automatically or manually.

http://blogs.msdn.com/b/biztalkcpr/archive/2011/02/10/using-biztalk-terminator-to-resolve-issues-identified-by-biztalk-msgboxviewer.aspx

One time settings
Here are some of the steps you need to perform once the environment is setup.

1. Install the Latest BizTalk Server Service Pack and Cumulative Update

2. Disable the Auto Update Statistics and Auto Create Statistics options

You must disable the Auto Create Statistics and Auto Update Statistics options on theBizTalkMsgBoxDb database. To determine whether these settings are disabled, execute the following stored procedures in SQL Server:
exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'
exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

You should set the CurrentSetting setting to off. If this setting is set to on, turn it off by executing the following stored procedures in SQL Server:

exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'
exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

3. Set the Max Degree of Parallelism property correctly

On the computer that is running SQL Server and hosting the BizTalkMsgBoxDb database, set the Max Degree of Parallelism run_value and config_value properties to a value of 1. To determine the Max Degree of Parallelism setting, execute the following stored procedure against the Master database in SQL Server:

exec sp_configure 'max degree of parallelism'

If the run_value and config_value properties are not set to a value of 1, execute the following stored procedure in SQL Server to set them to 1:

exec sp_configure 'max degree of parallelism', '1'
reconfigure with override

4. Make sure BizTalkMsgBoxDb and BizTalkTrackingDb data and log files are in separate drives, also if possible make sure you don't put BizTalkMsgBox and BizTalkTrackingDb data files or log files in the same drive.

Rebuilding indexes
The only supported method to rebuild an index in the BizTalkMsgBoxDb database is to run thebts_RebuildIndexes stored procedure. On BizTalk Server 2006 and later versions, you can run thedtasp_RebuildIndexes stored procedure to rebuild indexes in the BizTalkDTADb database.

If lots of data is expected to build up in the BizTalkMsgBox database, you can periodically rebuild indexes during scheduled downtime. The same guidelines apply to the tracking database.

You can use the DBCC DBREINDEX SQL command to rebuild an index in the other BizTalk Server databases. For an example of how to use the DBCC DBREINDEX SQL command, right-click thebts_RebuildIndexes stored procedure, and then click Properties.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;917845

Monitor the growth of certain tables Message Box Database (BizTalkMsgBoxDb)
Spool:
If the Spool tables have many records, many messages are currently active, dehydrated, or suspended. Depending on the size, the number of parts, and the fragmentation settings in these tables, a single message may spawn all these tables. Each message has exactly one row in the Spool table and at least one row in the Parts table. Create a benchmark for your BAU activities and make sure the spool table is not growing indefinitely. During you quite period when there are no BAU activities if you notice a large number of rows in this table, make sure unwanted suspended instance are cleared periodically. You can also use Message Box Viewer regularly to check if there are any unusual numbers of rows in the table and can use Terminator tool to safely remove them.

TrackingData_0_x and TrackingData_1_x TrackingData_0_x: These four tables store the Business Activity Monitoring (BAM) tracked events in the BizTalkMsgBoxDb database for TDDS to move the events to the BAMPrimaryImport database.
TrackingData_1_x: These four tables store the tracked events in the BizTalkMsgBoxDb database for TDDS to move the events to the BizTalkDTADb database.

You make sure there is at least one host configured with tracking enabled. This will run TDDS subservice responsible for moving the data from message box db to BizTalkDTADb and BAMPrimaryImport

BizTalk Tracking Database (BizTalkDTADb) dta_DebugTrace table typically becomes large in environments where orchestration shapes start/end is enabled. If there is no business value and if you got lots of orchestration in your solution, it's better to clear the check box for ?Shape start and end? option in the orchestration(s) properties.

dta_MessageInOutEvents table typically becomes large in environments where ?Message send and receive? is enabled for orchestrations and/or pipelines. If these tracking events are not required, clear the check box for this option in the orchestration and/or pipeline properties.

If the dta_DebugTrace table and/or the dta_messageInOutEvents table in the BizTalkDTADb database are too large, you can truncate the tables manually after you stop the tracking host. The BizTalk Terminator tool also provides this functionality.

dta_ServiceInstanceExceptions table typically becomes large in an environment that regularly has suspended instances. dta_serviceinstances table grows every time the user terminates an instance. DTA Purge and Archive SQL Server jobs should take care of clearing this table, so make sure the jobs are running correctly.

BAMPrimaryImport
TDDS_FailedTrackingData The TDDS_FailedTrackingData table gets populated whenever there is a tracking failure or even in cases where you haven't deployed your BAM activities, but your solution is trying to insert BAM data. In earlier version of BizTalk (2006 and 2006 R2) the DTA Purge and Archive SQL Server jobs didn't clear this table periodically which resulted in unlimited growth of this table. Make sure you got the hot fix explained here http://support.microsoft.com/kb/977289

Monitor the size of databases The size of the databases will vary from organisation to organisation depending on the volume of data processing. In any organisation having a bloated/large database will adversely effects the performance of your BizTalk environment. As a general rule of thumb, you can use the following numbers for guidance

BizTalkMsgboxDb: Not more than 5GB. However big your deployment is, your message box database should NOT go beyond this limit. In theory Message Box database only should hold transit data (aka inflight messages). On a healthy environment all the processed message will either be moved to BizTalk tracking database or BAM database. Having lot of suspended instances will also bloat the size of the message box database, so periodically clear them out or better design your solution in a way you are not going to have too many suspended instances (unless otherwise there is a genuine unhanded exception scenario).

BizTalkDTADb, BAMPrimaryImportDB: Around 10 GB max. This is again a finger in the air estimate. It's better to keep the tracking data and BAM data within this limit. You can control this by setting the appropriate values for your DTA purging/archiving job and making sure you are moving your BAM data from BAMPrimaryImport table to BAMArchieve database. Also make sure yourBAMArchive database is not bloated over a period of time. Do a hard purge after a set period like 3 or 6 months based on your business requirement.

The other databases like BizTalkMgmtDb, SSO, RulesEngine etc all store configuration data and they should be any bigger than 2GB.

Monitor transaction log sizes The size of the BizTalk databases transaction log is controlled by the BizTalk backup job. By default the recovery model for the BizTalk databases is set to Full. If the transaction log is not backed up or truncated on a regular basis, the log files or files can fill up. So, please make sure BizTalk backup job is configured and running successfully. This job automatically backup the BizTalk databases including transaction log, and thus ensures the transaction log does not grow to an unmanageable size. The backup job should also be performed multiple times during the day as it's the job that lets you recover your messages. The bigger the log file the more messages that could be lost.

It is not recommended to change the recovery model settings of the BizTalk databases. Changing this setting will put the BizTalk environment into a state where it may not be fully recoverable in the event of failure.

Not but the not the least the Backup BizTalk Server job is the only supported method to back up the BizTalk Server databases.

BizTalk 2010 Monitor BizTalk Server Job If you are using BizTalk Server 2010, you can run the Monitor BizTalk Server SQL Agent job to identify any known issues in Management, Message Box, or DTA databases. The job is created when you configure a BizTalk group in BizTalk Server Administration console or upgrade BizTalk from the previous version.

The Monitor BizTalk Server job scans for the following issues in Management, Message Box, and DTA databases:

Messages without any references
Messages without reference counts
Messages with reference count less than 0
Message references without spool rows
Message references without instances
Instance state without instances
Instance subscriptions without corresponding instances
Orphaned DTA service instances
Orphaned DTA service instance exceptions
TDDS is not running on any host instance when global tracking option is enabled.

The Monitor BizTalk Server job is configured and automated to run once in a week. Since the job is computationally intensive, it's recommended you to schedule it during downtime/low traffic.

The job fails if it encounters any issues; error string contains the number of issues found. Else, it runs successfully. You can see the details in the job history. If you run the job with Administrator privileges, error string will be logged to Event Viewer also (along with the job history).

Ad-hoc Full backup It may be required once in a while to force a full database backup. TheBizTalkMgmtDb.dbo.sp_ForceFullBackup stored procedure can be used to force a full backup of the data and log files. Execute this stored procedure, and then execute the Backup BizTalk Server SQL Agent job.

Cleanup all the data in test environment DO NOT do this in PRODUCTION
When you are managing test environment (especially performance testing) it may be required to clean up BizTalkMsgBoxDb and BizTalkDTADb. When I say clean up, completely wipe out all the data, hence the bold warning.

BizTalkMsgboxDb
1.    Copy the Msgbox_cleanup_logic.sql script from Drive:\Program Files\Microsoft BizTalk 200x\schemato the SQL Server.
2.    Execute this SQL script against the BizTalkMsgBoxDb database to update the bts_CleanupMsgboxstored procedure.
3.    Stop all BizTalk hosts, services, and custom isolated adapters. If you use HTTP or the SOAP adapter, restart the IIS services.
4.    Execute the bts_CleanupMsgbox stored procedure on all the BizTalkMsgBoxDb databases.
5.    Restart all host instances and BizTalk Server services.

BizTalkDTADb
1. Back up all BizTalk databases.
2. Execute the dtasp_CleanHMData stored procedure. Only use this option if the BizTalkDTADbdatabase contains many incomplete instances that must be removed.

To do this, follow these steps:
a.    Stop all BizTalk hosts, services, and custom isolated adapters. If you use HTTP or the SOAP adapter, restart the IIS services.
b.    Execute the dtasp_CleanHMData stored procedure on the BizTalkDTADb database.
c.    Restart all hosts and BizTalk Server services.

*** HR originated: -2147024774 in Debug View

2011-11-02T01:54:00.000-07:00

If any of you use Debug View you may have noticed some random output such as:

[7160]
[7160] *** HR originated: -2147024774
[7160] *** Source File: d:\iso_whid\x86fre\base\isolation\com\copyout.cpp, line 1302
[7160]
[7160]
[7160] *** HR propagated: -2147024774
[7160] *** Source File: d:\iso_whid\x86fre\base\isolation\com\enumidentityattribute.cpp, line 144
[7160]
[7160]
[7160] *** HR originated: -2147024774
[7160] *** Source File: d:\iso_whid\x86fre\base\isolation\com\copyout.cpp, line 1302
[7160]
[7160]
[7160] *** HR propagated: -2147024774
[7160] *** Source File: d:\iso_whid\x86fre\base\isolation\com\enumidentityattribute.cpp, line 144
[7160]
[7160]
.... etc....

The current 'workaround' is to just add a filter to ignore its output. If you use Debug View a lot like I do then hit Ctrl + L and paste the following into the exclude list:

* HR*; *d:\iso_whid*

Could not start the IIS Admin Service on Local Computer

2011-11-02T01:20:00.000-07:00

When I try to start the IIS Admin Service from services.msc I receive the following error:

Could not start the IIS Admin Service on Local Computer
Error2: The system cannot find the file specified.

At the same time I can also see the following message in the System event log:

Error: The IIS Admin service terminated with the following error. The system cannot find the file specified

Source Name: Service Control Manager

Event ID: 7023

This error usually occurs when the MetaBase.xml file is either missing or has been corrupted. MetaBase.xml is the file wherein the IIS 6 configurations are written to and read from.

The default location for MetaBase.xml is C:\WINDOWS\system32\inetsrv\ . The default location for MetaBase.xml file back up is C:\WINDOWS\system32\inetsrv\History\

To solve this problem you can either restore the copy of the MetaBase.xml file (If you have a separate backup) or grab a copy from the History folder and place it in the C:\WINDOWS\system32\inetsrv\ folder. After which rename it to MetaBase.xml. Rename it to MetaBase.xml? Yeah! That's because in the History folder you will find the backup in the form MetaBase_0000000244_0000000000.xml . Subsequently, you will also find backups of the MBSchema.xml in the same format.

The MetaBase.xml file is backed up whenever you make any configurational changes to websites, application pools or any IIS related settings. By default, C:\WINDOWS\system32\inetsrv\History\ contains 10 most recent backups. However, this property itself can be changed from MetaBase.xml. Here's how to do it,

Open up Metabase.xml file in your favorite text editor. Now look for the section that says IIsComputer. In this section you will find an entry which says, "MaxHistoryFiles". By default, the value of this property is set to 10. You can change that value to whatever you want. Save the changes and start the IIS Admin Service.

All said, this is not the recommended way of changing the MetaBase.xml file :) Do not change the Metabase.xml file directly until you are very certain of what you are doing. But, if not this way then how? Very simple, just run the following command from the command prompt:

cscript.exe adsutil.vbs set /MaxHistoryFiles "12"

As you can notice I am changing the value of the maximum history file to 12. You can place any number there that you want. Now here's something interesting! There may be cases where in you will open the MetaBase.xml file after running the above command and do not see your change reflected. The changes only reflected after you restart the IIS Admin Service. Well that's because you do not have Enable Direct MetaBase Edit check box selected in the IIS properties. To see the changes take effect instantaneously run this command from the command prompt:

cscript.exe adsutil.vbs set /EnableEditWhileRunning "1"

Note: Sometimes after you restart the IIS admin service, the websites are in stopped state and you will have to start them manually to get going.

Update 21/08/2008: I wouldn't want you to enable Direct Metabase Edit for this scenario, as I figured out that when you use Adsutil.vbs the changes are made into the IN-MEMORY metabase.They will be reflected instantaneously in your environment and will then be written to the physical Metabase.xml after 2 mins.

Now you are all set to reflect changes as soon as they are made. However never do this on a production box. This was shown for instructional purposes so that we move along quickly. :) To de-select the Enable Direct MetaBase Edit check box run this command

cscript.exe adsutil.vbs set /EnableEditWhileRunning "0"

Problem solved and we also know a little about MetaBase.xml file now.

Microsoft BizTalk 2010: Line of Business Systems Integration (book)

2011-10-04T00:43:00.000-07:00

Microsoft BizTalk 2010: Line of Business Systems Integration

on amazon

Microsoft BizTalk Server 2010 Unleashed (book)

2011-10-04T00:38:00.000-07:00

Microsoft BizTalk Server 2010 Unleashed

on amazon

What's New in BizTalk Server 2010 Training Kit

2011-10-04T00:33:00.000-07:00

Overview

The What's New in BizTalk Server 2010 training kit includes labs and training videos to help you learn about the new features of BizTalk Server 2010.

This training kit contains the following content:
Hands On Labs

Creating BizTalk Maps with the new Mapper
Consuming a WCF Service
Publishing Schemas and Orchestrations as WCF Services
Integrating with Microsoft SQL Server
Integrating using the FTP Adapter
Developers - Create a Role and Party-based Integration Solution
Exploring the New Settings Dashboard
Monitoring BizTalk Operations using System Center Operations Manager 2007 R2
Administrators - Create a Role and Party-based Integration Solution

Presentations and Videos

Introduction and New Features Overview
The New and Improved Mapper
Updated Adapter Features
Trading Partner Management
Configuring Performance and Application Settings
Monitoring BizTalk Using Operations Manager

File NameSizeBizTalk2010Labs.zip 8.0 MBDOWNLOAD

BizTalk2010LabsVideos.zip 822.0 MBDOWNLOAD

BizTalk Server 2010 Documentation

2011-09-29T00:29:00.000-07:00

Download the documentation for BizTalk Server 2010:

http://www.microsoft.com/download/en/details.aspx?id=11503

Overview
To get started with BizTalk Server 2010, download one or more of the following:

Readme.htm

Installation guide:

Installing BizTalk Server 2010 on Windows 7 and Windows Vista.docx

Installing BizTalk Server 2010 on Windows Server 2008 R2 and 2008.docx

Installing BizTalk Server 2010 and BAM in a Multi-Computer Environment.docx

KWUserGuide.exe

Upgrade guide:

Upgrading to BizTalk Server 2010 from BizTalk Server 2009 or 2006 R2.docx

PartyMigrationTool.exe

Setup troubleshooting guide (Troubleshooting BizTalk Server 2010 Setup.docx)

For updated and new Help content for BizTalk Server 2010, download one of the following:

If you don't have BizTalk Server 2010 installed, download BizTalkServer2010CHM.exe.

If you do have BizTalk Server 2010 installed and want to update the existing Help, download BizTalkServer2010HXS.exe. See the Instructions section for additional information.

System requirements

Supported Operating Systems: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

For CHM files: No special software required.

For DOCX files: Microsoft Word or Word Viewer.

For HTM files: Microsoft Internet Explorer or other HTM viewer.

For HXS files: Microsoft BizTalk Server 2010.

Instructions

To start the download, click the Download button next to the desired file.

Do one of the following:

To start the installation immediately, click Open.

To copy the download to your computer for installation at a later time, click Save.

To cancel the installation, click Cancel.

If you are unable to view the CHM file when you click Open, try the download again but select Save and choose where you want to save the file. Then use one of the following methods to open the CHM:

Method 1
1. Double-click the .chm file.
2. In the Open File-Security Warning dialog box, click to clear the Always ask before opening this file check box.
3. Click Open.

Method 2
1. Right–click the .chm file, and then click Properties.
2. Click Unblock.
3. Double-click the .chm file to open the file.

For the HxS file (available in the BizTalkServer2010HXS.exe):

Close the BizTalk Server documentation if you have it open.

Download and run the BizTalkServer2010HXS.exe file.

Click Unzip to unzip the documentation files to the C:\Program Files\Microsoft BizTalk Server 2010\Documentation folder. If you have installed BizTalk Server in a different folder, specify the installation location before you click Unzip. The contents of the download must be placed directly in the folder Microsoft BizTalk Server 2010\Documentation.

Open BizTalk Server Help to view the updated documentation.

Book of Biztalk 2010

2011-09-29T00:26:00.000-07:00

This are book:

Applied Architecture Patterns on the Microsoft Platform

BizTalk Server 2010 Unleashed

Microsoft BizTalk 2010: Line of Business Systems Integration

FTP Receive Adapter fails to publish message if the receive pipeline processing time exceeds the server timeout value

2011-09-23T02:45:00.003-07:00

Problem

Pipeline processing is performed on all messages that are received by the FTP Adapter. If the time taken to complete pipeline processing for messages received by the FTP connection times out then the message will not be published to the Messagebox and errors similar to the following may be generated in the Application log of the BizTalk server:

other

Event Type:Error
Event Source:BizTalk Server 2006
Event Category:BizTalk Server 2006 
Event ID:5719
Date:8/30/2006
Time:12:08:55 PM
User:N/A
Computer:BIZTALKSERVER
Description:
There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.PassThruReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "Pipeline " Receive Port: "ReceivePort1" URI: "ftp://FTPSERVER:21/*.txt" Reason: Unable to receive the file "file.txt   " from the FTP server.

and

other

Event Type:Warning
Event Source:BizTalk Server 2006
Event Category:BizTalk Server 2006 
Event ID:5740
Date:8/30/2006
Time:12:08:56 PM
User:N/A
Computer:BIZTALKSERVER
Description:
The adapter "FTP" raised an error message. Details "Unable to receive the file "file.txt   " from the FTP server. ".

Cause

The FTP Adapter attempts to delete the original copy of the message on the source FTP Server before it publishes the message to the Messagebox. If the connection has timed out then the FTP Adapter cannot delete the copy of the message on the source FTP Server.

Resolution

Use one of the following methods to mitigate this problem:

Increase the connection timeout value. Set the Idle timeout value on the FTP server to be at least the amount of the time it takes to process the file.
Use the Temporary Folder feature on the receive location. In this case, the FTP adapter copies the file to the temporary folder (typically local disk). The time to copy the file to local disk is less than the time it takes run the message through pipeline and persist it to the message box which effectively reduces the idle time.

Data may be duplicated or lost when you receive data in BizTalk Server 2006 by using the FTP adapter

2011-09-23T02:45:00.001-07:00

Problem

Data is duplicated or lost when you receive data in BizTalk Server 2006 by using the FTP Adapter.

Cause

The BizTalk Server 2006 FTP adapter uses the FTP client protocol to poll the designated FTP server and retrieves data from the server "as is." The FTP adapter does not validate any data that it retrieves. The FTP adapter sends the retrieved document to the BizTalk Messaging Engine for processing and then it deletes the original document from the FTP server. If the FTP adapter retrieves a document from the FTP server that is still being written to by the host application, the retrieved document will be incomplete. If the FTP adapter retrieves an incomplete copy of the original document, data duplication or data loss may occur in the following scenarios:

If the original document is still being written to the FTP server by the host application, the FTP adapter cannot delete the document and will retrieve another copy of the document at the next polling interval that is configured for the receive location. This behavior causes document duplication to occur.
If the host application has finished writing the document to the FTP server, the document will be deleted. This behavior will cause data loss to occur.

Resolution

To work around this behavior, use one of the following methods:

Configure the host application to write to a temporary folder on the same hard disk as the public FTP folder and to periodically move the contents of the temporary folder to the FTP folder. The temporary folder should be on the same hard disk as the public FTP folder to make sure that the move operation is atomic. An atomic operation is an operation that is functionally indivisible. If you write data to the public FTP folder by using the BizTalk Server 2006 FTP adapter, you can do this by specifying a Temporary Folder property in the FTP Transport Properties dialog box when you configure a send port. If you specify a Temporary Folder property, make sure that this folder is on the same physical disk as the public FTP folder.
Configure the FTP receive location to operate within a service window when the host application is not writing data to the FTP server. You can specify the service window when you configure the receive location properties.

FIX: A file is not removed from an FTP location when you use BizTalk Server 2006 R2

2011-09-23T02:40:00.001-07:00

Consider the following scenario in Microsoft BizTalk Server 2006 R2 or BizTalk Server 2009:

You retrieve a file from a subfolder at an FTP location by using an FTP receive location.
While BizTalk Server 2006 R2 is processing this file, the FTP connection times out.
After some time, BizTalk Server 2006 R2 opens a new FTP session, and then issues a DELE command.

In this scenario, BizTalk Server 2006 R2 cannot delete the received file from the subfolder at the FTP location. Additionally, the new FTP session is closed, and you can see log entries in the BizTalk Server 2006 R2 FTP log that resemble the following:

< 220 Microsoft FTP Service
> USER anonymous
< 331 Anonymous access allowed, send identity (e-mail name) as password.
> PASS xxxx
< 230 Anonymous user logged in.
> PWD
< 257 "/" is current directory.
> DELE file_name
< 550 file_name: The system cannot find the file specified.
> QUIT
< 221

When the BizTalk Server 2006 R2 or BizTalk Server 2009 next polls the FTP location, BizTalk Server 2006 R2 or BizTalk Server 2009 opens the FTP location and downloads the same file again.

CAUSE:
This problem occurs because BizTalk Server 2006 R2 or BizTalk Server 2009 does not issue a CWD command before it issues the DELE command. Therefore, instead of trying to delete the file from the configured subfolder, BizTalk Server 2006 R2 or BizTalk Server 2009 tries to delete the file from the FTP root directory.

HOTFIX:
The hotfix that resolves this problem is included in cumulative update package 1 for BizTalk Server 2006 R2 SP1.