Funzionamento di ITRisoluzione degli errori RPC

Zubair Alexander

A chi nel corso degli anni ha lavorato con piattaforme server Windows sarà probabilmente capitato di incontrare errori di chiamata a una procedura remota (RPC, Remote Procedure Call). Tali errori segnalano che il server RPC non è disponibile o che non ci sono più endpoint disponibili oppure forniscono qualche altro avviso enigmatico. Se questi messaggi creano disorientamento, consiglio di continuare a leggere. In questo articolo verranno

infatti esaminati alcuni errori comuni e varie tecniche da utilizzare per identificare gli errori RPC visualizzati e verranno illustrate alcune soluzioni a problemi specifici. Ma prima di affrontare gli errori RPC specifici e le relative soluzioni, sarà utile una solida base per quanto riguarda la terminologia RPC.

Che cos'è RPC?

RPC è un metodo di comunicazione interprocesso (IPC, Interprocess Communication) utilizzato da client e server per comunicare gli uni con gli altri. In poche parole, viene utilizzato dai programmi, in genere in un computer client, per eseguire un programma in un computer server. I client Microsoft® Outlook®, ad esempio, comunicano con Microsoft Exchange Server mediante RPC. Il computer client invia un messaggio al computer server con determinati argomenti e il server risponde al client con un messaggio contenente i risultati del programma eseguito.

Parte integrante di questo processo è l'endpoint, ovvero la porta o il gruppo di porte in un computer che viene monitorato da un server per rilevare le richieste dei client in ingresso. Più specificatamente, si tratta di un indirizzo specifico della rete di un processo server utilizzato per le chiamate RCP.

L'Endpoint Mapper, che fa parte del sottosistema RPC, si occupa della risposta alle richieste dei client per la risoluzione degli endpoint dinamici e in alcune situazioni esegue anche l'assegnazione dinamica degli endpoint ai server.

Un altro importante componente RPC è il servizio Localizzatore, che gestisce un elenco di servizi e server RPC sulla rete. Un client Windows® si connette al controller di dominio sulle porte SMB (Server Message Block) (TCP 139 e 445) ed esegue la ricerca dei servizi o dei server RPC attraverso il servizio Localizzatore.

La maggior parte dei servizi Windows incorporati comunica reciprocamente mediante RPC. Ad esempio, i servizi di certificazione, DCOM, FRS, MSMQ, MAPI e il servizio di replica di Active Directory® utilizzano RPC per la comunicazione. Di conseguenza, se il servizio RPC non funziona correttamente su una rete, è possibile che si verifichino vari problemi di comunicazione.

Errori RPC

Esaminiamo ora alcuni dei possibili errori che possono verificarsi in relazione al servizio RPC, anche se non si tratta assolutamente di un elenco completo.

Quando il servizio di Replica file ha esito negativo, potrebbe trattarsi del temuto errore di RPC non disponibile. Se si tenta di eseguire il mapping di un'unità, è possibile che venga restituito un errore di accesso negato. Quando si utilizza Utenti e computer di Active Directory, potrebbe essere visualizzato un messaggio di errore che comunica che il dominio specificato non esiste o non è raggiungibile. Durante l'accesso a un dominio potrebbe essere restituito un messaggio di errore che segnala che è impossibile accedere al dominio poiché l'account del computer del sistema nel dominio primario è assente o la relativa password non è corretta.

Quando il client Microsoft Outlook tenta di comunicare con Exchange Server, in caso di errori RPC è possibile che venga restituito al client un messaggio fuorviante in cui viene comunicato che le informazioni per l'accesso non sono corrette o che è impossibile eseguire l'accesso.

Oltre a questi errori, quando il servizio RPC non è disponibile, potrebbero verificarsi altri problemi. Ad esempio, potrebbe non essere possibile sfogliare il dominio in Risorse di rete o aprire lo snap-in Criteri di gruppo.

Questi sono solo alcuni dei casi in cui non ci si aspetta che la causa dei problemi sia dovuta a chiamate RCP. Ce ne sono molti altri e, ogni volta che si ha a che fare con processi remoti, gli errori RPC possono essere la causa principale delle difficoltà incontrate. Come riconoscere con certezza e soprattutto individuare l'errore esatto? Andiamo a scoprirlo.

Risoluzione dei problemi

