Mit Powershell aus dem AD Objekte abholen und nach nicht leeren Eigenschaften filtern
Es gibt viele Scriptbeispiele um mit Powershell Objekte aus dem Active-Directory abzuholen, bei denen eine bestimmte Eigenschaft ausgefüllt ist, oder nicht. Allerdings habe ich noch kein Script gefunden, dass ein Objekt abholt und dann davon alle leeren oder ausgefüllten Felder anzeigt. Das Problem liegt im Rückgabe-Wert des AD-Objekts. Dieses ist nämlich als Hash aufgehängt und läßt somit einen einfachen Zugriff auf den Wert zu. Erst mit Hilfe der .NET-Methode GetEnumerator() ist es möglich den Inhalt auszuwerten wie das folgende Beispiel anhand von get-aduser zeigt:
(get-aduser Administrator -properties *).getenumerator() | ? {$_.value} # zeigt alle ausgefüllten Eigenschaften
(get-aduser Administrator -properties *).getenumerator() | ? {!$_.value} # zeigt alle nicht ausgefüllten Eigenschaften
Befehle von Powershell Modulen eines anderen Rechners benutzen
Bei Windows XP und Server 2003 können Sie z. B. die Befehle aus dem Active-Directory Modul in der Powershell nicht benutzen. Es gibt jedoch eine Lösung, wie Sie die AD cmdlets (Befehle) ohne direkten Remotezugriff trotzdem in die Powershell Konsole von XP einbinden können:
$cred=get-credential
$session=new-pssession -computer 192.168.0.50 -cred $cred
invoke-command {import-module activedirectory} -session $session
import-pssession -session $session -module activedirectory
Im Script sind 2 Stellen fett markiert. Die erste Stelle enthält die IP-Adresse eines W2k8R2 DCs von dem die Modulbefehle importiert werden. Alternativ können Sie hier natürlich auch gerne den Namen einsetzen. Die zweite fett geschriebene Stelle am Schluß legt das zu importierende Modul fest. In diesem Beispiel ist es das AD Modul. Es kann natürlich auch ein X-beliebiges anderes Modul sein, dass auf der Remotemaschine allerdings instaloliert sein muss.
Powershell Richtlinie für Skriptausführung manipulieren
Mit der Powershell können aus Sicherheitsgründen erste einmal keine PS1 Scripte ausgeführt werden. Um Scripte ausführen zu können muss man mittels set-executionpolicy unrestricted oder per Gruppenrichtlinie im Active-Directory die Scriptausführung explizit erlauben. Andere mögliche Werte (z. B. dass nur digital signierte Scripte ausgeführt werden können) die man übergeben kann findet man mit help set-executionpolicy schnell heraus.
Aber was soll der ganze Aufwand? Hier einige Möglichkeiten die Standardausführungsrichtlinie außer Kraft zu setzen:
Von der Eingabeaufforderung aus
type NamedesPowershellscripts.ps1 | powershell -
Als Desktopverknüpfung
Legen Sie eine Standardverknüpfung auf dem Desktop über das Kontextmenü an. Als Ziel tragen Sie ein:
powershell -executionpolicy unrestricted -file C:\PfadzumScript\NamedesPowershellscripts.ps1
Registry-Hack
Wer mag kann auch einfach im CurrentUser-Key das Gegenteil vom LokalMachine-Key behaupten (bei 2008 R2 klappt dies leider nicht immer, dafür funktionieren die ersten beiden Varianten sogar bei einer anders lautenden Gruppenrichtlinie des Active Directory!!!):
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Powershell\1\ShellIds\Microsoft.PowerShell] "ExecutionPolicy"="Unrestricted"
Speichern Sie einfach den kursiv geschriebenen Text in einer Datei mit der Endung .reg und machen Sie anschließend einen Doppelklick darauf. Fertig!
Zentrale Gruppenrichtlinienverwaltung ohne Active Directory
Gruppenrichtlinien sind ein mächtiges Werkzeug für die Verwaltung von Windowsstationen. Es soll aber tatsächlich einige Netzwerke geben, die entweder immer noch als Arbeitsgruppe eingerichtet sind oder mit einer Samba Domäne (Version < 4.0) arbeiten. Dort würde man vielleicht auch gerne Gruppenrichtlinien einmal erstellen und auf allen Stationen anwenden.
Dazu müssen Sie lediglich auf einer der Windowssysteme die lokale Gruppenrichtlinienverwaltung gemäß Ihren Wünschen mittels gpedit.msc wie gewünscht konfigurieren. Auf dieser Station werden die Einstellungen dann im C:\Windows\System32\GroupPolicy Verzeichnis hinterlegt. Vorsicht! Nicht das Verzeichnis GroupPolicyUsers! Das werden Sie aber zunächst als einziges sehen. Erst wenn Sie im Explorer die versteckten und Systemdateien anzeigen lassen wird das GrouPolicy Verzeichnis sichtbar. Der Rest ist denkbar einfach! Lassen Sie auf eine Art Ihrer Wahl dieses Verzeichnis auf die anderen Computer kopieren – ggf. noch ein Reboot und fertig. Das war’s auch schon!
Wenn Sie mögen können Sie die Verteilung über ein einfaches *.bat Script erledigen lassen, dass Sie entweder durch doppelklick starten oder der Aufgabenplanung für regelmäßige Aktualisierungen übergeben.
Vertrauensstellung zwischen Active Directory Client und Domänencontroller
Manchmal verlieren AD Clients die Vertrauensstellung zu Ihren Domaincontroller. Dies kann vor allem dann passieren, wenn man den Client gerade vom Backup wiederhergestellt hat. Dies liegt meist daran, dass das Kennwort des Clients seit der Durchführung des Backups geändert wurde. Im Backup ist nun ein veraltetes und somit nicht mehr gültiges Password enthalten.
Ob der Client mit den DC noch eine Vertrauensstellung hat findet man mit dem Befehl (an der Eingabeaufforderung):
nltest /sc_query:Domänenname
heraus. Sollten dabei Fehler gemeldet werden kann man mittels:
netdom reset 'Computername' /domain:'Domänenname'
oder
nltest /sc_reset:Domänenname\Domänencontrollername
versuchen die Vertrauensstellung und damit übereinstimmende Kennwörter zwischen Client und DC wiederherzustellen. Mit PowerShell können Sie das ebenfalls versuchen indem Sie:
Test-ComputerSecureChannel –Repair
eingeben
Sharepoint 2010 sieht keine AD Konten
Wenn Sharepoint 2010 keine Benutzerkonten des Active Directory sieht liegt das wahrscheinlich daran, dass die virtuellen Maschinen einfach nur kopiert wurden. Auch bei Terminalservern bzw. Remotedesktopdiensten gibt es Probleme in der virtuellen Umgebung (egal ob VMware, VirtualBox oder Hyper-V) wenn die Computer einfach nur kopiert werden. Damit alles sauber funktioniert müssen Sie entweder sysprep -generalize (liegt im Verzeichnis C:\Windows\System32\Sysprep) oder den SID-Changer bei älteren Gastbetriebssystemen auf allen virtuellen Maschinen laufen lassen, bevor Sie diese in eine gemeinsame Domäne stecken. Der SID Wechsel beim Domänen bzw. Namenswechsel oder was durch die virtuelle Umgebung automatisiert geschieht reicht hier offenbar nicht aus. Dasselbe gilt natürlich auch bei physikalisch geklonten (Ghost, Dirve Image, etc…) Maschinen. Das Programm NewSID (SID-Changer) wird bei Microsoft nicht mehr zum Download angeboten, da es angeblich nicht notwendig ist. Daher hier der Download-Link der Zeitschrift Chip.