Microsoft Exchange Server 2016: Guida all’installazione – Parte 2/2

Nel precedente articolo, disponibile qui, abbiamo visto come eseguire l’installazione di un server Exchange 2016, in questa parte vedremo come completare la configurazione per poterlo rendere operativo.

Vediamo quali sono i passi successivi da compiere:

  • Inserimento del Product Key
  • Creazione di un connettore di invio
  • Aggiunta dei domini accettati
  • Modifica della Email Address Default Policy
  • Configurazione URL esterne/interne
  • Specifica della dimensione massima dei messaggi
  • Configurazione del certificato SSL
Inserimento del Product Key
  1. Collegarsi alla EAC tramite l’URL https://<server exchange>/ECP
  2. Inserire Username e Password
  3. Selezionare Servers nel menù a sinistra e Servers nel menù in alto
  4. Selezionare il proprio server Exchange e nella parte destra cliccare su Enter Product Key
  5. Nella finestra che si apre nel tab General inserire il Product Key e cliccate su Save
  6. Se il codice è corretto dovrebbe apparire il messaggio seguente:
    Product Key Warning
  7. Per rendere effettive le modifiche bisogna riavvia l’Information Store come richiesto nel messaggio di warning:
    Information Store
    Quindi Control Panel -> Administrative Tools -> Services -> Microsoft Exchange Information Store -> Restart

 

Creazione di un connettore di invio

Prima di poter inviare email è necessario creare un connettore di invio nel Mailbox server:

  1. Effettuare il login nella EAC
  2. Andare in Mail flow -> Send connectors e cliccare su + (New)
  3. Nel campo Name dell wizard inserire un nome a piacimento, ad esempio Internet e cliccare su Next
  4. Verificare che la voce MX record associated with recipient domain sia selezionata e cliccare su Next
  5. In Address space cliccare sul +, inserire nel campo Full Qualified Domain Name (FQDN) un * e cliccare su Save
    Add Domain
  6. Verificare che l’opzione Scoped send connector non sia selezionata e premere Next
  7. Nella voce Source server cliccare sul + e scegliere il proprio server Exchange dal menù a tendina
  8. Cliccare su Finish

A questo punto il connettore di invio appena creato dovrebbe comparire nell’elenco che prima era vuotoSend Connector

Da questa schermata possiamo anche abilitare i log di questo connettore cliccando su On nella parte destra sotto la voce Logging. La posizione predefinita per questo file di log è:

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

 

Aggiunta dei domini accettati

Nelle impostazioni iniziale l’unico dominio di posta accettato dal server Exchange è quello conincidente con il nome del dominio scelto che di solito è <nome_azienda>.local, quindi dobbiamo eliminare quello e inserire quello pubblico.

Il procedimento da seguire è questo:

  1. Effettuare il login nella EAC
  2. Andare in Mail flow -> Accepted domains e cliccare sul +
    Accepted Domain
  3. Nel campo Name inserire un nome mnemonico per questo dominio
  4. Nel campo Accepted domain inserite il dominio per il quale si vuol ricevere la posta
  5. Verificare che sia seleziona la prima delle tre opzioni: Authoritative: …
  6. Cliccare su Save

Il nuovo dominio dovrebbe essere visibile insieme a quello di default.

A questo punto dobbiamo impostare questo dominio come Predefinito, per far questo dobbiamo selezionarlo e quindi cliccare sulla matita, si aprirà la stessa finestra di prima ma ora possiamo spuntare la voce Make this the default domain e quindi cliccare su Save.

Il dominio .local non può essere ancora cancellato, infatti se lo selezionate e provate a cancellarlo riceverete l’errore seguente:

Remove Domain

Questo perchè quel dominio è ancora utilizzato dalla policy di default, quindi dobbiamo modificarla.

Modifica della Email Address Default Policy

