Crea cartella e file su Profilo utente corrente, da Profilo amministratore

Il nostro client consente di installare le applicazioni solo quando si accede come amministratore. L’applicazione che deve essere installata deve essere installata per l’utente corrente della macchina. L’applicazione si installa bene, il mio problema arriva quando ho bisogno di rilasciare un file di configurazione nella cartella appdata / profilo utente dell’utente. Poiché questo è dove lo desiderano, attualmente la configurazione viene rilasciata sul profilo di amministrazione durante l’installazione. Come faccio a superare questo, c’è un modo per me di controllare l’installazione se ci sono altri profili e magari scrivere a loro, ma questo sembra sporco.

Non creare il file di configurazione durante l’installazione, controllare e vedere se esiste nell’esecuzione del programma, in caso contrario, crearlo nella cartella del profilo degli utenti in esecuzione. Se esiste, utilizzare i dati al suo interno e continuare.

Mi limiterò a riassumere quello che gli altri hanno sostanzialmente menzionato, rimpolpando un po ‘le cose cercando di fare un “piccolo riferimento”.

Forse date un’occhiata alla menzione della funzione di protezione ransomware Win10 di seguito per un importante bocconcino su come questa modifica di Windows può influire sulla distribuzione di file di profilo utente .

APPROCCI COMUNI

  • Esistono molti modi per distribuire i file a ciascun utente su un computer, ma ci sono molti inconvenienti e problemi con la maggior parte degli approcci. In tutta onestà ci sono problemi con tutti gli approcci, in una forma o nell’altra.

  • Di seguito è riportato un elenco di alcuni approcci di implementazione comuni in primo luogo e quindi una menzione di alcuni “approcci basati su cloud”. In futuro questa discussione potrebbe diventare irrilevante in quanto le impostazioni sono interamente basate sul cloud e sincronizzate al volo e la distribuzione può passare interamente da una distribuzione per singola macchina a quella basata sull’utente. Dovremo aspettare e vedere come andrà a finire.

    • 1: modello per macchina

      • Installare il file di configurazione in un percorso per macchina leggibile da tutti gli utenti, quindi copiare il file da lì e inserirlo nel profilo utente all’avvio dell’applicazione utilizzando l’applicazione stessa per eseguire il lavoro di copia una volta per utente.
      • Questo è l’approccio raccomandato. È anche ansible aggiornare l’applicazione con la logica per applicare aggiornamenti per utente se è necessario utilizzare un approccio come questo: http://forum.installsite.net/index.php?showtopic=21552 .
      • Sarai sempre in esecuzione nel giusto contesto utente quando la copia sta accadendo, e non dovrai preoccuparti delle complesse complessità di impersonificazione, condizionamento e sequenziamento di MSI.
      • Un buon vantaggio di questo approccio è che funzionerà anche se la sorgente di installazione (MSI) è mancante al momento dell’avvio dell’applicazione.
    • 2: Crea file all’avvio – “Impostazioni predefinite interne”

      • Come suggerisce gilliduck, è sufficiente creare il file di configurazione all’avvio utilizzando i valori predefiniti interni dell’applicazione e non installare affatto il file . Succede una volta per utente, da quel momento in poi si utilizza il file che è lì. Tenere questo file fuori dal proprio programma di installazione significa eliminare il rischio che l’installatore lo sovrascriva accidentalmente o lo disinstalla.
      • La domanda ovvia è il motivo per cui è necessario un file di questo tipo – se è ansible crearlo dalle impostazioni predefinite interne? La risposta è ovviamente che si potrebbe voler applicare alcuni valori specifici che sono univoci per l’ambiente dell’utente una volta creato il file. Tuttavia, impostazioni come queste potrebbero essere salvate nel registro?
      • È ansible impostare le impostazioni personalizzate in questione nella sezione HKLM del registro tramite PROPRIETÀ PUBBLICHE durante l’installazione (configurabile dall’utente sulla riga di comando o tramite una trasformazione, vedere: Come utilizzare meglio i file MSI per informazioni su questo), e applicali per tutti gli utenti al momento dell’avvio dell’applicazione, in altre parole scrivili su HKCU. Oppure puoi semplicemente mantenere le impostazioni “di sola lettura” in HKLM e applicarle per tutti gli utenti in quel modo nella tua applicazione? (impostazioni non configurabili dall’utente, ad esempio il nome di un server di rete o simile).
      • È ancora ansible utilizzare il metodo dal link sopra per applicare gli aggiornamenti ai file di configurazione esistenti all’avvio dell’applicazione facendo in modo che l’installazione scriva un flag su HKLM per notificare che una distribuzione è “accaduta” dall’ultimo avvio.
      • Oppure, come detto, in alternativa utilizzare il registro per conservare le impostazioni.
    • 3: MSI Self-Repair

      • Metti il ​​file di configurazione in posizione per utente utilizzando l’ auto riparazione di MSI . Ciò si verifica quando si richiama un punto di accesso pubblicizzato, ad esempio un collegamento pubblicizzato utilizzato per avviare l’applicazione.
      • Richiede l’accesso alla fonte di installazione nel momento in cui avviene la riparazione. Assicurati di memorizzare nella cache il tuo file MSI sulla scatola.
      • L’auto-riparazione potrebbe non funzionare sui Terminal Server (funzione disabilitata). Sono passati anni da quando l’ho testato per l’ultima volta. Non sono sicuro di come i server siano configurati fuori dagli schemi in questi giorni.
      • A meno che non sia configurato, la disinstallazione può disinstallare il file di configurazione per l’utente che esegue la disinstallazione effettiva o, in modo critico, ciò può accadere durante un aggiornamento principale (che è in realtà una disinstallazione e una reinstallazione del prodotto). In altre parole: imposta il componente permanente (e non sovrascriverlo mai) – o il tuo file potrebbe apparire sovrascritto durante l’aggiornamento (ma è veramente disinstallato e reinstallato).
      • Per le impostazioni del registro HKCU non è necessario che sia disponibile la sorgente di installazione. Controlla la spiegazione di Stefan Kruger : http://www.msifaq.com/a/1011.htm . La procedura è la stessa per triggersre l’installazione di file profilo utente (ma è necessaria la fonte di installazione). Una discussione associata – nel caso sia utile .
      • Sebbene non sia stato testato da me, ho preso in considerazione l’impostazione di un valore del percorso della chiave del Registro di sistema su: HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] per rendere il valore del percorso chiave un “target mobile” in modo che l’auto-riparazione sia triggersto in modo affidabile quando l’utente accede a un nuovo computer (nonostante i profili di roaming che portano le impostazioni HKCU esistenti).
      • Come ho detto, non verificato poiché ho praticamente abbandonato questo approccio – dal momento che è meno affidabile dipendere da ogni nuovo aggiornamento di Windows. Qualcosa di strano viene cambiato ogni volta, con risultati imprevedibili.
      • Sebbene non sia correlato al 100%, posso menzionare la nuova funzione di protezione ransomware in Windows 10 come esempio: sembra che causi errori di runtime intermittenti per qualsiasi MSI che tenta di scrivere nelle cartelle di dati degli utenti. Resta da vedere quanti problemi di distribuzione avranno – mentre vediamo risultati intermittenti fino ad ora – cosa accadrà quando e se accenderanno la funzione di default ?.
      • E, seguendo la stessa linea di cui sopra, il software di sicurezza di terze parti fornisce anche ostacoli alla distribuzione bloccando determinate attività del file system e mettendo in quarantena i file contrassegnati per qualche motivo (inclusi i falsi positivi), causando l’auto-riparazione che non può mai completare, ma mantenere correre invano.
        • Vedere il numero 7 qui su software di auto-riparazione e sicurezza e malware : come evitare l’triggerszione dell’autoriparazione MSI con il mio pacchetto WiX / MSI?
        • Un riepilogo della complessità della distribuzione in generale: qual è il vantaggio e lo scopo reale dell’installazione del programma? e verso il basso qui: Windows Installer e la creazione di WiX .
      • Quindi, come breve sumrio , ecco alcuni motivi per cui diventa sempre più utile evitare la distribuzione di file di profilo utente tramite l’auto-riparazione:
        • Complicazioni del profilo di roaming .
        • Interferenze della funzione di protezione dei ransomware .
        • Interferenze nel software di sicurezza (in particolare i falsi positivi del malware).
        • Limitazioni del server terminal all’autoriparazione .
        • Ripristino dati o problemi di disinstallazione delle impostazioni durante l’aggiornamento principale .
        • Forse hai la stessa sensazione che provo: c’è di più, e continuerà a peggiorare.
        • I miei due centesimi : parla immediatamente con il tuo manager di una migliore gestione dei file di dati per la tua applicazione e abbandona tutti i tentativi di essere “intelligente” durante l’implementazione. Distribuisci per file macchina solo con MSI, se ansible.
        • In futuro questa preferenza potrebbe cambiare in quanto la tecnologia di implementazione cambia e le installazioni vengono eseguite solo per utente (forse).
        • Una descrizione più lunga del problema scritto in precedenza: Perché è consigliabile limitare la distribuzione di file al profilo utente o HKCU quando si utilizza MSI?
        • E un’intera chat disordinata sui problemi di distribuzione in generale : come evitare i difetti di progettazione comuni nella mia soluzione di distribuzione WiX / MSI?
    • 4: installazione triggers

      • Metti il ​​file di configurazione in posizione utilizzando la configurazione triggers . Ciò si verifica in caso di accesso utente (che richiede quindi un logout e il login avvengono a meno che non si accerti che il file sia installato anche sul profilo utente corrente al momento dell’installazione).
      • Questa è in effetti una variante dell’approccio 1. È necessario installare il file di configurazione in un percorso per macchina, leggibile da tutti gli utenti.
      • Quindi si registra un’attività nel Registro di sistema per eseguire “qualcosa eseguibile” una volta per utente. Puoi eseguire qualsiasi cosa come un file batch, eseguibile, script o il mio metodo preferito di riparazione MSI che riuscirà a mettere in atto il file del profilo utente (in questo caso non è necessario un file in un percorso per macchina, ma l’accesso alla fonte di installazione come viene eseguito il programma di installazione attivo).
      • Fare attenzione a non sovrascrivere un file di configurazione messo in atto durante l’installazione per l’utente corrente. Oppure disabilitare Active Setup per l’esecuzione di questo utente scrivendo la chiave HKCU che viene scritta dopo l’esecuzione del programma di installazione attivo per l’utente in questione (vedere il collegamento seguente).
      • La procedura è tentata spiegata nella mia risposta qui: Aggiornamento del registro di ogni profilo su Windows Server 2003 . È tutto basato su una chiave HKLM eseguita una volta per utente. Controlla la risposta collegata per i dettagli, e ci sono alcuni link esterni che forniscono molti più dettagli.
      • AGGIORNAMENTO : quando si installa su Terminal Server si mette il server in “modalità di installazione” e quindi le voci di registro per utente vengono scritte in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install e quindi scritte nell’hive HKCU di ciascun utente quando si collegano. Ciò potrebbe entrare in conflitto con ActiveSetup, per quanto ne so. Non ho mai avuto la possibilità di provarlo. L’imballaggio per Terminal Server viene generalmente eseguito da un team di server dedicato e specializzato.
    • 5: MsiProvideComponent

      • Phil’s MsiProvideComponent è interessante, non l’ho mai usato. Dovrei.

