Windows Server 2008 R2 ha consentito la distribuzione di Terminal Server (Servizi Desktop remoto) senza un dominio e senza alcuna insistenza sui domini. Ciò è stato molto utile, in particolare per le distribuzioni standalone virtuali o cloud di un server gestito in remoto per un client remoto che non ha bisogno o desiderio di funzionalità ActiveDirectory o Domain.
Questo è diventato costantemente sempre più difficile poiché Microsoft limita sempre più le sue tecnologie in ogni versione di Windows. Con Windows Server 2012, la configurazione delle licenze per Servizi Desktop remoto è più difficile quando non si trova su un dominio, ma è ancora possibile. Con Windows Server 2012 R2 (almeno nell'anteprima) le barriere sono ora gravi:
La procedura guidata Aggiungi / Rimuovi ruoli e funzionalità in Windows Server 2012 R2 ha una modalità di distribuzione RDS speciale che ha una regola che dice che se non ci si trova in un dominio non è possibile distribuire. Ti dice di creare o entrare prima in un dominio. Questo ovviamente è in diretto conflitto con il fatto che un controller di dominio Active Directory non dovrebbe essere lo stesso computer di un computer terminal server. Quindi la tecnologia di Microsoft non è tanto un sistema operativo cloud quanto un cluster di nodi indesiderati, necessario per supportare l'unica macchina che VOGLIO effettivamente distribuire. Questo è disgustoso, quindi sto cercando di trovare una soluzione alternativa.
Tuttavia, se salti quella procedura guidata e vai a selezionare le caselle di controllo nella procedura guidata Ruoli / Funzionalità principale, puoi distribuire le funzionalità, ma l'interfaccia utente non è lì per configurarle e quando torni alla pagina di configurazione RDS nella procedura guidata dei ruoli , viene visualizzato un messaggio in cui viene indicato che non è possibile amministrare il sistema di Servizi Desktop remoto quando si è effettuato l'accesso come amministratore del computer locale, poiché sebbene si disponga di tutti i privilegi di amministratore che si potrebbero avere (nel sistema basato sul gruppo di lavoro), l'interfaccia utente di configurazione RDS sarà non accettare tali credenziali e lasciarti continuare.
La mia domanda in breve è: posso ancora in qualche modo ottenere il seguente risultato finale:
- Devo consentire a 10-20 utenti per sistema di avere una sessione RDS (TS).
- Non ho bisogno di nessuna delle opzioni RDS di pantaloni fantasia, a meno che Microsoft non dipenda in qualche modo da quelle funzionalità presenti. Credo di aver bisogno dell '"Host sessione RDS" in quanto questo è il coraggio di "Terminal Server". Microsoft afferma che è "desktop Windows completo per client di Servizi Desktop remoto.
- Devo configurare le licenze in modo che il periodo di tolleranza non scada lasciando il mio RDS non funzionante, quindi questo probabilmente significa che ho bisogno di un modo per configurare TS CAL.
Se tutto quanto sopra potesse tecnicamente essere fatto con l'uso giudizioso di PowerShell, sono pronto a prendere in considerazione anche lo sviluppo di tutti gli script di PowerShell di cui avrei bisogno per fare quanto sopra. Non sto chiedendo a qualcuno di scriverlo per me. Quello che sto chiedendo è: qualcuno sa se esiste un impedimento tecnico a ciò che voglio fare sopra, oltre al paralizzante deliberato dell'interfaccia utente di R2 2012 per gli utenti di Workgroup? Le tecnologie sottostanti funzionerebbero comunque tutte se le manipolassi e le controlli da uno script di PowerShell?
Ovviamente una risposta Sì o No di 1 parola non è così utile per nessuno, quindi la domanda è davvero, sì o no, e perché? Nel caso in cui la risposta sia Sì, allora come.