Um eine Sitzung abzumelden (alle Prozesse töten):
shutdown -l
Um eine Sitzung zu trennen:
tsdiscon
Beides funktioniert natürlich nicht nur auf Windows Servern, sondern auch auf dem ganz normalen Windows-Client.
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:
- Rechte auf dem betroffenen Postfach erst entfernen
Remove-MailboxPermission -Identity GEMINSAMESPOSTFACH -user USERNAME -AccessRights FullAccess -InheritanceType All
- Dann die Rechte wieder hinzufügen, ohne Automapping
Add-MailboxPermission -Identity GEMEINSAMESPOSTFACH -user USERNAME -AccessRights FullAccess -InheritanceType All -AutoMapping $false
- 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
Der 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
Druckertreiber im Isolierten Modus ausführen (für RDS sowiso empfohen)
- Druckverwaltung öffnen und mit dem jeweiligen Printserver verbinden
- Zu „Treiber“ wechseln, Drucker markieren
- Rechte Maustaste „Treiberisolation festlegen“ > „Isoliert“
Clientseitige Druckaufbereitung deaktivieren
- Druckverwaltung öffne, zu „Drucker“ wechseln
- Eigenschaften des Druckers, Tab „Freigabe“
- „Druckauftragsaufbereitung auf Clientcomputern durchführen“ deaktivieren
- Bei allen betroffenen Druckern wiederholen
Druckprozessor auf WINPRINT zurücksetzen
- 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
- 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.
Terminal Server Windows-Update benachrichtigung entfernen
Problem
Benutzer erhalten auf Windows 2008/2008R2/2012/2012R2 Terminalservern (RDS) die Benachrichtigung das neue Updates zur Verfügung stehen. Je nach Konfiguration nervt das gelbe Popup die Benutzer auch gerne.
Lösung
Die Benachrichtigung lässt sich per Gruppenrichtlinie (GPO) entfernen:
Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Windows Update > „Zugriff auf alle Windows Update-Funktionen entfernen“
Den Eintrag auf „0 – Keine Benachrichtigungen anzeigen“ setzen.
HP Networking Utility (und ähnliches) entfernen
Problem
Nach einer De-Installation des HP PSP (Service Pack for Proliant) verbleiben noch Tools wie das HP Networking Utility, der Headless Registry Updater und Reste verschiedener Agenten auf dem System. Es gibt keinen Uninstaller dafür und die manuelle Entfernung dauert zu lange.
Lösung
Es gibt einen HP PSP Cleaner. Aufrufen, starten, sauber booten fertig. Grade nach P2V-Aktionen hilft das sehr gut weiter. Der Cleaner wurde gebaut von ctxadmtools, ist aber (wie immer) hinter einer login-email-registrierungs-wal versteckt. Zum Glück gibt es einen lokalen mirror (nur für admins). Download HP Service Pack for Prolian Cleaner (mirror).