none
Problema con outlook 2007 verso Exchange 2007. Non possono impostare regole di fuori sede (OOF, OOOA) RRS feed

Risposte

  • Ho risolto. Lo scrivo qui perchè possa essere utile anche per i posteri:

    lanciato Get-AutodiscoverVirtualDirectory | fl -property *url*, identity e controllato che gli url fossero corretti. erano vuoti.

    lanciato quindi Set-AutodiscoverVirtualDirectory -identity <la identity ottenuta> -internalUrl <l'url interno che devono usare i client interni> -externalurl <l'url esterno che devono usare gli esterni>

    POI

    controllato anche in get-webservicesvirtualdirectory. Di tutti gli URL ho il certificato pubblico installato con o principal name o Subject alternate Name, quindi ho escluso problemi di cert. (però ho "sbirciato" lo stesso con internet explorer su: https://<nomeserver>.<nomedominioext>/autodiscover/Autodiscover.xml ma era tutto OK)

    andato in IIS, modificato le impostazioni di SSL della cartella Autodiscover per il sito Exchange, impostando per IGNORARE i certificati clients.

    POI

    Ho dovuto RIAVVIARE TUTTO IL SERVER (i servizi Exch + iisreset non sono stati suficienti)

     

    poi è andato tutto a posto

     

    P.S. per chi ha tempo, glie ne racconto una....

    Se avete una SAN con le path ridondate in fibra e dovete cambiare un modulo fibra per il controllore passivo (certo che è passivo, gli è appena fallita la fibra...) ricordatevi di stare all'occhio con una cosa che può succedere:

    Il software MPIO del server potrebbe voler a tutti i costi riutilizzare la fibra numero 1 (leggi la scheda numero 1 sul server), dopo il riavvio. Quindi vedreste il disco con tutti i vostri preziosissimi dati in modalità "non inizializzato" e "illeggibile".... (certo, cerca di raggiungerlo mediante il controller passivo!...).

    In questo caso la soluzione per me è stata spresentare l'intera LUN al server e ripresentarla, partendo dalla seconda path.

    Siccome non è la prima volta che mi capita.... io vi ho raccontato una barzelletta .... ma voi pensateci...

     

     

    Ciao!


    Diego Castelli - MCSA 2003, MCP ISA 2004, MCTS Forefront. ITA: Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Contrassegnato come risposta Diego Castelli venerdì 10 dicembre 2010 14:21
    • Modificato Diego Castelli venerdì 10 dicembre 2010 14:26 aggiunto dettagli
    venerdì 10 dicembre 2010 14:21

Tutte le risposte

  • aggiornamento:

    [PS] C:\Windows\System32>Set-AutodiscoverVirtualDirectory -identity "DGRPDG01\Autodiscover (Default Web Site)" -internalurl https://xxxxxxxx/autodiscover/ -externalurl https://xxxxxxxx/autodiscover/

    sia con FQDN che con nome NETBIOS che con nome internet (che è risolto internamente con l'ip interno del server)

    Nulla.

    Ho lanciato il comando perchè se facevo Get-AutodiscoverVirtualDirectory | fl , i campi internalURL ed ExternalURL erano VUOTI.

    Non mi ricordo che cosa c'era prima, ma sicuramente i client hanno funzionato in precedenza per quasi un annetto....

    altra info: hanno un certificato pubblico godaddy con i nomi esterno FQDN come principal, interno FQDN e netbios come alternate.

     se visito https://xxxxxxxx/autodiscover/autodiscover.xml, mi da:

     

      <?xml version="1.0" encoding="utf-8" ?>
    - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    - <Response>
    - <Error Time="17:42:46.7542353" Id="2109776795">
      <ErrorCode>600</ErrorCode>
      <Message>Invalid Request</Message>
      <DebugData />
      </Error>
      </Response>
      </Autodiscover>

    Diego Castelli - MCSA 2003, MCP ISA 2004, MCTS Forefront. ITA: Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    giovedì 9 dicembre 2010 16:39
  • Ho risolto. Lo scrivo qui perchè possa essere utile anche per i posteri:

    lanciato Get-AutodiscoverVirtualDirectory | fl -property *url*, identity e controllato che gli url fossero corretti. erano vuoti.

    lanciato quindi Set-AutodiscoverVirtualDirectory -identity <la identity ottenuta> -internalUrl <l'url interno che devono usare i client interni> -externalurl <l'url esterno che devono usare gli esterni>

    POI

    controllato anche in get-webservicesvirtualdirectory. Di tutti gli URL ho il certificato pubblico installato con o principal name o Subject alternate Name, quindi ho escluso problemi di cert. (però ho "sbirciato" lo stesso con internet explorer su: https://<nomeserver>.<nomedominioext>/autodiscover/Autodiscover.xml ma era tutto OK)

    andato in IIS, modificato le impostazioni di SSL della cartella Autodiscover per il sito Exchange, impostando per IGNORARE i certificati clients.

    POI

    Ho dovuto RIAVVIARE TUTTO IL SERVER (i servizi Exch + iisreset non sono stati suficienti)

     

    poi è andato tutto a posto

     

    P.S. per chi ha tempo, glie ne racconto una....

    Se avete una SAN con le path ridondate in fibra e dovete cambiare un modulo fibra per il controllore passivo (certo che è passivo, gli è appena fallita la fibra...) ricordatevi di stare all'occhio con una cosa che può succedere:

    Il software MPIO del server potrebbe voler a tutti i costi riutilizzare la fibra numero 1 (leggi la scheda numero 1 sul server), dopo il riavvio. Quindi vedreste il disco con tutti i vostri preziosissimi dati in modalità "non inizializzato" e "illeggibile".... (certo, cerca di raggiungerlo mediante il controller passivo!...).

    In questo caso la soluzione per me è stata spresentare l'intera LUN al server e ripresentarla, partendo dalla seconda path.

    Siccome non è la prima volta che mi capita.... io vi ho raccontato una barzelletta .... ma voi pensateci...

     

     

    Ciao!


    Diego Castelli - MCSA 2003, MCP ISA 2004, MCTS Forefront. ITA: Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Contrassegnato come risposta Diego Castelli venerdì 10 dicembre 2010 14:21
    • Modificato Diego Castelli venerdì 10 dicembre 2010 14:26 aggiunto dettagli
    venerdì 10 dicembre 2010 14:21