Se si sospettano problemi con il servizio RPC, esistono alcuni strumenti che possono essere utilizzati per individuare i problemi.

Uno di questi è lo strumento Repadmin. Questo programma viene solitamente utilizzato per monitorare e risolvere i problemi di replica di Active Directory, ma può essere utilizzato anche per risolvere i problemi dell'RPC Endpoint Mapper. Per eseguirlo, al prompt dei comandi, digitare repadmin /bind. Se si sono verificati problemi RPC, è possibile che venga visualizzato un messaggio del tipo: "Nessun endpoint disponibile nel mapping degli endpoint". Questo è il primo indizio di problema correlato al servizio RPC.

Un'altra possibilità consiste nell'utilizzare lo strumento di diagnostica del controller di dominio (DCDiag), un programma da riga di comando per la diagnosi dei problemi relativi ai controller di dominio. Se viene visualizzato un messaggio di errore in cui viene indicato uno stato 1722 e che il server RPC non è disponibile, significa che è presente un problema RPC appena individuato dallo strumento di diagnostica del controller di dominio.

Quando si utilizza Ntdsutil (uno strumento da riga di comando utilizzato per la gestione di Active Directory e l'esecuzione di varie attività di manutenzione), a volte possono verificarsi errori RPC durante il tentativo di connessione al server. Molto probabilmente verrà visualizzato uno degli errori più comuni, ad esempio "Nessun endpoint disponibile nel mapping degli endpoint". Ancora una volta, si tratta di un indizio di possibili problemi con il servizio RPC. Anche lo strumento Gpotool, che verifica la coerenza degli oggetti Criteri di gruppo nei controller di dominio, restituirà errori simili se la causa è imputabile al servizio RPC.

Il file Dcpromo.log, che viene generato quando un server Windows 2000 Server o Windows Server® 2003 viene promosso a controller di dominio utilizzando lo strumento Dcpromo, può rivelare anch'esso la presenza di errori RPC. Ad esempio, se la promozione non riesce, è consigliabile esaminare il log, che si trova nella cartella %windir%\debug. Gli errori elencati forniranno indicazioni secondo cui il servizio directory non è riuscito a replicare la partizione o a creare l'oggetto. Alla fine del messaggio ci sarà un codice di errore. Ecco un esempio del tipo di messaggio di errore che potrebbe essere visualizzato nel file Dcpromo.log:

 
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)

Si noti il codice di errore 1722, che è presente quattro volte nel messaggio e indica che il server RPC non è disponibile. Nella Figura 1 sono riportati alcuni codici di errore con le relative descrizioni, ma è possibile trovarne altri all'indirizzo msdn2.microsoft.com/ms681386.

Figure 1 Codici di errore e relativa descrizione

Risoluzione degli errori RPC

Dopo aver visto in che modo è possibile individuare gli errori RPC, esaminiamo alcune soluzioni.

I client Microsoft si connettono all'RPC Endpoint Mapper sulla porta 135. L'Endpoint Mapper comunica quindi al client la porta su cui è in ascolto un servizio richiesto. I numeri di porta vengono assegnati in modo dinamico e sono compresi tra 1024 e 65535. Quando vengono visualizzati degli errori, ad esempio 1753, che indicano che nessun endpoint è disponibile nel mapping degli endpoint, significa che l'RPC Endpoint Mapper non è stato in grado di utilizzare per un servizio una porta di numero superiore a 1024. In seguito questo argomento verrà esaminato più in dettaglio.

La prima cosa da fare è controllare lo stato del servizio RPC sul server. A seconda del ruolo del server, lo stato del servizio RPC e del servizio Localizzatore RPC deve corrispondere a quello riportato nella Figura 2. Se uno dei due servizi non è configurato come illustrato nella figura, provare a regolare lo stato, riavviare il server e quindi eseguire un test per verificare se il problema è stato risolto.

Figure 2 Stato del servizio RPC

Verificare che sul client il ping del server che presenta problemi di connettività abbia esito positivo. Ad esempio, in caso di problemi di comunicazione con un server denominato DC1 il cui indirizzo IP è 192.168.1.200, utilizzare il comando seguente al prompt dei comandi per verificare che il DNS stia risolvendo correttamente l'host DC1:

Ping –a 192.168.1.200

Accertarsi di utilizzare l'opzione -a con l'indirizzo IP, non con il nome host.

