Tag: BizTalk 2006

BizTalk WCF Receive Adapters Wrap SOAP Body Content

On a recent project I was exposing a BizTalk orchestration as WCF for a Windows Forms client and a Windows Mobile client. For simplicity, a single BizTalk receive port was being used with multiple WCF receive locations. The BizTalk WCF publishing wizard allows this type of functionality through running of this wizard more than one time. This is by far one of the coolest WCF capabilities in BizTalk – the ability to expose multiple bindings (like you can do in WCF) for each BizTalk orchestration. For example, one BizTalk orchestration can be exposed for both a WCF-BasicHttp binding and a WCF-NetMSMQ binding through running the WCF publishing wizard twice, once choosing to publish a service endpoint for the WCF-BasicHttp binding, and then a second time as a Meta-data endpoint (MEX) for the WCF-NetMSMQ binding.
 
The message body properties for both of these receive locations was set to "Body" which is supposed to pull out the contents of the SOAP:Body from the WCF service call. When testing both of these bindings the contents of the SOAP:Body were being output but they were being wrapped in a part element like in the message given below:

<part i:type="a:string" xmlns:i="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:a="http://www.w3.org/2001/XMLSchema">Hello World!</part>
 
The application that was being implemented was one in which the body data needed to be passed along intact and not further wrapped. The MSDN documentation on the Message Body properties (http://msdn.microsoft.com/en-us/library/bb226478.aspx) did not mention that additional data would be passed along to wrap the content that was passed to the WCF receive location. The additional part element caused problems with the next system to receive the message. So I used the Path option rather than Body for the message body and used the XPath expression of /*[local-name()=’part’] to remove the additional wrapping of the data. This provided what I would expect to be included in the body part of the SOAP:Body – the data passed to the WCF operation and nothing more.
 
This tip should help you avoid one challenge of working with the new WCF features of BizTalk. Thanks!
0

More Tips for BizTalk ManagedDTS Issue

I was working on tracking down an issue with MDNs not being received for some AS2 communications. So I decided to enable the AS2 status reporting capabilities in BizTalk. I needed to configure BizTalk so that the BAM Tools functionality was available in order for the AS2 status reports to be available. During the process of using the BizTalk configuration wizard I received an error, which is given below:
 
"BizTalk 2006 Configuration: Microsoft SQL Server 2005 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine.  Please install Microsoft SQL Server 2005 Integration Services.  (Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper" … Additional information: “Could not load file or assembly ‘Microsoft.SqlServer.ManagedDTS, Version=9.0.242.0”…
 
This error occurred when trying to configure the BAM Tools and I was specifying the database server names and the names of the databases. A red icon with an "X" occurred to the left of the database name. If you did not know, you can double click on the red icon on all of the pages of the BizTalk configuration wizard to see the error. 
 
After looking on the internet I came across two blog posts (http://blogs.msdn.com/mattlind/archive/2006/08/30/730575.aspx, http://geekswithblogs.net/andym/archive/2006/11/27/99246.aspx) that gave me a few hints on what needed to be done but I still felt there were gaps in documentation and the blog posts so I wanted to give a little more information here for other people so that they would not need to come up with their own ideas of what needed to be done. I will also be referring to the multi-server BizTalk installation guide which can be found among the guides here: (http://www.microsoft.com/downloads/details.aspx?FamilyID=df2e8a88-fb23-49a4-9ac7-d17f72517d12&DisplayLang=en). The AS2 and EDI Status Reporting features of BizTalk Server 2006 R2 do provide a huge help in doing diagnostics of EDI interchanges and AS2 communications, but the process of enabling this feature is complicated.
 
A multi-server install usually means that BizTalk is on one (or more) servers and the SQL Server engine components are on some other (one or more) servers. In the BizTalk multi-server install guide, if you are trying to setup BAM Tools (one of the prerequisites for the AS2 Status reporting), it recommends that you install SQL Server Integration Services (SSIS) on the BizTalk box. This is wrong and could represent a license violation if you actually did this. This is one solution but there is actually a different solution which is better. BTW, the BAM install guide does not mention anything about the AS2 Status reporting so you can just skip this document if you are trying to setup the AS2 reporting functionality.
 
Although the error message indicates that the problem is a DLL named Microsoft.SqlServer.ManagedDTS is missing, this does not mean that something about the DTS functionality outside of SSIS is not functioning properly. This refers to a DLL that is installed on the SQL Server box relating to SSIS but not part of it that also needs to be on the BizTalk server. If you open up the SQL Server system and look in the GAC (at c:Windowsassembly), you will see that this DLL exists on a SQL Server where the "Workstation Tools" have been installed. So all that is required is that you install the SQL Server client tools on the BizTalk server which in the SQL installer are designated as "Workstation Tools". BTW, there is not a way to export a copy of the DLL from the GAC and I would advise against trying to individually copy this DLL out of a CAB from the SQL install because there are also additional DLLs that may need to be on the BizTalk server as well. It is important to note that it is not enough to just have the Workstation Tools installed only on the SQL Server itself. As one of the previous posters mentioned, you should select all of the Workstation Tools components on the install on the BizTalk server. This may require that you insert the install media into the BizTalk server or that you copy the installation software over to the BizTalk server.
 
In Andy Morrison’s post, he mentioned he had received an error when installing the SQL client tools (Workstation Tools), regarding OWC11. This is a variation on the install of the client tools. You could get other errors too – the key is to ensure the client tools run through successfully. Right before the client tools are installed you will see a window that goes through a series of prequisite checks for the SQL client tools install and you may need to ensure all of these tests pass with a warning or are successful before the client tools install will work. When I ran the client tools on the BizTalk server I did not receive an error so you may not need to reinstall OWC11 and you may not need to do a repair on the BizTalk installation. Ok, there are just a few more steps.
 
Then after you have run the Workstation Tools on the BizTalk server you will need to close the BizTalk configuration wizard and re-open it in order for the BAM Tools page to successfully see the Workstation Tools and connect to SQL Server appropriately. You can then specify the BAM Tools options and then recheck the AS2 status reporting option under the EDI/AS2 Runtime page. After running through the BizTalk configuration wizard successfully you will then need to open up the BizTalk administration console and go to the Party properties. On your AS2 party you will need to open up the AS2 properties and then on the General tab check to enable the AS2 status reporting. You may also want to check the other boxes on the Sender and Receiver pages of AS2 properties for whether to store the wire and decoded messages of the AS2 communications so that you can drill into this data from the Group Hub page.
 
After all of this configuration, you should restart your BizTalk applications and hosts and then wait a while so that the AS2 status reporting can collect some data. Then go to the Group Hub page and click refresh. The Group Hub page will now have some additional links to reports but you will probably need to scroll down on the group hub page in order to see them. Normally all of the group hub page fits within the standard size window but the additional AS2 status reporting enables the use of the scroll bar so be aware that these links may be off-screen initially when you view the Group Hub page.
 
Thanks,
 
0

Another BizTalk/PeopleSoft Integration Option

As I am wrapping up my BizTalk EDI project I also wanted to mention that this project has incorporated a nontraditional integration option between BizTalk and PeopleSoft. Microsoft provides the BizTalk Enterprise Adapter Pack which includes the PeopleSoft adapter. This provides a way to integrate between BizTalk and PeopleSoft and provides a handy way for extracting the message schemas of the different services exposed by PeopleSoft via the Compontent Interfaces. These days PeopleSoft itself has its own EDI integration platform as well as the ability to interact with the Filesystem and so there are various layers of infrastructure within PeopleSoft that you can choose to integrate over.
 
On my project it was possible to map PeopleSoft flat-file formats to EDI message types and exchange the files over the network and then out to the VAN. So rather than work directly with PeopleSoft, the solution was to work across a file system, receiving PeopleSoft flat files and transforming them to EDI and then on receipt of EDI messages, transforming them into PeopleSoft flat file acknowledgements. In my opinion this was a less difficult implementation option than the use of the PeopleSoft adapter because you did not need to configure a Java environment or install a PeopleSoft component interface. Next I will give some details of the PeopleSoft flat-file format to give you a little more information about how involved the mapping was in this solution.
 
The PeopleSoft flat file format was based on 3 groups of positional lines, the first group always has one line for each transaction (multiple in a batch), then the second group has n lines below the first group and the third group has m lines below the second group. The first group is tagged with 000A, the second group with 100A and the third with 200A. So for basic EDI messages this nesting of groups corresponded pretty well with the traditional PO1, N1, and SCH loops. Unfortunately the message format in PeopleSoft is configurable in the PeopleSoft administrator website and it is possible to add or remove columns very easily so it is possible that a message format could be changed and result in a disruption of the BizTalk application that uses the messages. 
 
The benefit of using the PeopleSoft adapter is that you have a sure reference for the generation of the message types. This was by far the largest challenge of the project; knowing the format details for the PeopleSoft adapter is not documented that well and is variable based on the message type configuration. But if you do not have the security option to install a custom component interface for the PeopleSoft adapter or have other difficulties getting the PeopleSoft adapter to work, this post has provided you with yet another option for integration.
 
Thanks, 
0

BizTalk EDI Routing Workarounds

I have been in the final stages of a large BizTalk EDI project and I have been struggling with the appropriate infrastructure for managing a single AS2 HTTP endpoint that interacts with a VAN over which multiple trading partners’ data is sent. The main challenge has been that if a single endpoint to BTSHTTPReceive.dll is exposed, it will provide data for many trading partners yet these partners may be used across one or more BizTalk applications. Since the endpoint usually exists as a 2-way receive port with As2EdiReceive/As2Send as the pipelines, I have been using send ports with filters to catch the messages after they are pushed to the MsgBox from the exposed endpoint. When just a single BizTalk application exists that includes the endpoint, all messages can be routed easily. But when more than one BizTalk application exists, it becomes much more complicated.
 
For example, if you have the exposed endpoint in Application 1 and two send ports in Application 2, these send ports will be able to pick up messages received on the exposed endpoint but you will see errors being logged from Application 1 that the messages could not be routed successfully. For this reason, I have found that it is important to have send ports that are used for picking up messages received through BTSHTTPReceive.dll in the same BizTalk application as the receive port for the endpoint. So I have written to disk the messages received from the endpoint that are used in other BizTalk applications as a way of offloading the messages to processes and orchestrations in the other BizTalk applications.
 
One problem with this approach is that sometimes the messages received in Application 2 do not have the correct ISA/GS headers or may have been altered through the application of the Global EDI properties. These properties can make understanding BizTalk routing very painful because they frequently cloud or disguise the intended recipient of messages. In my project, messages that are received in Application 2 have been placed in the correct folder so I know that the routing infrastructure was able to match the ISA and GS headers to the party properties, yet at some point during the routing the Global EDI properties were applied anyway. Today I identified a workaround for a situation in which a message has been routed with incorrect headers.
 
For send ports that have filters that write messages out to offload to other BizTalk applications, you can use a PassThruTransmit pipeline on the send port filter to write the body of an EDI message out to disk. You are probably thinking that this is crazy because this will represent the XML of the EDI message body. For me this worked great because the EDI message body stayed intact even when the EDI global properties got applied. Then on a receive port you can use the XmlReceive pipeline to pull in the message text written out via PassThruTransmit, which is an XML version of the EDI message body. This identifies the root of the message and identifies that it is the XML version of the message. In essence this functions a lot like an EDI receive without needing to worry about the resolution of the ISA/GS headers to determine the namespace because the namespace is included on the root of the EDI-XML message. So to summarize the process of getting an EDI message body from an exposed AS2 endpoint when the EDI global properties get messed up, use the following pipeline pattern in your ports:
 
BTSHTTPReceive.dll –> (R) AS2EdiReceive / AS2Send –> (S with Filter) PassThruTransmit –> (R) XmlReceive
 
Good luck to everybody working with EDI in BizTalk. Its easy once you get the hang of it, but until then its usually bumps and bruises. 🙂
 
Thanks,
0

Role Link Deployment Issue and Workaround

On my most recent project I am employing send port role links as a way to route messages within BizTalk for test and production EDI trading partners. This is one way to use a single orchestration for handling multiple trading partners (BizTalk parties). So in my orchestration instead of simply having a send port, I have a role link that contains a send port. Since the project’s deployment simply consists of a single server I am deploying directly from Visual Studio. During a recent round of changes I encountered an error that was consistently blocking deployment from Visual Studio. This error is given below:
 
Failed to update binding information.
Could not validate TransportTypeData, Address or Public Address properties for Receive Location <Receive Location Name>. Retrieving the COM class factory for component with CLSID {CFF09884-6582-49C2-A74F-0FD85849281E} failed due to the following error: 8007045a.
 
Another variation of this error is:
Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding information. Could not validate TransportTypeData, Address or Public Address properties for Receive Location <Receive Location Name>. Retrieving the COM class factory for component with CLSID {CFF09884-6582-49C2-A74F-0FD85849281E} failed due to the following error: 8007045a. 
These errors occur when trying to redeploy over BizTalk applications that use role links with send or receive ports. These deployments from Visual Studio have been attempted with the deployed BizTalk applications in both the enlisted/started and unenlisted/stopped states. I have found that these errors occur for me on more than one BizTalk development system, on both Windows XP and Windows Server 2003 systems, both running BizTalk Server 2006 R2. I was able to determine a modified deployment process to enable deployment to be successful in these scenarios. Here are the steps I came up with in order to successfully deploy a project with role links which is my workaround for the errors above:
 
  1. Build/rebuild in Visual Studio in the build configuration you want to deploy under.
  2. Stop the BizTalk application you want to deploy to.
  3. Export the latest bindings for the BizTalk application. This will include information about all of the send and receive ports and role links. You may want to check to include the global party information in a separate file for an exhaustive binding backup.
  4. Unconfigure the receive ports by right-clicking on the BizTalk application and clicking “Configure…”. I would specify <None> for the receive port bindings. Leave the role links completely configured and do not worry about removing the send ports from the BizTalk parties.
  5. Delete the receive ports from the BizTalk application.
  6. Deploy from Visual Studio
  7. Reimport the bindings that you exported in step 3.
  8. Make sure everything looks correct in the Configure window. The bindings should be rebound successfully.
  9. Start the BizTalk application again.
This is a mysterious problem that was not solved by rebuilding or cleaning my BizTalk solution. At this point it may be a BizTalk deployment bug. The benefit of the workaround is that you do not need to unconfigure the role links themselves or modify the send ports specified for each party. With one role link you could have many configured parties so this workaround could save you a significant amount of time during deployment.
 
Thanks,
1

BizTalk 2006 R2 Repair Fails with Visual Studio 2008 Installed

A few months ago I had posted on a way to run both Visual Studio 2008 and BizTalk Server 2006 R2 with Visual Studio 2005 so that you could take advantage of the new environment for developing WCF and WF projects while continuing to work with BizTalk. I had setup this software combination on my local development box in Windows XP and had been working fine without any significant issues. Although there are a few known issues about TFS compatibility across solutions that include BizTalk projects as well as .NET 3.5 projects, I had not encountered any issues with my BizTalk installation until today.
 
During some development I realized that I likely needed to do a repair on my BizTalk installation due to an error I was receiving about a key violation error in one of my BizTalk databases. It is a common recommendation that the installation be repaired through the Add/Remove programs repair part of the installation wizard when certain issues are encountered with BizTalk. So I loaded the BizTalk installation image and started the repair and everything worked fine until near to the end of the repair. Then all of a sudden I started receiving errors about the WCF adapters that are included with BizTalk Server 2006 R2. Here is an example error:
 
Failed to add adapter: WCF-NetNamedPipe, Error C0C025CA
 
A similar error occurred for nearly every one of the R2 WCF adapters with the name of the adapter being the only thing different in the error message. I clicked OK for every one of the error messages and this was apparently not a significant-enough error because it did not prevent the repair from continuing. The repair completed successfully without any other reports of problems. I checked in the Event Viewer and there were not any additional error messages to provide more information on what went wrong.
 
At this point I think the reason this problem occurred is because I have a version of Visual Studio on my system that is not currently compatible with BizTalk because I know that the BizTalk repair wizard did not have this problem running before I had installed Visual Studio 2008 side-by-side. Until I find more information about this error I have to say this is a known issue for BizTalk development where you have a side-by-side of Visual Studio 2005 with the BizTalk extensions and a separate Visual Studio 2008. At this point I am not sure whether the WCF adapters have suffered any sort of actual casualty by the repair wizard issues. But I think if you want to run the repair wizard successfully without any issues, be sure to uninstall Visual Studio 2008 prior to starting the repair wizard. Good luck with your BizTalk environment configuration!
 
1

Another Way to Explain BizTalk Role Links

I am working on a project where I am extending a BizTalk application so that I can route messages from a single FILE port to different BizTalk applications and various orchestrations through the use of role links. Role links are one of the less frequently used and discussed tools of an experienced BizTalk developer. Getting my mind around role links was difficult because of the number of configuration details required to setup a role link. I am indebted to Eric Stott’s blog post at http://blog.biztalk-info.com/archive/2006/10/25/BizTalk_Role_Links_explained.aspx, but I think it would seem easier to describe role links as a precursor to the WCF binding architecture. I will describe some architecture notes on role links next but to see my thoughts on how role links are like WCF, skip on down a few paragraphs.  
 
Role links are essentially the opposite of dynamic ports. A dynamic port consists of one port that then has multiple variations of configurations based on the dynamic expressions applied to this port for one adapter. A role link is a static configuration but is essentially a collection of ports of different adapters. For a dynamic port there is not always an explicit party concept; in a dynamic port a message is being sent from one organization to some other variable organization. And in a role link a message is either being sent or received and is then one of a collection of organizations for each endpoint. Role links are based on ports that are designated as being associated with some BizTalk party. The party can have one or more aliases which act as destination tokens when used with role link based routing.
 
So here are a few examples of how role links could be used:
– When you need to have dev, test, and production parties all hosted in a single BizTalk application and merely need to differentiate logic for these parties based on ports
– When you need to expose a single business process to multiple parties without creating more than one orchestration to handle all of them.
– When you need more than 1 backup port in a BizTalk application
– When you are struggling to manage so many BizTalk artifacts and are looking for a way to reduce the number of orchestrations
– When you want a lightweight built-in BizTalk routing mechanism that has a simple but flexible mechanism for specifying a routing destination.
– When you want to expose more than one adapter for some organization as connectivity options
 
This last example of a role link use helped me think about a more contemporary example of a role link. In WCF when you expose a service, it is possible to expose more than a single endpoint for a service so that the organization that connects to the service can use either HTTP or TCP or some other protocol or set of binding options to connect to the service. This is frequently used to expose a WSI basic profile service for interoperability and a WS-* or SOAP 1.2 service for newer clients as in the following example: http://keithelder.net/blog/archive/2008/01/17/Exposing-a-WCF-Service-With-Multiple-Bindings-and-Endpoints.aspx. WCF provides the binding infrastructure so that it is possible for a client to have various options for connectivity. In the same way, role links provide a way to provide to a client multiple integration options that all get consumed into the same business process.
 
So role links are very similar to the binding infrastructure in WCF due to the trasnport-level flexibility both enable. If you are a BizTalk developer, you should take role links for a spin because they provide some very valuable extensibility options. It does take a while to get used to role link abstractions so I recommend taking WCF as a good example of what role links seek to accomplish and then throw adapters and parties in the mix and it makes much more sense. Have fun with role links!
1

Comparing BizTalk and MOSS SSO Configuration

I was recently working on a SharePoint Business Data Catalog (BDC) project and needed to configure the single sign-on (SSO) functionality of SharePoint. For anyone not familiar with the SSO functions in BizTalk or SharePoint that I am talking about, I will explain it briefly. I am not speaking about SSO in the sense that a website or application user logs in once and only once. I am speaking about SSO functionality in these two server products which enables the secure storage of credentials used for connecting to external systems. There are two types of SSO – authorization and impersonation. So that everyone knows, I am talking about the SSO impersonation capabilities of these two server products.
 
Coming from a BizTalk background I had worked with SSO in BizTalk quite a bit but was not initially prepared with how different the configuration was for SharePoint. This post will attempt to do a thorough comparison of all of the SSO functionality between the BizTalk and SharePoint products.
 
Feature

BizTalk

SharePoint

Configuration Interface

Command-Line and BizTalk Configuration Wizard

SharePoint Central Administration website

Encryption Key Management

Possible only via Command-Line

Possible only via website function "Manage Encryption Key"

Encryption Key Backup

Command-Line File Based, Can backup to any file location

Website Based, Can backup only to a removable drive

SSO MMC Capability?

Exists as an MMC, can be loaded remotely with appropriate BizTalk install

MMC does not exist, cannot be configured remotely.

Requires RDP access for SSO configuration?

No

Yes

Group Setup for SSO

SSO Administrators, SSO Affiliate Administrators, SSO Service Account

SSO Administrators, SSO Administrator Account, SSO Service Account

Requires SSO Service Account to be process identity for configuration?

No

Yes

SSO delegation options

Credential based on port configuration

Credential variability options – Group and Individual options.

Runs as Windows Service?

Yes

Yes

Required on all servers in Farm?

No

Yes

Operates out of an SSO database?

Yes

Yes

Command-line options for SSO?

Yes

Partial

Automatic Credential Update?

Yes

No

The above table shows there are a considerable number of differences in the SSO configuration and functionality options of SSO across the two products. Perhaps in the future the two SSO products can provide a combination of the features in the chart above because both offer valuable options and would make an excellent combination together. A more consolidated SSO experience would also be helpful from a product administration perspective.

Thanks,

 

2

BizTalk and Hyper-V

Yesterday I learned about a resource for configuring virtual BizTalk instances in conjunction with the use of Windows Server 2008 Hyper-V. This guide is available on MSDN (http://msdn.microsoft.com/en-us/library/cc768518.aspx) or via a white paper download. This guide is very interesting because it pushes along the guidance on how to implement a scalable solution with BizTalk in which host instances are spread out on different servers for maximum performance.
 
The general MSDN guide for scaling out is at http://msdn.microsoft.com/en-us/library/aa546759.aspx, and an article for scaling out receiving hosts is at http://msdn.microsoft.com/en-us/library/aa577415.aspx. The benefit of the new Hyper-V guide is it shows much more of the details for different configurations of BizTalk host instances. The general scaling out guide basically makes the assumption that individual host instances will be physical machines. The Hyper-V guide represents the host instances as virtual machines with the guest OS of Windows Server 2003. It is important to note that this guide does not recommend or endorse BizTalk running in a host OS of Windows Server 2008, although this is technically possible. The guide does use Hyper-V included Windows Server 2008 for the host OS. It is important to remember that BizTalk licensing is based on the number of processors, any number of virtual instances may be installed with BizTalk on the same server. Here is a partial picture from the Hyper-V guide showing the relationship between the host with Hyper-V and guest BizTalk virtual machines:
 
hypervpic
 
Another one of the strengths of the Hyper-V guide is it shows a considerable level of detail about how scaling out the SQL Server instances should work, including having SQL Server instances virtualized as well. Interestingly, the SQL Server virtual machines ARE running on Windows Server 2008. Many file-level details such as filegroup organization and the separation of data files for SQL Server is discussed, which is very helpful for people who are planning on using Hyper-V with SQL. Another valuable detail is that specific examples of SAN implementation with RAID modes is also discussed. This extends the information previously available in the scaling out SQL Server for BizTalk installs article (http://msdn.microsoft.com/en-us/library/aa578625.aspx).
 
One of the values of this guide is that it helps reduce the cost and risk of entry for a customer into a Windows Server 2008 environment. Although BizTalk Server 2006 R2 is not officially supported on Windows Server 2008, Hyper-V as discussed in this guide enables some of the major strengths of Windows Server 2008 to be applied indirectly to BizTalk Server 2006 R2 host instances such as utilization of a larger amount of RAM and host OS performance improvements that would not be possible with the previous version of Virtual Server 2005. For companies not willing to run BizTalk Server 2006 R2 due to the risk of not being officially supported, this solution provides a documented workaround.
 
Check out the guide and have fun virtualizing BizTalk with Hyper-V!
0

Windows Server 2008 Roles and Features for BizTalk

I recently wrote a blog post about avoiding some of the pitfalls of installing BizTalk Server 2006 R2 onto Windows Server 2008. One of the gaps in my post was that I did not mention all of the roles and features that I used when configuring Windows Server 2008 prior to installing BizTalk.  Since there is really very little documentation out there on MSDN for BizTalk installs onto Windows Server 2008, I wanted to help clear up the documentation gaps so that others could get this latest version of the Windows Server running for their BizTalk environment.

For this BizTalk project, I was primarily using FILE, MSMQ, and the WebSphere MQ (MQSC) adapters in case you are wondering.  Here is a photo of the roles and features that I configured in order to get BizTalk to run successfully:

Win2K8-RolesAndFeatures

On Windows Server 2008 the initial page that loads is called the Server Manager and includes an excellent overview of the configuration of the server. The screenshot I provided above came from the Server Manager’s section for Windows Server 2008 configured roles and features. This list of roles and features does not cover all BizTalk features so you may be required to add other roles or features for BizTalk adapters other than the ones I used.

Thanks,

0

Blog at WordPress.com.

Up ↑