OpenScape Business V1 e migrazione da HiPath 3000 V9 (e precedenti): opinioni

[Vincenzob]

.... e quindi ho sbaglio qualche passaggio oppure....
i file xml generati non contengono info sull'hardware. Ho confrontato quello di ieri con quello esportato oggi sono identici (signature uguale).

Mha!

<?xml version="1.0" encoding="windows-1252"?>
<inventory_for_license_upgrade>
   <ignore_signature>
         <user_info>
            <publisher_x_ref_number></publisher_x_ref_number>
            <company_name>Localnet Livorno </company_name>
            <country>Italia</country>
            <street1>via umbria 7</street1>
            <street2></street2>
            <street3></street3>
            <city>Livorno</city>
            <zip_code>57014</zip_code>
            <country_code>IT</country_code>
            <company_email>vincenzo.becciu@localnettoscana.it</company_email>
            <notification_language>it</notification_language>
            <system_type>8</system_type>
         </user_info>
   </ignore_signature>
   <signature>4a09a1ad834a4221cf979db....................................

[Hunter]

Stesso "problema" che abbiamo riscontrato noi. Metto problema tra virgolette, perchè in realtà io non so se quella è un anomalia o la normalità. So solo che i primi due upgrade che abbiamo fatto i file xml erano diversi ed indicavano chiaramente quanti utenti TDM c'erano e quante licenze c'erano. 

[Riccardi]

Ciao
Il problema è la SD card, oppure la versione, prova a rifare la SD con la nuova aps " image_osbiz_v1_R2.2.0_324"
Il file .xml deve contenere il numero di licenze TDM relative al numero di interni funzionante sulla V9.

[Vincenzob]

Ciao
Il problema è la SD card, oppure la versione, prova a rifare la SD con la nuova aps " image_osbiz_v1_R2.2.0_324"
Il file .xml deve contenere il numero di licenze TDM relative al numero di interni funzionante sulla V9.

Ciao,
la SD card non è perchè l'ho rifatta ( con procedura utilizzando dvd e lettore sd card esterno) ma dopo il restore su OSBiz il file xml rigenerato nuovamente conteneva le medesime info senza mac ne TDM user vecchia H3K. Ho dovuto rispedire la cpu al fornitore che l'ha generato al volo... facendo i soliti passaggi che facevo io. Quindi alla fine non ho capito dovè il problema, probabilmente sul mio pc con Manager E ( anche se è ultima versione rilasciata).

Comunque gli aggiornamenti sull'istallazione appena terminata settimana scorsa sono:

Il restore del vecchio impianto H3K V9 su OSBIz, ha creato non pochi problemi (tenendo conto che era un impianto attivo e quindi lavorato fuori orario di lavoro) durante la configurazione lcr non completo e interconnessione sip1 non funzionante. Dopo varie prove la saggia decisione di eseguire un ripristino di fabbrica e riconfigurazione a mano del cliente. 72 Optipoint 500 , 24 bca e 40 linee flusso.

Quindi cigliegina sulla torta nell'esportazione del file xml ( fatto dal fornitore ) non mi sono accorto che i tdm user esportati per la licenza erano 77 e non 96. Ormai avevo generato il file di licenza, quindo ho dovuto acquistare i 19 tdm mancanti.

Questo perchè il DB H3K V9 aveva hardware collegato per 96 tdm( pallino verde ) ma per 19 telefoni non avevo inserito il numero d'interno. Ho provato a mandare una mail a CLS riconoscendo il nostro errore nel non aver assegnato il numero... ma la risposta è stata picche.

Quindi upgrade da V9 a OSBiz oltre ad hardware collegato assegnate anche il numero interno.

Mha....
Rimpiango un po le service di Carnelli e Dominjanni!

[Hunter]

 

