Upgrade UCCX z 8.5(1) na 10.6(1)

Popis vychází z testované situace, kde se upgraduje jeden server (tedy pouze Publisher, žádný cluster) Cisco Unified Contact Center Express (UCCX) 8.5.1.11004-25 = 8.5(1)SU4, který běží jako virtuální server na VMware ESXi 5.5. Na aktuální verzi 10.6.1.10000-39 = 10.6(1).

Ověření kompatibility a dokumentace

Jako první krok plánování upgradu je dobré se podívat na kompatibilitu různých verzí UCCX s CUCM. Z informací v Compatibility Matrix for Unified CCX se dozvíme, že je možný přímý upgrade z verze 8.5(1)SU4 na verzi 10.6(1). Ale že UCCX 8.5(1) SU4 je kompatibilní s CUCM 8.0(1) až 9.1(2)SU3 a UCCX 10.6(1) je kompatibilní s CUCM 9.1(1) až 10.5(2)SU1. Tedy pokud jsme provedli upgrade CUCM na 10.5(2), tak s ním již není kompatibilní UCCX 8.5(1)SU4!

Obecně můžeme provádět upgrade CUCM a UCCX tak, že buď prvně aktualizujeme UCCX a následně CUCM nebo prvně CUCM a pak UCCX. Ve chvíli, kdy aktualizujeme CUCM a jeho služby jsou nedostupné, tak nefunguje také UCCX. Záleží ovšem na vzájemné kompatibilitě verzí. V mé situaci po upgradu CUCM přestalo fungovat UCCX a ani se do něj nebylo možno standardně přihlásit (pouze účtem Platform Admin, info o účtech Účty na UCCX). Bylo možno provést upgrade UCCX a pak již vše fungovalo.

V dokumentu Virtualization for Cisco Unified Contact Center Express ověříme, že verze UCCX 10.6(1) je podporována na VMware vSphere ESXi 5.0 U1, 5.1, 5.5 a vyžaduje 8 GB vRAM, 2 vCPU, 146 GB vDisk, pokud máme do 100 agentů.

Z Cisco Download můžeme stáhnout soubor UCSInstall_UCCX_10_6_1_UCOS_10.6.1.10000-39.sgn.iso, u kterého je popis UCCX 10.6(1) (non-bootable) - Used for upgrading from the latest SU on 8.5(1) and 9.0(2) and 10.0(1) and 10.5(1) releases.

Oficiální dokumentace na Cisco webu

• stručně k nové verzi Unified Contact Center Express Release Notes 10.6(1)
• podrobně o upgradu Cisco Unified Contact Center Express Installation and Upgrade Guide, Release 10.6(1)
• další informace Virtualization for Cisco Unified Contact Center Express - Upgrading Unified CCX.

Standardní upgrade UCCX

Ve verzi 8 bylo UCCX sjednoceno s CUCM, takže i upgrade probíhá obdobně. Existují také různé typy upgradu:

• L2 Upgrade - Linux to Linux upgrade je nejjednodušší možnost, instalace probíhá do druhého (neaktivního) oddílu (partition) a server stále běží a obsluhuje klienty. Po instalaci se rozhodneme, kdy chceme přepnout verzi a provedeme restart serveru. Třeba upgrade 10.5.x na 10.6.x. Někdy se mluví o Maintenance Release (MR) upgrade, třeba 9.0.x na 9.0.y, nebo Service Update (SU), třeba 9.0.xSUy na 9.0.xSUz.
• Refresh Upgrade - tento upgrade se provádí ve chvíli, kdy došlo ke změně operačního systému. V průběhu instalace dojde (několikrát) k restartu a služby serveru jsou mimo provoz. Upgrade probíhá obdobně jako čistá instalace. Třeba upgrade 8.5.x na 10.6.x nebo 10.0.x na 10.6.x.
• Windows to Linux Upgrade - starší verze UCCX běžely na Windows, od verze 8.x jde o Linux, takže je třeba zásadní změna. Jde o upgrade z 7.0.x na 8.x a dále.
• COP soubor - oprava/úprava aktuální verze, někdy vyžaduje restart, instaluje se do aktivního oddílu a není možno odinstalovat