APPROCCI DI STILE CLOUD

  • Con l’archiviazione dei dati apparentemente in movimento verso il cloud, gli approcci comuni alla distribuzione dei file di dati potrebbero presto diventare obsoleti.

    • 6: Scarica il file delle impostazioni

      • Scarica il file delle impostazioni – una volta per ogni utente all’avvio dell’applicazione – da un database di rete locale / condivisione o da Internet , se questa è un’opzione.
      • Il file remoto può essere gestito da un amministratore per aggiornare i valori se ci sono nuovi valori predefiniti o qualcosa deve essere rimosso.
      • I meccanismi di configurazione nel file delle impostazioni compresi dall’applicazione potrebbero imporre nuovi valori “forzati” da applicare a tutti gli utenti.
      • Consentire la configurazione di un elenco di server in HKLM? Configurabile nel MSI tramite PROPRIETÀ PUBBLICHE ?
      • Oppure imposta un singolo URL nella configurazione durante l’installazione e mantieni un elenco di server tramite tale URL (reindirizza il server a cui punta tramite DNS, quindi la configurazione è un’attività di sysadmin senza la necessità di una nuova distribuzione?). Presente selezione impostata in HKCU.
    • 7: Impostazioni di lettura / scrittura dal database remoto

      • Le impostazioni di lettura / scrittura direttamente su / da un database AD locale o Internet in modo continuo invece.
      • Nessun file di impostazioni locali o una copia di sola lettura memorizzata nella cache per quando il server non può essere raggiunto? O semplicemente eseguire con le impostazioni predefinite dell’applicazione interna se il server non può essere raggiunto? Nessun file da gestire nel secondo approccio.
      • È ansible scrivere un elenco di server (URL) da utilizzare su HKLM (anche per criteri di gruppo?) E persino mantenere il server attualmente selezionato in HKCU per ciascun utente. Quindi il resto avviene online.
      • Generalmente utilizzati nelle applicazioni client / server aziendali finora – ma le piattaforms basate sul cloud cambieranno la distribuzione per sempre – in particolare per gli utenti domestici. Abbiamo visto i browser conservare le impostazioni tramite Internet per un lungo periodo (Chrome, Opera, Firefox, ecc.).
      • Archiviazione remota, database significa che puoi mantenere le impostazioni utente come attività di gestione del database e puoi anche eseguire la versione dei dati utente nel database e applicare facilmente nuove impostazioni predefinite o forzare l’aggiornamento dei valori esistenti per tutti gli utenti come attività DBO centralizzata .
        • Niente più fastidioso problema del profilo di roaming.
        • Non è più necessaria la distribuzione fallita di file profilo utente.
        • In breve: nessuna impostazione utente da implementare e i dati non saranno mai sincronizzati su macchine diverse.
        • Problemi di firewall / proxy e connettività di rete?

