Archiv der Kategorie: Active Directory Umgebungen

Windows Update Server (WSUS) Clients werden nicht alle in der Konsole angezeigt

Fehler:

Wsus Clients tauchen nicht alle in der Konsole auf. Eventuell wird 1 PC angezeit der dann wieder verschwindet und dann taucht ein anderer PC auf. Die passiert wenn PCs mit Images / Cloning erstellt wurden. Es werden gleiche SIDs vergeben (was eigentlich kein problem sein sollte) aber es werden auch gleiche SUSClient IDs vergeben die vom Wsus verwendet werden.

Löung:
In der Registry werden beim Clonen gleiche Wsus ids vergeben. Um das Problem zu lösen kann einfach eine erneute Generierung der SUSClientID über eine Bat Datei angestoßen werden.
1. Angepasster Script wsusFix.bat. Der Script löscht zwei Registrierung Schlüssel die dann neu erstellt werden,
2. Via GPO auf Computerobjekte ausführen ( Start , Herunterfahren Script) Richtlinien > Windows Einstellungen -> Skripte das Bat Script einbinden.

Rem – Batch script to delete duplicate SusClientIDs
Rem – Implement this script as a „Startup“ or „Logon“ script
Rem – Script creates an output file called %Systemdrive%\SUSClientID.log
Rem – If the %Systemdrive%\SUSClientID1.log is already present, then the script simply exits

@Echo off
if exist %systemdrive%\SUSClientID1.log goto end
net stop wuauserv
net stop bits
reg delete „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate“ /v SusClientIdValidation /f >> %systemdrive%\SUSClientID1.log 2>&1
reg delete „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate“ /v SusClientId /f >> %systemdrive%\SUSClientID1.log 2>&1
net start wuauserv
wuauclt.exe /resetauthorization /detectnow
:end
exit

Quellen:

http://support.microsoft.com/kb/903262http://blogs.technet.com/b/sus/archive/2009/05

http://blogs.technet.com/b/sus/archive/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-don-t-all-my-clients-show-up-in-the-wsus-console.aspx

Microsoft Patchday Februar 2016 event ID 15021 HttpEvent

Der Microsoft Patchday im Februar bringt auch mal wieder Probleme mit sich. Dieses mal scheinen unterschiedliche Exchange Server Versionen davon betroffen zu sein.

Auf einem Windows Server 2008 mit einem Exchange 2010 kann durch das Update das Netzwerkprofil (Heimnetzwerk, öffentliches Netzwerk oder Domänenetzwerk) geändert werden. Wenn das Netzwerkprofil nicht stimmt kann der Mail Server keine E-Mail empfangen.

Auf einem Windos Server 2012 mit Exchange 2013 verursachenten die Februar Updates ganz viele „event ID 15021 HttpEvent“ im Eventlog. Ebenfalls sollte weder die OWA Seite noch die ECP Seite funktionieren, da die Seiten nach dem Login einfach weiß bleiben. Outlook Clients haben  ebenfalls Probleme sich mit dem Exchange zu verbinden.