Náš upgrade UCCX z 8.5(1)SU4 na 10.6(1) je tedy Refresh Upgrade.

Příprava na upgrade

Předtím, než se pustíme do upgradu, je potřeba si ověřit a připravit několik věcí. Ty hlavní jsou:

• Ověřit, že máme k dispozici aktuální a kompletní DRS zálohu UCCX clusteru!
• Není špatné obecně ověřit, že všechny služby na serveru běží a vše je OK
• Patrně je to normální chování, hned po upgradu se server hlásí jako nelicencovaný a dokud nenahrajeme upgradovanou licenci, tak nefunguje (v menu chybí většina položek). Takže potřebujeme dopředu připravit nový licenční soubor.
• Připravit se na to, že u UCCX 10.6 se maximální počet IVR portů určuje podle HW parametrů, což znamená podle konfigurace VM, kterou jsme zvolili při vytváření virtuálu (počet agentů). Pokud jsme zvolili nejmenší konfiguraci pro 100 agentů, tak budeme mít 100 IVR Ports, i když jsme třeba před upgradem měli 150.

Proces upgradu

Obdobně jako u CUCM můžeme využít toho, že máme server ve virtuálním prostředí. Vytvořit kopii a provádět testování, zatímco nám produkce běží. K tomu se nám bude hodit síťově oddělené virtuální prostředí, které jsme si popsali v Migrace CUCM z fyzického HW do VMware kapitole Proces migrace.

Stručně popsaný postup upgradu je následující:

• splněné podmínky z předchozí kapitoly Příprava na upgrade (hlavně záloha a ověření funkčnosti)
• nainstalujeme potřebný COP soubor, při upgradu UCCX z nižší verze než 10.5 se nejprve musí aplikovat (instalovat) Cisco Options Package (COP) soubor ciscouccx.refresh_upgrade_v1.7.cop.sgn (instalace provede na konci restart Tomcatu) - popsáno v článku CUCM a UCCX instalace COP souboru, Locale, Device Pack

• instalační ISO soubor buď nahrajeme na FTP/SFTP server nebo jednoduše připojíme do virtuální mechaniky našeho UCCX VM pomocí VMware
• provedeme upgrade Publisheru
• přepneme verzi Publisheru
• pokračujeme nutnými akcemi po upgradu

Průběh vlastního upgradu

• Instalační ISO UCSInstall_UCCX_10_6_1_UCOS_10.6.1.10000-39.sgn.iso připojíme do virtuální mechaniky našeho UCCX VM
• pomocí GUI UCCX zahájíme upgrade - Cisco Unified OS Administration - Software Upgrade - Install/Upgrade
• zvolíme zdroj instalace (Source) DVD/CD, kořenový adresář (Directory) / a můžeme zadat SMTP server pomocí kterého dostaneme nějaké informace o průběhu upgradu

• v zadané lokalitě se hledají akceptovatelné soubory, pokud se nějaké naleznou, tak se nabídnou k výběru
• přečteme si různá upozornění, co se doporučuje udělat nyní a co po upgradu (přepnout verzi a vygenerovat a nainstalovat nové klienty)

• modální okno nás upozorní, že jde o Refresh Upgrade

• zahájí se instalace a zobrazuje log v textovém okně, trvá to nějakou dobu (okolo 7 minut) a pak se zobrazí informace, že příprava Refresh Upgrade proběhla, systém se restartuje a pokračuje v instalaci

• připojíme se pomocí VMware Virtual Machine Console na daný virtuál a sledujeme instalaci
• při restartu musíme odpojit instalační ISO z virtuální mechaniky (pokud to nestihneme a naběhne nám stránka s testem média, tak jej odpojíme a restartujeme)
• automaticky pak probíhá instalace, která je stejná, jako při čisté instalaci UCCX a trvá stejně dlouho (tedy běžně okolo 1:45 hodiny)

Přepnutí verze

Instalace (i když jde o Refresh Upgrade) proběhla do neaktivního oddílu a po dokončení nastartovala opět původní verze (na rozdíl od CUCM nemáme možnost zvolit přepnutí verze v průběhu instalace). Takže další krok je třeba provést ručně přepnutí verze.

Pomocí CLI nebo GUI Cisco Unified OS Administration - Settings - Version, zvolíme možnost Switch Versions.

