Automazione dell'installazione di più applicazioni

Sto cercando di scoprire un modo affidabile di bundling di diverse applicazioni che possono utilizzare diversi software di installazione (InstallShield, MS installer Service, Wise, ecc.) E automatizzare l'installazione di tutti in qualche modo. Non ho visto nessun prodotto là fuori che fa in modo affidabile. Ecco cosa vorrei fare:

  1. Installare diverse applicazioni che possono utilizzare diversi installatori.

  2. Installare applciations senza richiedere l'interazione manuale per each applicazione. Preferirei un'opzione nell'installatore principale per avere un'opzione personalizzata in cui è ansible select le applicazioni desiderate e fare clic su "Installa" e installarle (ma senza aprire l'installazione per quelle applicazioni)

  3. Avere il programma di installazione principale visualizzato solo nel menu Aggiungi / Rimuovi programmi all'interno di Windows, in modo che quando viene rimossa una sola applicazione, tutte le applicazioni installate vengono anche rimosse.

  4. Controlli i parametri di installazione per ciascuna applicazione in bundle in modo che possano essere installati in una struttura di directory correlata logica. Ad esempio, installare tutte le applicazioni in una cartella Program Files \ Bundled App Set.

Da quello che ho ricercato, in realtà sono solo alcuni modi per farlo:

  1. Installazione esterna, che avvia semplicemente l'installatore per each applicazione e richiede l'interazione manuale per each installatore (ma che rompe quasi tutti gli obiettivi sopra, ma alless installerà tutte le applicazioni scelte dopo l'interazione)

  2. Installazione automatica / silenziosa supponendo che ciascun installatore lo supporti tramite un file di risposta o le bandiere passate al programma di installazione.

  3. Ripagare le installazioni utilizzando un software che consente di tenere traccia delle modifiche apportte a un sistema durante l'installazione e registrare quelle modifiche che vengono poi riconfigurate in un nuovo installatore. Ho letto che questo non è molto affidabile e tende a rompere spesso. Può avere problemi nel rilevare cose come i servizi aggiunti a Windows.

C'è anche una quarta opzione utilizzando i moduli di unione, ma ciò functionrebbe solo se each applicazione utilizza lo stesso servizio di installazione di MS. Non l'ho elencata a causa di ciò.

Questa è veramente una domanda per le opinioni sul modo migliore per andare su questo. Alcuni software di cui ho accesso e possono essere riconfezionati, e altri software che non lo faccio. Preferirei non andare con un sistema ibrido, come usare # 1 e # 2, ma se devo, devo farlo.

Immagino che ci sia un modo per fare questo giusto, e sono aperto a qualsiasi opinione o suggerimenti per get qualcosa di simile a lavorare – e spero non essere incredibilmente fragile alla fine. Forse non è ansible? Qualsiasi aiuto è apprezzato. Grazie.

  • ESXi che concede le windows ospiti tutta la sua memory assegnata
  • Come faccio a vedere dal registro degli spettacoli degli events che il formato della data è stato modificato?
  • Consenti agli utenti di dominio di modificare le impostazioni della printingnte locale Windows 7 tramite Criteri di gruppo
  • Qualche idea su come emulare otto tabs di networking utilizzando una singola scheda fisica?
  • Connessione VNC a Windows XP
  • Prevenire le applicazioni che lampeggiano nella barra delle applicazioni - è questo ansible?
  • Come trovare la causa dell'account utente bloccato nel dominio di Windows AD
  • Servizio FTP per l'utilizzo su Windows Server?
  • 5 Solutions collect form web for “Automazione dell'installazione di più applicazioni”

    Ho usato una tecnica lungo le linee della soluzione pjhayward per anni. La nostra società utilizza centinaia di programmi diversi, alcuni dei grandi fornitori commerciali e altri da aziende di una persona. Le competenze tecniche di questi fornitori sono in tutta la mappa, soprattutto quando si tratta di progettare installatori.

    Considero MSI fornito dal fornitore il gold standard (anche se c'è ancora molta variazione nei disegni dei pacchetti). Utilizzando lo strumento libero di Orca di Microsoft (incorporato in uno o più dei suoi SDK di piattaforma, credo), è abbastanza facile creare i file di trasformazione per impegnare questi pacchetti nel nostro layout tipico. Personalizziamo il menu Start per raggruppare i programmi per categoria funzionale, modifichiamo la directory di installazione per raggruppare le applicazioni da parte del fornitore all'interno della cartella Programmi e spostiamo tutti i collegamenti desktop. I numbers di serie e gli indirizzi dei server di licenza vengono applicati, se del caso, forse un servizio di aggiornamento automatico è distriggersto, ecc.

    Il più grande vantaggio dell'utilizzo di MSI è che la politica di gruppo di Microsoft (che funziona tramite Active Directory e viene inclusa in tutte le licenze di Windows Server) può distribuire questi pacchetti, con le loro trasformazioni, a gruppi automatizzati di determinati gruppi oa richiesta dell'utente. Utilizziamo il metodo automatico, assegnando applicazioni di uso generale a tutte le macchine, applicazioni CAD a coloro che le potrebbero usarle, applicazioni Adobe a macchine specifiche (stupidissima licenza per sede), ecc. , se non è già stato chiesto e risposto.

    Per molti, molti installatori che non sono in formato MSI, passiamo ad un process di riprogettazione simile a pjhayward's. L'inconveniente più significativo per farlo è che l'installazione riprogettata perde qualsiasi intelligenza incorporata nell'installatore originale. La sensibilità alle differenze di piattaforms (ad esempio sisthemes a 32 o 64 bit) sarà compromise, probabilmente richiedendo ulteriori riassemblaggi per coprire each piattaforma. Le decisioni relative all'installazione e / o all'aggiornamento di componenti di terze parti verranno effettuate sulla macchina di campionamento, indipendentemente dai diversi stati iniziali delle macchine di destinazione. Eccetera.

    Parlando di componenti di terze parti: facciamo each sforzo per installare ciascun componente attraverso un pacchetto separato, indipendentemente dai desideri frequenti dei fornitori per unire tutto insieme. La loro strategia ha senso per una singola persona installando manualmente una manciata di prodotti software sulla propria macchina, ma si rompe nel caso di installazioni automatiche a molti nodes e di molti prodotti. Non import quanti fornitori si affidano a MSXML 6 o ad alcuni strumenti di gestione delle licenze oscuri, installiamo ognuno di loro una sola volta, in genere prima di installare i prodotti in cui sono stati distribuiti. Ciò inoltre aiuta a ridurre al minimo i declassamenti involontari della versione, dal momento che possiamo facilmente sapere se la versione in bundle è più vecchia o nuova di quella che stai già distribuendo.

    Utilizziamo WINinstall di Attachmate, distribuito in forma lite con i CD di Windows Server 2003. Abbiamo una licenza del prodotto completo, ma la versione LE, in combinazione con Orca e il supplemento occasionale incorporato vbscript, è stato sufficiente per le mie esigenze. I commenti di Evan Anderson su WINinstall sono validi, ma siamo stati in grado di vivere con le sue verruche.

    La list di pjhayward (attualmente) elenca un passo critico: Pulire il pacchetto di installazione acquisito prima di utilizzarlo per eseguire altre installazioni. I file indesiderati e le voci del Registro di sistema vengono spesso raccolti come parte del process di cattura e è importnte identificarli e rimuoverli prima che danneggino le successive installazioni. Cercare cose come le chiavi di registro di stato sequenziali che potrebbero essere completamente sbagliate per una macchina che è stata eseguita per un po ', e i file di cache di servizi di indexing o di Windows Update creati a metà cattura.

    Tieni presente che la licenza è al di fuori della portta della mia risposta, ma è abbastanza pertinente a questo tipo di scenario. Le tecniche di distribuzione di massa devono essere bilanciate con la consapevolezza dei diritti di utilizzo effettivi concessi dagli accordi di licenza di ciascun prodotto.

    Spero che aiuti. È forse più di quanto stai chiedendo e non corrisponde perfettamente all'approccio di distribuzione che la tua domanda descrive, ma è una soluzione che abbiamo trovato operabile da molti anni.

    Quando hai a che fare con un software per il quale non hai il codice per l'installazione, non c'è davvero una "risposta giusta".

    Puoi avere considerazioni relative al contratto di licenza se lo fai con un software di terze parti. L'errore del server non è un avvocato, ma se questo è per qualcosa che stai distribuendo al di fuori della tua organizzazione, l'avrei controllato dal tuo consulente.

    "Riprogettazione" significa cose diverse a persone diverse. A mio parere, significa build un nuovo programma di installazione per l'applicazione di qualcun altro. Tipicamente questi sono i pacchetti MSI, ma potrebbe anche essere un altro sistema di configuration. Ciò può essere fatto con strumenti automatizzati, "a mano", o con una combinazione di quelle strategie.

    La riorganizzazione tramite strumenti automatizzati può creare installazioni che funzionano perfettamente o che sono danneggiate senza speranza. L'utilizzo di uno strumento di ritriggerszione in modo cieco, senza esaminare attentamente il pacchetto che crea, può portre ad un enorme disordine. Alcuni strumenti (Wininstall LE, ti sto guardando) creano, per impostazione predefinita, file veramente brutti di MSI (un file per componente, tutto un keypath).

    La riorganizzazione "manualmente" mediante l'inversione di ingegneria delle "intenzioni" dell'autore del programma di installazione originale può rendere più pulibili le installazioni riconfezionate, ma bisogna davvero scavare e capire se il programma di installazione originale ha comportmenti che non si vedono la tua macchina di prova. Ciò finisce per essere un esercizio in reverse engineering (e, forse, frustrazione).

    Se potete get con le impostazioni non controllate per le applicazioni necessarie, penso che avrai la configuration più pulita. Se sei preoccupato dell'elenco Aggiungi / Rimuovi programmi (ARP), suppongo che il tuo shell di installazione possa modificare le voci del Registro di sistema ARP dopo che each configuration di terze parti completa per rimuovere le voci. (Personalmente, lascio solo le voci ARP …)

    Sarei estremamente attento, se questo prodotto è destinato all'utilizzo di COTS, che rilevi le installazioni esistenti dei programmi di terze parti che stai installando e gestisca in modo appropriato. Mi ricordo di un vecchio software didattico che ho usato per far fronte a ciò che avrebbe crollato ciecamente qualunque versione di QuickTime sia stata installata e lo sostituisca con qualche brutta versione di Win16, sia che mi sia piaciuto o no. Ugh …

    Se lo distribui al di fuori della tua organizzazione e degli altri sisthemes (come, ad esempio, io) possiamo avere a che fare con questa cosa, tenete conto dei nostri interessi. Vorremmo poter installare in silenzio il tuo prodotto e vorremmo poter mantenere i componenti di terze parti installati.

    L'unica opzione veramente valida per realizzare tutti i tuoi obiettivi è l'opzione # 3.

    Il motivo principale di riconfezionamento è in genere inaffidabile: quando le applicazioni sono originariamente installate, tutte sono installate sullo stesso sistema senza disinstallare le altre applicazioni innanzitutto. Ciò significa che si finisce con una dipendenza di sequenza per assicurarsi di avere tutte le librerie condivise correttamente installate.

    Se l'applicazione A ha installato la versione 1.0.0.1 di myLib.dll e l'applicazione B utilizza la stessa versione, il sistema di rilevamento delle modifiche non riconoscerà che l'applicazione B richiede il mioLib.dll a tutti, a less che non conservi una copia nella cartella di programma. Ciò è particolarmente problematico per le app che utilizzano librerie ridistribuibili da Microsoft, che possono essere o non essere sulla macchina di destinazione. La maggior parte delle applicazioni che utilizzano le librerie personalizzate tendono a mantenerle nella cartella del programma.

    Per get l'opzione # 3 per lavorare anche in modo remoto in modo affidabile, ecco cosa farò:

    1. Crea una macchina virtuale per installare le varie applicazioni. La maggior parte dei software VM che ho conosciuto ti permetterà di impostare le unità virtuali in modo da poter decidere se eseguire modifiche all'image dell'unità virtuale. Dopo averlo eseguito e triggersto, accendere tale function.

    2. Avviare il software di rilevamento delle modifiche.

    3. Installare un'applicazione / aggiornamento / qualsiasi cosa, assicurandoti di installarlo in Programmi \ BundledAppsAnywhere

    4. Rimuovere la voce del Registro di sistema che avrebbe posto l'applicazione nel pannello di controllo Add / Remove

    5. Completare il process di rilevazione dei cambiamenti.

    6. Spostare l'applicazione riprogrammata sulla macchina fisica.

    7. Ripristina il disco di annullamento di VM, quindi hai un sistema pulito.

    8. Ripetere i passaggi 2-7, se necessario.

    Ora, con tutto quello che ho detto, non sono in cima alle offerte attuali per la riconfezionamento delle soluzioni, quindi non sono a conoscenza di alcuna che ti darà la flessibilità desiderata per aggiungere e rimuovere i programmi come descritto.

    Se la vostra azienda è abbastanza grande (ad esempio, il loro budget IT è "enorme"), ci sono diversi prodotti che funzionano lungo queste righe.

    Se stai cercando qualcosa per ambienti di piccole e medie size, stai cercando di trovare le flag di installazione e poi script in qualche modo.

    forse dovresti provare Npackd ( http://code.google.com/p/windows-package-manager/ )

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.