Häufige Fragen / FAQ

Fehlersuche

• Probleme beim Anmelden von Windows an der Active Directory Domäne

  Bitte prüfen Sie genau alle Hinweise in der Anleitung 'Anlegen eines Computers' und 'Anmeldung Windows'. Darin sind einige wichtige Schritte und Prüfungen erklärt, von denen möglicherweise etwas vergessen wurde.

  Zusätzliche Hinweise:

  Wenn Sie vergessen, ein Computerobjekt im AD anzulegen und dennoch eine Anmeldung am Client durchführen, ohne eine spezifische OU zu adressieren, so landet ein frisches Computerobjekt im Container 'Computers' und die Anmeldung schlägt fehl.
  Warten Sie anschließend eine Stunde, bis das Computerobjekt automatisch gelöscht wurde.
  Danach können Sie in Ihrer OU wieder ein namensgleiches Computerobjekt anlegen und den Computer am AD anmelden.

  Sie können eine Anmeldung mit adressierter spezifischer OU nur mit Skriptmethoden durchführen. In diesem Fall sollte kein Computerobjekt am Ziel existieren. Eine gängige Skriptmethode ist die Verwendung des Powershell-Skriptlets 'Add-Computer'.
  Sie können auch von einem Administrationsarbeitsplatz mit installierten RSAT das Executable 'netdom.exe' mit seinen Optionen dazu benutzen.
  Netdom.exe ist portabel auf andere Rechner ohne RSAT, wenn Sie folgendes Dateikonstrukt einhalten:

  \netdom.exe
  \en-us\netdom.exe.mui
  \de-de\netdom.exe.mui

• Im Anmeldebildschirm ist nichts von dem Realm KERBEROS.TU-HARBURG.DE zu sehen

  Dies ist ein Indiz dafür, dass der frisch angemeldete Computer seine Gruppenrichtlinie nicht verarbeitet hat. Siehe unten.

• Beim ersten Anmelden als xyzAdminX@tu-harburg.de bin ich kein Administrator

  Dies ist ein Indiz dafür, dass der frisch angemeldete Computer seine Gruppenrichtlinie nicht verarbeitet hat. Siehe unten.

• Der frisch angemeldete Computer verarbeitet seine Gruppenrichtlinie (GPO) nicht

  Häufig wird vergessen, einen neu im Active Directory angelegten Computer zum Mitglied der xyzComputers-Gruppe zu machen.
  Der Computer kann dann nicht in der Baumstruktur seine ihm zugeordneten GPOs lesen.
  Falls der Computer bereits in der Gruppe war und es sich tatsächlich um die ersten Starts direkt nach der Anbindung handelt, beachten Sie bitte in der Anleitung 'Anmeldung von Windows' den Abschnitt 'Ausführen und Überprüfen der Gruppenrichtlinien'.

• Ein zuvor funktionierender Computer verarbeitet seit neuestem seine Gruppenrichtlinie (GPO) nicht

  Falls der Computer bereits regulär im Betrieb war und erst seit neuestem Verarbeitungsprobleme auftreten, dann müssen Sie dringend die Ereignisanzeige am Computer überprüfen, denn es kann mehrere Gründe geben!

  - Häufig kommt das an Laptops vor, bei denen gleichzeitig das Ethernetkabel und das WLAN eingeschaltet ist.
  Das Problem tritt nicht mehr auf, wenn beim Ethernet-Betrieb das WLAN deaktiviert wird und neu gestartet wird.
  
  - Das Netzwerk ist gestört, entweder in der Infrastruktur oder lokal, z.B. auch durch Fehlkonfiguration oder Netzspezifischer Software.
  Im Eventlog steht unter System [ist noch auszufüllen.].
  Entfernen Sie ggf. neu installierte Firewallsoftware, aktualisieren Sie die Treiber für die Netzwerkkarte und führen Sie die Konnektivitätstests in 'Anmeldung von Windows' durch.

  - Der Rechner hat wegen eines Festplattenfehlers oder harten Abschaltens eine Selbstreparatur durchgeführt und muss neu an das Active Directory angebunden werden. Das Passwort, welches lokal am Computer und in der Domäne übereinstimmen muss, ist auf einen alten Zustand zurück gefallen. Das kommt nur selten vor. Im Eventlog steht [ist noch auszufüllen.].
  Nehmen Sie den Computer mit abgesteckten Netzwerkkabel (!) aus der Domäne in eine temporäre Arbeitsgruppe ohne anschliessend neu zu starten.
  Stecken Sie dann das Netzwerkkabel wieder ein, melden Sie den Computer erneut an der Domäne an und starten Sie neu.
  
  - Der Benutzer des Computers ist Mitglied der Gruppe Administratoren und hat etwas getan, obwohl er gar nichts getan hat.
  Installieren Sie den Rechner neu und kontrollieren Sie von da an die Aktivitäten Ihrer "Administratoren".