Následuje potvrzení.

A dostaneme zprávu, že přepnutí verze bude trvat delší dobu a průběh restartu máme sledovat pomocí CLI. Opravdu, než se začal server restartovat, tak se zdánlivě nic neděje a trvalo to asi 20 minut. Poté již nastartovala nová verze.

Operace po upgradu

Bodově hlavní operace, které je hned po upgradu nutno provést. Některé jsou dále podrobněji rozepsány.

• Pokud byl virtuální stroj vytvořen pro starší verzi UCCX (pomocí staršího OVA template), tak se doporučuje změnit Guest OS na RHEL 6 (64 bit), síťový adaptér na VMXNet3, pokud je aktuálně méně vRAM, tak ji zvednout na požadované množství 8 GB. V případě problémů s VMware Tools můžeme použít CLI příkaz utils vmtools upgrade. Více informací v Modifying Virtual Machine Settings after Upgrade (L2 and RU) to Version 10.0(1) and later
• Nahrát novou licenci
• V dokumentaci jsem na to nenarazil, ale v praxi vždy po upgradu dostanu zprávu, že The Cisco JTAPI Client versions are inconsistent, takže je třeba provést JTAPI Resync
• Aktualizovat klienty (Agent Desktop, Desktop Administrator a Supervisor Desktop)

Cisco JTAPI Resync

Při každém upgradu UCCX jsem zažil situaci, že po připojení na Cisco Unified CCX Administration se zobrazí okno s informací, že je třeba provést Cisco JTAPI Resync.

The Cisco JTAPI Client versions are inconsistent. Please go to Cisco JTAPI Resync in the Unified CM Telephony Subsystem
 to install the Cisco JTAPI Client.

Půjdeme do menu Subsystems - Cisco Unified CM Telephony - Cisco JTAPI Resync a inicializujeme operaci.

Po dokončení je třeba provést restart služby nebo celého serveru (trval u mne 8 minut).

Aktualizace klientů - Client Configuration Tool

Jak jsme byli upozorněni již před upgradem, tak je po přepnutí verze potřeba spustit aplikaci Cisco Unified CCX Client Configuration Tool, která ze serveru stáhne instalace Agent Desktop, Desktop Administrator a Supervisor Desktop, nějak je upraví a opět nahraje na server.

Aplikaci stáhneme z UCCX - Cisco Unified CCX Administration - Tools - Plug-ins - Cisco Unified CCX Desktop Suites odkaz Cisco Unified CCX Client Configuration Tool. A spustíme stažený CAD Client Configuration.msi (na stanici musíme mít Java RE minimálně verze 1.7).

Nejprve musíme zadat adresu serveru.

Dojde ke stažení jednotlivých instalací.

A jejich opětovnému nahrání na server.

Při prvním spuštění klientů (Cisco Agent Desktop) dojde automaticky (po odsouhlasení) k jejich aktualizaci.

Otestování po upgradu

Po dokončení upgradu je určitě důležité ověřit stav služeb a celého serveru a otestovat funkčnost. Pokud jsme prováděli upgrade v testovacím prostředí v izolované síti, tak potřebujeme dva telefony. Na jeden se přihlásíme účtem agenta UCCX. Na servisní stanici nainstalujeme Cisco Agent Desktop a vyzkoušíme přihlášení (případně upgrade agenta). Z druhého telefonu vyzkoušíme volání na různé Hotline (UCCX skripty) a otestujeme jejich chování.

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).

Kontrolu služeb provedeme v Cisco Unified CCX Serviceability - Control Center - Network Services, všechny služby musí mít status IN SERVICE. V Cisco Unified CCX Administration - System - License Information - Display license ověříme licenci. Pod Cisco Unified CCX Administration - Subsystems - Cisco Media zkontrolujeme kanály (IVR porty).

Na CUCM můžeme ověřit registrace z UCCX, v Cisco Unified CM Administration - Device - CTI Route Point, že všechny jsou ve stavu Registered. Pod  Cisco Unified CM Administration - Device - Phone vyhledáme Device Type = CTI port a také musí být všechny ve stavu Registered.

Na UCCX otevřeme všechny aplikace Cisco Unified CCX Administration - Applications - Application management, jestli se nezobrazí nějaká chyba, jako

