Configuring IIS for the Isolated WCF Receive Adapters
To publish WCF services by using the BizTalk WCF Service Publishing Wizard, you must configure Internet Information Services (IIS), BizTalk isolated hosts, and Windows user group accounts. This section discusses issues related to configuring IIS for publishing WCF services with isolated WCF receive adapters such as the WCF-BasicHttp receive adapter, WCF-WSHttp receive adapter, and WCF-CustomIsolated adapter. For general information about hosting WCF services in IIS, see "Hosting in IIS" at http://go.microsoft.com/fwlink/?LinkId=75700.
Considerations When Configuring IIS
Internet Information Services 6.0
You can use IIS 6.0 configured with ASP.NET 2.0 to publish WCF services with isolated WCF receive adapters.
IIS 6.0 (for Windows Server 2003) uses the IIS application pools for processing Web service requests. IIS 6.0 supports multiple application pools. Each application pool process can run under a different user context.
BizTalk isolated hosts
To host the WCF services with isolated WCF receive adapters, you must create at least one isolated host in BizTalk Server. For more information about how to configure BizTalk isolated hosts, see "BizTalk Isolated Hosts" in Enabling Web Services.
Database access for multiple server installations
If BizTalk Server and the BizTalk Management database reside on different servers, you should change the user context of the IIS Application Pool to a domain user account.
When implementing a multi-server deployment, the Isolated Host Windows groups must exist on the domain to which the BizTalk database servers belong.
Minimizing account privileges and user rights
You use isolated hosts to give adapters that run in external processes access to the minimal amount of required resources to interact with BizTalk Server. For a secure deployment, you should give the user context for the external processes minimal privileges.
Security recommendations for the BizTalk Web Services Publishing Wizard
The virtual directory created by the BizTalk WCF Service Publishing Wizard inherits the access control lists (ACL) from the parent virtual directory or Web site.
The following sections contain security notes and recommendations for Windows Server 2003.
Enabling ASP.NET 2.0 for Isolated WCF Receive Adapters
The WCF services that the BizTalk WCF Service Publishing Wizard generates rely on functionality provided by ASP.NET 2.0 from the .NET Framework 3.0. If you have upgraded your BizTalk Server installation from BizTalk Server 2004 or installed two versions of ASP.NET, you will need to update any IIS virtual directories that are used in conjunction with the BizTalk WCF Service Publishing Wizard to use ASP.NET 2.0 or later. For information about how to enable ASP.NET 2.0, see How to Enable ASP.NET 2.0 for Published Web Services.
Configuring Application Pools for Isolated WCF Receive Adapters for Windows Server 2003
Internet Information Services (IIS) 6.0 in Windows Server 2003 allows multiple application pools to run simultaneously. Each application pool can run under a different user context. For information about IIS Manager in Windows Server 2003, see the IIS documentation in the Windows Server 2003 documentation set.
The BizTalk WCF Service Publishing Wizard automatically inherits the application pool set for the parent Web site for the Web services that you publish. The default setting is DefaultAppPool. Each time you create a Web service using the BizTalk Web Services Publishing Wizard, you must change the application pool to the previously added application pool. For information about how to configure application pools, see How to Enable Web Services for Windows Server 2003.
By default, this application pool runs under the Network Service security account. For a complete description of the Network Service security account and alternative accounts that you can use as the identity for the application pool, see the IIS documentation.
Using IIS Configuration Files with the WCF Adapters
There are situations where a developer or an administrator may change WCF adapter settings within a web.config configuration file to affect the IIS process in which an out-of-process WCF adapter is hosted. Settings made within an application’s configuration file can conflict with, or negate, WCF adapter configuration settings chosen from within the BizTalk Server Administration console and stored in the BizTalk configuration database. This can lead to unexpected behavior or to problems that are hard to diagnose.
It therefore makes sense to follow a few simple guidelines when using application configuration files for WCF adapters hosted in IIS. The primary message is to use the adapter configuration UI from within BizTalk Server to set adapter configuration properties. Configuration values set by using a custom configuration program and the Windows Management Instrumentation (WMI) APIs have the same effect as if they are done from the BizTalk Server Administration console. This is because the BizTalk Server adapter configuration UI also uses WMI APIs to write the changes to the configuration database.
If you need to set properties that are not exposed in the standard WCF adapter bindings, use the WCF-Custom or WCF-CustomIsolated adapter and set properties by using the WCF adapter’s UI from within the BizTalk Server Administration console. If you need to configure tracing in your application, use the web.config file for out-of-process adapters running in the IIS process space. To enable application tracing for in-process adapters, configure it within the BTSNTSvc.exe.config file. You can also use the machine.config file to provide global configuration settings, such as available binding extensions, for WCF adapters.
Remember that whenever you set adapter configurations by using IIS Manager, a web.config file, or the BizTalk adapter configuration UI, you must synchronize these changes so that the application’s configuration will work correctly. Having inconsistent application configuration settings can result in failures that are very hard to diagnose or debug. For example, if you are using transport security, enable HTTPS support in IIS and choose transport security for the receive location in the WCF adapter’s configuration UI from within BizTalk Server.