Se tutto funziona correttamente, si dovrebbe ottenere da DC1 una risposta simile a quella illustrata nella Figura 3. Si noti che anziché risolvere semplicemente l'indirizzo IP 192.168.1.200, il ping ha risolto anche il nome host dc1.contoso.com. Questo conferma che la risoluzione del nome DNS funziona correttamente e risolve l'host dc1.contoso.com esattamente come previsto.

Figure 3 Risposta del ping

C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms

È inoltre consigliabile verificare che il Registro di sistema del client Windows XP o Windows 2000 contenga almeno i quattro ClientProtocols elencati nel riquadro a destra nella Figura 4.

Figura 4** RPC ClientProtocols elencati nel Registro di sistema **

Se una delle voci è assente, aggiungere un nuovo valore di stringa con il nome e il tipo di dati illustrati nella Figura 4. Per impostazione predefinita, è presente una quinta voce denominata ncacn_nb_tcp, che viene utilizzata per identificare NetBIOS su TCP come famiglia di protocolli per l'endpoint. A seconda della configurazione, è possibile che questa voce non sia elencata in ClientProtocols, ma è possibile aggiungerla manualmente per vedere se gli errori RPC vengono risolti.

Si notino le chiavi presenti nella la cartella RPC nel riquadro di sinistra della figura, ovvero ClientProtocols, NameService, Netbios e SecurityService. Se viene visualizzata una chiave denominata Internet senza valori, provare a rimuoverla e a riavviare il computer. Potrebbe essere di aiuto alla risoluzione del problema. Come sempre, prestare attenzione quando si modifica il Registro di sistema di Windows.

Poiché, come citato in precedenza, il servizio RPC utilizza porte comprese tra 1024 e 65535, è necessario che queste porte non siano bloccate da un firewall. Il modo più semplice per verificare che una porta sia aperta è utilizzare lo strumento Port Query, disponibile in due versioni: una versione da riga di comando (PortQry) e una versione GUI (PortQueryUI).

PortQry può essere scaricato dall'Area download Microsoft. Per ulteriori informazioni, vedere l'articolo "Descrizione dell'utilità della riga di comando Portqry.exe". In questo articolo viene fornita una breve descrizione dei rapporti di stato di PortQry con esempi di comandi da utilizzare per la risoluzione dei problemi. Ricordare che è possibile utilizzare anche la versione GUI, che è molto più semplice e che può essere scaricata all'indirizzo go.microsoft.com/fwlink/?LinkId=73740.

Quando si utilizza lo strumento Port Query, è necessario eseguirlo su un computer che non presenta errori RPC e quindi sul computer in cui si stanno verificando. Ad esempio, se si desidera verificare che la porta 135, utilizzata dall'RPC Endpoint Mapper, è aperta, al prompt dei comandi utilizzare PortQry come segue:

portqry -n [servername] -e 135

Sia che si utilizzi PortQuery o PortQueryUI, il risultato ottenuto dovrebbe essere simile al seguente:

Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING

L'ultima riga indica che la porta 135 è aperta. In caso contrario, sarebbe stato indicato NOT LISTENING.

Per verificare un intervallo di porte, inserire l'intervallo dei numeri di porta separati da virgole, ad esempio "135,1024-5000".

Ulteriori soluzioni

Se sono stati tentati tutti gli espedienti indicati fin qui e il problema resta ancora senza soluzione, sono possibili alcune opzioni aggiuntive. A seconda dei problemi specifici nell'ambiente in uso, è possibile provare con una delle modifiche seguenti nel Registro di sistema (attenzione: prima di apportare qualsiasi modifica nel Registro di sistema, è importante eseguire il backup del sistema, specialmente del Registro di sistema, in modo che, se le cose vanno male, sarà possibile ripristinare il computer nello stato precedente).

Una possibilità consiste nel regolare MaxUserPort per specificare il numero di porta massimo che può essere assegnato dal protocollo TCP quando viene richiesta una porta utente disponibile. Per impostazione predefinita, in Windows Server 2003 il valore MaxUserPort è impostato su 5000, il che significa che viene utilizzato 5000 come numero di porta massimo, anche se la voce non esiste. A seconda della configurazione, questa voce potrebbe non essere presente nel Registro di sistema, nel qual caso è possibile aggiungerla nella posizione illustrata nella Figura 5.

