Sharepoint online - Document library permission

 Di solito creo le document library usando i gruppi di Office.

Il problema che ho riscontrato in alcuni casi e' l'impossibilita di scrivere nella libreria se non si e' membri del gruppo proprietari. Mentre non e' un problema dare i permessi di accesso alle sottocartelle, e' leggermente piu macchinoso farlo per la root. Io ho fatto cosi:

 - accesso al portale di Office

 - accesso alla libreria di sharepoint online (per intenderci non sono passato dall'interfaccia di amministrazione)

 - ingranaggio in alto a dx - impostazioni raccolta

 - Autorizzazioni per l'elenco di tipo raccolta documenti

 - concedi autorizzazioni

Nella schermata che si e' aperta ho aggiunto i gruppi/utenti con cui condividere ed a cui dare accesso alla directory principale.

N.B. In sharepoint assegnare dei permessi significa "condividere".

Validazione record SPF

Alcuni tool online per effettuare la validazione dei record SPF

 SPF Record Testing Tools

http://www.kitterman.com/spf/validate.html

SPF Surveyor

https://dmarcian.com/spf-survey/

Dig web interface

http://digwebinterface.com/

Microsoft 365 - importazione file pst - network upload

L'importazione dei file PST, se molto grandi puo essere un po macchinosa.

LE strade che si possono seguire sono essenzialmente

 - importazione tramite outlook. Configurare Outlook con le caselle dove devono essere importati i messaggi, e quindi importarli.

 - tramite upload in Microsoft 365

Per seguire la seconda strada occorre effettuare un po di operazioni preliminare prima di procedere.

LA prima operazione da seguire e' collegarsi in powershell al tenant ed eseguire il seguente conmando:

Enable-OrganizationCustomization

NOTE

Dobbiamo eseguire il comando poiche dobbiamo assegnare un nuovo permesso ad un ruolo esistente. Il permesso in questione e' mailbox import export.

PEr verificare che il comando sia andato a buon fine e' sufficiente eseguire questo comando:

Get-OrganizationConfig | FL isDehydrated

se il valore e' TRUE non e' stato eseguito

se il valore e' FALSE e' stato eseguito

La modifica all'organizzazione potrebbe richiedere un po di tempo per diventare davvero attiva. Ricordarsi di fare logoff logon prima di verificare.

Dopo che il comando sara' stato eseguito correttamente (non scritte rosse x interderci) dovremo aggiungere il ruolo necessario.

Aprire la console di exchange, andare in ROLE - ADMIN ROLE

Selezionare COMPLIANCE MANAGEMENT

Adesso dobbiamo aggiungere il permesso di MAILBOX IMPORT EXPORT al ruolo di compliance management

Ricordiamoci di aggiungere, in ASSIGNED membri e gruppi necessari.

Appena queste modifiche sono diventate attive, possiamo prcedere all'upload dei pst e delle modifiche necessarie.

Apriamo admin.microsoft.com e scegliamo conformita (compliance) e quindi "governance delle informazioni". - importazione - nuovo processo di importazione

Installare AzCopy dal link proposto, aprire una powershell ed eseguire il comando seguente:

AzCopy /source:"/path/to/pstfiles" /dest:<SAS URL> --recursive=true

.\AzCopy.exe /source:"J:\PSTs" /dest:"https://fsdfsfdgttrgergdfgdgdf.blob.core.windows.net/ingestiondata?sv=2099-04-05&sr=c&si=IngestionSasForAzCopy2034534353453455&sig=P3ffsd89f7sf7s89f78sd7fs9Kj%8s9f8sf98sf9s8f9s8fs9f8s9f89%3D&se=2099-07-02T13%3A08%3A51Z" /S /V:"J:\LOG\transfer.log" /Y

Dopo aver copiato i file e' ncessario preparare il file di importazione, che segue questo tracciato:

ES:

Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,ContentCodePage,SPFileContainer,SPManifestContainer,SPSiteUrl

Exchange,,PST01.pst,username@dominio.com,FALSE,/,,,,

Questo file dice, per il workload EXCHANGE, di importare il contenuto di PST01 nella casella username@dominio.com, e che non si tratta di una casella archivio (FALSE)

Salviamo il file con il nome PstImportMappingFile.csv

E possibile scaricare il modello del file ed avere degli esempi dai link sotto.

Andando avanti nel processo, ci viene chiesto il file cvs da utilizzare e di validarlo. Dopodiche, e' possibile procedere.

A questo punto, il file viene analissato. Al termine dell'analisi si puo premere sul simbolo della busta per procedere nell'importazione.

Al termine viene fornito un log con i dettagli.

TOOLS UTILI

AZ COPY - x copiare i file in cloud

https://aka.ms/downloadazcopy

https://azure.microsoft.com/en-us/features/storage-explorer/

REFERENCE

https://docs.microsoft.com/it-it/microsoft-365/compliance/importing-pst-files-to-office-365?view=o365-worldwide#BKMK_NetworkUpload

https://www.windowserver.it/2017/06/office-365-import-mail-da-pst/

https://lazyadmin.nl/office-365/import-pst-file-into-office-365/

TMR - Teams recording meeting - Registrazione meeting Teams

Può succedere che durante un meetings in Teams si decida di registrarlo. Può insorgere qualche problema nel momento in cui vogliamo condividere la registrazione con utenti esterni, soprattutto se il nostro tenant e stato creato prima del 2020 Q4.

Essenzialmente un meeting registrato puo essere salvato in Stream oppure in OneDrive/Sharepoint.

STREAM

Un meeting registrato in Stream non puo essere condiviso direttamente con utenti esterni alla propria organizzazione. Lo possiamo fare scaricando il video registrato e condividendolo, ad esempio con OneDrive, DropBox ecc. ecc.

ONEDRIVE/SHAREPOINT

Nei tenant piu recenti e' il metodo di default, e poco per volta lo dovrebbe diventare per tutti. I meeting registrati da un utente vengono salvati su OneDrive, mentre quelli di canale sono salvati su Sharepoint.

La condivisione, in questi casi è molto più semplice, poiché è analoga alla condivisione di qualsiasi altro file. 

MODIFICA POLICY DI SALVATAGGIO

E possibile cambiare la destinazione di salvataggio di un TMR. Per farlo aprire un powershell ed eseguire i seguenti comandi:

INSTALLAZIONE MODULI TEAMS POWERSHELL

Install-Module MicrosoftTeams

IMPORTAZIONE MODULO

Import-Module MicrosoftTeams

COLLEGARSI AL TENANT

Connect-MicrosoftTeams (MFA - vedi reference x dettagli)

oppure

$credential = Get-Credential

Connect-MicrosoftTeams -Credential $credential (standard auth)

MODIFICA POLICY PREDEFINITA

Set-CsTeamsMeetingPolicy -Identity Global -RecordingStorageMode "OneDriveForBusiness"

REFERENCE

https://docs.microsoft.com/en-us/MicrosoftTeams/tmr-meeting-recording-change

https://docs.microsoft.com/en-us/MicrosoftTeams/teams-powershell-install

HYPERV Replica

 Ecco un po di appunti sparsi sulla replica HyperV tra host in gruppo di lavoro, ed in particolare sulla gestione.

La replica hyperv puo avvenire tra host in dominio o in gruppo di lavoro (workgroup). Tra host in gruppo di lavoro, come nel nostro caso, e necessaria una parte preliminare piu articolata, che consiste nella creazione dei certificati, che vanno poi installati sui rispettivi host.

La scelta di lasciare gli host hyperV in gruppo di lavoro e’ relativa alla sicurezza, x evitare che con le credenziali di dominio si possa accedere anche agli host ed agli storage dove sono salvate le VM.

E’ possibile generare i certificati da qualsiasi PC o server.

Nel nostro caso ho generato i certificati dal mio PC, con Windows 10. I certificati coinvolti solo quella della CA authority (il mio PC, in questo caso) ed i due certifcati creati per l’host HYPERV_A e per HYPERV_B.

GENERAZIONE DEI CERTIFICATI

Ecco i comandi da eseguire per generarli (powershell):

GENERAZIONE DEL CERTIFICATO CA

New-SelfSignedCertificate -Type "Custom" -KeyExportPolicy "Exportable" -Subject "CN=HyperVCA" -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec "Signature" -KeyUsage "CertSign" -NotAfter (Get-Date).AddMonths(240)

In risposta al comando viene restituito il thumbprint del certificato ed il common name. Dovremo utilizzare il thumbprint nei comandi successivi

689A1887D9891AFE4B756118C8E04DC23E6DFE44  CN=HyperVCA

GENERAZIONE CERTIFICATO HYPERV_A

New-SelfSignedCertificate -type "Custom" -KeyExportPolicy "Exportable" -Subject "CN=HYPERV_A" -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec "KeyExchange" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2") -Signer "Cert:LocalMachine\My\689A1887D9891AFE4B756118C8E04DC23E6DFE44" -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddMonths(240)

GENERAZIONE CERTIFICATO HYPERV_B

New-SelfSignedCertificate -type "Custom" -KeyExportPolicy "Exportable" -Subject "CN=HYPERV_B" -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec "KeyExchange" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2") -Signer "Cert:LocalMachine\My\689A1887D9891AFE4B756118C8E04DC23E6DFE44" -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddMonths(240)

1CC38C74D619838E8D6DA1708ED79CAB2FAF0D8A  CN=HYPERV_A

106EB8002EFB7424254959DBD49EAC2F22F80E69  CN=HYPERV_B

ESPORTAZIONE DEI CERTIFICATI

Per esportare i certificati , aprire la console dei certificati (mmc – certificate snapin – computer – Cartella personal). Dentro dovrebbero esserci tutti e tre i certificati creati sopra. Esportare il certificato della CA come .cer (non esportare la chiave privata), mentre esportare quelli relativi agli host con la chiave privata, in formato .pfx (verrà chiesto di usare una password, necessaria successivamente per importarli).

IMPORTAZIONE CERTIFICATI SULL’HOST

I certificati quindi vanno importati sugli host.

HYPERV_A

HYPERVCA, HYPERV_A

HYPERV_B

HYPERVCA, HYPERV_B

Eseguire questi comandi per importarli

certutil -addstore -f Root "C:\hypervcert\HypervCA.cer"

certutil -f -p 11111111 -importpfx "c:\hypervcert\HYPERV_A_11111111.pfx"

– Disabilitare la verifica della revoca dei certificati digitando nel prompt dei comandi di tutti gli host Hyper-V:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

IMPOSTAZIONI PRELIMINARI DELLA REPLICA

Affinché tutto il processo di replica funzioni correttamente (failover e replica inversa), è necessario configurare entrambi gli host come replica. Infatti, nel funzionamento normale una VM viene replicata dall’host principale verso l’host di replica. Quando viene effettuato un failover i ruoli degli host rispetto alla VM si invertono, facendo diventare host di replica quello che era l’host principale e viceversa.

FIREWALL

E inoltre importante che la porta 443 del firewall sia aperta e che la risoluzione dei nomi, soprattutto se attiva l’autenticazione tramite certificato, funzioni correttamente.

RISOLUZIONE NOMI

Affinché l’autenticazione tramite certificato funzioni correttamente, è fondamentale che il nome host venga sempre risolto correttamente. Per questo motivo ho preferito mettere il nome host dei rispettivi dentro al file hosts di Windows in system32\drivers\etc\.

IMPOSTAZIONI REPLICA

IMPOSTAZIONE HOST

Nella impostazioni di HYPERV scegliere CONFIGURAZIONE REPLICA, ABILITAZIONE REPLICA e USA AUTENTICAZIONE BASATA SU CERTIFICATI (HTTPS). In caso di host in dominio può andare bene anche la kerberos. Tenere presente che usando i certificati e’ possibile cifrare il traffico di replica e con Kerberos no.

REPLICA VM

Dopo aver configurato gli host occorre attivare la replica per le singole VM. Tasto destro sulla VM e scegliere abilitazione replica. Seguire la configurazione guidata. Quando parte la replica, è possibile scegliere come vogliamo fare la prima sincronizzazione (ES: tramite rete)

OPZIONI REPLICA

Le opzioni di replica disponibili da host primario e host di replica sono leggermente diverse

HOST PRIMARIO

FAILOVER PIANIFICATO

In caso di manutenzione dell’host primario, attiva la replica sul secondario. Per funzionare la macchina principale deve essere spenta. Questo consente di fare un ultimo allineamento della replica, senza che vengano persi dati. E’ possibile decidere se accendere o no la VM di replica.

SOSPENDI REPLICA

Mette in pausa la replica tra i 2 host

VISUALIZZA STATO REPLICA

Controlla lo stato della reòlica

RIMUOVI REPLICA

Cancella la replica definitivamente

 

HOST REPLICA

FAILOVER

Si tratta dell’unplanner failover. Consente di attivare la replica in caso di blocchi improvvisi dell’host primario o VM principale. E’ una procedura di emergenza.

TEST FAILOVER

Verifica il corretto funzionamento della replica. Viene creata una macchina con il suffisso TEST, per verificare che tutto funzioni correttamente.

ESTENDI REPLICA

Consente di estendere la replica ad un terzo host

SOSPENDI REPLICA

Mette in pausa la replica tra i 2 host

VISUALIZZA STATO REPLICA

Controlla lo stato della reòlica

RIMUOVI REPLICA

Cancella la replica definitivamente

GESTIONE REPLICA – COME FARE UN FAILOVER

La funzione più utile è il planned failover (PFO) utile per “attivare” le VM sull’host di replica quando è necessario effettuare una manutenzione sull’host principale. In sintesi il processo del PFO e’ il seguente:

VM1_HYPERV_A su host HYPERV_A e replicata su HYPERV_B, come VM01_HYPERV_B

A regime la macchina in produzione è VM1_HYPERV_A ed è replicata su VM01_HYPERV_B.

Attivo il PFO: spengo VM1_HYPERV_A, le ultime modifiche sono riportate su VM01_HYPERV_B.

Si accende VM01_HYPERV_B e da ora in poi è lei la macchina di produzione.

In questo momento VM1_HYPERV_A e’ spenta e sto facendo le operazioni di manutenzione necessarie su HYPERV_A (l’host).

Dopo aver terminato le operazioni di manutenzione ho riacceso l’host HYPERV_A e sono pronte a riaccendere VM1_HYPERV_A. Per farlo ho la possibilità di invertire la replica o annullare il failover.

REPLICA INVERSA

Inverte il senso di replica. In pratica trasmettiamo le modifiche di VM01_HYPERV_B (produzione) a VM01_HYPER01 (ex produzione). Per concludere e riportare tutto alle condizioni iniziali, rieseguire un PFO ed una nuova REPLICA INVERSA.

ANNULLA FAILOVER

Consente di tornare indietro alla situazione precedente al failover. Se annulliamo il failover VM01_HYPERV_A ritornerà ad essere la VM di produzione e VM01_HYPERV_B tornerà ad essere la replica. Tutte le modifiche avvenute su VM01_HYPERV_B andranno perdute. Operazione caldamente SCONSIGLIATA in casi di domain controller, database ecc. ecc.

NOTE

La replica HYPERV è essenzialmente una soluzione di disaster recovery e non propriamente di backup o business continuity come un cluster. Per fare un failover pianificato (PFO) è OBBLIGATORIO spegnere le VM. La soluzione più indolore e rapida consiste nel tenere spenta la macchina di replica. Se non la si accende e’ possibile effettuare un ANNULLA FAILOVER senza perdere nulla in termini di informazioni, ed e’ molto veloce. E’ molto importante tenere presente il discorso dei checkpoint (production e standard), per evitare di perdere dati o introdurre errori.

 

 

 

ABILITARE AMMINISTRAZIONE REMOTA DEGLI HOST HYPERV DA UN CLIENT

E’ possibile installare la console Hyperv sul proprio PC per gestire direttamente gli host hyperv senza collegarsi direttamente al server. Per farlo occorre eseguire una serie di comandi:

SERVER

Sul server HYPERV al quale collegarsi eseguire i seguenti comandi

-        netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=Yes

-        netsh advfirewall firewall set rule group="Remote Event Log Management" new enable=Yes

FACOLTATIVO

-        netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

-        netsh advfirewall firewall set rule group="Remote Volume Management" new enable=Yes

CLIENT

Siccome stiamo parlando di server in workgroup, probabilmente non useranno gli stessi DNS del client. Per questo motivo il primo passaggio e' quello di aggiungere i nomi dei server al file hosts (C:\windows\system32\drivers\etc)

Dalla macchina CLIENT da cui connettersi al server in questione eseguire i seguenti comandi

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "HYPERV"

Enable-WSManCredSSP -Role client -DelegateComputer "HYPERV"

NOTA

Se il comando sopra non dovesse funzionare, si puo provare con quello sotto, generico per tutti gli host ed in seconda battuta restringerlo solo agli host necessari

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" - questo comando funziona x tutti gli host

N.B. Nel mio caso sul CLIENT ho dovuto avviare manualmente il servizio "Gestione remota Windows (WS-Management)" affinche il primo comando avesse esito positivo

AGGIUNTA DEGLI HOST IN GPEDIT.MSC

Configurazione computer > Modelli amministrativi > Sistema > Delega di credenziali > Consenti delega credenziali nuove solo con autenticazione server NTLM

wsman/HYPERV

A questo punto e' necessario aprire la console di HYPERV, aggiungere l'host a cui collegarsi e cliccare sulla casella "CONNETTI COME ALTRO UTENTE" ed inserirlo nel formato HYPERV\username

 

HYPERV CHECKPOINT

In HyperV esistono 2 tipologie di checkpoint: standard (crash consistent) e produzione (application consistent). E’ consigliato di usare i checkpoint standard solo in ambiente di test xche possono creare problemi con active directory e DB. In produzione è necessario utilizzare i checkpoint di produzione. Questi ultimi sono APPLICAZION CONSISTENT (il checkpoint effettua una richiesta ai provider VSS del guest). Con PFO non si presenta il problema perché viene effettuato lo switch a VM spenta. Nella situazione di un UNPLANNED FAILOVER (che si fa in situazioni di emergenza), bisogna cercare di ripristinare un APPLICATION CHECKPOINT, soprattutto se ci sono in ballo DB, AD ecc. ecc.

 

 

REFERENCE

https://itlabz10.tk/archives/1041

https://itlabz10.tk/archives/1025