Výchozím bodem, zde popisované situace, je jeden server Cisco Unified Contact Center Express (UCCX) 8.5.1.11004-25 = 8.5(1)SU4. UCCX běžel, stejně jako CUCM, na fyzickém serveru Cisco MCS 7825 H3 (HP7825H3), což je HP Proliant DL320 G5, kterému již skončila podpora.

Informace o podpoře, kompatibilitě apod.

Informace o podporovaném HW, SW a přímém upgradu nalezneme v Cisco dokumentech. Od verze UCCX 10.0 není podporován fyzický HW, ale pouze virtualizace.

Compatibility Matrix for Unified CCX

Unified CCX Software Compatibility Matrix for 8.5(1) SU4

Unified CCX Software Compatibility Matrix for 10.6(1)

Podpora virtuálních serverů VMware pro CUCM. Verze UCCX 8.5(1) SU4 je podporována na VMware vSphere ESXi 4.0 U3, 4.1 U1, 5.0, 5.1. Požadavek je fyzický server s procesorem Intel Xeon a minimálně 2 vCPU, 4 GB vRAM, 1x 146 GB vDisk, 1x vNIC. Verze UCCX 10.6(x) je podporována na VMware vSphere ESXi 5.0 U1, 5.1, 5.5, vyžaduje 8 GB vRAM.

Virtualization for Cisco Unified Contact Center Express

Unified Communications in a Virtualized Environment

Podrobnější požadavky na virtualizaci jsou popsány v UC Virtualization Supported Hardware.

Migrace do virtuálního prostředí

Oficiální informace o migraci UCCX do virtuálního prostředí popisuje článek Migrating and upgrading Unified CCX from physical to virtual server. Princip je stejný jako u CUCM (zde není možnost využít PCD), provedeme čistou instalaci a obnovíme zálohu.

Proces migrace

Využijeme síťově oddělené virtuální prostředí, které jsme použili pro migraci CUCM, a do něj přidáme nový server pro UCCX. Migrace bude probíhat následovně:

• příprava virtuálního prostředí s izolovanou sítí a pomocných strojů - máme hotovo
• kontrola UCCX a ověření, že máme aktuální zálohu (nebo provedení manuální zálohy), od doby zálohy se nesmí provádět změny konfigurace
• vytvoření virtuálního stroje z OVA šablony a čistá instalace se stejnými hodnotami jako má provozní server
• obnova zálohy
• přesun (rehost) licence pro novou licenční MAC
• vypnutí fyzického prostředí a přepojení virtuálního

Instalace UCCX serveru

Z Cisco download stáhneme OVA template cucm_8.6_vmv8_v1.5.ova (nebo lépe novější UCCX_10.6_vmv8_v2.6.ova) a z něj vytvoříme virtuální stroj. Při vytváření volíme verzi (nastaví HW parametry) dle počtu agentů.

Pozn.: Jestli v OVF zvolíme konfiguraci pro 100 agentů nebo 300 či 400, je důležité i do budoucna a to nejen pro maximální počet agentů, ale také IVR portů. Ve verzi 8.6 můžeme mít konfiguraci pro 100 agentů a 150 IVR portů, ale když uděláme upgrade na verzi UCCX 10.x, tak 100 agentová verze nastaví 100 IVR portů (a obdobně 300 agentová 300 portů).

Do virtuální mechaniky připojíme instalační ISO, já jsem použil Bootable_UCSInstall_UCCX_8_5_1_UCOS_8.5.1.11001-35.sgn.iso. A započneme instalaci, kdy v průvodci vyplníme údaje o serveru. Je důležité, aby byly naprosto stejné, jako u stávajícího serveru, který chceme migrovat.

Průběh standardní instalace mapuje v obrázcích článek UCCX 8.5 čistá instalace. Instalace probíhá identicky jako u CUCM. V kroku je Checking Network Connectivity dostaneme varování, že je nedostupný DNS server. Můžeme zvolit Ignore a pokračovat v instalaci.

Na Linuxovém serveru mi přestala fungovat služba NTP, takže jsem dostal varování o jeho nedostupnosti.

Po opravě se korektně detekoval a instalace mohla pokračovat.

Upgrade na potřebnou verzi

Protože já mám provozní servery na vyšší verzi, než pro jakou jsem měl instalační ISO, tak jsem musel udělat upgrade na provozní verzi. Upgrade můžeme v tomto případě udělat rovnou jako součást instalace (popsáno v návodu) nebo spustit hned po dokončení instalace.

K virtuálu jsem připojil ISO UCSInstall_UCCX_8_5_1_UCOS_8.5.1.11004-25.sgn.iso. Pomocí Windows stanice jsem otevřel webové rozhraní Cisco Unified OS Administration a provedl upgrade z DVD/CD (upgrade můžeme provést i pomocí CLI). Upgrade popisuje článek UCCX proces standardního upgradu.

Obnova zálohy - Restore

