Categoria: Windows Server

Posted on by

Exchange – cassette postali condivise

Le cassette postali condivise consentono a un gruppo di persone di monitorare e inviare posta elettronica da un indirizzo di posta elettronica comune, come info@mecdata.it. Quando un utente del gruppo risponde a un messaggio inviato alla cassetta postale condivisa, il messaggio di risposta sembrerà inviato dalla cassetta postale condivisa, non dal singolo utente.

Le cassette postali condivise vengono usate quando più persone devono accedere alla stessa cassetta postale, ad esempio un’informazione aziendale o un indirizzo di posta elettronica di supporto, una reception o un’altra funzione che potrebbe essere condivisa da più persone.

Le cassette postali condivise includono un calendario condiviso ed una rubrica condivisa.

Licenze: La cassetta postale condivisa può archiviare fino a 50 GB di dati senza assegnare una licenza. Per volumi più elevati, è necessario assegnare una licenza alla cassetta postale

Utenti esterni: Non è possibile concedere agli utenti esterni all’azienda (ad esempio, utenti con un account Gmail) l’accesso alla cassetta postale condivisa

Conversione delle cassette postali: È possibile convertire le cassette postali utente in cassette postali condivise.

Troppi utenti: Quando sono presenti troppi utenti designati che accedono contemporaneamente a una cassetta postale condivisa (è consigliabile non più di 25), è possibile che non riescano a connettersi a questa cassetta postale o abbiano incoerenze come i messaggi duplicati nella posta in uscita

Posted on by

Error from Filezilla Client to Microsoft IIS FTP Server

When you connect to ftp server create with Microsoft IIS using Filezilla Client you should have this error

GnuTLS error -48: Key usage violation in certificate has been detected. Could not connect to server

Your configuration settings are something like this :

  • Protocol: FTP – File Transfer Protocol
  • Encryption: Require explicit FTP over TLS

The problem is with self signed certificate on server side. This is a problem with the certificate generation of Microsoft IIS, as it does not allow the certificates to be used for digital signatures.

How to generate a valid certificate with IIS

This is a server-side issue, and it did not appear previously because earlier versions of FileZilla shipped with a GnuTLS version that didn’t make this check.

Quoting Tim Kosse’s post in the FileZilla forum thread:

In any case, the problem is with your server’s X.509 certificate chain: Either the server certificate itself or another certificate in the chain has a key usage restriction that is violated. For example a certificate with a key usage restriction to signing cannot be used to authenticate TLS connections. See section 4.2.1.3 of RFC 5280.

This is a problem with the certificate generation of Microsoft IIS (but may also happen if you incorrectly generated a certificate with another method), as it does not allow the certificates to be used for digital signatures. OpenSSL is much more relaxed about this and won’t fail because of it, so it may work with other apps.

On the client side, you can either disable TLS, downgrade to an earlier version of FileZilla (neither of these is recommended due to potential security risks), or use a different client which uses another library such as OpenSSL for now.

How to generate a valid certificate with IIS

This needs to be done on the server side, Yobviously.you can generate the certificate with PowerShell instead until the issue is fixed by Microsoft. Open PowerShell in admin mode.

The following powershell command will create our self-signed certificate for our binding and store it in the Personal Store (Note how I also store a reference to the certificate in a variable called $cert this will be needed further on):

$binding = "192.168.1.70"
$cert = New-SelfSignedCertificate -DnsName "$binding" -CertStoreLocation "cert:\LocalMachine\My"

However, this is not enough to make the certificate work for HTTPS in our browser. We need to add our newly created certificate to the Trusted Root Certificate store. To do this we take our $cert variable which references our created certificate and add it to our Trusted Root Certificate store like so:

$DestStore = new-object System.Security.Cryptography.X509Certificates.X509Store([System.Security.Cryptography.X509Certificates.StoreName]::Root,"localmachine")
$DestStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$DestStore.Add($cert)
$DestStore.Close()

Now you have to set the new certicate on your ftp site using IIS Admin.

Posted on by

Migrare cassette postali IMAP a Microsoft 365 – Office 365 – Exchange online

Di seguito i passi necessari in sequenza per migrare un dominio IMAP su Exchange Online.

  1. Aggiungere il dominio al tenant Microsoft 365. Non dovete completare la configurazione del mail server.
  2. Aggiungere gli utenti di dominio a Microsoft 365. Ogni utente deve avere una licenza Microsoft 365 Business Basic, Standard o Premium
  3. Preparare il file csv per la migrazione, separato da virgola. Nella prima riga mettere EmailAddress,UserName,Password. Nelle righe successive i dati : “EmailAddress è l’account Microsoft, “UserName” è l’account del server imap e “Password” è la password del server imap

esempio di csv

