Exchange 2013: Errore durante l’installazione del CU7

Anche il Cumulative Update 7 di Exchange Server 2013 ci si mette…

Siccome sono un amante delle missioni suicide, ultimamente ho ereditato un cliente con un’infrastruttura di server implementata da un altro tecnico. Quando il cliente mi ha segnalato di avere da tempo un po’ di problemi mi sono trovato in un ginepraio… Ogni singola componente del sistema aveva problemi.

• Repliche di Active Directory non funzionanti;
• Tutta l’infrastruttura si appoggiava ad un vecchio domain controller Win2003 (il malfunzionamento delle repliche non aveva consentito di mandare in produzione i nuovi DC Win2012);
• Pezzi di SharePoint 2013 abbandonati su un domain controller;
• Exchange 2013 con mille problemi… e oggi parlerò di uno di questi.

L’installazione è stata realizzata a luglio 2014 e scopro che su Exchange 2013 non è stato installato neppure il Service Pack 1 (rilasciato a febbraio 2014…). Considerando che non è neppure stata attivata la licenza, regolarmente acquistata dal cliente, e la macchina risulta in modalità trial, la cosa non mi stupisce particolarmente.

Decido di installare il SP1, vedere cosa succede, e poi applicare il Cumulative Update 7.

L’installazione del Service Pack 1 fila liscia. Il server funziona, quindi decido di applicare il CU7. Ovviamente, dopo oltre un’ora di attesa, alla fase 10 di 18, tutto si blocca con un bell’errore.

Riporto il testo dell’errore, così da agevolare le ricerche tramite Google…

Errore:
Si è verificato il seguente errore durante l’esecuzione di “$error.Clear();
$connectors = Get-ReceiveConnector -Server $RoleFqdnOrName;
foreach($connector in $connectors) { if($connector.MaxLocalHopCount -gt 1) { Set-ReceiveConnector -Identity $connector.Identity -MaxLocalHopCount 5 } };
“: “Microsoft.Exchange.Management.SystemConfigurationTasks.ReceiveConnectorRoleConflictException: I valori specificati per i parametri Bindings e RemoteIPRanges sono in conflitto con le impostazioni nel connettore di ricezione “MI-PH-MAIL01\Connettore Sharepoint 2013″. I connettori di ricezione assegnati a ruoli Trasporto diversi su un unico server devono essere in ascolto su binding di indirizzo IP e porta univoci.
in Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
in Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
in Microsoft.Exchange.Management.SystemConfigurationTasks.SetReceiveConnector.InternalValidate()
in Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
in Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)”.

Errore:
Si è verificato il seguente errore durante l’esecuzione di “$error.Clear();
$connectors = Get-ReceiveConnector -Server $RoleFqdnOrName;
foreach($connector in $connectors) { if($connector.MaxLocalHopCount -gt 1) { Set-ReceiveConnector -Identity $connector.Identity -MaxLocalHopCount 5 } };
“: “Microsoft.Exchange.Management.SystemConfigurationTasks.ReceiveConnectorRoleConflictException: I valori specificati per i parametri Bindings e RemoteIPRanges sono in conflitto con le impostazioni nel connettore di ricezione “MI-PH-MAIL01\Default Frontend MI-PH-MAIL01″. I connettori di ricezione assegnati a ruoli Trasporto diversi su un unico server devono essere in ascolto su binding di indirizzo IP e porta univoci.
in Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
in Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
in Microsoft.Exchange.Management.SystemConfigurationTasks.SetReceiveConnector.InternalValidate()
in Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
in Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)”.

In pratica l’errore mi dice che questo connettore di ricezione, di nome Connettore SharePoint 2013, ha un binding di indirizzo IP e porta di ascolto in conflitto con quello del connettore predefinito di Exchange 2013.

Bello, se non che a questo punto né la console né la shell di Exchange sono più funzionanti. Ora, a di la del fatto che per come la vedo io, questo controllo Microsoft lo dovrebbe fare come prerequisito ed avvisare prima di demolire il server arrivando alla fase 10 su 18, come faccio a sistemare la cosa?

Mi viene incontro il buon vecchi ADSI Editor. Lo eseguo e mi connetto al contesto relativo alla configurazione.

Vado a cercare il connettore espandendo le voci che evidenzio nella figura seguente:

Con un doppio click sul connettore incriminato, vado alla ricerca dei parametri relativi all’IP e alla porta di ascolto, che sono rispettivamente:

msExchSmtpReceiveRemoteIPRanges

msExchSmtpReceiveBindings

Li modifico entrambi, così da eliminare il conflitto. In seguito andrò a riconfigurarli in modo corretto. Ora l’importante è far ripartire il server, anche perché è la 1.30 di venerdì notte e sono un po’ stanchino…

Al posto di 10.0.0.5 metto un 10.0.0.8

E al posto della porta 25 metto al momento la 26.

Così facendo il connettore è in ascolto su un IP e una porta differente. Provo quindi a rieseguire l’installazione del CU7. Fortunatamente si accorge che i primi 9 passaggi sono già stati eseguiti e sono andati a buon fine, quindi mi chiede se voglio riprendere da dove ci eravamo lasciati. Sono aperto al dialogo, quindi accetto.

OK, la fase critica è superata e l’installazione prosegue in scioltezza.

Non resta che attendere e vedere che tutto sia tornato in funzione (sperando che SP1 e CU vari abbiano risolto le magagne che il cliente segnalava, inoltre).

Dopo un’oretta circa e un riavvio del server ecco OWA nuovamente in funzione.

Ricapitolando, operazione iniziata alle ore 19.30 e conclusa alle ore 2.25.

Non male come venerdì sera, no?

Lunedì sistemerò anche il connettore di SharePoint. Ora vado a dormire.