1. Key Elements to Deploying OCS

2. Where to Start  OCS can seem to require an awful lot of servers _ Edge, Director, Front End, SQL, Monitoring, SQL, Archiving, SQL, Mediation, Group Chat, SQL, …  Project I was working on the objectives where to reduce mobile phone spend by offering enterprise voice and reduce conferencing by offering live meeting to external users. 80K users, 10K ent voice, UK & USA phone numbers 80K users, 10K ent voice, UK & USA phone numbers  Phased Implementation Lab Lab Pilot (7k) Pilot (7k) Production 80K, 10K ent voice Production 80K, 10K ent voice

3. Planning  High level planning tool is the OCS Planning Tool  Capacity largely determined by number of concurrent users Logon rate and number of endpoints Logon rate and number of endpoints Contention rate to PSTN Contention rate to PSTN  Considerations disaster recovery and resilience  Network Impact _ in particular voice and video

4. Key Requirements  Active Directory Windows Server 2003 Domain functional level. DCs W2k3 SP1+ Windows Server 2003 Domain functional level. DCs W2k3 SP1+ If LCS or OCS R1. Global Settings may be in system container. If multiple domains suggest moving to config container before schema prep If LCS or OCS R1. Global Settings may be in system container. If multiple domains suggest moving to config container before schema prep  Significant Certificate and DNS requirements which will be covered later  Hardware\OS 64 bit only

5. Voice Implementation

6. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) User DID homed on PBX only

7. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) User call control: Click to call/pick up on OC or dial on phone Routing, features: PBX only, voice only, features from PBX incl. VM Media: Transported by PBX to PBX phone, no outside user Presence: PBX line presence

8. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) User DID homed on PBX only PBX Co- Existence: Dual Forking (RCC optional) User DID homed on both PBX and OCS

9. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) User call control: Click to call/pick up on OC or dial on phone Routing, features: PBX only, voice only, features from PBX incl. VM Media: Transported by PBX to PBX phone, no outside user Presence: PBX line presence PBX Co- Existence: Dual Forking (RCC optional) User call control: From OC or phone Routing, features: OCS features from OC, PBX features from phone, VM from PBX Media: Choice of voice to OC or PBX phone for each call; benefits of OC to outside users Presence (with RCC): Merged OCS “on-the- phone” presence and PBX line presence

10. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) User DID homed on PBX only PBX Co- Existence: Dual Forking (RCC optional) User DID homed on both PBX and OCS Enterprise Voice “Standalone” with SIP-PSTN Gateway User DID homed on OCS or PBX only

11. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) User DID homed on PBX only PBX Co- Existence: Dual Forking (RCC optional) User DID homed on both PBX and OCS Enterprise Voice “Standalone” with SIP-PSTN Gateway User DID homed on OCS or PBX only Enterprise Voice “Standalone” with Direct SIP User DID homed on OCS or IP-PBX only

12. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) User call control: Click to call/pick up on OC or dial on phone Routing, features: PBX only, voice only, features from PBX incl. VM Media: Transported by PBX to PBX phone, no outside user Presence: PBX line presence PBX Co- Existence: Dual Forking (RCC optional) User call control: From OC or phone Routing, features: OCS features from OC, PBX features from phone, VM from PBX Media: Choice of voice to OC or PBX phone for each call; benefits of OC to outside users Presence (with RCC): Merged OCS “on-the- phone” presence and PBX line presence Enterprise Voice “Standalone” with Media Gateway or Direct SIP User call control: From OC Routing, features: OCS features, incl. Exchange UM integration Media: OC media including multimedia; all benefits of OC to outside users, etc Presence: OCS native “on the phone” presence

