Ho provato subito a passare da V2 R1.0.0 a V3 R3.11.0, l'upgrade si interrompeva proponendomi:

1 Factory default
2 Update 1
3 Update 2

Scegliendo 2 o 3 restituisce un errore e torna alle 3 opzioni non restando che scegliere 1, annullando di fatto il processo di upgrade.

Poi ho letto in una delle ultime service, che per diversa gestione dello spazio su disco, è necessario usare una release inferiore a V3 R3.2.0, quindi suggeriscono di usare V3 1.2.0 o 1.3.0 ora mi sfugge, dopodiché vai a V3 R3.11.0.
Comunque meglio farsi una bella immagine che in 15 minuti ti rifai il disco.

Saluti

rescue_OMX_V2_R1.0.0_003.img

I sw physdiskwrite 0.5.2 + PhysGUI per scrivere la chiavetta hanno apparentemente svolto la loro funzione, in realtà la chiavetta non ha funzionato, nel 2010 ricordo che tutto andò correttamente.

Forse a causa di aggiornamenti di XP non va più.

Saluti

Buongiorno a tutti,

ho un problema con il rescue disk,
ho preparato per sicurezza ben 2 chiavette,
avvìo OSOMX con chiavetta inserita ma di ferma sempre su "Verify DMI pool" per circa 5-6 minuti e poi riavvìa ripetendo il problema.

Avete qualche suggerimento?

Grazie,

buona giornata.

Ciao a tutti,

ho bypassato il problema installando un Hipath 2000 v2 recuperato, come nuovo nodo (7) nella sede di OSOMX Master.

OSOMX (1) vede solo questo nodo (7) come sede di tutti gli interni remoti, il collegamento OSOMX > Hipath 2000 è in SipQ ovviamente.
Nell' Hipath 2000 ho inserito solo l'lcr come un normale nodo (-2xx ecc. ecc.) e tramite H323 posso comunicare nuovamente con il resto della rete.

Ciao

Ho aggiunto alla rete in questione  il nostro OSOMX aziendale, ho creato prima la vpn col cliente... Funziona perfettamente per quanto riguarda le chiamate in rete con l' altro OSOMX.
(((LA centrale dell' ufficio però non vede più i bri isdn, è come se fossero scollegate dalla centrale, qualcuno sa perchè?))))

Escluderei i firewall a questo punto.

Ho un altro cliente che ha OSOMX in rete con H2000 V2 e funziona a meraviglia, quindi un pabx precedente a HOOEE...

Ciao a tutti,
pare che le vpn con le sedi remote non siano più stabili come prima, ho controllato saltuariamente da remoto il firewall nodo 1 e ho scoperto che a volte è giù la vpn con il nodo 2, a volte quella col 3 e coì via fino al 5, a volte sono tutte giù o solo 3 su 5 ecc.
Le adsl per le vpn sono dedicate al voip, la navigazione è assicurata da altro router (tutte adsl Alice).
Può essere che lo scambio dati in SipQ sia talmente basso da far chiudere le vpn ?
Inoltre le comunicazioni tra nodi sono scarse comunque, visto che sono negozi, non ci sono nemmeno PC che lavorano in rete con il nodo 1.
I firewall Watchguard Edge X55e in questione pare che non abbattano la connessione in caso di scarso traffico, infatti non ho trovato parametri tipo "Always Up", e il manuale dice chiaramemente in merito alla disconnessione: " do not do this ".

Oppure c'è troppa latenza sulla adsl nodo 1 e quindi il problema è lì, le vpn vanno giù per condizioni di rete insufficienti.
Innanzitutto dovrò trovare la soluzione per la stabilità delle vpn, poi vedrò per le comunicazioni tra OSOMX e HOOEE.

Ciao

Ciao, mi serve solo la chiamata base senza alcun servizio e dicevo del ping solo come controllo che la vpn sia in piedi.
Non funziona la chiamata nel senso che compongo il numero interno e mi dice "adesso impossibile", oppure rimane a display il numero e non succede nulla, quando invece la chiamata funziona la conversazione è perfetta e funziona anche per svariati minuti.
Ho qualche dubbio sui firewall (Watchguard) che sono fermi come sw al 2009,
se guardo nei log del firewall di una sede slave, vedo che a volte i pacchetti in arrivo dal pabx Master (source 192.168.1.2) risultano in arrivo dalla vpn e quindi transitano, a volte risultano in arrivo dall' interfaccia esterna e quindi vengono droppati...