• Beim Anmelden eines normalen Benutzers erscheint sein Heimlaufwerk H: nicht, das Teamlaufwerk T: aber schon

  Vermutlich ist an dem Rechner die Benutzerkontensteuerung (UAC) angeschaltet und der Benutzer befindet sich in der Gruppe der lokalen Administratoren.
  In diesem Fall wurde das Heimlaufwerk im UAC-Admin Tokenset von der Windows-API verbunden und das Teamlaufwerk im UAC-Benutzer Tokenset von einem Skript.
  Das Heimlaufwerk wird zwar verbunden, aber nur sichtbar für Prozesse, die der Benutzer mit erhöhten Privilegien gestartet hat. Das Desktop läuft mit niedrigen Privilegien.

  Lösung: Sie können entweder die UAC deaktivieren oder Windows beibringen, Netzwerkverbindungen in beiden 'UAC-Ebenen' anzuzeigen. Letzteres geht mit folgendem Registry-Eintrag sowie einem Neustart formuliert als Kommandos:

  reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v
  "EnableLinkedConnections" /t REG_DWORD /d 1 /f
  shutdown -r -f -t 1

• Alles wurde richtig gemacht und mehrfach überprüft, dennoch laufen die Systemstartskripte nicht

  Leider gibt es Netzwerkkarten / Netzwerkkartentreiber, die dem System beim Start zu früh vermitteln, das Netzwerk sei erreichbar. Dies führt dazu, dass Windows zu früh versucht, die Gruppenrichtlinien zu erreichen und abbricht. Im Eventlog 'System' steht immer wieder von der Quelle 'GroupPolicy' ein Event mit der ID 1000/1001.
  Bei einigen Netzwerkkarten von Intel kann bei der Treiberkonfiguration die Einstellung 'Wait for Link', vom Standard 'Auto' auf 'An' gestellt werden und das Problem tritt nicht mehr auf. Bei manchen aktuellen BroadCom- und Realtek- Netzwerkkarten wird nach Lösungen gesucht.
  (Das Umstellen das Link-Speed weg von Auto-Negotiation hilft an der Stelle leider nicht.)
  Systemstartskripte laufen bei solchen Problemrechnern leider nur dann noch, wenn Windows wegen Updates spezielle Startphasen betreibt.
  Immerhin werden von Clients im laufenden Betrieb ca. alle 1 1/2 Stunden die Gruppenrichtlinien ausgeführt, allerdings ohne die Skripte.
  Die Hersteller sollten dazu kontaktiert werden um korrigierte Treiber zu liefern.

• Bei Computern, die vom Hersteller vorkonfiguriert in Betrieb genommen werden, funktioniert die Kerberos-Anmeldung nicht

  Wir haben in seltenen Fällen (bei HP-Office Computern mit Anmeldungsunterstützungssoftware und Lenovo Laptops mit Fingerabdruck-Anmeldesoftware) erlebt, dass eine Anmeldung an das Realm KERBEROS.TU-HARBURG.DE nicht funktioniert. Gehen Sie auf Suche nach gut gemeinter aber nicht benötigter vorinstallierter Herstellersoftware und deinstallieren Sie diese.

Häufige Fragen / FAQ

• Frage:
  Wie aktualisiert man schnell die Mitgliedschaft eines Computers im AD?
  (Er ist eigentlich bereits angemeldet, aber es gibt Probleme.)

  Antwort:
  Prüfen Sie dringend vorher, ob das Computerobjekt für den betroffenen Computer im Active Directory vorhanden ist, sonst sind die folgenden Schritte zum Scheitern verurteilt.
  Sehen Sie bei der Gelegenheit auch nach, ob das Computerobjekt Mitglied in Ihrer Computergruppe 'xxxComputers' ist.
  In der Windows-Ereignisanzeige (in System) müssten dazu auch Fehler von der Quelle 'NETLOGON' zu sehen sein.
  Variante A, manuell, umständlicher:
  1.) Melden Sie sich als lokaler Administrator oder als als delegierter OU-Admin an dem Client an.
  2.) Ziehen Sie das Netzwerkkabel ab (oder trennen Sie das WLAN).
  3.) Starten Sie die Computereigenschaften durch Ausführen von 'sysdm.cpl'.
  4.) Machen Sie den Computer zum Mitglied der Arbeitsgruppe 'TEMP'
     Falls Sie nach Anmeldedaten gefragt werden, geben Sie als Benutzer und Passwort jeweils 'temp' ein.
     Starten Sie anschliessend den Rechner nicht neu, auch wenn Sie dazu aufgefordert werden.
  5.) Stecken Sie das Netzwerkkabel wieder ein (oder verbinden Sie das WLAN wieder).
  6.) Machen Sie den Rechner wieder zum Mitglied der Domäne 'tu-harburg.de'
     Verwenden Sie bei der Aufforderung die Anmeldedaten Ihres delegierten OU-Admins
     (xyzAdminX@tu-harburg.de).
  7.) Starten Sie anschliessend nach Aufforderung den Rechner durch.
  Variante B, via Powershell, schneller:
  1.) Melden Sie sich als delegierter OU-Admin (xyzAdminX@tu-harburg.de) an dem Client an.
  2.) Geben Sie im Windows-Suchfeld 'powershell' ein und drücken Sie STRG+SHIFT+ENTER
     (Im Fenstertitel muss dann zu Beginn 'Administrator:' stehen.)
  3.) Führen Sie folgendes Kommando aus: Reset-ComputerMachinePassword
  4.) Starten Sie anschliessend den Rechner durch.

