Dopo l'aggiornamento di SQL Server, è necessario aggiornare Vault Server. È possibile aggiornare Vault Server per ambienti a sito singolo o multisito.
La procedura ottimale consiste nel completare la fase di convalida del backup e rivedere la fase di aggiornamento SQL prima di avviare l'aggiornamento di Vault Server.
Per ulteriori informazioni, consultare la sezione relativa al proprio ambiente.
Seguire le istruzioni riportate in questa sezione per l'aggiornamento di un Vault Server per un singolo sito.
Aggiornare una o due release?
L'aggiornamento di uno o due release implica un'installazione del server del Vault. L'aggiornamento di tre o più release richiede installazioni intermedie del server del Vault.
Ad esempio, in caso di aggiornamento da Vault Professional 2012 a Vault Professional 2016, utilizzare il percorso di migrazione "3 o più".
Verifica versione SQL
Verificare che la versione esistente di SQL sia compatibile con la release successiva del Vault da installare. Se la versione di SQL esistente richiede un aggiornamento (vedere il capitolo precedente di questo documento Aggiornamento SQL), eseguire gli aggiornamenti necessari, quindi tornare a questa sezione.
Installazione di Vault Server
L'installazione di Vault Server 2011 o di una release più recente supporta la disinstallazione automatica del server del Vault 2010 o versioni successive. Di conseguenza, non è necessario disinstallare Vault 2010 o una release più recente.
In ogni installazione di Vault Server, attivare l'opzione per scaricare e applicare i service pack.
Al termine dell'installazione, viene richiesto di avviare l'applicazione del server del Vault e di migrare i Vault. Non è possibile migrare i vault in questo momento .
Applica hotfix
Tutte le hotfix create dopo l'ultimo service pack devono essere installate su ogni sito. L'installazione delle hotfix garantisce che siano applicati gli aggiornamenti più recenti per la corretta migrazione.
Migra Vault
Quando viene avviato per la prima volta il Vault Server, viene richiesto all'amministratore di migrare il vault e i database di libreria. Gli utenti non possono accedere al vault fino al termine della migrazione. Non migrare fino a quando tutti i service pack e le hotfix non sono state applicate.
Se un service pack o una hotfix viene applicata dopo la migrazione, è richiesta una migrazione build-to-build (b2b). La migrazione B2B un'opzione della riga di comando descritta dettagliatamente nella sezione Timeout migrazione e nella guida Wiki per Autodesk Vault.
Seguire le istruzioni riportate in questa sezione se il Vault Server è meno recente di tre o più versioni rispetto alla release dell'aggiornamento corrente.
Ogni release del server di Autodesk Vault supporta la migrazione da due release precedenti. Quando si effettua l'aggiornamento su tre o più release, è necessario migrare il database SQL passando per release intermedie del Vault. Questa operazione viene eseguita installando ogni altra release di server del Vault, fino alla release finale.
Ad esempio, per la migrazione da 2012 a 2016, è necessario installare Vault 2014 come passaggio intermedio.
Release |
Supporta la migrazione da |
|
---|---|---|
2016 |
2015 |
2014 |
2015 |
2014 |
2013 |
2014 |
2013 |
2012 |
2013 |
2012 |
2011 |
2012 |
2011 |
2010 |
2011 |
2010 |
2009 |
... |
...-1 |
...-2 |
Verificare che la versione esistente di SQL sia compatibile con la release successiva del Vault da installare. Se la release di SQL esistente richiede un aggiornamento (vedere il capitolo precedente di questo documento Aggiornamento SQL), eseguire gli aggiornamenti necessari, quindi tornare a questa sezione.
Il Vault 2009 e le release precedenti richiedono la disinstallazione manuale prima di installare una release più recente. Il Vault 2010 e le release più recenti non richiedono la disinstallazione manuale prima di installare una release più recente.
Questa procedura è valida solo per Vault 2009 o versioni precedenti. Copiare il file …/server/web/services/web.config e connectivity.vaultmanager.exe.config prima di eseguire la disinstallazione di Vault Server 2009 o di una release precedente. Disinstallare solo il server del Vault, non rimuovere SQL o il database del Vault.
Durante l'installazione, attivare l'opzione per scaricare e applicare i service pack. Se richiesto, non migrare al termine dell'installazione.
Aggiornamento da release 2008/2009 a release 2010/2011
I valori personalizzati nei seguenti file di configurazione devono essere copiati manualmente nei nuovo file di configurazione. Prestare attenzione agli errori di battitura: un errore in questi file potrebbe bloccare il corretto funzionamento del server. Non sostituire i file nuovi con file meno recenti e non modificare le impostazioni se non seguendo le indicazioni di questo elenco. I file di configurazione precedenti potrebbero non contenere tutti i campi elencati nei file di configurazione più recenti. Anche i nomi dei campi nei file di configurazione precedenti potrebbero variare leggermente.
File Web.config:
<httpRuntime maxRequestLength=”_____” executionTimeout=”____” />
<identity impersonate=”true” userName=”____________\__________” password=”_____________” />
<timeouts connection=”___” defaultCommand=”___” longCommand=”____” />
<fragmentationCriteria minPageCount=”__” minScanDensity=”__” maxLogicalFrag=”__” />
<remoteServer enabled=”_____” protocol=”tcp” transferLocation=”” />
<creationParameters vaultSize=”_____” vaultGrowth=”_____” librarySize=”____” libraryGrowth=”____” />
<connectivity.settings>
<add key=”EventRetryInterval” value=”______” />
<add key=”IndexingSearchWakeupDelay” value=”______” />
<add key=”IndexingUpdateWakeupDelay” value=”______” />
<add key=”EcoNotificationProcessingDelay” value=”______” />
<add key=”DatabaseStatisticsUpdateTime” value=”______” />
<add key=”FilestoreVacuumTime” value=”______” />
<add key=”OptimizeIndexesTime” value=”______” />
<add key=”FullcontentIndexing” value=”______” />
<add key=”LockVacuumTime” value=”______” />
<add key=”EffectivityUpdateTime” value=”______” />
<add key=”CacheObjectExpiration” value=”______” />
<add key=”PageSizeMaximum” value=”______” />
<add key=”PageSizeDefault” value=”______” />
<add key=”PageSizeIndexing” value=”______” />
</connectivity.settings>
<connectivity.web>
<server port=”__” sslRequired=”______” />
</connectivity.web>
<smtpserver name=”______” port=”__”>
<authenticate enabled=”______” username=”” password=”” />
</smtpserver>
<maxMessageLength value=”______” />
<server value=”______” />
<add key=”WebServiceTimeout” value=”______” />
<webServer>
<add key=”SSL” value=”_” />
<add key=”PORT” value=”___” />
</webServer>
Tutte le hotfix create dopo l'ultimo service pack devono essere installate su ogni sito. L'installazione delle hotfix garantisce che siano applicati gli aggiornamenti più recenti per la corretta migrazione.
Non migrare i vault fino a quando tutti i service pack e le hotfix non sono state applicate. Una volta pronti, avviare l'applicazione del server del Vault. Viene richiesto all'amministratore di migrare il vault e i database di libreria. Accettare l'offerta e migrare tutti i vault.
I vault devono essere migrati alla release installata prima di poter installare la release successiva del Vault. Se un service pack o una hotfix viene applicata dopo la migrazione, è richiesta una migrazione build-to-build (b2b). La migrazione B2B è un'opzione della riga di comando descritta nella sezione Migrazione dei dati del Vault dopo l'installazione di una correzione o di un aggiornamento della Guida in linea di Autodesk Vault.
Se la release installata è tre o più release precedente della release finale, ripetere i passaggi di Aggiorna almeno tre release.
Se la release installata è una o due release precedente della release finale, non sono richieste release intermedie. Accedere alla procedura descritta in Sito singolo.
Autodesk Vault supporta due stili di replica dei dati su siti multipli. Il primo è un gruppo di lavoro dove sono presenti più installazioni per il server del Vault che si connette a e condivide un server SQL. Il secondo tipo è una replica completa in cui sono presenti due o più server SQL replicati. Ulteriori dettagli sono disponibili nella guida Wiki per il Vault.
Il concetto di installazione intermedia è descritto nella sezione
Aggiorna almeno tre release in Sito singolo del presente documento. Lo scopo dell'installazione intermedia è per garantire una corretta migrazione del database SQL (questa migrazione riguarda il database e non il contenuto). In un ambiente multi-sito o replica, il primo server aggiornato migra il database SQL. Di conseguenza, l'installazione di release del Vault intermedie è richiesta solo per il primo server aggiornato. Dopo che il primo sito viene migrato alla release finale, tutti gli altri siti possono installare la release finale, saltando le release intermedie del server del Vault.
Aggiorna gruppo di lavoro
In un gruppo di lavoro qualsiasi server del Vault potrebbe essere il primo ad aggiornarsi. Il sito selezionato migra anche il database SQL. Tutti gli altri siti non riusciranno ad accedere al server SQL finché non si aggiornano allo stesso prodotto, release e service pack.
La procedura ottimale consiste nell'iniziare con il sito dotato della connessione più rapida al server SQL. Una volta pronti all'aggiornamento, attenersi alla procedura delineata nella sezione Sito singolo. Aggiornare il server selezionato agli ultimi release e service pack prima di passare agli altri siti.
Quando l'aggiornamento del primo sito termina, installare il server del Vault sui siti rimanenti. Se si esegue l'aggiornamento dal server del Vault 2009 o da versioni precedenti, disinstallare il server del Vault su tutti gli altri siti. Successivamente, installare la release e il service pack finali, saltando le release intermedie. Le release del server intermedie non sono richieste sugli altri siti del gruppo di lavoro.
Aggiornamento dei gruppi di lavoro connessi
La migrazione di un ambiente completamente replicato deve iniziare con il gruppo di lavoro del server di pubblicazione. Tutti i gruppi di lavoro del server di sottoscrizione devono essere in linea e disponibili durante la migrazione del server di pubblicazione. Fintanto che un server del Vault e un server SQL di un gruppo di lavoro sono disponibili, quel gruppo di lavoro è considerato disponibile. Se un gruppo di lavoro del server di sottoscrizione non è in linea e non può essere reso disponibile, posticipare la migrazione.
Convalidare lo stato della replica di tutti i gruppi di lavoro e database prima della migrazione. In caso di problemi di replica, devono essere risolti prima di continuare. I dettagli sullo stato della replica sono disponibili nella guida Wiki del Vault, sotto a Attività dell'amministrator/Gestione della replica.
Eseguire la migrazione di un sito dal gruppo di lavoro del server di pubblicazione seguendo la procedura descritta nella sezione Sito singolo. L'installazione del server del Vault migra automaticamente il database SQL. La migrazione del database SQL viene automaticamente replicata a tutti i database del server di sottoscrizione. Al termine dell'installazione del server del Vault sul primo sito, installare release del Vault, service pack e hotfix finali su tutti gli altri siti di tutti i gruppi di lavoro.
Qualora siano richieste release intermedie per il server, sono richieste solo sul primo server. Tutti gli altri server del Vault in tutti i gruppi di lavoro devono installare release, service pack e hotfix del server del Vault finali, saltando le release intermedie.