1. Administering, Deploying and Securing BizTalk Server 2004 Scott Woodgate Lead Product Manager Microsoft E-Business Servers

2. Agenda Simplified architecture for development Full Production architecture Full Secure Scale-Out Architecture Performance Preliminaries Physical Deployment How-To

3. Basic Architecture Adapter Host Orchestration #1 Orchestration #2 Receive Port Send Port TrackingDB Config DB DB Adapter Receive Pipeline BusinessRules Send Pipeline Publish and Subscribe Message Box (SQL) Message Format 1 Message Format 2

4. Basic Architecture Developer Perspective demo demo

5. Scale-Out Requirements Multiple BizTalk Servers Processing CPU threshold Partition processing work into “containers” Similar/Different security requirements Multiple SQL Servers Database Lock contention/CPU threshold Approx 1:3 ratio (db:processing) Scale out each layer independently BizTalkServer SQLServer n n Independent scale-out

6. The simple stuff: Database Scale-Out

7. Core SQL Databases BizTalkMsgBoxDb: “MessageBox” High traffic volume read/write intensive BizTalkMgmtDb: Configuration Low traffic volume read in production Writes for EDI and BTF2.0 acks BizTalkDTADb: Tracking High traffic volume writes in production Low traffic volume reads in production SSODB: Single-Sign On Low traffic volume reads in production Low traffic volume writes in production These databases are almost always used and can be placed in separate SQL machines depending on traffic requirements.

8. MessageBox scale-out/fault tolerant model Master MessageBox Routes incoming message Activation: Round-robin Correlation: Route to messagebox containing persisted state Scaled out MessageBoxes Process messages Persist orchestration state Databases are the only state container ALL Databases should be MSCS clustered for fault tolerance MasterMessageBox MessageBox 2 MessageBox 1 Activation Correlation Which MessageBox contains the state? Round robin Orchestration

9. Feature specific SQL Databases BAMArchive, BAMStarSchema, BAMPrimaryImport: BAM May be high traffic volume if using BAM BizTalkHWSDb: Human Workflow May be high traffic volume if using HWS BizTalkRulesEngine: Rules Engine May be high traffic if using rules engine These databases are used dependent on features used and can be placed on separate SQL machines dependent on traffic requirements.

10. demo demo MessageBox scale out demo

11. The flexible stuff: BizTalk Scale-Out

12. BizTalk Scale concepts: Hosts A host is a logical container for BizTalk Server resources such as orchestrations, receive and send adapters Why have hosts? Hosts provide resource partitioning Hosts provide security partitioning What do I put in a single host? Resources that scale together and have the same security requirements When do I move resources out of a particular host? When the resources aren’t scaling together or security requirements change In the default install for development this is a single host Host “A” Host “C” Orchestration #1 Orchestration #2 Example: Orchestration #1 calls Orchestration #2 File Receive Adapter Host “D” HTTP Receive and Send Adapter Web Services Receive and Send Adapter Example: Orchestration #3 receives through either HTTP or Web Services Host “B” Orchestration #3

13. BizTalk Scale concepts: Host Instances A host instance is a physical instance of a logical host on a single machine Why have host instances? Create a single container and scale it out easily by creating new instances One host can have many instances (1: many) One machine may only run a single host instance of a particular host (1:1) By default for development there is a single host instance of the single host with all resources are added to that host Machine “1” Machine “3” Host Instance A Host Instance B Host Instance C Host Instance D Host Instance A Host Instance B Machine “2” Host Instance A Host Instance C

14. In-Process Host Instances Physical concept: Instantiated Host Instances are created as physical Windows Services running under a user name and password BizTalk Server controls these processes They are the BizTalk Server processes hence “in-process” Can start, stop Isolated Host Instances Abstract concept: Instantiated Isolated Hosts run out of process of BizTalk Server. No new service is created. For example aspnet runs in an isolated host as it has its own service BizTalk Server can not control these processes Creating an Isolated Hosts Instance containing resources, such as adapters, gives the process permissions to submit a message to BizTalk Server Authentication Trusted This host will pass the message sender context through the system. Example: Ford submitted a message to the system. The message will continue to be identified as from Ford. Non-Authentication Trusted This host will normalize the sender of the message to “guest” Example: You don’t trust code running in the host BizTalk Host concepts

