PREMESSA
Anno nuovo, sistema operativo nuovo (con un anno di ritardo rispetto all'uscita ufficiale, ma chi è così folle da installare in ambiente di produzione un sistema appena uscito?), ma problemi vecchi .

Alcune delle funzionalità più interessanti riguardano il mondo dei servizi Terminal, tra cui la pubblicazione delle applicazioni ed il Terminal Service Gateway (oggetto di questo articolo) che consente di accedere ai servizi terminal attraverso un tunnel HTTPS (a patto di avere Windows XP lato client e la nuova versione del client RDP 6.1). Questo servizio fa uso della tecnologia RPC over https (usata fino ad ora per Outlook) per "incapsulare" la sessione terminal all'interno della porta 443 dell'https con l'innegabile vantaggio che l'accesso TS puo' essere facilmente esportato ed acceduto tramite Internet: la sicurezza viene infatti garantita sia dall'https che dalle policy che governano l'accesso alle risorse (gli utenti devono infatti autenticarsi sul gateway prima di ricevere la schermata del terminal).

PROBLEMA
Dato che il funzionamento di questo servizio è basato su IIS, il primo oggetto da configurare è appunto questo servizio sulla base delle esigenze necessarie (creare e assegnare il certificato, configurare il logging, rinominare ilDefault Web Site con un nome più significativo, disabilitare i moduli non necessari, ecc). 

Passando però alla configurazione del TS Gateway, la console va in errore con un chiarissimo ed esplicativo messaggio:



 
Il dettaglio del messaggio d'errore riporta quanto segue:
 
at Microsoft.TerminalServices.Proxy.SnapIn.BackEnd.WmiTerminalServicesGatewayStore.AddServer(String serverName, Boolean getData)
   at Microsoft.TerminalServices.Proxy.SnapIn.TsProxyServer.ConnectToServer(IProgressDisplay progress)
   at Microsoft.TerminalServices.Proxy.SnapIn.SnapInStartPage.SnapInStartPageNode.ConnectToServer(String serverName, Boolean silent)
   at Microsoft.TerminalServices.Proxy.SnapIn.TSProxySnapIn.OnLoadCustomData(AsyncStatus status, Byte[] persistenceData)
  at Microsoft.ManagementConsole.NamespaceSnapInBase.ProcessRequest(Request request)
   at Microsoft.ManagementConsole.SnapIn.ProcessRequest(Request request)
   at Microsoft.ManagementConsole.Internal.SnapInClient.Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request)
   at Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request)
   at Microsoft.ManagementConsole.Executive.RequestStatus.BeginRequest(IMessageClient messageClient, RequestInfo requestInfo)
   at Microsoft.ManagementConsole.Executive.SnapInRequestOperation.ProcessRequest()
   at Microsoft.ManagementConsole.Executive.Operation.OnThreadTransfer(SimpleOperationCallback callback)
 

E' bello vedere che il mondo si evolve e finalmente i nostri beneamati programmatori riescono a scrivere dei messaggi di debug chiari ed esplicativi, dai quali si deduce immediatamente quale parte sta facendo casino .

SOLUZIONE

Mettendo il messaggio di errore su Google, si trovano ben due articoli: uno nei forum di Microsoft ed un altro su un sito tedesco in lingua ovviamente teutonica.
Nel forum Microsoft dicevano di aver risolto disinstallazione tutto (IIS e TS Gateway) e ripartendo da zero: ora, dato che la macchina su cui stavo lavorando era stata appena installata, l'idea di reinstallare i due ruoli non era particolarmente accattivante, anche perchè ormai questo approccio è diventata la barzelletta degli informatici.

Il sito in tedesco l'avevo scartato, dato che della lingua teutonica conosco ben pochi idiomi: il sistemista con il quale stavo lavorando però ha suggerito di provare il traduttore di Google per vedere se comunque potevano esserci informazioni utili. Scettico sulle funzionalità dei traduttori automatici (anche se ho scoperto dai log che molti lo usano sul mio sito) ho comunque voluto provare: quando Google ha finito il suo lavoro ho iniziato a leggere ma, dopo pochi minuti, mi sono ritrovato ad imprecare alla volta dei programmatori di Redmond. 
Il motivo è semplice: un collega germanico suggeriva che il problema era legato al nome del sito web (io l'avevo cambiato rispetto al Default Web Site predefinito) e che rimettendo i valori predefiniti la console riprendeva il suo funzionamento. Che il nome del sito web fosse diventato così importante l'avevo già precedentemente sperimentato con Exchange 2007, ma il vedere che anche il TS Gateway era interessato da questo bug (oops, feature) mi ha fatto decisamente disperare.

La soluzione al problema è stata quindi quella di verificare che il nome del sito su IIS fosse proprio Default Web Site 
(ovvero il valore predefinito). La figura sottostante mostra l'impostazione a cui si sta facendo riferimento: al posto del nome gateway ci deve essere il termine Default Web Site.

 


Come detto prima, anche l'OWA di Exchange 2007 si lega al nome del sito Web di IIS, anche se poi tramite powershell si riesce a rimappare le funzionalità di OWA sul nuovo nome del sito. Probabilmente anche sul TSGateway si puo' fare, ma per ora non ho trovato niente.

Alla fine una domanda rimane spontanea: "Ma perchèèèè? (detto con il tono di Aldo del famoso italico trio).