An error occured while loading the Script SCRIPT[scriptname.aef]. Please check log for more details.

Problémy se skriptem

Na několika aplikacích se mi zobrazila výše uvedená chyba skriptu. Ve všech případech byl v tomto skriptu použitý Java kód pro zaslání emailu. Dle informací UCCX 10.6 používá Sun JRE 1.7.0_40, starší verze využívaly předchozí verze Java. Custom JAR proto musí být nově zkompilovány (Integration Custom JAVA application with UCCX 10.0), to ale nebyla moje situace. Navíc má být problém, že skript nejde otevřít ani v UCCX Editoru (musí se použít stará verze), ale tam se mi otevřel i zvalidoval.

Detailní informace o chybě bychom měli nalézt v logu. Má se jednat o MIVR Trace Logs, které stáhneme z UCCX serveru pomocí Real-Time Monitoring Tool (RTMT) - Trace & Log Central - Collect Files - Cisco Unified CCX Engine - nic dalšího Next, Next Save (Tech Tip: Collecting MIVR Logs in UCCX / IP IVR 8.x & later). Tam jsem ale nic nenalezl.

Řadou pokusů jsem zjistil, že chyba nastává, když se v kódu použije proměnná javax.mail.Message.RecipientType.TO. Když jsem vyměnil dva řádky

message.setRecipients(javax.mail.Message.RecipientType.TO, javax.mail.internet.InternetAddress.parse(EmailRecipient));
javax.mail.Transport.send(message);

za jeden nový

javax.mail.Transport.send(message, new javax.mail.Address[]{new javax.mail.internet.InternetAddress(EmailRecipient)});

Tak vše začalo fungovat.

Licencování

Na rozdíl od CUCM, kde se začal pro licencování využívat Prime License Manager, tak u UCCX zatím zůstává vše při starém. Licence je vázána na první uzel (Publisher) pomocí License MAC, která se sestavuje z řady parametrů serveru. Oficiální popis Unified CCX Licenses, jde o následující hodnoty (uvedeny jsou i příklady):

• Time zone: Europe/Prague
• NTP server 1 (or none): 10.1.0.10      
• NIC speed (or auto): auto
• Hostname: uccx
• IP Address: 10.0.0.4
• IP Mask: 255.255.255.0              
• Gateway Address: 10.0.0.1
• Primary DNS: 10.0.0.10
• SMTP server: 10.0.0.20
• Certificate Information (Organization, Unit, Location, State, Country): Firma s.r.o., IT, Praha, CZ, CZ

Tyto údaje zadáváme při instalaci v průvodci a později je můžeme měnit. Pokud jakoukoliv hodnotu změníme, tak se okamžitě změní licenční MAC a začne běžet 30 dní Grace Period na instalaci nové licence. Pokud hodnotu vrátíme zpět, tak se licence stane opět validní. Vygenerování licenční MAC z daných hodnot můžeme i na webu Cisco Unified Communications Answer File Generator. Hledal jsem, jak se dají změnit Certificate Information, jde to pomocí CLI příkazu

set web-security IT "Firma s.r.o." Praha CZ CZ

Při provedení upgradu serveru se (většinou) licenční MAC nezmění, ale licence pro starší verzi již není platná. V dokumentaci License Grace Period se uvádí, že pokud licence přestane být platná, tak máme 30 dní Grace Period, kdy můžeme fungovat bez licence. To by bylo obdobné chování jako u CUCM, kde po upgradu opravdu funguje 60 dní Grace Period. V praxi ale UCCX hned po upgradu nefunguje a hlásí, že nemá licenci (různé zdroje potvrzují, že jde o běžný stav).

Pomocí Cisco Product Upgrade Tool musíme požádat o upgrade licence. Tu následně nahrajeme na UCCX, třeba pomocí webového rozhraní Cisco Unified CCX Administration - System - License Information - Add License(s). Poté je doporučeno provést restart.

Bug CSCur84592 - žádné IVR porty

Po korektním upgradu a nahrání licence jsem narazil na problém, že se v detailech licence zobrazovalo Total IVR Port(s): 0 (a opravdu žádné IVR porty nebyly, před upgradem byla hodnota 150).