13. Users have both PBX phone and OC Users have either PBX phone or OC Legacy Scenario: RCC only (partially deprecated) Anchors PBX, not UC experience (how to place a call when nomadic? multimedia?) PBX economics and ops (proprietary PBX CTI, requires 3rd party signaling gateway…) Some RCC features deprecated in OC’07 RCC is dead-end, but can help extend life of existing PBX while preparing for OCS Voice PBX Co- Existence: Dual Forking (RCC optional) Richest experience, best of both worlds (limited VM integration) PBX economics and ops, dual licensing Likely to require PBX upgrade Limited availability to date but in plan Best for users who need PBX feature set, in combination with Enterprise Voice for other users Enterprise Voice “Standalone” with Media Gateway or Direct SIP Full UC experience UC economics and flexibility Interoperates with any PBX (with Gateway) Limited “pure voice” feature set and survivability in W13 Best for subset of users with simple feature set needs, especially nomadic, PC centric or collaborative; other users should stay on the PBX for now Gateway or Direct SIP: infrastructure, not feature issue; at small/medium scale, gateway is simple, inexpensive and proven method of inter-connecting; MS UC works with vendors to support Direct SIP to facilitate scaling

14. CCM Example

15. DNS and Certificates  The supported SIP URIs drive the DNS and certificate requirements For each domain supported DNS records and certificates are required For each domain supported DNS records and certificates are required  Typically the SIP URI is the same as a user’s e-mail address Eg sip:alistair.keay@uk.didata.com  There are two clients Communicator and Live Meeting. Two Sets of DNS records for internal and external connection. “meet:sip:alistair.keay@uk.data.com;gruu;opaque=app:conf:focu s:id385aa8ec0fcb4879dcb40c%3Fconf-key=JvrI7t324Vx” “meet:sip:alistair.keay@uk.data.com;gruu;opaque=app:conf:focu s:id385aa8ec0fcb4879dcb40c%3Fconf-key=JvrI7t324Vx”  Federation requires _sipfederationtls._tcp.uk.didata.com  Phone edition requires _ntp._udp.uk.didata.com

16. DNS and Certificates

17. Access Edge Certificates  For PIC a single FQDN of the access edge is given and this is the primary name in cert. eg acp.didata.com  Also for @didata.com _sipfederationtls._tcp.didata.com _sipfederationtls._tcp.didata.com _sip._tls.didata.com _sip._tls.didata.com  Now for @uk.didata.com the server offering the service for _sip._tls.uk. didata.com can NOT be acp. didata.com but must be same domain as srv record. Eg sip.uk.didata.com. This name needs to be added as a SAN to the certificate

18. Example of Edge Server  Cert Assigned to access Edge Acp. didata.com Acp. didata.com San sip.uk.didata.com, sip.fr.didata.com etcSan sip.uk.didata.com, sip.fr.didata.com etc  Cert Assigned to web edge Web.didata.com Web.didata.com  Cert Assigned to av ege Av.didata.com Av.didata.com  Cert Assigned to intranet edge Edge. didata.com (Can be internal cert. NB HLB etc) Edge. didata.com (Can be internal cert. NB HLB etc)

19. Example of Director  When deployed  Similar to the access edge role a cert is required with typically multiple SANs  Primary cert name is that of pool  Then for each domain _sipinternaltls._tcp. didata.com will point to sip. didata.com  _sipinternaltls._tcp.uk. didata.com will point to sip.uk. didata.com

20. Deploying Edge Servers  Decide on redundancy requirements, dr.  Capacity will drive minimum number  Co-locate all roles unless a good reason not to do so  For single edge box it is acceptable to have a NATed AV edge server (public ip)  For load balanced edge boxes the AV edge public IP must not be NATed  The intranet IP must never be NATed but must be routable

21. Number of IPs required

22. Install Steps  Install files, activate, choose roles, account, configure IP and names,

23. Firewall Rules

24. Call Flow and Firewalls

25. Directors _ Are they required  No…  But they are recommended

26. Role Of Director  Internally When multiple pools deployed When multiple pools deployed Deterministic Client Connection. Re-directs clients Deterministic Client Connection. Re-directs clients Only point where multiple SANs required Only point where multiple SANs required  From Outside Next hop from access edge Next hop from access edge Authenticates users before proxying on data Authenticates users before proxying on data