Windows Server 2012R2 RDS Web Anmeldedomäne als Standart setzen

Problem

rds-anmeldedomaene-vorgeben

In Exchange 2013 lässt sich die Anmeldedomäne für die OWA-Anmeldung sehr komfortabel vorgeben. In der RDS Webanmeldung (RDS Web Access) geht das leider nicht so schnell und komfortabel. Wie legt man die Standard-Anmeldedomäne (Default ist blöderweise der lokale Server) fest, so dass Benutzer nur noch ihren Anmeldenamen tippen müssen?

Lösung

Es gibt einen Quick-Hack und eine die optisch deutlich ausgewachsenere Möglichkeit.

Quick-Hack

Einen Registry-Eintrag hinzufügen, der die Default-Domain für alle Anmeldungen festlegt. Das gibt es für 32bit-Dienste und 32bit-Dienste (wie den IIS) getrennt. Idealerweise setzt man beides, dann ist das Anmeldeverhalten konsistent.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\WinLogon
Zeichenkette (String): "DefaultDomainName"
Wert: ANMELDEDOMAE.NE
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon
Zeichenkette (String): "DefaultDomainName"
Wert: ANMELDEDOMAE.NE

Ausgewachsene Möglichkeit mit Anpassung der Loginseite

Die Anmeldeseiten und deren Sourcen werden angepasst, damit die Anzeige der Domänenanmeldung ebenfalls entfällt.

  • Die gleiche Registry-Anpassung wie oben durchführen
  • Loginseite bearbeite. Die notwendigen Dateien liegen in %windir%\Web\RDWeb\Pages\de-DE
  • Angepasst wird die Datei „login.aspx“

Vorher

const string L_DomainUserNameLabel_Text = "Domäne\\Benutzername:";

Nachher

const string L_DomainUserNameLabel_Text = "Benutzername:";

Eine großartige Schritt-für-Schritt Anleitung um die Webseite vollständig und korrekt zu bearbeiten, haben die msfreaks zusammengestellt: https://msfreaks.wordpress.com/2014/07/22/properly-removing-the-domain-prefix-requirement-from-rd-web-access-2012-r2/

RDS (Remote Desktop Server oder Terminal Server) Lizensierungsmodus festlegen

Problem

Der frische Terminalserver (RDS-Host) ist installiert und nagelneue RDS-CALs sind gekauft und hinzugefügt. Leider zeigt die Terminalserver Lizenzdiagnose immernoch diesen Fehler an:

Legen Sie den Lizenzierungsmodus auf dem Remotedesktop-Sitzungshostserver entweder auf "Pro Benutzer" oder auf "Pro Gerät" fest. 
Verwenden Sie den Remotedesktoplizenzierungs-Manager, um die entsprechenden Lizenzen auf dem Lizenzserver zu installieren.

In dem so nett vorgeschlagenen Terminalserver Lizenzmanager lässt sich diese Einstellung aber nicht finden.

Lösung

Das geht nur in der Lokalen- oder Gruppenrichtlinie. Man öffne die Lokale Computerrichtlinie (Ausführen > gpedit.msc) und stelle den Modus in diesem Pfad korrekt ein:

Lokale Richtlinie -> Computerkonfiguration -> Administrative Vorlagen -> Windows-Komponennten -> Remotedesktopdienste -> Remotedesktopsitzungs-Host -> Lizenzierung

Hier ergeben zwei Einstellungen Sinn:

„Angegebene Remotedesktop-Lizenzserver verweden“: Mit dieser Richtlinieneinstellung können Sie die Reihenfolge angeben, in der ein Remotedesktopsitzungs-Hostserver versucht, Remotedesktop-Lizenzserver zu finden.

„Remotedesktop Lizenzierungsmodus festlegen“: Mit dieser Richtlinieneinstellung können Sie den Typ der Remotedesktopdienste-Clientzugriffslizenz (Remotedesktopdienste-CAL) festlegen, die erforderlich ist, um eine Verbindung mit diesem Remotedesktopsitzungs-Hostserver herzustellen.

 

Outlook 2010/2013 „Diese Ordnergruppe kann nicht geöffnet werden. Fehler bei der Anmeldung an Microsoft Exchange“

Problem

Ein Outlook-Client möchte freigegebene oder „gemeinsam genutzte“ Mailboxen („Gemeinsame Ordner“) von einem Exchange Server 2010/2013 nicht mehr freiwillig öffnen. Das passiert bei Exchange 2013 nach der Installation von CU5 (oder höher) aber auch sporadisch. Die Ordner werden zwar weiterhin per Automapping ins Outlook eingebaut und sind dort sichtbar, können aber nicht geöffnet werden. Manchmal sind die Ordnernamen dort auch nicht mehr korrekt, sondern es wird nur noch ein Name mehrfach hintereinander angezeigt.

