Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo consente di risolvere i problemi relativi all'installazione dei ruoli di Servizi Desktop remoto .This article helps troubleshoot issues related to the installation of Remote Desktop Services (RDS). Il problema si verifica quando si distribuisce una nuova distribuzione di Servizi Desktop remoto o si aggiungono manualmente ruoli a un sistema o a una distribuzione di Servizi Desktop remoto esistente.
Esistono diverse cause, diversi comportamenti possibili e messaggi di errore. Questo articolo illustra alcuni di questi motivi comuni.
Verificare se TLS 1.0 è disabilitato nel sistema
Annotazioni
Questo problema specifico si applica solo a Windows Server 2016 e versioni precedenti. Da Windows Server 2019 e versioni successive, il ruolo Broker connessione per desktop remoto può comunicare con il Windows Internal Database (WID) utilizzando versioni più recenti di Transport Layer Security (TLS), come TLS 1.2.
Sintomi
Si supponga di usare la posta in arrivo WID in Windows Server. Se si disabilita TLS 1.0 quando si configurano le impostazioni di sicurezza, si verificano i problemi seguenti:
Non è possibile installare il ruolo Broker Connessione RD.
Il servizio RDS ha esito negativo.
Una distribuzione di Servizi Desktop remoto esistente che usa Gestore connessione Desktop remoto e WID ha esito negativo.
Il servizio Gestione Desktop remoto (RDMS) non viene avviato.
Quando si tenta di avviare RDMS, viene visualizzato il messaggio di errore seguente:
Il servizio Gestione Desktop remoto nel computer locale è stato avviato e quindi arrestato. Alcuni servizi si arrestano automaticamente se non sono in uso da altri servizi o programmi.
Motivo
Questo comportamento è previsto a causa delle dipendenze correnti tra RDS e WID. RDMS e Gestore connessione dipendono da TLS 1.0 per l'autenticazione con il database. WiD attualmente non supporta TLS 1.2. Pertanto, la disabilitazione di TLS 1.0 interrompe questa comunicazione.
Annotazioni
Le distribuzioni di Servizi Desktop remoto che usano Broker di connessione devono stabilire un canale crittografato con WID usando uno dei metodi seguenti:
- TLS
- SSL 3.0
- Standard Federali di Elaborazione delle Informazioni (FIPS)
Risoluzione
Per risolvere il problema, utilizzare uno dei seguenti metodi:
- Non disabilitare TLS 1.0 in una singola distribuzione di Connection Broker.
- Configurare una distribuzione del Broker di connessione ad alta disponibilità che utilizza un'istanza dedicata di SQL Server.
- Aggiornare i computer che eseguono il servizio Servizi Desktop remoto a Windows Server 2019.
Annotazioni
Microsoft ha rilasciato il supporto TLS 1.2 per Microsoft SQL Server per consentire alle comunicazioni di SQL Server di usare TLS 1.2.
Il ruolo di Connection Broker non riesce a installarsi a causa della rimozione delle autorizzazioni "Accedi come servizio" per gli account di servizio.
Quando si tenta di installare il ruolo Gestore connessione Desktop remoto, l'installazione non riesce con l'errore seguente:
Impossibile installare il servizio ruolo Broker connessioni RD nel server <ServerName> - Fallito.
Questo avviene in genere perché l'oggetto "NT SERVICE\ALL SERVICES" è stato rimosso dal criterio di sicurezza Accesso come servizio oppure esiste un altro criterio che nega l'accesso come privilegio di servizio all'account del servizio corrispondente.
È anche possibile visualizzare l'evento di errore seguente nel registro eventi di sistema:
Log Name: System
Source: Service Control Manager
Date: mm/dd/yyyy hh:mm:ss pp
Event ID: 7041
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: MyServer.com
Description:
The MSSQL$MICROSOFT##WID service was unable to log on as NT SERVICE\MSSQL$MICROSOFT##WID with the currently configured password due to the following error:
Logon failure: the user has not been granted the requested logon type at this computer.
Service: MSSQL$MICROSOFT##WID
Domain and account: NT SERVICE\MSSQL$MICROSOFT##WID
This service account does not have the required user right "Log on as a service."
User Action
Assign "Log on as a service" to the service account on this computer. You can use Local Security Settings (Secpol.msc) to do this. If this computer is a node in a cluster, check that this user right is assigned to the Cluster service account on all nodes in the cluster.
If you have already assigned this user right to the service account, and the user right appears to be removed, check with your domain administrator to find out if a Group Policy object associated with this node might be removing the right.
Risoluzione
Aggiungere di nuovo il gruppo "NT SERVICE\ALL SERVICES" al criterio di sicurezza Accesso come servizio . Verificare inoltre che questo gruppo o un altro oggetto account del servizio (come il servizio di rete) non rientri nella policy di sicurezza Nega accesso come servizio.
Se l'errore persiste dopo che le condizioni precedenti vengono soddisfatte, provare ad aggiungere l'account del servizio "NT SERVICE\MSSQL$MICROSOFT##WID" al criterio di sicurezza Accesso come servizio .
Problemi relativi a WinRM
Server Manager, interfaccia utente RDMS (Interfaccia utente di Servizi gestione Desktop remoto) e cmdlet di PowerShell di Servizi Desktop remoto si basano principalmente su WinRM per funzionare.
Se il problema è correlato a Server Manager o l'interfaccia utente di RDMS non funziona correttamente, potrebbe verificarsi un problema correlato a WinRM.
Un motivo comune è la presenza di un proxy impostato sull'interfaccia WinHTTP del sistema. È possibile controllare questa operazione eseguendo il comando seguente in un prompt dei comandi con privilegi elevati:
netsh winhttp show proxy
Se è configurato un proxy, è possibile rimuoverlo usando il comando seguente:
netsh wintthp reset proxy
In alternativa, impostare le esclusioni usando il comando seguente (è consigliabile rimuovere prima il proxy a scopo di test. Usare i passaggi precedenti per verificare che il proxy sia effettivamente la causa del problema):
Per esempio:
set proxy proxy-server="http=<proxy>;https=<sproxy>:88" bypass-list="\*.contoso.com"
È inoltre possibile verificare se sono configurati nel sistema oggetti Criteri di gruppo correlati a WinRM sotto il percorso seguente. Può anche essere un buon test per rimuoverli temporaneamente a scopo di test.
Configurazione> computerPolitiche>>Modelli amministrativiComponenti> di WindowsGestione remota Windows (WinRM)
Infine, è possibile cercare nel Visualizzatore eventi i potenziali eventi problematici di WinRM sotto:
Registri applicazioni e servizi>Microsoft>Windows>Windows Gestione remota>Operativo
Impossibile aggiungere un Host della sessione RD a una raccolta di sessioni o creare una nuova raccolta.
L'aggiunta di un host sessione Desktop remoto a una raccolta potrebbe non riuscire. È possibile che vengano visualizzati messaggi di errore diversi. In genere, il messaggio di errore inizia con "Impossibile aggiungere l'host di sessione RD alla raccolta..." seguito da una frase che descrive in modo più dettagliato la causa.
Questo comportamento può essere causato da motivi diversi. Ecco alcune possibili cause:
Motivi correlati a WinRM, come descritto nelle sezioni precedenti di questo articolo.
L'host della sessione RD ha oggetti Criteri di gruppo esistenti configurati, soprattutto quelli relativi ai Servizi Desktop remoto (RDS), che impediscono alla distribuzione di modificare le impostazioni desiderate. Per risolvere questo problema, rimuovere temporaneamente gli oggetti Criteri di gruppo, aggiungere l'host sessione Desktop remoto alla distribuzione o alla raccolta, quindi riapplicare gli oggetti Criteri di gruppo desiderati.
Il messaggio di errore può variare. In genere, il messaggio di errore può essere "Impossibile configurare il Server Host sessione Desktop remoto <ServerName>." Operazione non valida."
Annotazioni
Ecco un elenco di oggetti Criteri di gruppo comuni che potrebbero causare questo comportamento. Tuttavia, consigliamo di rimuovere eventuali oggetti Criteri di gruppo correlati ai Servizi Desktop remoto (RDS) e di effettuare un test:
- Richiedere l'autenticazione utente per le connessioni remote usando l'autenticazione a livello di rete
- Impostare il livello di crittografia della connessione client
- Usare i server delle licenze di Desktop remoto specificati
Percorsi verso i precedenti oggetti Criteri di gruppo
- Configurazione computer>Modelli amministrativi>Componenti di Windows>Servizi Desktop remoto>Sicurezza
- Configurazione computer>Modelli amministrativi>Componenti Windows>Servizi Desktop remoto>Host sessione Desktop remoto>Licenze
Se viene visualizzato un messaggio di errore che contiene "Non è stato possibile tradurre alcuni o tutti i riferimenti di identità" durante l'aggiunta di un Host Sessione Desktop Remoto a una raccolta, questo indica in genere problemi relativi alla risoluzione dei SID dei gruppi che fanno parte dell'elenco delle autorizzazioni della raccolta delle sessioni.
Possono esserci diversi motivi per cui si verificano problemi nel risolvere il SID. È consigliabile contattare il supporto tecnico Microsoft per un'analisi dettagliata della situazione. Per confermare questo problema (o risolverlo temporaneamente), è possibile testarlo rimuovendo gradualmente gruppi di utenti dall'elenco di autorizzazioni raccolta sessioni fino a quando non si identificano i gruppi che causano il comportamento.
Il messaggio di errore "Impossibile connettersi al server utilizzando Windows PowerShell Remoting" può essere dovuto a diversi motivi, ma una possibile causa è che le variabili d'ambiente sono state modificate o configurate in modo non corretto.
Per risolvere questo problema, segui questi passaggi:
- eseguire il
sysdm.cpl
comando . - Nella finestra Proprietà sistema selezionare la scheda Avanzate e quindi selezionare Variabili di ambiente.
- In Variabili di sistema selezionare Modifica percorso>.
Potrebbero essere presenti diverse variabili di ambiente e questo può variare in base a ogni sistema, ma assicurarsi che le variabili seguenti siano presenti e configurate correttamente:
- %SystemRoot%\system32
- %SystemRoot%
- %SystemRoot%\system32\Wbem
- %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
- %SYSTEMROOT%\System32\OpenSSH\
- eseguire il