Microsoft Support

Page 41 of 939« First...102030...3940414243...506070...Last »

PRB: Error 1722 or 2744 Occur During the Installation of BizTalk Server

oneMscomBlade,oneMsomNav,oneMscomFooter,

Taken from:
PRB: Error 1722 or 2744 Occur During the Installation of BizTalk Server

FIX: Binding configurations for some binding types are not saved in the WCF-Custom adapter or in the WCF-CustomIsolated adapter in BizTalk Server Administration Console

Consider the following scenario in Microsoft BizTalk Server:

  • You configure a receive location or a send port to use the
    “WCF-Custom” transport type or the “WCF-CustomIsolated” transport type in BizTalk Server
    Administration Console.
  • In Binding configuration, you change one of the following
    binding types:

    • mexHttpBinding
    • mexHttpsBinding
    • mexNamedPipeBinding
    • mexTcpBinding
    • ws2007FederationHttpBinding
    • ws2007HttpBinding

In this scenario, the change that you made for the binding types are not saved in the Transport
Properties window. Additionally, if you reopen the
Transport Properties window, the binding configuration for the binding type
that you tried to change is reset to the original value.

Note The WCF-CustomIsolated adapter is used for a receive location
that is running in an isolated host. The WCF-Custom adapter is used for both receive
locations and send ports to connect to Windows Communication Foundation (WCF)
services. For more information about how to configure these adapters, see the More Information
section.

Cumulative updated information

For BizTalk Server 2009, the hotfix that resolves this issue is included in Cumulative Update 1 for BizTalk Server 2009.

For more information about how to obtain the cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:

2429050

(http://support.microsoft.com/kb/2429050/
)

Cumulative update package 1 for BizTalk Server 2009

Hotfix information

A
supported hotfix is available from Microsoft. However, this hotfix is intended
to correct only the problem that is described in this article. Apply this
hotfix only to systems that are experiencing this specific problem.

If the hotfix is available for download, there is a “Hotfix download
available” section at the top of this Knowledge Base article. If this section
does not appear, submit a request to Microsoft Customer Service and Support to
obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required,
you might have to create a separate service request. The usual support costs
will apply to additional support questions and issues that do not qualify for
this specific hotfix. For a complete list of Microsoft Customer Service and
Support telephone numbers or to create a separate service request, visit the
following Microsoft Web site:

Note The “Hotfix download available” form displays the languages for
which the hotfix is available. If you do not see your language, it is because a
hotfix is not available for that language.

Prerequisites

You must have Microsoft BizTalk Server 2006 R2 installed to apply
this hotfix.

Restart requirement

You do
not have to restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released
hotfix.

File information

The English version of this hotfix has the file
attributes (or later file attributes) that are listed in the following table.
The dates and times for these files are listed in Coordinated Universal Time
(UTC). When you view the file information, it is converted to local time. To
find the difference between UTC and local time, use the Time
Zone
tab in the Date and Time item in Control
Panel.

Collapse this tableExpand this table

File name File version File
size
Date Time Platform
Microsoft.biztalk.adapter.wcf.common.dll 3.6.1517.2 374,664 06-Apr-2009 15:33 x86

Note Because of file dependencies, the most recent hotfix that
contains these files may also contain additional files.

Microsoft
has confirmed that this is a problem in the Microsoft products that are listed
in the “Applies to” section.
For more information about Configuring the WCF-Custom
adapter, visit the following Microsoft MSDN Web site:
http://msdn.microsoft.com/en-us/library/bb226520.aspx