Jedna věc je, že někdy v minulosti došlo ke změně, a pro UCCX verze Standard a Enhanced (Premium je na tom hůře) se počet IVR portů určuje podle HW parametrů. To ve virtualizaci znamená dle konfigurace OVA šablony. Při nasazení šablony volíme, jestli jde o konfiguraci pro 100, 300 nebo 400 agentů, a podle toho dostaneme 100, 300 nebo 400 IVR portů. Informaci o tom nalezneme v oficiální dokumentaci (docela skrytou) Cisco Unified Contact Center Express Design Guide, Release 10.6(1) - IVR Ports nebo v různých diskusích How to change the Number of IVR ports in a UCCX?.

Ale to, že na migrovaném a upgradovaném UCCX je 0 IVR portů, je způsobeno bugem UCCX: Total number of IVR ports 0 after upgrade to UCCX 10.X. V popisu je sice uvedeno, že jsou postiženy pouze verze 10.0(1) a 10.5(1), ale to nebude úplně pravda. Jediným řešením je kontaktovat Cisco TAC, kdy se technik musí vzdáleně připojit na náš UCCX server a pomocí účtu root modifikovat interní parametry.

Sledoval jsem zásah technika a také se snažil najít nějaký workaround (technik mi opravil pouze testovací server a doumlouvání času pro ostrý upgrade bylo hodně složité), takže zde uvedu různé podrobnosti. Celý problém je v interních proměnných, kde je uveden výrobce a model serveru. Na původním fyzickém serveru jsem měl HP, MCS7825H3, na čistě instalovaném virtuálním serveru je uvedeno VMware, Inc., MCSVMware. Dle mého názoru je chyba, že tyto údaje jsou součástí zálohy, takže při migraci se přepsali údaje virtuálního serveru. Verzi CUCM 8.6 to nijak nevadilo, ale po upgradu na CUCM 10.6 to je problém (možná proto, že se počet IVR portů určuje podle HW parametrů a zde se objevuje hodnota, se kterou Cisco nepočítá).

Pozn.: Inkriminované hodnoty si může na UCCX serveru zobrazit a dopředu ověřit, že jde o náš problém. Pomocí GUI UCCX Cisco Unified CCX Administration - System - Server - Info (details) v položce Properties.

Původně jsem myslel, že by se dal problém obejít tak, že po upgradu provedeme zálohu. Pak nově nainstalujeme čistý server a obnovíme zálohu. Bohužel se s obnovou přepíší i tyto špatné hodnoty.

Takže je třeba se domluvit s TACem, technik se připojí přes WebEx. Nejprve mu musíme povolit přístup na UCCX server, kde v CLI zadáme dva příkazy (třetí nám zobrazí aktuální stav).

utils remote_account enable
utils remote_account create ciscotac 10

utils remote_account status

Pro úpravu hodnot využil technik nástroj CET Tool (cettool.exe), který je možno stáhnout z UCCX serveru https://UCCX-DNS/uccxinstalls/CetTool.exe. Spouští se na Windows stanici (s právy lokálního administrátora). V aplikaci se pak zadává připojení na UCCX server a účet root.

První termín se technikovi nezadařilo, aplikace padala na nějakou Java výjimku (kterou ani nestudoval), takže nakonec to sváděl, že je třeba čistá stanice s Windows 7 32 bit (což se ukázalo, že problémy nebyl). Při druhém termínu již po několika hodinách uspěl. Zjistil, že na serveru chybí složka /opt/cisco/uccx/temp, kam si CetTool ukládá výsledný soubor exportfile.gz. Po jejím vytvoření s právy user - uccxuser, group - uccxservice již nástroj fungoval.

Takže bylo možno změnit v uzlu com.cisco.crs.cluster.config.NodeConfig na záložce Computer Info hodnoty

Model: MCSVMware (původně Hardware Type: MCS7825H3)
OS Version: 2.6.18-274.12.1.el5PAE (původně 2.6.9-89.0.20.ELsmp, při čisté instalaci 2.6.32-358.18.1.el6.bz1012042.1.x86_64)
Vendor: VMware, Inc. (původně HP)

Po tomto zásahu se již správně zobrazilo 100 IVR portů a služby UCCX serverů korektně fungovaly.