Figura 5** Impostazione di MaxUserPort nel Registro di sistema **

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000

Quando si modifica il Registro di sistema, è necessario considerare gli altri eventuali effetti collaterali, il che non è sempre facile. La modifica di questa voce può influire su Microsoft Exchange Server nel caso in cui il valore venga impostato al di sotto di 50.000. Se Exchange Server Analyzer rileva che il valore della chiave MaxUserPort del Registro di sistema è minore di 50.000, verrà visualizzato un avviso. È consigliabile impostare il valore su 60.000; in caso contrario potrebbero essere generati messaggi di avviso del proxy NSPI (Name Service Provider Interface), ad esempio l'evento 9040. Per ulteriori informazioni, vedere il documento Microsoft "Il valore MaxUserPort è troppo basso".

Un'altra possibilità è regolare TcpMaxDataRetransmissions. I pacchetti TCP attendono la ricezione di un riconoscimento dall'estremità ricevente. Se questo non perviene prima della scadenza del timer, i pacchetti vengono nuovamente trasmessi per il numero di volte massimo indicato da TcpMaxDataRetransmissions. Il valore predefinito per questo parametro è 5, ma è possibile provare con un valore pari a 4 o anche 3. Non utilizzare un valore inferiore a 3.

Se la voce TcpMaxDataRetransmissions del Registro di sistema non esiste, è possibile aggiungerla nella posizione seguente in questo modo:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

Per ulteriori informazioni su TcpMaxDataRetransmissions, vedere l'articolo 170359 della Microsoft Knowledge Base "Come modificare il valore di timeout massimo per la ritrasmissione TCP/IP".

Un altro valore del Registro di sistema che è possibile sperimentare è TcpTimedWaitDelay. Se un client utilizza troppe porte, è molto probabile che le porte si esauriscano prima che le connessioni chiuse vengano rilasciate dal protocollo TCP/IP. Questo avviene perché TCP/IP non rilascia la connessione fino a quando non è trascorso un periodo di tempo pari al doppio della durata massima del segmento (MSL, Maximum Segment Lifetime) (questo periodo viene definito stato di attesa). Inoltre, poiché ogni MSL è impostato su 120 secondi e TCP/IP non rilascia la connessione finché non sono trascorsi due MSL, saranno necessari 240 secondi (4 minuti) per il rilascio di una connessione chiusa. Si noti che questo è un problema noto di Windows NT® corretto con un service pack; di conseguenza ci sono oggi molte meno probabilità che si verifichi questo problema. Tuttavia, Microsoft consiglia la regolazione di questa impostazione come una delle possibili soluzioni degli errori dell'RPC Endpoint Mapper, come spiegato nell'articolo della Knowledge Base "Come risolvere un problema con l'RPC Endpoint Mapper".

TcpTimedWaitDelay viene aggiunto nel Registro di sistema nella posizione seguente:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

Per ulteriori informazioni su TcpTimedWaitDelay, vedere l'articolo della Knowledge Base "Quando le porte per i client Windows NT terminano". Sebbene non vengano consigliati valori specifici, si può provare a ridurre TcpTimedWaitDelay a 60 (secondi) in decimale, ovvero 3c in esadecimale.

Conclusioni

Gli errori RPC possono essere la causa principale di numerosi errori di comunicazione sulla rete. Esistono fortunatamente alcuni sistemi creativi con cui è possibile risolvere questi problemi di difficile comprensione. Alcuni degli strumenti suggeriti sono incorporati, mentre altri sono disponibili nel Resource Kit di Windows Server. Molti di essi sono elencati nella Figura 6. Questi strumenti possono essere utilizzati per individuare la causa e la posizione degli errori RPC per poi applicare una delle tecniche trattate in questo articolo per risolvere la condizione di errore.

Figure 6 Strumenti per la risoluzione dei problemi RPC

Zubair Alexander, MCSE, MCT e Microsoft MVP, è proprietario di SeattlePro Enterprises, una società di consulenza e formazione IT. La sua esperienza si estende su tutto il settore: autore, assistente universitario, consulente, tecnico di rete, conferenziere, architetto della protezione, amministratore di sistemi, redattore tecnico e istruttore. È possibile contattarlo all'indirizzo alexander@techgalaxy.net.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.