Lync 2010 migracion y coexistencia

3,132 views

Published on

Migración y coexistencia de OCS 2007 / OCs 2007 R2 a Lync Server 2010

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,132
On SlideShare
0
From Embeds
0
Number of Embeds
330
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lync 2010 migracion y coexistencia

  1. 1. Microsoft Communications Server "14“ Management: Migración y Coexistencia Guillermo Sánchez Consultor IT – EXO S.A gsanchez@itsanchez.com.ar
  2. 2. Descripción del Webcast • Objetivos – Planificar la coexistencia de CS 14 con las versiones anteriores de OCS (Cliente / Servidor) – Describir los pasos necesarios para la migración – Entender como funciona la coexistencia entre CS 14 y OCS 2007 – OCS 2007 R2 • Después del webcast debería conocer: – Planificación de plan de Migración – Conocer los escenarios de Migración – Actualizar OCS 2007 / OCS 2007 R2 a CS 14
  3. 3. Agenda • Fundamentos – Motivacion – Prioridades – Ámbito (Scope) • Planificando – ¿Que queremos migrar? – Demo: ¿Cómo migramos? – Migración de extremo a extremo (Flujo de trabajo) • Interoperativilidad • Lecciones aprendidas y casos atípicos
  4. 4. Coexistencia Motivación, Prioridades, Ámbito (Scope)
  5. 5. Lo mas importante al Migrar a CS 14 • Nueva arquitectura de adminitracion – Adminitracion Centralizada (Central Management) – Creador de Topología (Topology Builder) – Communications Server PowerShell – Communication Server Panel de Control (Control Panel) • Alejándose de – Dependencia de Directorio Activo (Active Directory) – Windows Management Instrumentation (WMI) – Microsoft Management Console (MMC 3.0) • La alta disponibilidad del servicio es un asunto critico.
  6. 6. Prioridades • Minimizar el impacto del usuario final • Minimizar la disrupción del servicio • Minimizar el costo de hardware • Reducir al mínimo el costo de TCO durante la migración.
  7. 7. Antes de Migrar OCS 2007 R2 Office Communications Server 2007 R2 Actualizaciones Requeridas Application Update URL Microsoft Office Communicator 2007 R2 July 2010 Update package http://go.microsoft.com/fwlink/?LinkId=204763 Microsoft Office Live Meeting 2007 July 2010 Update package http://go.microsoft.com/fwlink/?LinkId=204764 Microsoft Office Live Meeting Conferencing Add-In July 2010 Update package http://go.microsoft.com/fwlink/?LinkId=204765 Office Communications Server 2007 R2 September 2010 Update package http://go.microsoft.com/fwlink/?LinkId=204766 Microsoft Office Communicator 2007 R2 Phone Edition July 2010 Update package http://go.microsoft.com/fwlink/?LinkId=204767
  8. 8. Ámbito: Versiones anteriores • Esta soportado migrar de – Office Communication Server 2007 – Office Communication Server 2007 R2 • Desde ahora llamaremos “legacy” al grupo de versiones soportadas a migrar. • Las ultimas actualizaciones acumulativas (cumulative updates) son requeridas en todos los servidores y clientes legacy • No esta soportada la migración de LCS 2005 o versiones anteriores
  9. 9. Ámbito: Ruteo Soportado • Los clientes legacy pueden conectarse con OCS 14 • Ruteo en ambiente mixto (CS 14 / OCS) – pool with edge/director – pool with pools • La misma versión rutea – Edge and director – Gateway and mediation server – Pool and mediation server – Pool and monitoring/archiving – Pool and Group Chat
  10. 10. Ámbito: Ruteo No Soportado • Clientes CS 14 con servidores Legacy • Ruteo ambiente Mixto – Edge and director – Gateway and mediation server – Pool and mediation server – Pool and monitoring/archiving – Pool and Group Chat
  11. 11. Ámbito: Ruteo Ambiente Mixto
  12. 12. Ámbito: Migración Métodos y Escalas • Escalas hacia arriba o abajo – Pool-por-pool – Site-por-site – Global last – Side-by-side • Menor impacto usuario final • Sin corte de Servicio • Piloto  Prueba  Producción – Minimizar los requerimientos de Hardware – Realizar una prueba con pocos usuarios – Reducir el impacto del usuarios final Pools Data Center Sites Global Deployment Microsoft Redmond Tukwila-1 Tukwila-2 Dublin Dublin-1
  13. 13. Migración de Prueba ¿Que?¿Como?¿Por que?
  14. 14. ¿Como es la migración? • Topología – Servidores de confianza para servers, apps, edges • Configuración – Configuración Global (ex. location profile to dial plans) – Configuración de Usuarios(e.g. voice, conference policy) – Customizacion (ex. conference directories, contact lists, call forwarding settings) • Objetos de Contactos – Usuarios movidos a CS 14, configuración – Usuarios no movidos se contactan con OCS • Los clientes y dispositivos deben migrarse por separado Migrated Data Topology Configuration Users
  15. 15. Como: PowerShell, TB, y CSCP • Topologia – Topology Builder – Merge-CsLegacyTopology • Configuración – Import-CsLegacyConfiguration – Import-CsLegacyConferenceDirectory • Usuarios – Move-CsLegacyUser – Communication Server Control Panel • Objetos de Contactos – Move-CsApplicationEndpoint for application moves – Move-CsRgsConfiguration for Response Group moves Migrated Data Topology Configuration Users
  16. 16. Como: Piloto Test  Produción • Piloto – Instalar CS 14 mezclar e importar – Mover los usuarios de prueba instalar cliente CS 14 • Prueba – Verificar que funcione la coexistencia – Validar experiencia de administradores y nuevos usuarios • Produción – Definicion de nuevo Hardware – Mover todos los usuarios Legacy, instalacion nuevos clientes – Verificación final decomision del OCS 2007
  17. 17. Como: Piloto  Test  Produción Diferencias entre versiones a migrar
  18. 18. 2007 R2 Stage 2: Piloto CS 14 • Origen Pool 2007 R2 • Deploy 14 pool side-by-side • Activation adds 14 into legacy AD • Merge adds legacy into 14 CMS
  19. 19. 2007 R2 Stage 2: Move Trial Users • Leverage migration tools here • Trial users on both R2 and 14 pool to validate interoperability • Deploy 14 clients to some of trial users on 14 pool, legacy clients for others
  20. 20. 2007 R2 Stage 2: Routing with Pool 14 Pilot • External access through 2007 R2 director and edge
  21. 21. 2007 R2 Stage 3: Pilot 14 Edge and Director • Deploy 14 pilot edge and director together
  22. 22. 2007 R2 Stage 3: Routing with Pilot 14 Stack • Route 14 remote access through 14 edge and director • Route 14 federation through 2007 R2 edge and director • Keep 2007 R2 federation and remote access through 2007 R2 edge and director
  23. 23. 2007 R2 Stage 4: Production Edge and Director • Federation Flip • Update external federation DNS entries to point to 14 edge • Existing 2007 R2 deployment now dependent on
  24. 24. 2007 R2 Stage 4: Routing with Production 14 Edge and Director • Route 14 federation and remote access through 14 edge and director • Route 2007 R2 federation through 14 edge and director • Route 2007 R2 remote access through 2007 R2 edge and director
  25. 25. 2007 R2 Stage 5: Production 14 Pool • Move 14 pilot pool into 14 production • Expand hardware allocation to take all legacy users • Upgrade data center and support SLAs to full production level • If big changes, then rerun trial validation
  26. 26. 2007 R2 Stage 5: Migrate Rest of Users from 2007 R2 to 14 Pool • Leverage migration tools here • Move all users from target 2007 R2 pool onto 14 pool • Move non-user contact objects too • Fully vacate 2007 R2 pool in order to decommission pool
  27. 27. Compare 2007 to 2007 R2 • Stage 2: – Work is merger of 2007 R2 Stage 2 and 3 – Routing is same as 2007 R2 Stage 3 • Stage 3: does not exist, merged into stage 2 • Stage 4: does not exist, deferred to very end • Stage 5: – Work is same as 2007 R2 Stage 5 – Routing is same as 2007 Stage 2
  28. 28. 2007 Stage 2: Pilot 14 Pool, Edge and Director Side- By-Side • Deploy full stack of pool, edge, and director side-by- side instead of pool alone
  29. 29. 2007 Stage 2: Routing with Pool 14 Pilot, Edge, and Director • Same routing as Stage 3 of 2007 R2 migration staging AD Legacy Pool Legacy Director Legacy Edge Legacy Remote Access Legacy and Latest Federation Production Latest Pool Pilot Latest Director Latest Edge Latest Remote Access Latest Federation Legacy Users Audio, Video, and App Sharing all flow through Legacy Edge to Legacy Pool Latest Users Audio, Video, and App Sharing all flow through Latest Edge to Latest Pool Access traffic can flow through either edge, will be rerouted for media and data flows
  30. 30. 2007 Stage 5: Production 14 Pool, Edge, and Director • Same migration as Stage 5 for 2007 R2 • No change in routes, same as 2007 Stage 2 AD Legacy Pool Legacy Director Legacy Edge Legacy Remote Access Legacy and Latest Federation Production Latest Pool Latest Director Latest Edge Latest Remote Access ProductionLegacy Users Audio, Video, and App Sharing all flow through Legacy Edge to Legacy Pool Latest Users Audio, Video, and App Sharing all flow through Latest Edge to Latest Pool Access traffic can flow through either edge, will be rerouted for media and data flows
  31. 31. When: Scaling Up From Pilot  Trial  Production • Stage 0 includes planning migration staging pool- by-pool, site-by-site • Stage 1: Prepares Legacy Deployment • Stage 6 and 7 iterates for each pool in a site – Stage 5: Pilot Next Pool, Move Trial Users, Validate Via Trial – Stage 6: Move Next Pool into Production, Move Rest of Users, Vacate Legacy Pool • Stage 8: for each additional site, iterate through stage 2 through 7 • Stage 9: global, deployment-wide migration
  32. 32. Stage 10: Client/Device Migration • Communicator 14 client will not connect to legacy servers • 14 homed users with Communicator 14 can interoperate with legacy homed users • There alternatives to Communicator – Legacy clients – Reach (Silverlight web client conferencing only) – Attendee Communicator (per user install) • Some 14 features will not light up until there are 14 clients (presence privacy)
  33. 33. Partner Vendors and Migration • Consult vendors early – Gateway – Archiving – Monitoring – Third Party Applications – Consultant and IT solutions • Management architecture shift – Move to PowerShell, end WMI support – AD and Contact Object changes – Move to CS Control Panel, no more MMC • Consultancies geared up for acceleration
  34. 34. Interoperation
  35. 35. Interoperation • Definition: the behaviors of the legacy and latest product during the time legacy and latest coexist • Goal: Compatibility, Continuity of Service • Views into Interoperation – Conferencing Workload – Voice Workload – Audio Conferencing – Response Groups – Third Party Applications – Rest of the workloads
  36. 36. Conferencing Co-Existence (1) • Product direction: Live Meeting is converging into Communicator • Meetings just work during server migration • Legacy Office Communicator, Add-In Clients – Can schedule, edit, join, and ad hoc meetings – Meeting content is not moved • Legacy Live Meeting Client – Migrated Live Meeting meetings still work – Live Meeting console and Add-in still work
  37. 37. Conferencing Co-existence (2) • Experience pivots at client deployment • Communicator 14 install removes legacy communicator, add-in, Live Meeting client – Can not schedule or edit Live Meetings – Can join Live Meetings via Communicator 14 • Customers of Live Meeting on-premises – Plan for retraining to Communicator meetings – Some might shift to Live Meeting service
  38. 38. Enterprise Voice Co-existence (1): Versions Must Match Legacy Gateway Routes to Legacy Mediation Server • Incoming Routes • Outgoing Routes Upgraded Gateway Routes to 14 Mediation Server • Incoming Routes • Outgoing Routes
  39. 39. Enterprise Voice Co-existence (2) Versions Must Match • 14 Gateways coexist with legacy Gateways • Incoming Routes • Outgoing Routes
  40. 40. Audio Conferencing Co-existence • User calls CAA on OCS 2007 R2 to join a W14 conference. • CAA on OCS 2007 R2 transfers call to CAA on 14, CAA on 14 joins user to 14 AV MCU.
  41. 41. Response Group Service Co-existence (1) • Response Group Service (RGS) works with Microsoft Communications Server 14 co- existence. • OCS 2007 R2 and Microsoft Communications Server 14 users can be agents of response groups on OCS 2007 R2
  42. 42. Response Group Service Co-existence (2) • The admin can deploy RGS 14 and create new response groups. • OCS 2007 R2 and 14 users can be agents of non-anonymous response groups on 14 • Only 14 users can be agents for anonymous response groups.
  43. 43. Response Group Service Migration (3) • At any time, the admin can migrate all the RGS OCS 2007 R2 response groups to 14 (using PowerShell). • The migration is transparent for users. • The migrated response groups can be configured as all the other response groups, using PowerShell or CS Control Panel
  44. 44. Third Party Application Interop • Discuss support policy with vendor of app • UCMA 3.0 based apps – Installed on 14, can coexist with legacy pool • UCMA 2.0 based apps – Installed on legacy, can coexist with 14 – Installed on legacy, can be migrated to 14 – Can be installed directly on 14 • SIP Programming Language (SPL) – No runtime compatibility – App needs to be recompiled – App registration will be PowerShell not WMI
  45. 45. Other Component Co-existence • Will “just work” – Instant Messaging and Presence – Exchange Unified Messaging – Outlook Web Access • Legacy clients and components do not support DNS load balancing – Exchange Unified Messaging – Legacy Pools and Office Communicator – Gateways – Legacy Clients • Story pending for Group Chat and XMPP
  46. 46. Atypical
  47. 47. Atypical Migration Cases (1) • Tri-existence – Case: currently migrating to R2 or 2007 app – Guidance: must be on single version to migrate • Expanded Edge – Case: 2007 R2 edge expanded – Guidance: move to consolidated • No Hardware Budget – Case: need to maximize hardware reuse – Guidance: note 14 is 64 bit only and think through continuity of service driven resiliency
  48. 48. Atypical Migration Cases (2) • Selective Servicing – Case: selective approach to deploying updates – Guidance: latest updates are first support ask • Cloud Now – Case: want move from on-premises to hosted – Guidance: deploy 14 federated edge ASAP • On-Premises Live Meeting – Case: heavily integrated on-prem Live Meeting – Guidance: leverage compat, plan for transition
  49. 49. Atypical Migration Cases (3) • Want New Client Before New Server – Case: new UX alone will drive productivity – Guidance: prioritize those users for early move • Prerelease Partners – Case: customer deployed pre-release of 14 – Guidance: adding minor version upgrade • Premature Migration of a User – Case: User moved too early, does not fit yet – Guidance: user rollback supported, 14 customizations lost, 14 meetings need to be rescheduled, clients/devices need downgrading
  50. 50. Atypical Migration Cases (4) • Waited to long to get to 2007 releases – Case: customer has LCS 2005 or earlier – Guidance: “not supported”, “consult partners” • Didn’t manage older releases correctly – Case: some dirty AD data blocks migration – Guidance: backup AD, clean-up stray values • Delays in vendor partner compatibility work – Case: third party ISV or IHV critical path – Guidance: loop back with our partner teams
  51. 51. Next Steps • Planning – Deploy latest updates – Plan site-by-site sequence through deployment • Fund initial hardware investment – Pilot Microsoft Communications Server 14 pool – Production Microsoft Communications Server 14 director and edge • Edge preparations for OCS 2007 R2 – If expanded edge, move to consolidated – Prepare DMZs for another edge – Prepare for federation flip at Stage 4
  52. 52. Session Objectives and Takeaways • Session Objectives: – Plan for coexistence of CS 14 with prior versions of both server and client software – Describe the implications of various migration and coexistence approaches – Use our coexistence investments to support migration from prior versions to CS 14 • Session Takeaways: After this session I can: – Describe coexistence and migration motivation, implementation, and trade-offs – Walk customers through migration experiences – Evangelize migration is accessible, achievable
  53. 53. © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

×