Veraltete Computerkonten im Active Directory finden

Problem

Eine wiederkehrende und frustrierende Verwaltungsaufgabe für das Active Directory ist, alte Computerkonten (Server, Desktop-PCs, Laptops … ) sauber zu entfernen. Viele Admins fügen eigentlich immer nur hinzu, alte Konten werden nicht aufgeräumt. Einen eingebauten Automatismus dafür gibt es nicht.

Ein Blick auf die Registerkarte „Objekt“ eines Computerkontos zeigt zwar, wann die Update-Sequenznummer (USN) aktualisiert wurde, aber nicht wann sich der Computer das letzte mal bei der Domäne angemeldet hat.

Lösung

Es gibt verschiedene Möglichkeiten, um festzustellen, ob ein Computerkonto in Active Directory veraltet ist. Der empfohlene („Best Practice“) Ansatz besteht darin, eine Richtlinie für Ihre Active Directory-Domäne einzurichten, in der die Regeln erläutert werden. Das Problem dabei sind aber remote-Systeme, wie zum Beispiel ein Laptop, wo der entsprechende Benutzer in der Lage ist, alles zu tun, was er über eine Webanwendung benötigt.

Inaktive Computer im AD mit dsquery suchen

C:\> dsquery computer -inactive <WOCHEN>

Der Befehl wird so für die gesamte Domäne (des ausführenden Computers) ausgeführt. Einschränkungen sind aber möglich:

C:\> dsquery computer OU=Hiersuchen,DC=domain,DC=local -inactive <WOCHEN>

Leider kann dsmove nicht mit dieser Liste direkt gepiped werden, da ist die Powershell etwas komfortabler. Um also ältere Computer in eine eigene OU zu verschieben, ist an der CMD-Shell ein Dreizeiler erforderlich:

dsquery computer -inactive <WOCHEN> > liste.txt
FOR /f %%i in (liste.txt) do dsmove %%i -newparent OU=<INACTIVE-OU>,DC=domain,DC=local
del liste.txt

 

 

Inaktive Computer im AD mit der PowerShell suchen

Das geht sogar in Tagen, nicht nur in Wochen. Dafür muss die Variable entsprechend geändert werden (-60).

PS C:\> $then = (Get-Date).AddDays(-60)
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then}

Die ausgegebenen Objekte lassen sich so direkt weiterpipen.

Mehr Beispiele an der Powershell

# Ausgabe veralteter Computerkonten als halbwegs sinnvolle Liste
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Sort-Object -Property "lastLogonDate" | FT Name,lastLogonDate
# Veraltete Computerkonten im AD deaktivieren
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Set-ADComputer -Enabled $false
# Veraltete Computerkonten im AD löschen
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Remove-ADComputer

 

Windows 10 Store Apps im Autostart ausführen oder auf Desktop verknüpfen

Nach einiger Verwirrung wie das wohl in der schönen neuen App-Welt geht, wissen wir jetzt wie man unter Windows 10 und Server 2016 Verknüpfungen zu Apps erstellen kann. Ob diese Verknüpfung auf dem Desktop, im Autostart oder woanders hin soll, ist egal – Verknüpfung ist Verknüpfung.

  1. Dieser virtuellen „Application Folder“ Ordner öffnen (Start > Ausführen). Der enthält alle Store-App Links:
    %windir%\explorer.exe shell:::{4234d49b-0245-4df3-b780-3893943456e1}
  2. Verknüpfung von hier aus an den gewünschten Ort erstellen

Den Autostart-Ordner erreicht man übrigens schnellstmöglich auf die selbe Art und weise über die URL

shell:startup

 

Outlook: Hart gelöschte Element außerhalb von „Gelöschte Elemente“ wiederherstellen (z.B. Posteingang)

Problem

Manchmal hat man ein Element in Microsoft Outlook „hart gelöscht“ (dauerhaft gelöscht) und möchte dieses trotzdem wiederherstellen. Wir flinken Admins haben das Problem manchmal bei einem vorschnellen „Shift+Del“ im Posteingang (=“endgültig löschen“). Das klappt aber nicht.