Obnova se provádí opět identicky jako u CUCM. Celý průběh mapuje článek UCCX 8.5 Disaster Recovery. V oficiální dokumentaci (sice pro novější verzi) je popis Restore SA Setup (with Rebuild) (SA je Stand Alone, HA je High Availability). Potvrzuje moji myšlenku, že je možné přeskočit úvodní konfiguraci a hned po instalaci se pustit do obnovy.

Využijme SFTP server na servisní stanici. Obnova se provádí přes webové rozhraní UCCX - Disaster Recovery System. Nejprve musíme definovat Backup Device, což je SFTP server na naší stanici, menu Backup - Backup Device.

Poté zahájíme obnovu pomocí průvodce Restore - Restore Wizard. Zvolíme náš server, nabídnou se nalezené zálohy, volíme vlastnosti, které chceme obnovit. Poslední krok je zvolit servery, které chceme obnovit, kde zvolíme náš jediný server.

Obnova ve virtuálním prostředí u mne proběhla za 20 minut. Následně je třeba provést restart, který trval 7 minut.

Při úspěšném dokončení zálohy se zobrazí informace, že po restartu je potřeba provést JTAPI data resync. A dokonce informace, že se nachází Cisco Unified UCCX Administration - Subsystems - Cisco Unified CM Telephony - Data Resync. Jenže taková položka se v menu nenachází. Hledal jsem, jestli se má použít Cisco JTAPI Resync nebo Data Synchronization, ale žádnou informaci jsem nenalezl. Pustil jsem tedy JTAPI Resync a pouze kontrolu Data Sync, vše proběhlo bez chyb.

Abychom mohli stahovat klientské balíčky z UCCX, tak je nejprve musíme vygenerovat. Vygenerování klientských balíčků pomocí aplikace Cisco Unified CCX Client Configuration Tool. Vyžaduje na stanici Java Runtime. Celý proces proběhl během 2 minut.

Ověření funkčnosti

Na testovací telefon v izolované síti se přihlásíme účtem agenta UCCX. Na servisní stanici nainstalujeme Cisco Agent Desktop a vyzkoušíme přihlášení, případně další funkce.

Pozn.: Pokud se nám nedaří přihlásit do aplikace, tak může být problém, jestli na CUCM do RMJTAPI uživatele přidáváme telefony (pak tam musí být náš testovací) nebo device profily. A jestli daný uživatel není přihlášen i na jiném telefonu (díky obnově zálohy CUCM).

Problém s obnovou

Funkční testy proběhly bez chyb, tak jsem počítal, že je obnova v pořádku (ta samozřejmě ani v logu neuváděla žádnou chybu). Ale ukázalo se, že nefunguje napojení agenta na Service Desk. V rozhraní UCCX - Cisco Desktop Administrator chybělo Work Flow pro tento účel. Když jsem studoval dále, tak celkově v Cisco Desktop Administrator byla řada nedostatků. Na internetu jsem nalezl, že chybějící Work Flow po DRS obnově řeší více lidí, ale žádné řešení.

Pod Layout List chyběl defaultní seznam OODefault. Parametr Call Variable 1 jsem měl přejmenovaný na CSQ a přidaný do seznamu Default, oboje bylo pryč. V menu Multiline, Monitoring & Recording chyběla položka Display Settings. Chybělo celé menu Cisco Unified Presence Settings. Při otevření VoIP Monitoring Device nebyla k dispozici žádná Default VOIP Monitor Service a na stránce se zobrazovala chyba (stejná byla i na stránce Remove VoIP/Recording & Playback Services).

CDAUI2000 An error has occurred. Contact technical support.

Pozn.: V oficiální dokumentaci jsem nalezl jedinou poznámku, která říká, že pokud editujeme defaultní Enterprise data fields nebo layouts, tak se změny ztratí po upgradu, ale custom fields zůstanou zachovány.

Několikrát jsem zkusil nově zálohu a obnovu (vždy jsem se vracel ke snapshotu po čisté instalaci) a podrobně jsem prostudoval logy, kde nebyla žádná chyba. Pokaždé jsem dopadl stejně. Zkoušel jsem opravit jednotlivé chyby. Vytvořit nově Work Flow a upravit související nebyl problém a vše fungovalo. Ale jak se zbavit chyby u VoIP Monitoring jsem nikde nenalezl (odpovídající služby běžely).

Nakonec jsem jen tak udělal pokus, založený na mé předchozí zkušenosti s Disaster Recovery, kdy při obnově na fyzický server nefungovalo vše, tak jsem dělal obnovu znovu a vše začalo chodit. A ono to opravdu pomohlo. Udělal jsem několik pokusů a pokaždé bylo vše bez problémů, když jsem dodržel postup. Na čistě instalovaný server obnovit data, provést restart a hned znovu obnovit stejná data.

Přijde mi to jako velmi závažná chyba, u mne se projevila na verzi UCCX 8.5(1)SU4.

Získání licence

Vše je stejné jako při migraci CUCM. Po obnovení zálohy systém detekuje, že má neplatnou licenci. Máme 30 dní (grace period) na nahrání korektní licence. Stejná situace je i s licenční MAC, takže odkazuji na závěr minulého článku o migraci CUCM.