none
Exchange 2007 - RPC over HTTP connectivity failed. RRS feed

  • Domanda

  •  Devo preparare la nostra installazione aziendale di Exchange 2007 (Aggiornato al SP3 e con l'ultimo UR, singolo server con tutti i ruoli su Windows 2008 sP2) per migrare le cassette postali verso Office365 ed Exchange Online.  Non ho eseguito io l'installazione di Exchange iniziale e non ne ho documentazione quindi non ho informazioni tranne quelle che posso prendere dalla consolle di gestione di Exchange ma temo siano stati fatti degli errori abbastanza gravi...

     Fino ad ora abbiamo sempre usato certificati autofirmati, dato che il certificato SSL "buono" è obbligatorio per la migrazione ho acquistato un certificato SAN da GoDaddy e l'ho installato nei servizi Exchange.
     Ho poi eseguito il test di analisi della connettività sulla nostra installazione tramite il "Remote connectivity Analizer" per  verificare cosa c'è da sistemare nell'installazione e sono incappato in un problema che non ho idea di come risolvere...

    Attempting to ping the MAPI Mail Store endpoint with identity: SERVERMAIL.domain.lan:6001.
         The attempt to ping the endpoint failed.
          Tell me more about this issue and how to resolve it

        Additional Details

    The RPC_S_SERVER_UNAVAILABLE error (0x6ba) was thrown by the RPC Runtime process.
    Elapsed Time: 3005 ms.

     Il problema è chiaro, il tool non riesce (ovviamente!) a risolvere il nome di rete locale dell'endpoint... Ma come risolvere il problema?

     Se ho capito bene, quel riferimento è al server che ospita le cassette postali (nel caso specifico, la stessa macchina stessa) solo che è registrato all'interno dell'infrastruttura Exchange con il suo nome di rete locale invece che con l'url pubblico... E' una cosa che si può risolvere?

      Tutti gli altri test vanno a buon fine, se può servire ho configurato l'autodiscovery per utilizzare il record SRV invece che gli alias "autodiscover".

    venerdì 16 ottobre 2015 16:21

Risposte

  •  Ok, ne sono venuto a capo...

     Ho dovuto aggiungere al file hosts del server il nome interno, in modo che venisse risolto in IPv4 invece che in IPv6.

     Non ci ho pensato subito perchè avevo capito che il problema era stato risolto con un UR precedente... Comunque ora è a posto, grazie del supporto.

    lunedì 19 ottobre 2015 11:42

Tutte le risposte

  • Il fatto che tu veda un tentativo di connessione verso il nome interno dell'exchange è corretto, quello è l'RPC endpoint con cui cerca di parlare il client.

    Ovviamente se ci stiamo collegando dall'esterno, prima di tutto deve essere stabilito il tunnel ssl che consente di arrivare all'RPC endpoint e per consentire questo è necessatio che OutlookAnywhere (RPC/HTTP) sia configurator e funzionante. Il nome privato del server è corretto che sia un nome privato e quindi non raggiungibile da internet, lo diventa attraverso il tunnel ssl stabilito da OA (Outlook Anywhere).

    Qui puoi trovare le indicazioni per configurare il Servizio o verificare come sia configurator adesso:

    https://technet.microsoft.com/en-gb/library/bb123889(v=exchg.80).aspx

    Per fare una sintesi, la cosa importante è che il nome che tu hai configurato come "ExternalHostName" in OutlookAnywhere sia presente nel certificate pubblico che stai usando e che il record DNS esterno relativo a questo nome punti ad un IP pubblico la cui porta 443 (https) venga girata al server Exchange.

    Roberto



    Roberto Ferazzi
    Microsoft® MVP Exchange Server
    Moderator in the Microsoft TechNet Forums
    My MVP Profile

    MSExchange.Community

    sabato 17 ottobre 2015 07:07
    Moderatore
  • Grazie per la risposta.

     Stando così le cose, non riesco a capire perchè il test di connettività fallisca... In base al link che mi hai segnalato, i passaggi da fare sono 3:

    1. Install a valid Secure Sockets Layer (SSL) certificate from a trusted certification authority (CA) that the client trusts. => Fatto. Ho usato GoDaddy perchè era quello che costava meno, dato che mi serve solo per fare la migrazione del server verso Office365. Però ho preso un certificato SAN ed i nomi host inseriti nel certificato dovrebbero essere giusti. Non c'è però il nome interno del server Exchange visto che quando ho cercato di aggiungerlo GoDaddy ha segnalato che non era più è possibile farlo e che tutti i certificati contenenti nomi non raggiungibili su internet sarebbero tutti scaduti automaticamente al 01 Novembre 2015.

    2. Install the Windows RPC over HTTP Proxy component. => E' un server Windows 2008 SP2, nel "Server manager" alla voce "Features"  il componente "RPC over HTTP Proxy" risulta installato.

    3. Enable Outlook Anywhere on a computer that has the Exchange Server 2007 Client Access server role installed. => L'installazione di Exchange è su singolo server, dalla "Exchange management consolle" per quella macchina il ruolo "Client Access" risulta installato e "Outlook Anywhere" abilitato. Ho verificato l'impostazione dello "External host name" ed è impostato correttamente, corrisponde al certificato generato. Il metodo di autenticazione impostato è la "basic authentication" e "SSL offloading" è disabilitato.

     Non mi spiego quindi perchè il test di connettività fallisca... Per quello che può valere, OWA è perfettamente funzionante dall'esterno (porta 443 sullo stesso IP).
    lunedì 19 ottobre 2015 08:09
  •  Ok, ne sono venuto a capo...

     Ho dovuto aggiungere al file hosts del server il nome interno, in modo che venisse risolto in IPv4 invece che in IPv6.

     Non ci ho pensato subito perchè avevo capito che il problema era stato risolto con un UR precedente... Comunque ora è a posto, grazie del supporto.

    lunedì 19 ottobre 2015 11:42
  • Giusto una nota sull'IPv6.

    Lo hai lasciato abilitato ?

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    lunedì 19 ottobre 2015 19:27
  •  Sì, l'ho lasciato abilitato. Perchè?

     Comunque il server dovrebbe avere i giorni contati, per il passaggio a Exchange Online.

    martedì 20 ottobre 2015 08:00
  • L'ho chiesto perchè non è supportato disabilitare l'IPv6 sui server Exchange e volevo essere sicuro che avessi seguito le best practice.

    Giorni contati è un po' forte.

    Exchange 2016 è stato rilasciato da pochissimo per cui abbiamo ancora qualche anno :-)

    C'è anche da tenere conto che Exchange Online non è la soluzione di tutti i mali. In alcuni casi, non è la scelta più appropriata/corretta.

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

    martedì 20 ottobre 2015 08:09
  •  Ciao, grazie dell'interessamento.

     Il nostro server Exchange "on-premise" è un Exchange 2007 SP3. Il passaggio imminente alla soluzione "online" è stato deciso per demandare al gestore del servizio cloud la manutenzione della macchina, degli "information store" e del grosso della gestione dello spam, per sgravare il personale IT interno di parte delle attività quotidiane.

     Sicuramente ci sono dei pro e dei contro... Speriamo siano più i "pro".

    martedì 20 ottobre 2015 08:33
  •  Ho un ultimo dubbio, non strettamente correlato a questo problema ma che è emerso mentre ci lavoravo.

     Per configurare l'autodiscovery ho dovuto installare sul server Exchange un certificato SAN firmato da un'autorità attendibile, in sostituzione del certificato emesso dalla CA aziendale che avevo finora usato.

     Ho fatto emettere il certificato a GoDaddy e quando ho cercato di aggiungere il FQDN interno al certificato SAN (SERVERMAIL.dominio.lan) GoDaddy mi ha segnalato che non è più possibile farlo perchè tutti i certificati che contengono nomi non raggiungibili da internet (come ad esempio il nome NETBIOS o il nome di rete locale) scadranno in automatico al 01 Novembre 2015. Onestamente la cosa mi ha colto abbastanza impreparato, non ne avevo mai sentito parlare...

    Ma, al di là di questo, ora quando i nostri client aprono Outlook ricevono un avviso in cui si segnala che il certificato ricevuto (valido ed emesso da un'autorità attendibile!) ma non corrisponde al nome del sito a cui ci si sta connettendo (che sarebbe il FQDN interno dello stesso server).

    1. E' vera questa informazione ricevuta da GoDaddy?
    2. Se è corretto che i nostri client utilizzino il nome di dominio interno del server per connettersi alla casella postale, come si può gestire questa situazione senza che ogni volta venga fuori l'avviso di sicurezza?

    [EDIT:]

     Ok, mi rispondo da solo...Bastava fare una ricerchina. In effetti sembra sia vero e ci sono delle procedure da utilizzare tramite EMS per rinominare gli endpoint di Exchange che utilizzano nomi di rete locale.

     Ad esempio: https://www.digicert.com/ssl-support/redirect-internal-exchange-san-names.htm

     Grazie a tutti del supporto!


    martedì 20 ottobre 2015 15:46