Lösung: (Quelle [1])

  • Öffnet die cmd.exe
  • folgenden Befehl eintippen:  netsh http show sslcert
  • Ihr bekommt eine Liste mit Verbindungen und Informationen angezeigt
  • Sucht euch die Verbindung 127.0.0.1:443 oder wenn nicht vorhanden 0.0.0.0:443 raus
  • Unter der Verbindung gibt es den Zertifikatshash (certificate hash) und die Anwendungs ID(application ID
  • Kopiert euch diese beiden Werte in eine txt und macht eventuell noch einen Screenshot von der gesamten Ausgabe
  • Führt nun den folgenden Befehl in der CMD aus: netsh http delete sslcert ipport=0.0.0.0:444
  • Führt im Anschluss folgenden Befehl aus, wobei Ihr den Hashwert und die Anwendungs ID durch die Werte in der txt ersetzen müsst :
  • netsh http add sslcert ipport=0.0.0.0:444 certhash=456456456456456 appid=“{45645645645645-4564532341}“

[1] Adam1115 Blog

Sicherheitslücke in Microsoft Gruppenrichtlinen

Microsoft hat diesen Monat einen Patch für eine Sicherheitslücke in den Gruppenrichtlinien veröffentlicht. Die Sicherheitslücke erlaubt es durch einen Man-in-the-Middle Angriff dem Benutzer ein anderes Anmeldeskript unterzuschieben.Der Sicherheitspatch von Microsoft rüstet aber nur eine Funktion nach, die man selbst aktivieren muss. Vielleicht ändert Microsoft diese Standardeinstellung noch mit späteren Versionen, doch solange dies nicht der Fall ist, heißt es selbst Hand anlegen und Funktion aktivieren. Den passenden Artikel wie Ihr die Funktion aktiviert findet Ihr im Anhang unter [2].

Quelle:

Sysprep bei Lenovo OEM Windows nicht möglich

Wenn man mehrere PCs oder Notebooks kauft und diese alle gleich einrichten möchte, dann gibt es normalerweise die Möglichkeit Sysprep zu verwenden. Sysprep ist ein Tool, welches von Windows mitgeliefert wird und es ermöglicht es eine Windows Installation zu generalisieren. Zuerst bereitet man einen PC mit allen Programmen*[1] vor, um dann anschließend das Sysprep auszuführen. Nachdem Sysprep ist die Installation generalisiert und kann mit der Hilfe von anderer Software auf alle anderen PCs kopiert werden.

Vor Kurzem habe ich aber von Bekannten mitbekommen, dass ein Sysprep bei Lenovo PCs mit bereits installieren Windows nicht möglich ist. Nähere Infos dazu könnt Ihr unten in den beiden verlinkten Seiten finden.

[1] Es gibt bei den Programmen einige Ausnahmen, welche man erst nach dem Sysprep installieren sollte. Besonders bei Programmen, die tief ins System hineingreifen, sollte man vorsichtig sein. Es ist z.B. keine gute Idee den Symantec Endpoint Protection vor dem Sysprep zu installieren, denn dies führt nachher zu Problemen.

[2] http://www.borncity.com/blog/2013/04/13/sysprep-schlgt-bei-lenovo-oem-systemen-fehl/

[3] https://social.technet.microsoft.com/Forums/windows/en-US/ae433b22-8bd4-4d9a-95f3-ec87b0d78175/lenovo-windows-7-preimaged-system-not-allowing-me-to-image-sysprep-causes-reboot-loop?forum=w7itproinstall

Vertrauensstellung zur Domäne gestört


Wenn man mit Windows Netzwerken zu tun hat, wird man zwangsläufig mal in den Fehler laufen, dass die Vertrauensstellung zwischen einem Client/Server zu der Domäne gestört ist. Diese Meldung taucht üblicherweise beim Anmelden an die Domäne auf und verhindert eine Anmeldung an den PC, wenn man einen Domäne Benutzer verwendet.  
Beheben kann man den Fehler, indem man sich mit einem lokalen Benutzer an dem Client/Server anmeldet und diesen dann aus der Domäne entfernt. Nachdem man den Client/Server entfernt hat den PC einfach neu starten und sich erneut mit dem lokalen Benutzer anmelden und den PC erneut in die Domäne aufnehmen. Nach einem weiteren Neustart kann der PC wieder wie gewohnt verwendet werden. Vorher vorhandene Profile nehmen üblicherweise keinen Schaden.
Manchmal kommt es aber vor, dass einem kein lokaler Benutzer bekannt ist oder das Kennwort des Benutzers nicht bekannt ist. Hierfür gibt es eine einfache Lösung, die heißt – Netzwerkkabel ziehen. Hat der PC keine Verbindung mehr zum Netzwerk, ist wieder eine Anmeldung mit einem Domäne Benutzer wieder möglich. Die Anmeldung unterliegt an dieser Stelle aber der Beschränkung, und zwar ist diese nur mit Benutzern möglich die sich bereits mindestens 1x an diesem PC angemeldet haben. Hat der Domäne Nutzer, mit dem man sich angemeldet hat, administrative Rechte, so legt man einfach einen neuen lokalen Benutzer an und legt ein Kennwort fest.
Sollten keine administrativen Rechte vorhanden sein, dann ist das ebenfalls kein Weltuntergang. Den Lösungsweg für diesen Fall werde ich jedoch in einem anderen Artikel beschreiben.
Hier noch mal die Lösung in kurz ohne viel Text:
  1.  Mit lokalen Benutzer anmelden (mit Admin rechten)
  2. PC aus Domäne entfernen / den PC einer lokalen Arbeitsgruppe hinzufügen
  3. PC neu starten 
  4. Mit lokalem Benutzer anmelden und PC erneut in die Domäne aufnehmen 
  5.   PC neu starten
Kein lokaler Benutzer/Passwort bekannt?
  1. Netzwerkkabel entfernen
  2.  Anmeldung mit Domäne Benutzer welcher bereits 1x an dem PC angemeldet war (mit Admin rechten)
  3. Anlegen eines lokalen Benutzers mit Kennwort und Aufnahme dieses Benutzers in die Gruppe der Admins
  4. Weiter mit Schritt zwei, wie oben beschrieben.