EmailAddress,UserName,Password
terrya@contoso.edu,contoso\terry.adams,1091990
annb@contoso.edu,contoso\ann.beebe,2111991
paulc@contoso.edu,contoso\paul.cannon,3281986
  1. Entrare come amministratore in Microsoft 365 e andare nell’interfaccia di amministrazione di Exchange. (nb. questa guida riguarda l’interfaccia di amministrazione “classica” di Exchange. Selezionare “destinatari” a sinistra; selezionare “migrazione” in alto.
  2. A centro pagina c’è un pulsante con tre punti : …. Selezionandolo si inserisce l’endpoint cioè il server sorgente Imap. Nella finestra successiva aggiungere il nuovo endpoint (IMAP).
  3. Creare una nuova migrazione. lanciare la migrazione
  4. una volta terminata la migrazione, nel tenant, potete finire la configurazione del dominio per quello che riguarda il server di posta, seguendo le istruzioni sul tenant e modificando i vostri dns

Le Regole della migrazione

Si possono mettere tutti gli utenti in una migrazione. Quando una migrazione termina con errori, si può eliminare un utente dalla stessa ed inserire lo stesso utente in un altra migrazione. Si possono avere più migrazioni contemporaneamente ma non può esistere lo stesso utente in più di una migrazione. La migrazione può esistere per un massimo di 60 giorni.

Non è una migrazione

In realtà Microsoft fa una operazione più sofisticata di una “banale” migrazione : fa una sincronizzazione. Sincronizza l’intera cassetta postale imap sulla cassetta Exchange in una direzione (da imap ad exchange). E’ sofisticato ma meno efficace di una normale migrazione : la sincronizzazione non è in tempo reale ma dopo 24/30 ore. Quindi volendo sostituire il mail server gli utenti perderebbero almeno 24 ore di email.

Configurazione di outlook

Sui client Outlook potete aggiungere il nuovo account di Exchange online. Sarà uguale alla cassetta postale precedente, ma sarà gestita da Exchange. Per un certo periodo avrete quindi 2 cassette postali che gestiscono la stessa posta ma su server diversi: uno è il vecchio server imap , l’altro il nuovo server Exchange. Quando la migrazione sarà terminata e avrete spostato anche i record mx sul dns, potete cancellare la vecchia cassetta postale. Prima di farlo però dovete spostare anche i contatti ed il calendario dalla “vecchia” alla “nuova” :

Contatti : selezionate tutti i contatti, tasto destro, selezionate “sposta” e quindi “copia nella cartella…”, contatti della cassetta di Exchange.

Calendario : Per spostare gli appuntamenti tra i 2 calendari : visualizzate entrambi i calendari e trascinate gli appuntamenti dal vecchio al nuovo.

Problemi nella migrazione

Se avete problemi di sincronizzazione potete indagare usando PowerShell. Prima di tutto installare ExchangeOnlineManagement. 

Connettersi al tenant :

Connect-ExchangeOnline -UserPrincipalName <your Admin Username>

Compare la schermata di richiesta password.

Lista di tutti gli endpoint nel tenant

get-migrationendpoint|FL

Test dell’endpoint

Test-MigrationServerAvailability -Endpoint <Identity of the endpoint from above>

Vedere le impostazioni della migrazione di un utente

Get-SyncRequest -Mailbox  <user>

Esportare il dettaglio di una migrazione :

Get-MigrationUserStatistics <user> -IncludeSkippedItems -IncludeReport 
-DiagnosticInfo "showtimeslots, showtimeline, 
verbose" | Export-Clixml C:\temp\MigMyUser.xml

Le cassette postali Exchange hanno un limite di 35MB. Se durante la migrazione dovete spostare qualcosa di più grande dovete cambiare questo limite.

Set-Mailbox -Identity <user> -MaxReceiveSize 150MB

Documentazione :

Posted on by

Register a web application with Azure AD Portal App Registration to connect to a Microsoft 365 tenant

PowerShell Limits

Through Powershell it is possible to connect to a Microsoft 365 tenant to perform operations on users, groups and any other element of the tenant. When you use this tool, Powershell presents you with the mask for entering your account and password. You can write accounts and passwords directly in the Powershell script but it would be a serious security compromise.

Application

An alternative is to build a software that connects directly to the Tenant through customized keys present in the Tenant itself. In other words, it is necessary to communicate to the Tenant that there is a certain application that is authorized to access the Tenant. Furthermore, for each operation that you want to perform on the Tenant it is necessary to specify the appropriate permissions. To create these applications, we recommend that you follow the excellent tutorial “.Net Core console application for calling Microsoft Graph“.  This post proposes the images present in the previous tutorial only to specify how the application must be prepared on the Microsoft Tenant.

Register a web application with Azure AD Portal App Registration

Open a browser and navigate to the Azure Portal. Login using your account. Select the resource “Azure Active Directory”. On the left side menu, select “App regitstration”. Click New registration from the current page.

On the Register an application page, specify the following values:

  • Name = Name of your Application
  • Supported account types
  • Redirect URI
    • Type = Web
    • Value = https://localhost:8080   (*)

(*) The Redirect URI value must be unique within your domain. This value can be changed at a later time and does not need to point to a realy hosted URI.

It is now necessary to store 2 values that will be used in your application:

  • Application (client) ID
  • Directory (tenant) ID

Certificates & secrets

Click Certificates & secrets.

  1. Click New client secret.
  2. On the Add a client secret dialog, specify the following values:
    • Description = Your secret’s description
    • Expires = In 1 year (for example)
  3. Click Add.

After the screen has updated with the newly created client secret copy the VALUE of the client secret. This secret string is never shown again, so make sure you copy it now.

API permissions

Click API permissions.

  • Click Add a permission
  • On the Request API permissions panel select Microsoft Graph.

  • Select Application permissions.

Now you have to choose between the permissions to authorize your app. For example, to create an application to read alla information about Tenant’s users, in the “Select permissions” search box type “User”.Select User.Read.All from the filtered list. At the end, on the API permissions content blade, click Grant admin consent for the Tenant.

Summary of the data necessary for the application

Let’s see what data your application needs to connect and operate on the Microsoft Tenant.

  • applicationId = “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”;
  • applicationSecret = “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”;
  • tenantId = “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”;
  • redirectUri = “https://localhost:8080”;
  • domain = “yourtenant.onmicrosoft.com”;

Permissions

  • User.Read.All : Read all users’ full profiles
  • User.ReadWrite.All : Read and write all users’ full profiles
  • Group.ReadWrite.All : Read and write all groups
  • Notes.ReadWrite.All : Read and write all OneNote notebooks

Documentation

Posted on by

Apache su Windows – AH00072: make_sock: could not bind to address [::]:80

Scenario

Sul vostro Windows,  Apache non parte. Andate nell’event viewer e trovate l’evento di errore :

AH00072: make_sock: could not bind to address [::]:80

Problema

Il problema è dovuto al fatto che una applicazione sta utilizzando la porta 80 del vostro sito su Apache. Come scoprire quale è questa applicazione ?

Aprite il command prompt (cmd). Digitate

netstat -ano

Vedete tutte le porte aperte del vostro computer occupate da una applicazione. Trovate la riga che (in questo caso) riguarda la porta 80. Alla colonna PID è indicato il numero del programma che sta usando la vostra porta.

Aprite task manager (gestione attività) , nella tab “Dettagli” attraverso la colonna PID trovate il programma che sta usando la vostra porta.

Soluzione

Avete 2 possibilità : o fermate il programma oppure, se il programma vi serve, cambiate la porta usata da questo programma, se possibile, oppure quella usata da Apache.

Se il programma che avete trovato attraverso il PID è System, significa che è lo stesso Windows a bloccare la porta. Aprite i servizi e dovete stoppare il servizio “Servizio Pubblicazione sul Web“. Dovrete anche settare la partenza in manuale, se invece fosse in Automatico perché altrimenti il giorno dopo vi si ripresenterebbe il problema.

Posted on by

Windows server – Active Directory – useful links

Move active directory roles from a domanin controller ti another

VERIFICARE E MODIFICARE I RUOLI FSMO DI UN DOMINIO WINDOWS

Backup Domain Controller

Aggiungere un Backup Domain Controller ad un dominio Active Directory esistente

Installing licenses for Remote Desktop

Licensing Mode for Remote Desktop Session Host is not Configured

Modalità gestione licenze di Desktop remoto non configurata

Posted on by

iis error 0x80070021 on web.config

Questo errore si presenta installando un sito con IIS in locale su un windows 10 o un windows 8.1. Non è escluso che si possa manifestare anche sui sistemi operativi server.

Dettaglio Errore

Modulo
IIS Web Core

Notifica
BeginRequest

Gestore
Non ancora determinato

Codice errore
0x80070021

Errore di configurazione
Impossibile utilizzare la sezione di configurazione in questo percorso. L’errore si verifica quando la sezione è bloccata a livello padre. Il blocco avviene per impostazione predefinita (overrideModeDefault=”Deny”) o è impostato esplicitamente da un tag di percorso con overrideMode=”Deny” o con il precedente allowOverride=”false”.

File di configurazione
\\?\C:\inetpub\wwwroot\test\web.config

Percorso fisico
C:\inetpub\wwwroot\test\miofile

Metodo di accesso
Non ancora determinato

Utente accesso
Non ancora determinato

SOLUZIONE

Dovete installare anche .NET e gli strumenti di sviluppo di IIS

oppure