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.

 

CentOS 6 statische IP-Adresse an der Shell konfigurieren

logo_smallStatische IP-Adresse in CentOS konfigurieren

Die Netzwerkkonfiguration in CentOS Linux ist in der Datei

/etc/sysconfig/network-scripts/ifcfg-eth0

abgelegt. Der Inahlt der Datei sieht bei einer statischen IP so aus:

DEVICE="eth0"
 NM_CONTROLLED="yes"
 ONBOOT=yes
 HWADDR=DE:AD:BE:EF:F1:04
 TYPE=Ethernet
 BOOTPROTO=static
 NAME="System eth0"
 UUID=5fbfffff-0fff-7ffb-4ff1-fffffff3e02
 IPADDR=192.168.66.6
 NETMASK=255.255.0.0

Default Gateway

Für das Routing ist diese Datei

/etc/sysconfig/network

verantwortlich, die dann so aussieht:

NETWORKING=yes
HOSTNAME=foobaerchen
GATEWAY=192.168.1.1

DNS-Einstellungen

DNS-Einstellungen sind wie bei (nahezu jedem) Linux in der

/etc/resolv.conf

abgelegt. Der Inahlt sieht dann auch entsprechend einfach aus:

nameserver 8.8.8.8      # Replace with your nameserver ip
 nameserver 192.168.1.1  # Replace with your nameserver ip

Wenn alle diese Einstellungen getätigt sind, einmal das Netzwerk neu starten:

/etc/init.d/network restart

 

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.