(http://msdn.microsoft.com/en-us/library/bb226520.aspx)

For
more information about Configuring the WCF-CustomIsolated adapter, visit the
following Microsoft MSDN Web site:
http://msdn.microsoft.com/en-us/library/bb246042.aspx

(http://msdn.microsoft.com/en-us/library/bb246042.aspx)

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
824684

(http://support.microsoft.com/kb/824684/
)

 Description of the standard terminology that is used to describe Microsoft software updates

Article ID: 967036 – Last Review: January 15, 2015 – Revision: 3.0


Applies to
  • Microsoft BizTalk Server 2006 R2 Standard Edition
  • Microsoft BizTalk Server 2006 R2 Enterprise Edition
  • Microsoft BizTalk Server 2006 R2 Developer Edition
  • Microsoft BizTalk Server 2006 R2 Branch Edition
  • Microsoft BizTalk Server 2009 Branch
  • Microsoft BizTalk Server 2009 Developer
  • Microsoft BizTalk Server 2009 Enterprise
  • Microsoft BizTalk Server 2009 Standard
kbnosurvey kbarchive kbbiztalk2006r2sp1fix kbbtsadapters kbautohotfix kbexpertiseinter kbfix kbhotfixserver kbqfe kbbiztalk2009presp1fix KB967036

Continued here:
FIX: Binding configurations for some binding types are not saved in the WCF-Custom adapter or in the WCF-CustomIsolated adapter in BizTalk Server Administration Console

How to Debug a Windows Scripting Component That Is Called from an XLANG Schedule

You can use Microsoft BizTalk Server Orchestration Designer to implement schedule ports by using Microsoft Windows Scripting Component (.wsc) components. This
article describes how to step through the .wsc script code in a debugger after an XLANG schedule that is running has called the script.

To break into a
scripting component that has been called from an XLANG schedule, follow these steps:

  1. Enable Microsoft Script Debugger just-in-time (JIT) debugging.

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

    269827

    (http://support.microsoft.com/kb/269827/
    )

    PRB: VBScript ‘STOP’ Statement in .wsc Components Does Not Start Script Debugger When Called from ASP

  2. Paste the following line of code at the top of your component code,
    just before the registration tag.

  3. Put STOP statements in your code where you want the debugger to
    break in.
  4. Install Microsoft Script Debugger.

    The following file is available for download from the Microsoft Download Center:

    Collapse this imageExpand this image

    Download the Microsoft Script Debugger package now.

    (http://download.microsoft.com/download/7/7/d/77d8df05-6fbc-4718-a319-be14317a6811/scd10en.exe)

    For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:

    119591

    (http://support.microsoft.com/kb/119591/
    )

    How to Obtain Microsoft Support Files from Online Services

    Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.

  5. Verify that the application identity of the XLANG Scheduler COM+ application is set to Interactive User or to the specific account that you will
    use to log on when you start your debugging session.
  6. Stop the XLANG Scheduler COM+ application before
    you try to debug your scripting component. You may have to repeat this step every time that you want to start a debugging
    session.
  7. You must be logged on to the BizTalk Server
    console directly to start a debugging session. If you are connected to the BizTalk
    Server through a Terminal Server session, the debugger will break into the
    script code at the STOP statement. However, the prompt to start the debugger will
    only be visible on the BizTalk Server console.

    If BizTalk Server is installed
    on a computer that is running Microsoft Windows XP or Windows Server 2003, you can start a Terminal Server
    session to the computer that is running BizTalk Server by using the optional /console switch (mstsc.exe /console) to gain access to the BizTalk Server console.

Article ID: 830480 – Last Review: January 15, 2015 – Revision: 4.0


Applies to
  • Microsoft BizTalk Server 2002 Standard Edition
  • Microsoft BizTalk Server 2000 Standard Edition
kbnosurvey kbarchive kbdownload kbhowto KB830480

More:
How to Debug a Windows Scripting Component That Is Called from an XLANG Schedule

BUG: A new record that is added to a parent DataGrid control does not populate the foreign key column in the child DataGrid control

In your Windows application Windows Form, you have added two
DataGrid controls that have the Parent-Child relationship between them.
After you add a new record in the parent DataGrid, and then you click the child DataGrid to populate the foreign key column, the column value is not
displayed in the child DataGrid. The new record is displayed in the child DataGrid only after you click a different row in the parent DataGrid, and then you click the child DataGrid.
The problem occurs because the newly added record of the
parent DataGrid is not added to the Dataset.

The relationship between the parent table and the
child table is defined in the Dataset. Therefore, the foreign key column is not populated to the child DataGrid. When you click any other parent DataGrid record, and then click the child DataGrid, the new record is added to the DataSet, and the record is displayed in the child DataGrid.

To resolve this problem, call the Refresh method of the Currency Manager for the DataSet before you click the child DataGrid. You can call the Refresh method in the RowChange event of the parent table.

To do this, follow these
steps:

  1. Add the following code to add the event handler for the RowChange event in the Form_Load function.

    Visual Basic .NET Code

       ' Event handler for RowChange event
       AddHandler DataSetName.Tables("TableName").RowChanged, New DataRowChangeEventHandler(AddressOf Row_Changed)

    Visual C# .NET Code

       // Event handler for RowChange event
       objds.Tables"authors".RowChanged += new System.Data.DataRowChangeEventHandler(Row_Changed);

  2. Add the following code for the RowChange event to refresh the Currency Manager:

    Visual Basic .NET Code

       Private Sub Row_Changed(ByVal sender As Object, ByVal e As DataRowChangeEventArgs)
          ' Get the Currency Manager
          Dim myCurrencyManager As CurrencyManager = CType(Me.BindingContext(objds, "authors"), CurrencyManager)
          ' Refresh the Currency Manager
          myCurrencyManager.Refresh()
       End Sub

    Visual C# .NET Code

          private void Row_Changed( object sender, System.Data.DataRowChangeEventArgs e )
    
             // Get the Currency Manager
             CurrencyManager myCurrencyManager = (CurrencyManager)this.BindingContextobjds, "authors";
             // Refresh the Currency Manager
             myCurrencyManager.Refresh();
          

Microsoft has confirmed that this is a bug in the Microsoft products that are
listed at the beginning of this article.
For more information, visit the following MSDN Web sites:

Article ID: 816227 – Last Review: January 14, 2015 – Revision: 2.0


Applies to
  • Microsoft ADO.NET 1.1
  • Microsoft Visual Basic .NET 2002 Standard Edition
  • Microsoft Visual Basic .NET 2003 Standard Edition
  • Microsoft Visual C# .NET 2002 Standard Edition
  • Microsoft Visual C# .NET 2003 Standard Edition
kbnosurvey kbarchive kbvs2002sp1sweep kbdisplay kbctrl kbcontrol kbwindowsforms kbtable kbdesigner kbdatabinding kbdatabase KB816227

See the original article here:
BUG: A new record that is added to a parent DataGrid control does not populate the foreign key column in the child DataGrid control

EWS throttling occurs after a migration of Office 365 Dedicated/ITAR to Exchange Server 2013

After you migrate user accounts to a Microsoft Office 365 dedicated/ITAR instance that’s running Microsoft Exchange Server 2013, you notice performance problems for high-volume Exchange Web Services (EWS) applications. The specific symptoms may include, but are not limited to, the following:
  • Application time-outs that are caused by an EWS throttling delay
  • Denied connections that are caused by EWS concurrent connection throttling
  • “500″ or “503″ HTTP errors
This issue occurs because of one or more of the following reasons:  
  • A fundamental architecture change in Exchange Server 2013 causes the EWS throttling budget to be calculated based on the back-end (Mailbox) servers instead of on the Client Access server (as it is done in Exchange Server 2010).
  • When you use a service account to access various mailboxes, the connections are routed to the back-end server that hosts the target mailbox. However, the default connection-routing path is made to the back-end server that hosts the service account mailbox. Therefore, the EWS throttling budget is calculated based on the back-end server that hosts the service account mailbox, regardless of which back-end server hosts the target mailbox.
To resolve this issue, use one of the following methods. You can try both solutions to determine which method works best in your specific situation. 

Method 1

Force the Exchange front-end server to route the EWS connections to the back-end server that hosts the target mailbox. To do this, implement the X-AnchorMailbox HTTP header and its value in your EWS calls. The value of the header is defined as the SMTP address of the target mailbox that’s accessed.

In the EWS-managed API, use the Add method of the HTTPHeaders object to add an HTTP header to your EWS call, as in the following example:

service.HttpHeaders.Add("X-AnchorMailbox", targetSmtp);

Method 2

Change the Exchange object type that’s associated with the service account. If the object is changed from a mailbox-enabled object to a mail user object, all EWS connections are routed to the back-end server that hosts the target mailbox.

For more information about the X-AnchorMailbox header, see the following articles:

Article ID: 2990048 – Last Review: January 14, 2015 – Revision: 3.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal

See the article here:
EWS throttling occurs after a migration of Office 365 Dedicated/ITAR to Exchange Server 2013

BUG: Cookie-less session-state requests are broken when you install multiple versions of the .NET Framework on your computer and then you remove the .NET Framework 1.0

This article describes the problem that occurs when you have multiple versions of the Microsoft .NET Framework installed on your computer and when removal of the earlier version causes cookie-less session-state requests to break.

When you install multiple versions of the Microsoft .NET
Framework on your computer and then you remove the .NET Framework 1.0,
cookie-less session-state requests are broken.
When you remove the .NET Framework 1.0, the version of
Microsoft ASP.NET that is associated with the ASP.NET Internet Information
Services (IIS) Registration Tool (Aspnet_regiis.exe) is removed from your
computer. This action removes all the filters and removes all the mappings to the latest remaining ASP.NET Internet Server API (ISAPI) version
that is installed on your computer. This action also sets the wrong name for the w3svc/filters/FilterLoadOrder attribute and IIS cannot load the filter.
To resolve this problem, manually add the Microsoft .NET
Framework 1.1 filter in IIS. To do this, follow these steps:

Open IIS

  1. Click Start, point to
    Settings, and then click Control
    Panel
    .
  2. Click Administrative Tools, and then
    double-click Internet Service Manager. Internet
    Information Services
    opens.
  3. Double-click your ComputerName
    under Internet Information Services.

    NoteComputerName is a
    placeholder for the name of your computer.

Set the .NET Framework 1.1 filter in IIS

  1. In IIS, click Default Web Site.
  2. On the Action menu, click
    Properties. The Default Web Site Properties
    dialog box appears.
  3. Click the ISAPI filters tab.
  4. Click Add. The Filter
    Properties
    dialog box appears.
  5. Type .aspx in the Filter
    Name
    box.
  6. Click Browse.
  7. Locate the Aspnet_filter.dll file. By default, the
    Aspnet_filter.dll file is located in the
    C:WinntMicrosoft
    .NETFrameworkv1.14322
    folder.

    NoteWinnt is a placeholder for
    the Microsoft Windows folder on your computer.

Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the “Applies to” section.
For more information, visit the following Microsoft
Developer Network (MSDN) Web sites:

Article ID: 834488 – Last Review: January 14, 2015 – Revision: 2.0


Applies to
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
kbnosurvey kbarchive kbpending kbwebserver kbcookie kbbug KB834488

See more here:
BUG: Cookie-less session-state requests are broken when you install multiple versions of the .NET Framework on your computer and then you remove the .NET Framework 1.0

BizTalk Server uses the <prop:identity> element instead of the <rcpt:identity> element for receipts

BizTalk Server is not compliant with the BizTalk
Framework. The BizTalk Framework 2.0: Document and Message Specification states
that the //deliveryReceipt/identity element belongs to the
http://schemas.biztalk.org/btf-2-0/receipts namespace. However, the //deliveryReceipt/identity element declares the
http://schemas.biztalk.org/btf-2-0/properties namespace.

If you send
messages in a BizTalk Framework envelope to BizTalk Server and you request a
delivery receipt, the delivery receipt does not comply with the BizTalk
Framework specification. For example, the following line is listed in the delivery
receipt:

uuid:31C24EF4-EF6C-4DAE-8CE0-ACDE53AAEFC6

This line should be:

uuid:31C24EF4-EF6C-4DAE-8CE0-ACDE53AAEFC6

This problem occurs because the code does not use the
element. Instead, the code uses
element.

Service pack information

To resolve this problem, obtain the latest service pack for Microsoft BizTalk Server 2002. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

815781

(http://support.microsoft.com/kb/815781/
)

How to obtain the latest BizTalk Server 2002 service pack

Hotfix information

For compatibility between service pack levels and versions of BizTalk Server, this hotfix is an all or nothing scenario. You should install this hotfix or BizTalk Server 2002 Service Pack 1 on all servers that are running BizTalk Server 2002. These include partners. You should also install this hotfix if servers that are running BizTalk Server 2000 are also in the environment. These include partners.

BizTalk Server 2002

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a “Hotfix download available” section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

Note The “Hotfix download available” form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.

Date         Time   Version     Size	  File name
------------------------------------------------------
06-Dec-2002  21:58  3.0.1554.0  721,168  Cisparser.dll

BizTalk Server 2000

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem.

If the hotfix is available for download, there is a “Hotfix download available” section at the top of this Knowledge Base article. If this section does not appear, submit a request to Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

Note The “Hotfix download available” form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.

Date         Time   Version     Size	  File name
------------------------------------------------------
31-Jul-2003  14:29  2.0.2009.0  680,208   Cisparser.dll
31-Jul-2003  14:29  2.0.2009.0  688,400   Ciscore.dll
Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

After you install this service pack or hotfix, you must
create the following registry entry and set the value of the entry to 1 to cause BizTalk to use the new receipt format
(). If you install this service pack or hotfix,
compatibility issues may occur when you exchange receipts between two BizTalk
Server systems if the service pack or hotfix has not been installed on both
systems and if both systems are not generating receipts by using the new format.

Collapse this tableExpand this table

Key Name Type Location
UseFixedReceiptFormat REG_DWORD HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesBTSSvc

To create this value in the registry, follow these steps:

  1. Click Start, click Run, and type regedit.
  2. Locate the registry entry, and then create a new DWORD value by using the information in the table.

    A
    value of 1 indicates that the new receipt format () is
    generated, and a value of 0 indicates that the original receipt format
    ( ) is generated.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the “Applies to” section.

This problem was first corrected in Microsoft BizTalk Server
2002 Service Pack 1.

Article ID: 811092 – Last Review: January 14, 2015 – Revision: 4.0


Applies to
  • Microsoft BizTalk Server 2002 Standard Edition
  • Microsoft BizTalk Server 2000 Standard Edition
kbnosurvey kbarchive kbautohotfix kbhotfixserver kbqfe kbbiztalk2002sp1fix kbfix KB811092

Read More:
BizTalk Server uses the <prop:identity> element instead of the <rcpt:identity> element for receipts

FIX: 0×8004005 Error Message When BizTalk Server 2002 Communicates with an HTTP Web Server

When BizTalk Server 2002 communicates with an HTTP Web
server by using HTTP/1.1, the HTTP Web server may gracefully close a TCP
connection, and BizTalk Server may stop responding. The following unspecified
error message is logged in the application event log on the computer that is
running BizTalk Server:

Event Type: Warning
Event Source: BizTalk Server Event
Category: (2)
Event ID: 324 Date: 6/30/2003
Time: 8:12:48 AM

User: N/A Computer: BTS

Description:
The description for
Event ID ( 324 ) in Source ( BizTalk Server ) cannot be found. The local
computer may not have the necessary registry information or message DLL files
to display messages from a remote computer. The following information is part
of the event:

0×80004005 Unspecified error

0x012b A
transmission attempt failed.

Service Pack Information

To resolve this problem, obtain
the latest service pack for Microsoft BizTalk Server 2002. For additional
information, click the following article number to view the article in the
Microsoft Knowledge Base:

815781

(http://support.microsoft.com/kb/815781/
)

INF: How to Obtain the Latest BizTalk Server 2002 Service Pack

Hotfix Information

A supported
fix is now available from Microsoft, but it is only intended to correct the
problem that this article describes. Apply it only to systems that are
experiencing this specific problem.

To resolve this problem, contact
Microsoft Product Support Services to obtain the fix. For a complete list of
Microsoft Product Support Services phone numbers and information about support
costs, visit the following Microsoft Web site:

Note In special cases, charges that are ordinarily incurred for
support calls may be canceled if a Microsoft Support Professional determines
that a specific update will resolve your problem. The usual support costs will
apply to additional support questions and issues that do not qualify for the
specific update in question. The English version of this fix has the file
attributes (or later) that are listed in the following table. The dates and
times for these files are listed in coordinated universal time (UTC). When you
view the file information, it is converted to local time. To find the
difference between UTC and local time, use the Time Zone tab
in the Date and Time tool in Control Panel.

   Date        Time    Version           Size     File name
   -------------------------------------------------------------
   18-Jul-2003  00:56  3.0.1575.0        540,944  Sharedcomp.dll

Note Because of file dependencies, the most recent hotfix or feature
that contains these files may also contain additional
files.

Microsoft
has confirmed that this is a problem in the Microsoft products that are listed
at the beginning of this article.
This problem was
first corrected in Microsoft BizTalk Server 2002 Service Pack
1.
In a network trace of the communication between the computer
that is running BizTalk Server and the HTTP Web server, you may notice that the
computer that is running BizTalk Server correctly acknowledges the graceful
exit. However, it then incorrectly tries to send data over the closed
connection. When this behavior occurs, the HTTP Web server resets the
connection to the computer that is running BizTalk Server and causes the
unspecified error in the event log.

Article ID: 824766 – Last Review: January 14, 2015 – Revision: 5.0


Applies to
  • Microsoft BizTalk Server 2002 Standard Edition
kbnosurvey kbarchive kbbiztalk2002sp1fix kbfix kbbug KB824766

Continued here:
FIX: 0×8004005 Error Message When BizTalk Server 2002 Communicates with an HTTP Web Server

Recommended transaction isolation level of BizTalk Server 2002 COM+ components

The
transaction isolation level for all Microsoft BizTalk Server COM+ components is
set to Serialized if you install Microsoft BizTalk Server 2002 on a computer that
is running Microsoft Windows Server 2000.

The
transaction isolation level for all BizTalk Server COM+ components is
set to Serialized if you install Microsoft BizTalk Server 2002 on a computer that
is running Microsoft Windows 2000 and subsequently upgrade the operating system
to Microsoft Windows Server 2003 or Microsoft Windows XP.

The
transaction isolation level for four of the BizTalk Server COM+ components is
set to Read
Committed
if you install BizTalk Server 2002 on a computer that is running
Windows Server 2003
or Windows XP.

If you have
installed BizTalk Server 2002 on a computer that is running Windows Server
2003, Microsoft recommends that you change the transaction isolation level for
the BizTalk.InterchangeStateEngineTx.1 component
back to Serialized by following the instructions that are listed in the “More
Information” section of this article.

Microsoft
recommends the following application isolation settings for the following
BizTalk Server 2002 COM+ components:

Collapse this tableExpand this table

COM+ component Recommended application isolation setting Hosting COM+ application
BizTalk.InterchangeStateEngineTx.1 Serialized BizTalk
Server Internal Utilities
BizTalk.BTSSubmit.1 Read Committed BizTalk
Server Internal Utilities
BizTalk.WrapBYOT.1 Read Committed BizTalk
Server Internal Utilities
BizTalk.Interchange.1 Read Committed BizTalk
Server Interchange Application
WkFlow.SysMgr Serialized XLANG Scheduler
BizTalkWorkflow.SkedDBHelper.1 Any XLANG
Scheduler Persistence Helper
All COM+ components that are installed on Windows Server
2000 have a non-configurable transaction isolation level of Serialized. However, on Windows Server 2003, the COM+ component transaction
isolation level is configurable. This behavior permits BizTalk Server 2002
Setup to change the component-level transaction isolation level from the
default setting of Serialized. When you install BizTalk Server 2002 on Windows Server 2003,
BizTalk Server 2002 Setup creates the BizTalk.InterchangeStateEngineTx.1
COM+ component with a
default transaction isolation level of Read
Committed
.

To
change the transaction isolation level for the
BizTalk.InterchangeStateEngineTx.1 COM+
component
to Serialized, follow these steps:

  1. Start the Component Services Microsoft Management Console
    (MMC) snap-in. To do this, click Start, point to
    Programs, point to Administrative Tools, and
    then click Component Services.
  2. Expand Computers, expand My
    Computer
    , and then expand COM+
    Applications
    .
  3. Right-click BizTalk Server Internal
    Utilities
    COM+ application, and then click
    Properties.
  4. Click the Advanced tab.
  5. On the Advanced tab, click to clear the
    Disable changes check box, and then click
    OK.
  6. Expand the BizTalk Server Internal
    Utilities
    COM+ application, expand Components,
    right-click the BizTalk.InterchangeStateEngineTx.1
    component, and then click Properties.
  7. Click the Transactions tab.
  8. On the Transactions tab, change the
    selected value in the Transaction Isolation Level list to Serialized, and then click
    OK.
  9. Repeat steps 3 through 8 for the other COM+ components
    that are listed in the table above as needed. As you complete steps 3, 6, and 8,
    substitute the appropriate values from the table in the “Summary” section of this article for any COM+ component
    that you are modifying.
  10. Shut down any COM+ applications that you have changed the
    transaction isolation level for, and then stop and restart the BizTalk
    Messaging Service. To shut down the COM+ application, right-click the COM+
    application, and then click Shut down.

    Note If the Shut down command is not available, the
    COM+ application is not running. Therefore, you do not have to shut it
    down.

For more information about how to configure COM+ transaction
isolation levels, visit the following Microsoft Web site:

Article ID: 834439 – Last Review: January 14, 2015 – Revision: 5.0


Applies to
  • Microsoft BizTalk Server 2002 Standard Edition
kbnosurvey kbarchive kbinfo KB834439

Visit site:
Recommended transaction isolation level of BizTalk Server 2002 COM+ components

An error message occurs in the Messaging Manager when you attempt to search existing objects

oneMscomBlade,oneMsomNav,oneMscomFooter,

See more here:
An error message occurs in the Messaging Manager when you attempt to search existing objects

Page 41 of 939« First...102030...3940414243...506070...Last »

Recent Comments

    Archives

    Categories