• Frage:
  Wie kann es passieren, dass ein Windows-Client auf ein Mal ein falsches Computerpasswort im Active Directory hat?

  Antwort:
  Sehr oft kommt das vor, wenn ein Administrator eine virtuelle Maschine auf einen alten Zustand zurückversetzt oder bei einem normalen Client ein altes Backup zurückspielt.
  In selteneren Fällen kann die Systemstartreparatur von Windows schuld sein, wenn beispielsweise im falschen Moment der Rechner stromlos wurde.
  Im Normalbetrieb ändert ein Active Directory Client sein Computerpasswort ca. alle 30 Tage - bei virtuellen Maschinen, die häufiger zurückversetzt werden sollen, kann man das abstellen aber bei regulären Rechnern ist das Verhalten ein relevantes Sicherheitsmerkmal.

• Frage:
  Wir brauchen dringend den Microsoft-Store mit Microsoft-Accounts?

  Antwort:
  Die Store-Funktionalität und die Verwendung von Microsoft-Accounts sind durch die RZ Global Optout GPO deaktiviert.
  Mit den in der OU vorhandenen delegierten GPOs (xyzStandard/OtherComputerGPO) können die entsprechenden Gegenregeln formuliert werden.
  (Durch Einstellungen mit den lokalen GPO an den Clients können die Regeln nicht überstimmt werden.)
  Die zu setzenden Gegenregeln sind wie folgt (englisch):

  Group Policy Management Console (gpmc.msc)
      Computer Configuration, Policies
      Windows Settings
          Security Settings
              Local Policies/Security Options
                  Accounts: Block Microsoft accounts = This policy is disabled
      Administrative Templates
          Windows Components/Microsoft account
              Block all consumer Microsoft account user authentication = Disabled
          Windows Components/Store
              Turn off the Store application = Disabled
  

  Zusätzlich muss in einer überstimmenden Whitelist der Store wieder hinzugefügt werden.
  Das geht manuell oder mit dem TUHH-AppControl-Configurator.exe (wie beschrieben im Abschnitt "Appcontrol Configurator Windows10").
  Als Resultat muss die Datei "C:\Program Files\TUHH\TUHH-AppControl-Logonscript\TUHH-AppControl-WhiteList.txt" eine nicht-auskommentierte Zeile Microsoft.WindowsStore enthalten.

• Frage:
  Geräte, die an dem Active Directory angebunden sind, sich aber extern im HomeOffice befinden, brauchen lange beim Systemstart und bei der Anmeldung?

  Antwort:
  Der Grund für einen sehr langsamen Systemstart und/oder eine verzögerte Anmeldung im Homeoffice ist im Regelfall dadurch bedingt, dass Windows aus dem freien Internet Kontakt zu der TUHH DNS Infrastruktur bekommt, aber nicht zu den internen Diensten.
  Ein SEHR effektiver Schritt, besondere Wartezeiten zu vermeiden, ist das VERHINDERN des den Internetkontaktes in der Start- und Anmeldephase!
  Hierzu sollte für das jeweilige WLAN-Profil eingestellt werden, dass NICHT AUTOMATISCH verbunden werden soll, sondern erst durch manuelles Klicken des Benutzers. Das System startet dann deutlich schneller und die Anmeldung auf das Desktop erfolgt mit lokal zwischengespeicherten Anmeldedaten.
  Sobald das Desktop erreicht wurde, kann von dort aus mit zwei Klicks das WLAN verbunden werden und danach das VPN aufgebaut werden.
  Zur Zeit arbeitet das RZ an einer Verbesserung dieser Ablauffolge mit dem Ziel, einen VPN-Aufbau vor der Benutzeranmeldung zu ermöglichen.
  Zusätzlich folgt hier eine Liste von GroupPolicy GPO Einstellungen, die den Systemstart mit Internetkontakt beeinflussen. Diese Regeln können sowohl auf Festrechner vor Ort als auch auf HomeOffice-Geräte zielen, also bieten sich dafür die xyzStandardComputersGPO oder xyzOtherComputersGPO an:
  

  System/Group Policy
    Specify startup policy processing wait time = Enabled
      Amount of time to wait (in seconds): 20
  System/Scripts
    Specify maximum wait time for Group Policy scripts = Enabled
      Seconds: 30
  

  Falls die Delegierte OU schon recht lange existiert und zur alten Generation gehört, kann es sein, dass die Standardeinstellung für Servergespeicherte Profile in der xyz RZ Machine Policy noch auf Synchronisieren konfiguriert ist. In dem Fall empfehlen wir, zumindest für Notebooks die Synchronisation von Profilen abzuschalten (was mittlerweile bei neuen OUs Standard ist):

  System/User Profiles
    Only allow local user profiles = Enabled  
    Prevent Roaming Profile changes from propagating to the server = Enabled