Sommario

Non mi piace più l’ opzione 3 (Ripristino automatico) e l’ opzione 4 (Impostazione triggers), anche se li ho usati molte volte – e funzionano quando sono fatti bene. Tuttavia, non sono immuni ai problemi del profilo di roaming (i file non vengono copiati sul posto in tutti i sistemi su cui l’utente si collega) e mancano dell’accesso all’origine di installazione MSI quando la riparazione è in esecuzione, il che può causare problemi di distribuzione. Ci sono anche frequenti complicazioni durante gli aggiornamenti principali con le impostazioni di ripristino e l’auto-riparazione non riesce sui server terminal. L’auto-riparazione potrebbe non riuscire per l’installazione nel profilo utente a causa della protezione ransomware o dell’interferenza del software di sicurezza. La riga di comando specificata nell’opzione 4 (Impostazione triggers) potrebbe essere bacata e cancellare i dati (ad esempio si triggers il flag errato per la riparazione di msiexec.exe e si forza la sovrascrittura del file di impostazioni per errore – questo spesso non viene scoperto finché non è troppo tardi e il danno è fatto). E ci sono ulteriori problemi che mi sfuggono adesso. Entrambi gli approcci hanno limitazioni simili ma leggermente diverse.

Sempre più preferisco approcci basati su cloud per rendere obsoleti i file delle impostazioni utente locali (e isolati), ma raramente sono stato in grado di implementare le cose in questo modo. Questi approcci al cloud possono tuttavia affrontare problemi con problemi di firewall / proxy e problemi di connettività di rete – e probabilmente molte altre cose di cui non sono ancora a conoscenza (ora gli sviluppatori litigano con i DBO piuttosto che con gli specialisti dell’implementazione, ecc … ;-)). Il calcolo distribuito ha i suoi difetti: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing . Inoltre: negli approcci basati su cloud può essere ancora una buona idea che le applicazioni consentano il backup delle impostazioni su disco, quindi ovviamente è ancora necessaria una gestione dei file o esportare solo un paio di tabelle di database? Inoltre: se si installa una versione di prova dell’applicazione, è ansible che sia in grado di funzionare senza connettività di rete – nel caso in cui l’utente si trovi dietro un firewall molto stretto. È un errore molto costoso da fare per non consentire all’utente di testare le funzionalità dell’applicazione per motivi tecnici.