Invece io devo dire che non ho avuto grossi problemi, anzi è stranamente andato tutto liscio fino alla fine (fin troppo perchè sono arrivato a caricare la licenza invece di lasciare la macchina nel periodo di prova, quindi non sono riuscito a fargli provare i servizi.

Nel mio caso l'unica criticità presente era che non sapevo come gestire l'IVM, non ci ho messo molto a capire che l'IVM anche sull'OSBiz è un "qualcosa" di "a sè stante" il sistema non genera licenze per le caselle VM, semplicemente lo lascia lavorare eliminando l'EVM ( mi sono chiesto a questo punto se avessi dovuto aprire le caselle sull'EVM per averne le licenze...bho  ) la conversione del DB non ha avuto alcun problema, anche se non era qualcosa di particolarmente elaborato, quindi potevo aspettarmelo.

Ho notato che gli handset che sulla versione 9 erano visti come Comfort (pur non essendo dei Professional) vengono visti come comfort anche sull'OSBiz, ovviamente se il cordless viene "ri-registrato" perde la funzionalità e passa in GAP.

A questo proposito io "stickerei" le cose da controllare assolutamente e che sul documento di migrazione non sono presenti, ad esempio quella di mettere numero e nome all'interno TDM (non è scritto da nessuna parte, io lo sapevo, però per brutte esperienze precedenti).

Un'altra cosa che ho notato è che facendo il copia incolla del file xml sul campo della migrazione licenze sul CLS è che il file crea una piccola "riga iniziale" che non va copiata nella fattispecie questa:

<?xml version="1.0" encoding="windows-1252" ?>

perchè generando la chiave di migrazione si viene a verificare un errore e prima di capire che il problema era quello ci abbiamo messo qualche minuto.

Saluti

[Vincenzob]

 

... ma Hunter ti dirò io ho penato un pò per il restore del db H3k V9, probabilmente per la presenza della booster card, ma inizialmente perche non generava il file .xml. e comunque ho ancora da capire se è un problema sull'istallazione Manager E sul mio portatile oppure bo.
Poca esperienza è la prima che mi capita di migrare, non mancherà occasione.
Comunque riguardo al restore del vecchio db... nella prima installazione, dove di esegue funzione per attivare i famosi 30 canali insterconnessione sip, non mi partiva la procedura ( cosa che ha poi fatto partendo da una situazione di restore complteto) quindi non mi funzionava l'autoattendant, LCR non aveva nemmeno una rotta configurata. Comunque personalmente la prossima la faro partendo da una situazione pulita, non certo da un restore...

Con il file .xml non ho avuto problemi, l'ho copiato tutto editandolo tutto con un file di testo e incollato su CLS.