Achtung: Die selben Symptome treten auch auf, wenn eine PST-Datei mit Outlook verbunden ist, die nicht richtig glesen werden kann. Bei wiederspenstigen PST-Files hilft aber SCANPST („%ProgramFiles(x86)%\microsoft office\officeNN“) schnell und zuverlässig weiter.

Lösung

Es gibt da einen „Effekt“ bei der Anwendung der Exchange-Updates (CU5/CU6/CU7 bisher). Was genau die Ursache ist wissen wir nicht und betrachten es auch nicht als unsere Aufgabe, den Fehler zu suchen. Fakt ist, das die Automapping-Services tatsächlich falsche Daten an einge Outlook-Clients übergeben. In der XML-Datei sind tatsächlich doppelte Ordnernamen und falsche IDs enthalten.

Der Fehler kann manuell schnell (wir sind ja hier bei ugg.li) behoben werden, durch die Umgehung der AutoMapping-Funktion:

  1. Rechte auf dem betroffenen Postfach erst entfernen
    Remove-MailboxPermission -Identity GEMINSAMESPOSTFACH -user USERNAME -AccessRights FullAccess -InheritanceType All
  2. Dann die Rechte wieder hinzufügen, ohne Automapping
    Add-MailboxPermission -Identity GEMEINSAMESPOSTFACH -user USERNAME -AccessRights FullAccess -InheritanceType All -AutoMapping $false
  3. Gemeinsam genutze Postfächer manuell im Outlook-Profil verbinden (Profil Ändern > Erweiterte Einstellungen > Tab „Erweitert“ > hinzufügen). Dann klappts auch wieder mit dem Zugriff.

 

Adobe Reader druckt nicht „Das Dokument konnte nicht gedruckt werden“

Problem

rdsprinters02Der Adobe Reader XI druckt auf Terminal Servern keine PDF-Dateien mehr aus sondern vermeldet bockig „Das Dokument konnte nicht gedruckt werden“ und/oder „Es wurde keine Seiten zum Drucken ausgewählt„. Das Phänomen tritt unter Windows Server 2008/R2 und Server 2012/R2 auf, sowohl auf Terminalservern (RDS) als auch in einem „Admin Only“ Account. Grundsätzliche liegt das an gewissen Schwächen des Adobe Readers in Mehrbenutzerumgebungen, die sich öfters bei Treibern zeigen, deren Entwicklungszeil ebenfalls kein Mehrbenutzersystem war. Also praktisch alle Treiber außer „Universal“ Treibern.

Lösung

In den meisten Fällen hat es uns geholfen, die Druckertreiber auf dem Printserver im Isolierten Modus auszuführen, die Clientseitige Druckaufbereitung zu deaktivieren (was bei Terminalservern grundsätzlich der Fall sein sollte) und den Druckprozessor zurück auf den Standardmäßigen WINPRINT zu stellen.

Manchmal hilft es, nur die Verbindungsschlüssel für den Betroffenen Benutzer zurpückzusetzen. Das ist aber kein Allheilmittel.

reg delete "hkcu\printers\connections" /f

drucker-isoliert-und-winprintDruckertreiber im Isolierten Modus ausführen (für RDS sowiso empfohen)

  1. Druckverwaltung öffnen und mit dem jeweiligen Printserver verbinden
  2. Zu „Treiber“ wechseln, Drucker markieren
  3. Rechte Maustaste „Treiberisolation festlegen“ > „Isoliert“

Clientseitige Druckaufbereitung deaktivieren

 

  1. Druckverwaltung öffne, zu „Drucker“ wechseln
  2. Eigenschaften des Druckers, Tab „Freigabe“
  3. „Druckauftragsaufbereitung auf Clientcomputern durchführen“ deaktivieren
  4. Bei allen betroffenen Druckern wiederholen

Druckprozessor auf WINPRINT zurücksetzen

  1. Auf dem betroffenen Druckserver die  Drucker auf den WinPrint Prozessor zurücksetzen. Dafür ALS ADMIN an der Powershell ausführen:
    set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Printers\*' -name 'Print Processor' -value WinPrint
  2. Auf dem betroffenen Druckserver die  TREIBER auf den WinPrint Prozessor zurücksetzen. Dafür ALS ADMIN an der Powershell ausführen:

    32bit (x86)

    set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\*' -name 'Print Processor' -value WinPrint

    64bit

    set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\*' -name 'Monitor' -value $null

Ein risige Dankeschön an „aardum“ für seinen Ausführlichen Artikel in seinem Blog. Der Mann weiss wovon er spricht, bei interesse ist ein Blick in seinen Bericht empfehlenswert.