Domino policies: what else?

Domino policies: what else?Stefano Benassi

Mi presento... Stefano Benassi, 40 anni Laureato in Ingegneria Elettronica a Parma nel 1997 Dopo 3 anni nellautomazione industriale... ....sempre Lotus (prima programmazione, poi Notes, Domino, Sametime, Traveler, ...) IBM Certified System Administrator 01/02/2010: libero professionista

Agenda A cosa servono Come sono strutturate Tipi di settings Policies effettive Quando si applicano Troubleshooting Best practices Tips & Tricks Q&A

A cosa servono Ottobre 2002: Domino 6 -> nascono le policy Le policies consentono agli amministratori di definire alcune configurazioni che vengono automaticamente implementate (anche in modo forzato) nellinfrastruttura Domino per gestirne il funzionamento Vantaggi ✔ Centralità ✔ Uniformità

Come sono strutturate Sono documenti Notes nella Domino Directory 2 tipi di documenti: ✔ POLICY: definisce in che modo tali impostazioni vengono applicate agli utenti (COME) ✔ POLICY SETTINGS: contengono le impostazioni che voglio applicare agli utenti (CHE COSA)

Come sono strutturate POLICY (release 8.5+) ✔ Organizzative ✔ Esplicite (sulla persona) ✔ Esplicite (dinamiche) Ogni policy può contenere un solo documento per ogni tipo di settings

Come sono strutturate POLICY ORGANIZZATIVE ✔ applicate agli utenti di unorganizzazione/unità organizzativa o a tutti → * ✔ se un utente viene spostato nella gerarchia Domino, vengono modificate le impostazioni applicate

Come sono strutturate POLICY ESPLICITE (sulla persona) ✔ applicate sui documenti persona (obsolete) → tool “Assign policy” ✔ svantaggi: a un utente posso applicarne solo una (il campo non è multi-value) ✔ fino alla release 8: scelta obbligata ✔ dalla release 8: policy assegnabili a gruppi ma non dinamicamente, aggiungo utenti ma non viene applicata la policy

Come sono strutturate POLICY ESPLICITE (dinamiche) ✔ applicate a un utente/più utenti/gruppi di utenti ✔ vantaggi: aggiungendo una persona ad un gruppo, gli viene applicata la policy -> cambio gruppo, cambia la policy ✔ disponibili dalla release 8.5 ma vengono applicate ai client dalla release 8.0.1+

Come sono strutturate POLICY ESPLICITE

Come sono strutturate POLICY SETTINGS ✔ Le configurazioni sono raggruppate per tipo di funzionalità ✔ Sono cresciuti di numero nel corso degli anni: ➔ 5 nella Domino 6 ➔ 6 nella Domino 7 ➔ 9 nella Domino 8.0.1 ➔ 10 nella Domino 8.5 ✔ 3 tipi di campi: ➔ Menù a tendina ➔ Caselle di controllo ➔ Campi liberi

Tipi di settings REGISTRATION SETTINGS ✔ Utilizzati nel processo di registrazione utente (Domino Administrator) ✔ Registro un utente specificando solo nome, cognome e password ✔ Utile con domini multiazienda (multicertificato) ✔ Fanno risparmiare tempo SETUP SETTINGS ✔ Utilizzati solo una volta in fase di setup di un client Notes ✔ Obsolete: "Set initial value" nei Desktop settings

Tipi di settings DESKTOP SETTINGS ✔ Importantissimi! ✔ Gestiscono il funzionamento quotidiano dei client Notes ✔ Applicati tramite il Dynamic Client Configuration MAIL SETTINGS ✔ Controllano le preferenze della posta ✔ Impostazioni che facilitano l’utilizzo da parte degli utenti ✔ Vengono applicate ogni 12 ore dall’Administration Process ✔ Tell adminp process mailpolicy

Tipi di settings SECURITY SETTINGS ✔ Controllano la gestione della sicurezza utente ✔ Complessità e scadenza della password ✔ Notes Execution Control List (ECL) ✔ Gestione certificati ✔ Sicurezza plug-in di Eclipse ✔ NEW (8.5): Notes Shared Login ✔ NEW (8.5): ID Vault ARCHIVE SETTINGS ✔ Utilizzati per determinare i criteri di archiviazione della posta

Tipi di settings LOTUS TRAVELER SETTINGS ✔ Gestiscono la configurazione dei device mobili supportati CONNECTIONS SETTINGS ✔ Utilizzati per la configurazione del server IBM Connections ROAMING SETTINGS ✔ Utilizzati per la configurazione degli utenti roaming che appoggiano una share di rete i propri roaming files SYMPHONY SETTINGS ✔ Utilizzati per la configurazione del tool di produttività individuale Lotus Symphony (associazione file - programma)

