Cind treci de la o singura baza de date la doua baze de date, in general singurul pas necesar este ALTER DATABASE [<initiatordb>] SET TRUSTWORTHY ON;. Detaliile despre de ce acest pas este necesar sint explicate aici: http://msdn2.microsoft.com/en-us/library/ms188304.aspx

Daca vrei sa faci totul 'de mina', cea mai simpla configurare este urmatoarea. Sa consideram doua instanze de SQL Server: host1 (initiator sau client) si host2 (target sau server)

1. creaza mesajele si contractul dorit  (CREATE MESSAGE TYPE/CREATE CONTRACT) in baza de date din host2
2. creeaza queue si service in baza de date din host2. Service trebuie sa fie 'bound' la contractul folosit
3. GRANT SEND ON SERVICE::[<targetservicename>] TO [public]; in host2
4. creeaza mesajele si contractul in host1 (definitia trebuie sa fie identica ca in host2)
5. creeaza queue si service in host1. Nu este necesar 'bound' la contract
6. in host2.master creeaza un database master key
7. in host2.master creeaza un certificat (CREATE CERTIFICATE [host2_cert] WITH SUBJECT = 'host2_cert')
8. creeaza un endpoint pentru service broker in host2 folosind authenticare pe baza de certificate: CREATE ENDPOINT [broker] STATE=STARTED AS TCP (LISTENER_PORT=4022) FOR SERVICE_BROKER (AUTHENTICATION = CERTIFICATE [host2_cert])
9. GRANT CONNECT ON ENDPOINT::[BROKER] TO [public]
10. repeta pasii 6-9 pe host1
11. creeaza un route pe host1 (in baza de date unde este service-ul) pentru service-ul de pe host2: CREATE ROUTE [routeToTarget] WITH SERVICE_NAME = '<target_service_name>', ADDRESS = 'tcp://host2:4022'
12. creeaza un route pe host 2 (in baza de date unde este service-ul) pentru service-ul de pe host1: CREATE ROUTE [routeToInitiator] WITH SERVICE_NAME ='<initiator_service_name>', ADDRESS = 'tcp://host1:4022'

Acum potzi initzia dialoguri intre host1 si host2, trebuie sa specifici WITH ENCRYPTION = OFF in BEGIN DIALOG pentru ca nu sa setat securitate la nivel de dialog intre cele doua service.

Daca vrei sa folosesti contractul [DEFAULT], potzi omite pasii 1 si 4.

Configurarea aceasta itzi asigura in trafic authenticare TLS intre host1 si host2 (folosind cele doua certificate din master), dar fara authorizare (pentru ca permisiunea de connect este acordata la 'public'). Traficul este incriptat (RC4).

Pentru troubleshooting, primul lucru la care trebuie sa te uitzi totdeauna este sys.transmission_queue.transmission_status in baza de date de unde trimitzi mesajele. Urmatorul pas in troubleshooting este sa atasezi Profiler si sa monitorizezi totate evenimentele din categoria 'Broker' si in plus 'Security Audit/Audit Broker Login' si 'Security Audit/Audit Broker Conversation'. Asigurate ca selectezi toate coloanele in Profiler, fii atent ca daca nu pornesti de la un template 'blank' in mod normal ascunde majoritatea coloanelor, inclusiv citeva absolut necesare.

Porneste de la doua baze de date noi, ca sa nu ai ceva obiecta ramase de la incercari anterioare (remote service bindings, routes). Atentie daca folosesti acelasi nume de service de mai multe ori in baze de date diferite, in mod normal toate sint valide ca target si se poate ca traficul sa faca automat load-balancing intre ele (fiecare nou BEGIN DIALOG va alege un target aleator intre cele posibile).

 Cu Service Listing Manager potzi face totzi pasii 6-12 de mai sus intr-un singur pas:

ssbslm exchange initiator "<numeserviceinhost1>" -S <host1> -d <host1db> -E /masterdbmkpwd Secret#123 /dbmkpwd Secret#123 target "<numeserviceinhost2>" -S <host2> -d <host2db> -E /masterdbmkpwd Secret#123 /dbmkpwd Secret#123