Per modificare la Defautl Policy di creazione delle email dobbiamo procedere in questo modo:

  1. Effettuare il login nella EAC
  2. Selezionare mail flow -> email address policies
  3. Selezionare la Default Policy e cliccare sulla matita
  4. Nel tab email address format cliccare sul +
  5. Nel campo Select an accepted domain selezionare il dominio pubblico che abbiamo creato in precedenza
  6. Eventualmente modificare il formato di default per la creazione degli indirizzi di posta
  7. Selezionare il checkbox Make this format the reply email address
  8. Cliccare su Save
  9. Selezionare il dominio ora la riga contenente il formato relativo al dominio .local e cliccare sul per rimuovere la voce
  10. Cliccare su Save
  11. Cliccare OK nel messaggio di Warning.

A questo punto possiamo tornare in mail flow -> accepted domains e cancellare il dominio .local tramite l’icona del cestino.

Configurazione URL esterne/interne

A quesot punto dobbiamo impostare le URL interne ed esterne per raggiungere il nostro server Exchange. Un modo semplice di configurarle è quello di utilizzare lo stesso indirizzo sia internamente che esternamente, ad esempio mail.<dominio azienda>.<estenzione dominio>.

Esternamente dovrete configurare i DNS pubblici per far puntare il record mail verso l’IP pubblico della vostra connessione Internet, mentre intrnamente dovrete creare una zona mail.<dominio azienda>.<estenzione dominio> nel server DNS e farla puntare all’IP privato del server Exchnage.

Per impostare gli indirizzi possiamo usare la EAC, andare in server e modificare a mano tutti i vari indirizzi oppure possiamo utilizzare uno script in PowerShell in modo da automatizzare il tutto.

Lo script è scaricabile da questo link, e si compone di due file, ConfigureExchangeURLs.ps1 e GetExchangeURLs.ps1. Il file GetExchnageURLS.ps1 server per visualizzare gli indirizzi impostati, mentre l’altro per impostarli.

Vediamo quindi come usare il comando per impostare gli indirizzi, aprite la Exchange Management Console e digitate:

.\ConfigureExchangeURLs.ps1 -Server srv-exc01 -InternalURL mail.dominio.com -ExternalURL mail.dominio.com

non dovrebbero comparire errori e al termine potete verificare le nuove impostazioni con il comando:

.\Get-ExchangeURLs.ps1 -Server srv-exc01

dovreste vedere tutti gli indirizzi interni ed esterni impostati al valore corretto.

Al posto di srv-exc01 sostituite il nome del vostro server Exchange.

 

Specifica della dimensione massima dei messaggi

La dimensione predefinita dei messaggi di posta elettronica è 35MB per i connettori di invio, 36MB per i connettori di ricezione e di 10MB per il ruolo Trasporto.

Per verificare questi valori potete usare i seguenti comandi:

get-transportconfig | ft maxsendsize, maxreceivesize 
get-receiveconnector | ft name, maxmessagesize 
get-sendconnector | ft name, maxmessagesize

Normalmente sono bassi e si impostano a un valore standard di 50MB, l’impostazione deve essere eseguita sui vari connettori, sul ruolo di trasporto, nelle mailbox, etc. per applicare le modifiche in modo veloce potete usare questi comandi:

get-transportconfig | Set-TransportConfig -maxsendsize 50MB -maxreceivesize 50MB
get-receiveconnector | set-receiveconnector -maxmessagesize 50MB
get-sendconnector | set-sendconnector -maxmessagesize 50MB
get-mailbox | Set-Mailbox -Maxsendsize 50MB -maxreceivesize 50MB

 

Configurazione del certificato SSL

L’ultimo step per la configurazione del nostro server Exchange è quello di installare un certificato SSL che viene usato sia da Outlook Anywhere sia da Exchange ActiveSync. Il certificato non può essere del tipo self-signed (cioè rilasciato dal server stesso) ma deve essere rilasciato da una CA valida che può essere sia una CA installata internamente in azienda oppure una CA pubblica. Il vantaggio di usare un certificato rilasciato da una CA pubblica è quello di essere riconosciuto automaticamente mentre se usate una CA interna dovrete esportare il certificato della CA e installarlo su tutti i computer che devono usare Exchange.