15. demo demo Host and host instances demo

16. Example: Multiple Orchestration Host Instances Scenario: Message comes in for Orchestration #1 part of Host Instance “A” Which Machine executes it? Machine “1”, “2” or “3” depending on availability. For this example machine “1”, host “A” executes the orchestration Half-way through the orchestration sends out a message and persists state to the messagebox waiting for a responses There is no affinity to host instance once dehydrated. The response message comes back and depending on availibility any of “1”, “2” or “3” can execute the orchestration Machine “1” Host Instance A Host Instance B Host Instance C Host Instance D Machine “3” Host Instance A Host Instance B Machine “2” Host Instance A Host Instance C

17. Example: Adapter Scale-Out Adapters have two parts that can scale independently: Receive side called the receive handler Send side called the send handler Why scale independently? Traffic differences Example: Receive 100 messages process them Send back 500 messages Fully fault tolerant if there are two host instances running a specific adapter receive or send handler Receive handler can be installed in: multiple hosts and instantiated on their multiple host instances not for scale-out but for differing traffic requirements (eg. Inside firewall web services and outside firewall web service) Send handler for this version is restricted to one host per adapter an its multiple host instances This scale-out gives you the ability to minimize the adapters installed to the machines that need them n Host “A” File Receive Adapter Host Instance Instance“A” Host “B” File Receive Adapter Host Instance Instance“B” n Host “C” File Send Adapter Host Instance Instance“C”

18. Adapter Specific Scale-Out Behaviours How an adapter behaves when there are two receive handlers pointing to a location is adapter specific HTTP/S, Web Services Use NLB through WLBS Scales out (both receive at once round-robin) Fault tolerant Run as Isolated Hosts File: Use UNC path Scales out (both receive at once round-robin) Fault tolerant Requires registry work (Rename function) In-Process BizTalk Message Queuing Use NLB through WLBS Fault tolerant No scale-out, one MSMQT instance at a time can service a single queue due to “in-order” messaging support for this transport In-Process Custom Adapter Adapter dependent In-Process or Isolated The above rules apply for both the send handler and the receive handler

19. demo demo Adapter Handler demo

20. Example: Simple (Yes Simple) Scale-Out Scenario: Receive a message from a trading partner through web services, execute a business process that sends the message to SAP Hosts A: Web Services Receive Adapter Handler B: Orchestration C: SAP Send Adapter Handler Host Instance A on Machine 1 B on Machine 2 C on Machine 3 Advantages: Minimize adapter installs to machines that need them ($) Independently scale out receive from send and orchestration Hosts are scale invariant, keep the same three hosts and add host instances

21. Built in Services 1: Tracking The tracking service writes tracking information to the tracking database The tracking service runtime runs in a host like the other artifacts My default “tracking” is in the default host The most secure installation has tracking in a dedicated host so no user-code is inside the process Create a new host and select “Tracking” An aside (unrelated to tracking): The certificate is used for inbound decryption of incoming messages

22. Built-in Services 2: Single Sign On Even if you are not using SSO capabilities directly BizTalk Server leverages SSO for URL information as it provides a secure store SSO does not run in a host it has its own windows service SSO designed to minimize attack surface with only one machine per farm containing the key Master Key is used for encryption and resides on Master SSO server It is CRITICAL that you back- up your SSO master key \Program Files\Common Files\Enterprise Single Sign-On SSOConfig.exe –backupsecret myfile SSODatabase BizTalkServer MASTER SSO Contains Secret key BizTalkServerSSOrequests

23. Single Sign-on Fault-Tolerance What if the power-supply in the Master SSO Machine blows up? Scenario A: Slave machines cache the information they need in memory and runtime will continue but: NO changes to ports or SSO configuration Convert a slave machine to a master with the backup-key to restore complete functionality Scenario B: MSCS Cluster the SSO service Which do I choose? Scenario A will be suitable for most customers and is consistent with adapter and orchestration scale out SSODatabase BizTalkServer MASTER SSO Contains Secret key BizTalkServerSSOrequests

24. demo demo SSO database/back-up walkthrough

25. BizTalk Administrator Tools MMC Snap-in for Administering BizTalk Scaling Creates new message boxes Defines Hosts and enlists applications Enrolls new Servers as Host Instances Operations Start / Stop Orchestrations Enable / Disable Receive Locations WMI and ExplorerOM command-line scripting Deployment tool (more on this later)

26. demo demo WMI command-line script example: Enabling a receive location

27. Security, Security, Security

28. Security Hardening Secure by design: threat modeling, security design reviews code quality tools, secure coding guidelines, code reviews, security bug bashes MS employed ethical hackers to harden the product Secure by default: running with least privilege, reducing attack surface Turn on the dials to use them don’t turn them off For example MSMQT not installed by default

29. Quick Revision: Hosts and Security Run each host in its own security account Isolates each host from seeing outside data Ability to trust or not trust hosts to identify partners Isolated hosts prevent untrusted code from impacting other applications For example if IIS/ASP.NET was comprised BizTalk Server will not be as it is an isolated host

30. Example: Secure Physical Topology

31. This is an example, not the example Active Directory based (domain users, groups) Domains enforce trust boundaries Least privilege accounts (most distributed) Locked down platform configuration Minimal custom setup on each box Centralized administration No BizTalk bits in DMZ No trust with DMZ (assumed) Windows authentication everywhere N.B. Domains were used for “hard” isolation boundaries but we do expect customers to run services and orchestration in the middle tier using VLANs to segregate at the network level Notes: Scaled out Secure Topology

32. Role based security All tools and runtime work against SQL Roles Message Boxes Configuration Database Tracking Database … Specify Windows Group for each DB during setup BizTalk Server Administrators (default) Isolate user by specifying a different group for each database Message Box (runtime and operations) Configuration Database (config only) Tracking Database (historical data)

33. Security – for another day Partner Management User authentication avoiding denial of service Message security PKI, S/MIME Transport security HTTPS

34. Performance EARLY “BETA” NUMBERS “Messaging” >= BTS2002 1 msgbox/3 processing machines = 130msg/sec 4 msgboxes/10 processing machines = 600msg/sec “Orchestration” 5x faster 1 msgbox/3 processing machines = 200msg/sec Request/Reply: < 1sec 1 msgbox/4 processing machines = 170 msg/sec Subsecond latency Out of box the maximum latency introduced by the messagebox in the polling cycle is 500 ms per message hop within the messagebox and this number is set in BiztalkMgmtDb..adm_ServiceClass table (column MaxReceiveInterval). You may reduce it to a non-zero value for more aggressive polling.

35. Physical Deployment

36. BizTalk Artifacts Developer produces Orchestrations Pipelines Schemas Maps Rules Use abstractions for physical locations Built into assemblies for deployment

37. Deploying Applications Get the bits on the box Deploy assemblies Configure the environment Map the developer logical to the real world environment Configure Relationships Send/Receive Ports, Partners, Roles

38. BizTalk Explorer Defines the deployment topology Integrated with Visual Studio UI for defining physical environment Maps logical Orchestration ports to physical locations Maps applications to Hosts

39. Deployment Wizard GACs and registers assemblies Export config created by Explorer Modify to stage from test to production Import on production server Import capability to batch config XML based script Configure entire solution with one file Add and configure new partners

40. One-Click Deployment with BizTalk Installer BizTalk specific VS Setup project Custom Action DLL tailored to BizTalk Auto-packages BizTalk project output Point-n-click to add your projects Updates MSI package with every build Imports configuration scripts Extensible All standard setup capabilities Include your assemblies Write your own custom actions

41. Application Deployment demo demo

42. Next Steps Start building with the BizTalk Server 2004 beta Come to my session tomorrow Check on the BizTalk Server 2004 overview whitepaper by David Chappell http://blogs.gotdotnet.com/scottwoo http://blogs.gotdotnet.com/scottwoo