Policies effettive Policies coinvolte: organizzative + dinamiche + una esplicita I settings applicati ad un utente sono un insieme dei parametri derivati dalle varie policies a lui applicate Vengono calcolati al momento in cui la policy viene applicata1. GERARCHIA: vale sia per le organizzative che per le esplicite (tramite il nome) ✔ “Vince” la policy più specifica (valutata campo per campo)

Policies effettive2. SPECIFICITA’: una policy “più specifica” ha la precedenza su di una “meno specifica”. Quindi, in ordine crescente di specificità: ✔ Organizzativa ✔ Dinamica ✔ Esplicita

Policies effettive Gli attibuti di “Enforce” e “Inherit” funzionano su policy per le quali esiste un rapporto di parentela padre/figlio Una policy esplicita è sempre figlia di qualsiasi policy organizzativa che si applica all’utente, a meno che non sia impostata come policy “eccezione” (TN 1224460)

Policies effettive ENFORCE: impongo un setting da una policy a specificità minore ad una maggiore (dall’alto) INHERIT: impongo un setting da una policy a specificità minore ad una maggiore (dal basso) ✔ Non viene forzato a livelli inferiori sotto quello di inherit (a meno che non sia contemporaneamente specificato l’enforce)

Policies effettive PRECEDENZA (policy dinamiche): 1 organizzativa + 1 esplicita ma tante dinamiche Problema: valori differenti su policy differenti per un certo parametro Soluzione: precedenza delle policy dinamiche! Eventuali conflitti vengono risolti per generare una sola policy dinamica prima di combinarla con le altre

Policies effettive Utente con: 2 organizzative + 2 dinamiche + 1 esplicita

Policies effettive HOW TO APPLY: determina la persistenza nel tempo del valore di un parametro specificato via policy

Policies effettive1. DONT SET VALUE: non viene specificato nessun valore per il parametro che è come se non esistesse ✔ Se è una checkbox e non viene spuntata, il valore viene comunque utilizzato2. SET INITIAL VALUE: il valore viene impostato solo la prima volta che viene applicata la policy, se l’utente ne modifica successivamente il valore questo viene mantenuto (quindi Setup = Desktop + S.I.V.) ✔ I client pre-release 8 non interpretano questo valore

Policies effettive3. SET VALUE WHENEVER MODIFIED: se l’utente ne modifica il valore questo viene sovrascritto ✔ i valori vengono reimpostati a quelli specificati nella policy ogni 12 ore4. SET VALUE AND PREVENT CHANGES: il valore viene impostato e reso immodificabile da parte dell’utente

Policies effettive Come per il valore, anche per l’HTA valgono “Inherit” ed “Enforce” Don’t set value + “Enforce” → il parametro non ha un valore nella policy effettiva Pulsante di modifica massiva dell’HTA: molto utile!

Quando si applicanoCreo o modifico una policy: quando avrà effetto? AGGIORNAMENTO DELLA NAMES ✔ Ogni 1 minuto ✔ UPDATE_NAB_VIEWS_DISABLE ✔ UPDATE_NAB_SUPPRESSION_TIME (minutes) ✔ Load updall names –T ($Policies) –R ✔ Policy dinamiche: cache dei gruppi REPLICA SULL’HOME SERVER ✔ Modifiche sul server amministrativo del dominio ✔ Replica sull’home server dell’utente

Quando si applicanoCreo o modifico una policy: quando avrà effetto? APPLICAZIONE ✔ Mail/Traveler: 12 ore (ADMINP_POLL_INTERVAL) o tell adminp process mailpolicy ✔ Archive: compact -A ✔ Setup: setup iniziale del client Notes ✔ Altre: 1) Notes invia “digest” delle policy durante lautenticazione con lhome server 2) Domino calcola ciò che quel client Notes dovrebbe avere in quel momento 3) Se i due valori sono diversi, comunica il refresh delle policy 4) Dynamic Client Configuration: se necessario, API NAMEGetPolicy → pull policy effettiva 5) Policy “cachata” nella names e applicata → vista nascosta ($Policies) 6) Il nuovo “hash” viene memorizzato per essere trasmesso la volta successiva Notes configuration settings have been refreshed

Troubleshooting Policy Synopsis Vista ($Policies) dei contatti Log.nsf Policy Viewer del Domino Administrator Variabili di debug