Visto che il costo dei certificati è di qualche decina di euro l’anno e che ci sono società tipo StartSSL (https://www.startssl.com/) che rilasciano alcuni tipi di certificati gratuiti vedremo come importare uno di questi certificati.

Il primo STEP è quello di generare un certificato SSL valido che contenga il nome DNS che abbiamo impostato nei passaggi precedenti, quindi nel nostro caso mail.<dominio azienda>.com. Una volta generato il certificato dobbiamo scaricarlo preferibilmente nel formato PKCS #12 che contiene anche la chiave privata.

Apriamo quindi la Exchange Management Console e digitiamo:

Import-ExchangeCertificate -Server <nome server exchange> -FileName "<nome certificato>.p12" -Password (ConvertTo-SecureString -String '<Password impostata per la chiave privata>' -AsPlainText -Force) -FriendlyName "Microsoft Exchange Server"

Una volta terminato il comando possiamo verificare l’importazione dalla EAC nella sezione servers -> certificates, il nuovo certificato dovrebbe essere presente:

Certificato

A questo punto dobbiamo dire ad Exchange di utilizzare il nuovo certificato, selezionatelo e cliccate sulla matita o effettuate un doppio click, nel wizard nella sezione services selezionate i servizi:

  • SMTP
  • IMAP
  • POP
  • IIS

e cliccate su Save. Nella finestra di Warning che compare cliccate su Yes:

Warning

Una volta fatto questo possiamo selezionare il certificato standard self-signed e cliccare sul cestino, al solito Warning rispondiamo Ok.

Warning

A questo punto se provate a collegarvi via web all’indirizzo https://mail.<dominio azienda>.com non dovreste più ricevere il warning per certificato non valido:

Https

Se avete seguito tutti i passi il vostro nuovo server Microsoft Exchange 2016 è pronto per entrare in produzione, dovete a questo punto solo creare le mailbox, liste di distribuzione, Public Folder etc.

Uno strumento molto utile per verificare la corretta configurazione di:

  • Exchange ActiveSync
  • Exchange ActiveSync Autodiscover

è il tool online Microsoft Remote Connectivity Analyzer.

 

 

Exchange: The WS-Management service cannot process the request. The load quota for the system has been exceeded.

Aprendo la PowerShell di un server Exchange (2010/2013/2016) può capitare di ricevere un errore del tipo:

VERBOSE: Connecting to SRV-EXC01.byteware.local.
New-PSSession : [srv-exc01.byteware.local] Connecting to remote server srv-exc01.byteware.local failed with the
following error message : The WS-Management service cannot process the request. The load quota for the system has been
exceeded. Send future requests at a slower rate or raise the system quota. For more information, see the
about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
 gTransportException
 + FullyQualifiedErrorId : -2144108120,PSSessionOpenFailed

Per risolvere il problema dovete aprire la console Internet Information Services (IIS) Manager e all’interno degli Application Pools effettuare il Recycle dell’MSExchangePowerShellAppPool:

IIS

Successivamente la Exchange Management shell si aprirà senza problemi:

Exchange Management shell

Cambiare porta al Remote Desktop Web Access (RD Web Access)

L’RD Web Access (Remote Desktop Web Access) è uno strumento molto utile e si presta a molte applicazioni sia esternamente all’azienda sia internamente.

L’RD Web Access è sostanzialmente un portale che risiede su un server interno e che viene pubblicato verso l’esterno:

RDWeb

tramite questo portale l’utente può effettuare il login utilizzando le sue credenziali di Active Directory e successivamente può collegarsi in RDP a un qualunque host interno all’azienda o lanciare direttamente le applicazione installate su un server tramite RemoteApp.

RemoteApp

Il grande vantaggio dell’RD Web Access è quello di utilizzare una sola porta in ingresso, HTTPS (443), sul quale far veicolare sia le connessioni RDP internet sia le RemoteApp tramite l’RD Gateway:

RD Gateway

Il problema sorge quando abbiamo un solo indirizzo IP pubblico e magari un server Exchange che pubblica già OWA sulla porta 443, in questo caso non possiamo pubblicare l’RD Web Access con le impostazioni standard ma dobbiamo cambiare porta.

Il cambio della porta è relativo sia al portale Web Access sia alla porta usata dall’RD Gateway.

Per modificare la porta di ascolto del portale Web Access la procedura è molto semplice e consiste nel modificare il Binding del website su una porta diversa dalla 443, ad esempio 444:

Site Binding

Una volta IIS potete provare a collegarvi sulla nuova porta e dovreste riuscire a collegarvi al portale.

A questo punto dobbiamo modificare anche la porta usata dall’RD Gateway, altrimenti se provate a lanciare una RemoteApp riceverete un errore.

Per far questo aprire una console PowerShell e usate il comando:

Set-RDSessionCollectionConfiguration –CollectionName "Your Collection" -CustomRdpProperty "gatewayhostname:s:<GATEWAY.FQDN>:<Port, e.g. 9999>" -ConnectionBroker <Your Connection Broker>

questo modificherà la porta di default da 443 a quella che avete impostato.

Una volta fatto questo potete pubblicare le varie applicazioni e tutto dovrebbe funzionare senza problemi.

Quello che ci rimane da configurare è l’accesso a un PC interno, infatti se proviamo a collegarci con un PC interno tramite il tab Connect to a remote PC, otteniamo l’errore:

Remote Desktop Connection

perchè di default viene passata la porta standard (443) per l’RD Gateway. Per modificarla dobbiamo aprire IIS e modificare le Application Settings per sito RDWeb, in particolare dobbiamo impostare il parametro DefaultTSGateway con l’host e la porta corrette:

Application Settings

Windows 2012 R2: We couldn’t complete the updates. Undoing changes.

In questi giorni sto configurando un nuovo server per un cliente con Windows Server 2012 R2 con il ruolo di Hyper-V, una volta installate le varie macchine virtuali è giunto il momento degli aggiornamenti, dopo aver installato il WSUS e scaricati gli update si parte con l’installazione:

Installing updates...dopo una mezz’ora buona riavvio le macchine virtuali e non è più possibile entrare in RDP!!!

Mi collego allora dalla console di Hyper-V e mi accorgo che il problema è che la VM sta facendo il roll-back degli aggiornamenti, operazione che durerà un’altra mezz’ora:

We couldn't complete the updates

Il problema è dovuto a una incompatibilità della patch di sicurezza KB2920189 con il Secure Boot delle VM Gen2.

La soluzione è molto semplice, dovete spegnere la macchina virtuale, andare nelle proprietà della VM stessa e disabilitare il Secure Boot:

Secure BootUna volta avviata potete installare gli aggiornamenti senza problemi.

VMWare ESXi: Could not find a trusted signer

Oggi stavo cercando di aggiornare i driver di un controller Adaptec di un host VMWare ESXi tramite SSH ed ho ottenuto l’errore “Cloud not find a trusted signer”:

# esxcli software vib update -v /tmp/vmware-esxi-drivers-scsi-aacraid-510.5.2.1.41024.-1.1.5.802205.x86_64.vib

[InstallationError]
 ('Adaptec_Inc_bootbank_scsi-aacraid_5.1.5.2.1.41024-1OEM.510.0.0.802205', 'Could not find a trusted signer.')
 vibs = Adaptec_Inc_bootbank_scsi-aacraid_5.1.5.2.1.41024-1OEM.510.0.0.802205
 Please refer to the log file for more details.

per evitare la verifica  della firma e installare l’aggiornamento basta aggiungere ‘–no-sig-check‘:

# esxcli software vib update -v /tmp/vmware-esxi-drivers-scsi-aacraid-510.5.2.1.41024.-1.1.5.802205.x86_64.vib --no-sig-check
Installation Result
 Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
 Reboot Required: true
 VIBs Installed: Adaptec_Inc_bootbank_scsi-aacraid_5.1.5.2.1.41024-1OEM.510.0.0.802205
 VIBs Removed: Adaptec_Inc_bootbank_scsi-aacraid_5.1.5.2.1.40301-1OEM.510.0.0.802205
 VIBs Skipped:

 

%d blogger cliccano Mi Piace per questo: