Hope This Helps

Problem:
Wenn wird unter Windows 8/10 freigegebene Drucker hinzufügen oder entfernen, dann dauert es teilweise mehrere Minuten, bis diese erscheinen bzw. verschwinden.

Lösung:
Nach einer langen Suche der Ursache, haben wir dann doch die Wurzel des Übers gefunden. Windows lädt Metadaten über den Drucker im Hintergrund herunter. Bis das nicht abgeschlossen ist, wird der Drucker nicht angezeigt bzw. schwindet dieser nicht aus der Übersicht. Diesen Download kann man deaktivieren und es scheint keine Nachteile zu geben.

Man findet diese Einstellung verzwickt im System. Entweder man sucht nach "Geräteinstallationseinstellungen ändern" oder man beendet den Spuk mittels einer GPO:
Computerkonfiguration > Administrative Vorlagen > System > Geräteinstallation
Abrufen von Gerätemetadaten aus dem Internet verhindern

Oder auch das Setzen des folgenden Registry-Keys führt zum Erfolg:

Pfad: HKLM\SOFTWARE\Policies\Microsoft\Windows\Device
Valuename: MetadataPreventDeviceMetadataFromNetwork
Valuetyp: DWORD
Vlaue: 0|1

Zusätzliche Informationen für GPO und Registry: admx.help: Abrufen von Gerätemetadaten aus dem Internet verhindern

Problem:
Ich habe eine Published App für die Benutzer zur Verfügung gestellt und veröffentlich diese entweder über die RDWeb-Webseite des Terminalservers oder ich hänge die Apps direkt bei den Windows-Clients unter "Remote-App zugreifen" ein. Dabei wird beim Starten immer folgende Fehlermeldung angezeigt:


Lösung:
Zur Lösung müssen zwei Sachen umgesetzt werden:
1. Man muss das Zertifikate des RDS-Servers als "Vertrauenswürdige Stammzertifizierungsstelle" und als "Vertrauenswürdige Herausgeber" veröffentlichen (z.B. mittels GPO)
2.) Man muss den Thumbprint des veröffentliche Zertifikates als vertrauenswürdig einstufen (z.B. mittels GPO)

Also bauen Sie sich eine Zertifikats-GPO, soweit noch nicht vorhanden. Hierin importieren Sie das RDS-Zertifikat unter "Computerkonfiguration" -> "Windows-Einstellungen" -> "Sicherheitseinstellungen" -> "Richtlinien für öffentliche Schlüssel" unter den Punkten "Vertrauenswürdige Stammzertifizierungsstellen" und unter "Vertrauenswürdige Herausgeber".
Jetzt öffnen Sie das Zertifikat und kopieren sich den Thumprint unter den Eigenschaften heraus.
Diesen Thumprint fügen Sie dann in folgender GPO ein, um das Zertifikat vertrauenswürdig zu machen:
"Computerkonfiguration" -> "Administrative Vorlagen" -> "Windows-Komponenten" -> "Remotedesktopdienste" -> "Remotedesktopverbindungs-Client" ->"SHA1-Fingerabdruck von Zertifikaten angeben, die vertrauenswürdige RDP-Hersteller darstellen".

HINWEIS:
Der Thumbprint muss OHNE Leerzeichen eingegeben werden und mein 2016er-Server wollte unbedingt die Buchstaben als Großbuchstaben.

Problem:
Ich habe eine Published App auf einem Server 2016 mit RDS. Für das Starten der App ohne Fehlermeldung benötige ich ein Zertifikat. Wenn ich das über die GUI erstelle, dann ist dieses immer nur 1 Jahr gültig. Das ist zwar sicherheitstechnisch korrekt, aber für eine Applikation für 10 Mitarbeiter jedes mal ein größerer Aufwand.

Lösung:
Ich erstelle auf dem RDS Server der Published App einfach ein Self Signed Certificate mittels Powershell mit entsprechenden Namen und angepasster Gültigkeitsdauer.

Hier der Befehl:

New-SelfSignedCertificate -Subject “server.domain.local” -DNSName “server.domain.local”, “rds.domain.local”, "Netbiosname Server" -CertStoreLocation “cert:\LocalMachine\My” -KeyAlgorithm RSA -KeyLength 2048 -KeyExportPolicy Exportable -NotAfter (Get-Date).AddYears(5)

Erklärungen:
DNSName: Hier geneben Sie alle FQDNs kommegetrennt an, über die der Server erriechbar sein soll. Nettes Feature...ich kann hier auch IP-Adressen und NetBIOS-Namen angeben, da ich nicht den Restriktionen einer öffentlichen Zertifikatsstelle unterliege.

-KeyExportPolicy: Das Zertifikat bzw. der private Schlüssel sollte exportierbar sein, falls man diesen sichern möchte.

-NotAfter: Hier kann man ein Gültigkeitsdatum des Zertifikats angeben. Ich selbst nehme immer den heutigen Tag (Get-Date) und Addiere x Jahre dazu (hier z.B. 5 Jahre).

Das Zertifikat verteile ich dann per GPO an alle Clients und setze noch den SHA1-Thumbprint als vertrauenswürdig um die unschöne Fehlermeldung zu unterdrücken.
Das habe ich hier erklärt: RDS Terminalserver: Published App meldet beim Starten "Unbekannten Hersteller"

Ich hatte folgenden Fehler bei Outlook-User, die eine größere Ordnerstruktur durchsucht haben


Die User bekommen tatsächlich nur 250 Suchergebnisse angezeigt, was jetzt nicht besonders viel ist, wenn man eine ältere Mail sucht!

Ich dachte erste, dass es was mit den MaxObjects zu tun hat und habe daher die MaxObjects für Folder, FolderView, Message und MessageView auf 2000 gesetzt. Heute besteht das Problem weiterhin. Nach etwas Recherche habe ich doch dann tatsächlich einen Eintrag gefunden, der das Problem schildert und löst.
Dieses Einstellung kann erst seit Exchange 2013 CU11 geändert werden und muss aber manuell angepasst werden.

1.) Öffnen Sie die Datei "%ExchangeInstallPath%/Bin/Microsoft.Exchange.Store.Worker.exe.config"
2.) Suchen Sie hier den Schlüssel /runtime
3.) Fügen Sie danach folgende Zeilen hinzu:

<appSettings>
      <add key="MaxHitsForFullTextIndexSearches" value="1000" />
</appSettings>

Hiermit werden die Suchergbnisse auf 1.000 Elemente erweitert.
4.) Starten Sie den Informationsspeicher durch

Damit aber noch nicht genug, da wir hiermit die Beschränkung auf dem Server aufgehoben haben, aber NICHT am Client.
Hier gibt es noch eine Einstellung im Outlook, die die Suchergebnisse ebenfalls beschränkt:

Scheinbar gibt es aber in den Microsoft-GPOs keine Einstellungsmöglichkeit und somit muss man einen RegKey per GPO ausstreuen. Diese Einstellung gibt es aber erst ab Outlook 2013. Hier die RegKeys dazu:

Office 2013: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Search
Office 2016: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Search
REG_DWORD “SearchResultsCap” anlegen
Hier den Wert “0” vergeben (Hier kann auch der gleiche Wert wie auf dem Server eingetragen werden)

Ein scheinbar kleines Problem hat mich gut beschäftigt!

Quelle: somoit: Exchange 2013 – Solved the “Search results limited to 250” bug

Problem:
Alle Windows 10 Clients und Windows 2016 Server haben sich plötzlich Ihre Updates nicht vom WSUS sondern direkt von Microsoft geholt. Da ich die Kontrolle über meine Updates haben wollte, habe ich mich mit dem Problem beschäftigt und fand auch die Ursache "Dual Scan". Hierbei handelt es sich um einen Update-Mechanismus von Microsoft, der mit Windows 10 1607 bzw. dem Cumulative Update KB4034658 vom August 2017 eingeführt wurde. Wie kann ich jetzt meine Updates wieder selbst kontrollieren?

Lösung:
Dualscan wird immer dann aktiviert, wenn man per GPO einen WSUS-Server den Clients zuweist und gleichzeitig Qualitäts- oder Feature-Updates zurückstellt.
Um das "Problem" zu kontrollieren benötigen Sie die GPOs von Windows 10 1607 und das obengenannte Update KB4034658 für Windows 10 und Server 2016. Wenn Sie die Updates und GPOs (zentrale GPOs bei einer AD) eingespielt haben
Danach finden Sie in den GPOs unter
"Computerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows Update" den Punkt ""Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird" Diesen aktivieren Sie und danach wird der Client wieder seine Updates vom WSUS beziehen.
Sollte eine GPO nicht möglich sein, dann können Sie das Ganze auch über die Registry steuern:

Registry Path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
Value Name: DisableDualScan
Value Type: REG_DWORD
Values: 1 (Enabled) oder 0 (Disabled)

Quelle: Tchnet: Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed

Problem:
Wenn wir neue Computer in die AD aufnehmen und diese nicht in die richtige OU Verschieben, dann wirken die ganzen GPOs nicht auf den jeweiligen Rechner (Software, Einstellungen, Admins etc.). Ich wollte eine Benachrichtigung beim Anmelden bekommen, wenn der Computer sich noch in der Default-OU befindet. Da die OU "Computers" keine GPOS zulässt, wollte ich neue Computer in einer eigenen OU Erstellen und hier eine Inital-GPO wirken lassen mit Benachrichtigungstext beim Anmelden.


Lösung:
Die Voraussetzungen für die nachstehende Lösung ist eine Domänenlevel mindestens "Windows Server 2003".

Folgende Vorgehensweise um die neue Default-OU für Computer zu erstellen:

1.) Erstellen Sie eine neue OU (z.B. "NewComputers") und schützen Sie diese vor unabsichtlichen Löschen!

2.) Geben Sie auf einem DC folgenden Befehl in einer CMD mit Admin-Rechten ein:
redircmp OU=NewComputers,DC=domain,dc=tld
(z.B. in der Domäne demo.local würde der Befehl wie folgt heißen: redircmp OU=NewComputers,DC=demo,dc=local)

3.) Testen der neuen Einstellung, in dem man einen Computer der Domäne hinzufügt!


Quelle:IT Pro Central: How to define an OU as default location for new Computer objects