Wenn man vor dem endgültige löschen Elemente nicht in den Ordner Gelöschte Objekte verschiebt, werden diese Elemente (standartmäßig) dauerhaft am Dumpster vorbei wirklich gelöscht. Daher klappt die Wiederherstellung mit „Gelöschte Elemente wiederherstellen“ dort auch nicht.

Lösung

Standardmäßig ist die Funktion „Gelöschte Objekte wiederherstellen“ nur auf dem Ordner „Gelöschte Objekte“ in persönlichen Ordnern des Benutzers aktiviert. An anderen Orten gelöschte Elemente können nicht wiederhergestellt werden.

Man kann das Verhalten ändern

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\DataCollection]
"DumpsterAlwaysOn"=dword:00000001

Danach Outlook neu starten, fertig.

Als Downloads

Mehr Hintergrundinformationen dazu: https://support.microsoft.com/de-de/help/246153

Windows 8/10 Suche findet keine Inhalte mehr in PDF-Dateien

Problem

Unter Windows 8/8.1 und Windows 10 findet die Suche „auf einmal“ keine Text-Treffer mehr in PDF-Dateien. Normalerweise funktioniert die Volltextindizierung auch für PDF-Dateien ausgezeichnet, auber „auf einmal“ klappt das nicht mehr.

Lösung

Der Adobe „the Krebsgeschwür“ Reader ist in den allermeisten Fällen schuld. In vielen Cases zerstört dieser bei der Installation oder beim Update den Windows PDF-Reader iFilter.

In der Windows-Registry unter de Schlüssel HKEY_CLASSES_ROOT\.pdf\PersistentHandler den „Standart“ Wert ersetzen:

{F6594A6D-D57F-4EFD-B2C3-DCD9779E382E} (FALSCH)

{1AA9BF05-9A97-48c1-BA28-D9DCE795E93C} (RICHTIG)

Danach den Dienst Windows-Suche stoppen und wieder starten. Falls der Ordner PersistentHandler unter .pdf nicht existiert, muss man ihn vorher neu anlegen.

Schneller Fix für die Kommandozeile:

C:\> REG ADD HKEY_CLASSES_ROOT\.pdf\PersistentHandler /d "{1AA9BF05-9A97-48c1-BA28-D9DCE795E93C}" /t REG_SZ /f
C:\> net stop WSEARCH && net start WSEARCH

Leider kann Windows die nun fehlenden PDFs nicht nachträglich erkennen. Allerdings wird jedes PDF das vom Dateisystem modifiziert wird, wird automatisch neu indiziert …

WSUS Verbindungsfehler, Serverknoten zurücksetzen (Event 501 und SQL Event 18456)

Problem

Die WSUS-Dienste starten nicht mehr so ganz richtig, es gibt den Fehler bei der Anmeldung für den Benutzer „NT-AUTORITÄT\Netzwerkdienst“. Das passiert nach der Installation des Updates KB3148812 und/oder KB3159706. Die Updatesuche auf den Clients schlägt ebenfalls fehl.

Lösung

Schuld ist ein Fehler beim Starten der WSUS-Dienste aufgrund einer unvollständigen Patchinstallation. Die schnellste Möglichkeit ist die Deinstallation von KB3148812 / KB3159706.

Die vollständige Fehlerbehebung ist allerdings zwar umständicher, aber sicherer. Nachfolgende Upates funktionieren wieder und die sichere Anmeldung bleibt intakt.

  1. „Als Administrator“ die Post-Setup Scripts für die WSUS-Utils ausführen ausführen:
    C:\> "%programfiles%\Update Services\Tools\wsusutil.exe" postinstall /servicing
  2. „Als Administrator“ die .NET HTTP-Aktivierung nachinstallieren
    PC C:\> Add-WindowsFeature NET-HTTP-Activation
  3. „Als Administrator“ die Datei „%programfiles%\Update Services\WebServices\ClientWebService\Web.Config“ bearbeiten und ganz unten vor dem „</system.serviceModel>“ Tag eine Site-Bindung einfügen:
    </bindings>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
    </system.serviceModel>
  4. „Als Administrator“ einen IIS-Neustart auslösen
    c:\> iisrest /noforce

Mehr Informationen und eine Klick-Anleitung: https://support.microsoft.com/en-us/help/3159706/