Autoren-Archiv: admin

RDS (Remote Desktop Server oder Terminal Server) Lizensierungsmodus festlegen

Veröffentlicht am von — Keine Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓

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“

Veröffentlicht am von — 9 Kommentare ↓

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“

Veröffentlicht am von — 3 Kommentare ↓

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.