ISA 2006 Outlook 2010 fuori dominio: problemi con con risposte automatiche
Scenario:
Outlook 2010 su client in dominio azienda.lan che si connettono a un Exchange 2007 nel dominio azienda.it con rete protetta da ISA 2006.
In una configurazione come questa di fatto i client Outlook interni si comportano verso il server Exchange come fossero dei client esterni.
Ciò può essere fonte di qualche piccolo malfunzionamento come ad esempio nel caso si cerchi di gestire le regole fuori ufficio in Outlook 2010 (e probabilmente anche in Outlook 2007, per la configurazione delle regole di Out of Office si veda How to use the Out of Office Assistant in Outlook).
Infatti tentando di aprire la funzionalità delle Regole Automatiche si ha il seguente errore:
Questo problema può essere causato da vari motivi a riguardo si vedano:
- Error message when you try to open the Out of Office Assistant in Outlook 2007: “Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later
- Error message when you try to set an OOF message in Outlook 2007: “Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later”
- Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later. ?!?
In questo scenario però la causa è dovuta al fatto che i client configurati per utilizzare ISA Server 2006 come proxy redirigono verso quest’ultimo le richieste di autodiscover che servono per individuare il server Exchange e iniziare una comunicazione su HTTPS per configurare le regole automatiche.
La problematica è discussa nel post Internal Autodiscovery not working with ISA 2006 using wpad.dat del forum di MSExchnage.org, dove l’utente indica che le soluzioni sono due:
- Non utilizzare il proxy autodetection per evitare di utilizzare il file WPAD.DAT fornito da ISA 2006 e gestire manualmente o via GPO l’impostazione del poxy e l’eslusione del server Exchange.
- Modificare il file WPAD.DAT creato da ISA Server.
Onestamente non mi soddisfa nessuna delle due soluzioni suggerite ed ho ovviato creando una access rule su ISA Server che consentisse agli utenti interni l’accesso tramite HTTPS al server Exchange definendo il Domain Name Set Server Exchange contenente le seguenti voci:
- azienda.it
- autodiscover.azienda.it
- mail.azienda.it
A questo punto se viene utilizzato il certificato autofirmato di Exchange 2007 sui client Outlook 2010 verrà visualizzato il seguente warning:
Per risolvere questo problema mi è stato utile seguente post Troubleshooting Certificate Mismatch Warnings in Outlook 2007 Clients on Small Business Server 2008 in cui si fa riferimento all’articolo della KB A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service.
Nell’articolo si indica che i client Office 2010 e client Outlook 2007 tramite l’hotfix KB939184 possono rilevare l’Autodiscover service tramite un record DNS SRV:
“This article describes a new feature in Microsoft Office Outlook 2007. This new feature enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service.
This feature is also available in Outlook 2010.”
“By using the software update that is described in this article, Outlook 2007 will perform an additional check for a DNS SRV record in order to locate the Autodiscover service. This additional check does not require complex configuration or a valid certificate for the Autodiscover service.”
In sostanza occorre configurare sul DNS del dominio azienda.it un record SRV con le seguenti impostazioni:
Ovviamente il DNS sul DC del dominio azienda.lan avrà come forwarder per il dominio azienda.it il DNS di quest’ultimo (ovvero un DC di azienda.it).
La problematica del warning del certificato digitale può avare anche cause e soluzioni a rigurado si vedano:
[…] l’errore in realtà l’autodiscover era configurato come avevo descritto tempo fa nel post ISA 2006 Outlook 2010 fuori dominio: problemi con con risposte automatiche (ovvero creando un record dns SRV nel dominio del server Exchange per la porta TCP 443, il servizio […]