Il grande vantaggio delle opzioni 1 e 2 è che funzioneranno anche se il supporto di installazione originale è mancante all’avvio della riparazione. Ciò è particolarmente importante per la distribuzione domestica e di piccoli uffici in cui la distribuzione può avvenire in modo casuale senza una condivisione centralizzata dei pacchetti. È ansible aggirare questo problema (MSI di origine mancante) utilizzando i metodi di memorizzazione nella cache per memorizzare nella cache l’intero MSI sul sistema durante l’installazione (disponibile in Installshield, non ho controllato WiX o Advanced Installer).

Puoi farlo funzionare con la funzione di riparazione. L’immagine grande è che il file è stato installato per un utente al momento dell’installazione in un percorso del profilo utente e in un’installazione per sistema significa che il file mancherà quando un altro utente si collega per utilizzare l’app. Dipende dalla struttura dei componenti MSI, dalle funzionalità e dalle scorciatoie, ma l’avvio dell’applicazione con una scorciatoia pubblicizzata potrebbe comportare l’installazione del file mancante con una riparazione automatica. Ovviamente ciò richiede che l’MSI sorgente rimanga disponibile.

Tuttavia, il modo più sicuro per installare il file per ogni nuovo utente è chiamare esplicitamente MsiProvideComponent passando il ProductCode dell’MSI, il nome della funzione, l’ID del componente e così via come descritto nella documentazione. Come dicono i documenti, questo installerà il componente se manca, richiedendo nuovamente che l’MSI di origine sia disponibile.

Questa funzionalità si occupa del caso in cui ci sono account utente che non sono stati ancora creati, quindi ovviamente non puoi ancora inserire i file nelle loro cartelle dei profili.

Se sia l’approccio migliore rispetto ad altri dipenderà da dettagli specifici dell’app.