Troubleshooting Policy Synopsis ✔ Utile per determinare la policy effettiva sul server

Troubleshooting Policy Synopsis ✔ Summary only/Detailed ✔ Polcysyn.nsf nella data su locale

Troubleshooting Policy Synopsis ✔ Policy coinvolte nel calcolo della policy effettiva per un utente ✔ Valore di ogni parametro impostato (non così agevole...)

Troubleshooting Vista ($Policies) nei contatti ✔ Utile per determinare la policy effettiva scaricata sul client Notes

Troubleshooting Log.nsf ✔ Utile per determinare eventuali problemi riguardo alla DCC ✔ Possibili cause: 1) DisableDynConfigClient=1 nel notes.ini 2) Non è specificato l’home server sul documento località 3) AcceptUpdates=0 sul documento località 4) Chiave pubblica file id <> chiave pubblica documento persona

Troubleshooting Policy viewer ✔ By Settings: utile per determinare quali settings su quali policy ✔ Doppio clic → modifico direttamente i settings

Troubleshooting Policy viewer ✔ By Hierarchy: selezionando un utente e un tipo di settings, visualizzo la policy effettiva applicata all’utente

Troubleshooting Variabili di debug ✔ Debug_policy=2 ✔ Debug_Dynconfig=1 ✔ Debug_ClientRecord=1 Meglio con... ✔ Debug_console=1 → mostra in una DOS shell cosa fa Notes ✔ Debug_outfile=C:temppolicydebug.txt → output su file

Best practices Struttura semplice → utilizzare: ✔ policy organizzative ✔ policy dinamiche ✔ policy esplicite (meno possibile) ✔ possibilmente no eccezioni (top management) Il deploy di una policy organizzativa errata può compromettere la produttività di un’azienda

Best practices Steps di deploy 1. creare una policy dinamica 2. creare i settings 3. assegnare i settings nella policy 4. creare un gruppo per gli utenti di test (pochi) 5. assegnare la policy al gruppo 6. periodo di test: raccogliere più feedback possibile 7. se ok, ampliare il numero degli utenti di test 8. se ok, dinamica -> organizzativa

Tips & Tricks Desktop policy per utenti iNotes ✔ occorre definire anche settings di tipo mail “Set initial value” funziona sempre una volta ✔ vengono sovrascritte le impostazioni utente Firma delle policy ✔ vengono applicate e utilizzate se correttamente firmate ✔ id expired ✔ utente cancellato

Tips & Tricks Cancellazione documenti policy ✔ organizzative: cancellata solo la policy ✔ esplicite: richiesta nell’admin4 per cancellare eventuali riferimenti ✔ settings: cancellati i riferimenti in tutte le policy che li utilizzano ✔ ATTENZIONE: ciò che viene inviato al client, rimane in funzione se cancellato senza essere sostituito! Ambienti con versioni miste: ✔ pre 8.0.1: policy effettiva calcolata dal client ✔ mail policy: dipendono dalla versione del template ✔ settings presenti su server ma non disponibili su client (versione inferiore)

Tips & Tricks Nome server in formato canonico ✔ se gerarchico, le policy non si aggiornano Policy dinamiche ✔ utilizzo di gruppi, non nomi individuali ✔ non solo gruppi “Auto-populated”, anche “normali” Errore mail policy ✔ “NAMELookups are limited on this server to a size smaller than what would be returned” → Namelookup_max_mb=2

Tips & Tricks No “CTRL-Z”! ✔ reimpostare un nuovo valore No reset delle policy da remoto ✔ cancellazione manuale ✔ editare e salvare il documento persona (sul server amministrativo) ACL Domino Directory → accesso “Editor” ✔ creazione: ruolo [PolicyCreator] o [PolicyModifier] ✔ modifica: ruolo [PolicyModifier] ✔ ruolo [PolicyReader]: replica con server Domino 4.67a-

Tips & Tricks Notes.ini, Locations e Managed Settings ✔ nei desktop settings → tab “Custom Settings” ✔ cancellazione variabili nel notes.ini: no! ✔ locations: tutte, non solo una specifica ✔ managed settings: pluginID/preferenceID=preferenceValue es. deploy automatico di Sametime No Connection documents

Q&ADomande?

Grazie agli sponsor per aver reso possibile i Dominopoint Days 2012! Main Sponsor Vad sponsor Platinum sponsor Gold sponsor

Domino policies: what else?

by stefano.benassi on Jun 23, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Domino policies: what else? Presentation Transcript