Riguardo le licenze TDM, penso non si siano comportati tanto bene, nel senso che il database che ho allegato alla mail spedita a CLS per spiegargli che non avevamo messo il numero sulle porte ( dove fisicamente c'erano attaccati i telefoni ) perchè nel bel mezzo di un' ampliamento presso il cliente,
hanno risposto semplicecemente....Dear Mr. Becciu, please purchase the 19 licenses TDM to the customer.
quindi visti i tempi che corrono ( e quello che costano ) al cliente proveremo a fatturare queste nuove licenze NON PREVISTE... spenrando bene...

Non è proprio una bella considerazione dei Partner...

[Kimera]

C'è di che rimanere sconcertati...evidentemente, viste le esperienze tecniche di migrazione tutt'altro che "lineari" da voi riportate, c'è di che riflettere prima (e, aggiungo pure, al solo pensiero) di passare ad OpenScape Business V1 un sistema che si trova stabilmente in HiPath 3000 V9...personalmente rimango dell'idea che il Vendor abbia complicato molto le cose e mi chiedo: tutto questo a chi giova alla fine (a migrazione conclusa/vendita delle licenze conclusa)? al Vendor? al Partner (che diviene/oppure è già un Partner "sistemistico")? ad entrambi? al Cliente?

P.S. Sarò "polemico" ma un ragionamento si deve fare:
Non capisco (soprattutto di questi tempi) il ragionamento riguardo la mancata generazione delle licenze TDM pro-porta quando ad esse non è assegnato un numero di interno anche se il terminale Up0/E è fisicamente connesso (cosa lecita): se è difficoltoso procedere durante un ampliamento come viene riportato (so che durante un ampliamento ci sono decine di cose da fare/verificare/completare)...questo non significa forse che il Vendor (lo ammetto, mi sto infastidendo a chiamarlo Unify! di unificazione non vedo nulla) ha strutturato il sistema di migrazione per indurre i Partner a comprare (e a rivendere, se ce la fanno...) delle licenze (che prima non esistevano ed il Cliente non era obbligato ad acquistare!) per il solo fatto che viene reso difficile/impossibile conquistarle (in modo più o meno "furbo") durante l'attività di migrazione stessa? o forse in Germania migrano in un altro modo (altra scaletta di update)? mah...

[Hunter]

hanno risposto semplicecemente....Dear Mr. Becciu, please purchase the 19 licenses TDM to the customer.
quindi visti i tempi che corrono ( e quello che costano ) al cliente proveremo a fatturare queste nuove licenze NON PREVISTE... spenrando bene...

Non è proprio una bella considerazione dei Partner...

 

Ma che razza di risposta è!? 

Onestamente avrei risposto con una serie di improperi di vario genere.

Devo dire che il sistema di migrazione delle licenze comunque è di una stupidità disarmante. Semplicemente avrebbero dovuto "conteggiare" gli utenti TDM in base all'equipaggiamento di macchina e non al database perchè chiaramente essendo noi "umani" possiamo commettere errori, errori che tra l'altro non sono evidenziati, perchè sul manuale di migrazione non è scritto da nessuna parte di inserire gli utenti con nome e numero di interno, nè di scollegare eventuali optiset e sostituirli con openstage o optipoint, non è spiegato come vengono "licenziati" i VM, non è evidenziato che i dect passano da confort a GAP e queste per ora sono le cose più evidenti che abbiamo verificato. Ma immagino che che ne saranno altre. 

Credevo he la parola "partner" significasse che remiamo tutti dalla stessa parte, ma mi rendo conto che non è per niente così.

C'è di che rimanere sconcertati...evidentemente, viste le esperienze tecniche di migrazione tutt'altro che "lineari" da voi riportate, c'è di che riflettere prima (e, aggiungo pure, al solo pensiero) di passare ad OpenScape Business V1 un sistema che si trova stabilmente in HiPath 3000 V9...personalmente rimango dell'idea che il Vendor abbia complicato molto le cose e mi chiedo: tutto questo a chi giova alla fine (a migrazione conclusa/vendita delle licenze conclusa)? al Vendor? al Partner (che diviene/oppure è già un Partner "sistemistico")? ad entrambi? al Cliente?

Onestamente l'unico vantaggio che ho riscontrato nel fare l'upgrade è che l'OSBiz ha una sorta di HG1500 integrato, che le BS4 hanno 4 canali e non vanno licenziate, e che espandere il sistema ha un costo relativamente più basso, perchè se avevo necessità di 15 interni dovevo forzatamente acquistare una scheda da 8 Up0e o 4 BCA, mentre ora il costo della scheda è più basso ma devo pagare le licenze. Per il resto migrare da un HiPath 3X V.9 a un OSBiz non so se il gioco valga la candela. 

[Kimera]

Credevo he la parola "partner" significasse che remiamo tutti dalla stessa parte, ma mi rendo conto che non è per niente così.

Essere Partner...basicamente dovrebbe significare essere "compagni" di viaggio/lavoro/intenzioni...e sì, remare dalla stessa parte adottando un modello di Business che non scontenti nessuno o che accontenti tutti i principali attori coinvolti (Vendor, Partner, Cliente) in egual misura...invece Io vedo ultimamente un netto sbilanciamento. Convincetemi del contrario!

Onestamente l'unico vantaggio che ho riscontrato nel fare l'upgrade è che l'OSBiz ha una sorta di HG1500 integrato

Mi pare però che le potenzialità del media gateway integrato nella Motherboard dell'OpenScape Business non siano proprio comparabili con (nè superiori a)quelle del caro e vecchio modulo HG1500, lo dico anche in termini di termini di funzionalità "libere" dal nuovo modello di Licensing che il Vendor ha adottato (pensa solo al Trunking tra sistemi o verso SIP TS Providers) senza parlare poi dei canali puri gestibili (senza usare moduli aggiuntivi). Spero di non sbagliarmi perchè c'è da perdersi tra i numeri e, soprattutto, nessuno si è preso la briga di effettuare un confronto tecnico che faccia emergere perchè NON passare ad OpenScape Business e rimanere in HiPath 3000 V9 (a parte la ovvia considerazione del EoL che presto o tardi scenderà sulla testa di questi sistemi).

le BS4 hanno 4 canali e non vanno licenziate

Questo però va contestualizzato...quella che indichi è tipicamente una funzionalità che viene usata in sistemi nei quali il sistema DECT è altamente utilizzato e nei quali la copertura radio deve servire un ambiente molto denso di terminali (quindi, in ambienti del genere, se necessiti di questa particolare funzionalità è evidente che sei in un caso in cui ti aumenta anche il costo pro utente cosa che prima, se non mi sbaglio, non accadeva con il vecchio modello di Licensing pur dovendo licenziare i canali aggiuntivi sulle BS).

espandere il sistema ha un costo relativamente più basso, perchè se avevo necessità di 15 interni dovevo forzatamente acquistare una scheda da 8 Up0e o 4 BCA, mentre ora il costo della scheda è più basso ma devo pagare le licenze.

Anche questo dipende da che livello usi per valutare la convenienza della migrazione: una scheda con 8 Up0/E aveva e può continuare ad avere un costo "fisico" anche moderatamente alto, ora invece hanno abbassato tale costo introducendo però la variabile del "Licensing per User" quindi, tu dici, nonostante questo nuovo costo addizionale il costo totale è inferiore...sì ma non tieni conto che per arrivare nella situazione in cui sei in OpenScape Business V1 e puoi goderti questo costo inferiore sugli ampliamenti (MAC) devi aver speso per passare da HiPath 3000 V9 a OpenScape Business V1 e quindi il paragone va fatto a posteriori e non a priori...tenendo dunque in conto anche del costo di migrazione. Allora, a posteriori, il costo pro-porta è effettivamente più basso? lo è sempre? o solo per certe particolari migrazioni/configurazioni o solo per certi nuovi sistemi?

Per il resto migrare da un HiPath 3X V.9 a un OSBiz non so se il gioco valga la candela. 

Da quel che leggo, direi di no...soprattutto perchè non sento nessuno (in genere chi NON si lamenta di qualche cosa NON va a scriverlo nei Forum) che invece difende la migrazione non tanto dal punto di vista delle perdite/guadagni tecnici/economici ma dal punto di vista di cosa si perde o si guadagna a passare ad OpenScape Business V1 in termini di servizi...considerando però la situazione media delle PMI in Italia e del loro uso dei servizi UC. E' questo che spaventa.

[Vincenzob]

Per il resto migrare da un HiPath 3X V.9 a un OSBiz non so se il gioco valga la candela. 

[/quote]

Ha volte è necessario... in questo caso il mio cliente aveva 3800 con 3 schede 24 smlo2 e 1 slmae utilizzava 4 operatori automatici analogici a 4 canali, usati su vari servizi in entrata ( agenzia di viaggi ) con 2 flussi primari 3. Così non si poteva gestire più di 4 chiamate in entrata con il messaggio quindi, invece di inventarsi altre soluzioni con IVM integrati o esterni, abbiamo deciso di upgradare la macchina.

Alla fine, dopo le varie disavventure ( evitabili forse con procedura diversa ) il cliente è soddisfatto del risultato perlomeno era quello che si aspettava. Messaggio in entrata per tutti i clienti messaggio in lingua per chiamate dall'estero ecc.

Penso che una buona soluzione, per la Migrazione da V9 a OSBiz,  sia quella di utilizzare il database esistente del cliente e generare la chiave di licenza da parte di CLS direttamente evitando inutili errori e perdite di tempo, presso clienti dove oltretutto l'upgrade e su macchine che sono in produzione!

Ovvio che per noi non è stato indolore in termini economici.

Quindi clienti con impianti "vecchi e perfettamente funzionanti" da poter proporre una soluzione nuova ci sono. Ma..... è dura con i tempi che corrono convincerli, a meno che non parta da una loro necessità!


Saluti a tutti.

[Kimera]

Curiosità Off Topic: avevate preso in considerazione (ad esempio) l'opportunità di affiancare all'HiPath 3800 V9 (rimodulando la configurazione relativa alle VMs e/o agli Auto-Attendands ed relativi moduli fisici coinvolti) una piattaforma quale l'OSO LX oppure l'OSO HX?

Quali servizi la migrazione da HiPath 3800 V9 ad OpenScape Business V1 ha portato con sè che, nel vostro caso specifico (mi pare con delle problematiche legate soprattutto alla parte VMs/Auto-Attendands per la gestione vocale delle chiamate entranti), non potevano essere gestiti/attivati lasciando l'HiPath 3800 V9 sostanzialmente così com'era (sicuramente con delle riconfigurazioni di programmazione) e dirottando i nuovi servizi UC verso OSO HX od OSO LX?

Saluti, Kimera.

[Hunter]

Curiosità Off Topic: avevate preso in considerazione (ad esempio) l'opportunità di affiancare all'HiPath 3800 V9 (rimodulando la configurazione relativa alle VMs e/o agli Auto-Attendands ed relativi moduli fisici coinvolti) una piattaforma quale l'OSO LX oppure l'OSO HX?

Bè difronte a una situazione del genere io non so se avrei affiancato un 3800 ad un LX-HX. Credo che sarebbe stata una gestione più complessa del sistema. Onestamente ho sempre preferito le soluzioni "all-in-one" nella fattispecie OSO MX piuttosto che HiPath 3000 con server OSO. Vero che in definitiva ottieni gli stessi servizi, anzi, forse qualcosa di più peculiare, ma credo che la gestione di due apparati, che si parlano, è vero, ma che devi controllare e manutenere in ogni situazione, alla lunga creino un doppio indice di criticità, che su un sistema del genere, deve essere preso in considerazione.

[Kimera]

Credo che sarebbe stata una gestione più complessa del sistema.

Posso anche essere d'accordo su una simile opinione. D'altra parte bisogna anche essere pronti ad ammettere che la migrazione affrontata, vuoi per un motivo vuoi per un altro, non è stata affatto indolore, letto ciò che si è verificato; viene da chiedersi: "Quanto di quello provato si sarebbe verificato con l'integrazione di un OSO LX o di un OSO HX ad un sistema esistente?".

Ovviamente tutto quanto si discute dipende da come si progetta e realizza un sistema od un suo ampliamento.

Ad ogni modo...per controbattere sul tema della facilità di gestione per il sistema "All In One"...basterbbe ricordare solamente che una soluzione di tale tipo oltre che "compatta" è anche (o può divenire) un "Single Point of Failure".

Una soluzione a componenti separati (HiPath 3000 V9 + OSO LX/HX) permetterebbe invece, da un lato, di applicare ancora il concetto del "Dividi Et Impera" mantenendo sì due entità dalla gestione differente (non credo problematica) ma garantirebbe, dall'altro, anche di poterle controllare e gestire in modo separato e, forse, anche in modo abbastanza autonomo.

Come particolare, non vale poco...soprattutto di questi tempi dove i sistemi hanno la tendenza a specializzarsi e divenire così anche molto complessi.

Che succederebbe infatti se l'OpenScape Business V1 (inteso proprio come appliance "All In One") manifestasse qualche problema/anomalia alle funzioni UC (cosa tutt'altro che improbabile vista la complessità raggiunta)? le funzioni "tradizionali", le funzioni "voce" per capirsi, sarebbero salvaguardate rispetto a quelle UC (ed accadrebbe anche il viceversa) oppure un problema (tecnico/di configurazione/dovuto ad un aggiornamento Firmware) o una manutenzione azzardata manderebbe, rispetto ad una soluzione a componenti separati ma interconnessi, tutto il sistema a gambe all'aria?

Tornando però al tema della differenza dei servizi a cui accennavo, che sì può dire?