(De-)Aktive Benutzer des Active-Directory auflisten
Das Benutzer-Attribut UserAccountControl enthält im 2. Bit die Information ob ein Benutzerkonto aktiviert (=0) oder deaktiviert (=1) ist.
In Powershell ist das eigentlich gar kein Problem, da hier ein Attribut Enabled ($true oder $false) geliefert wird, dies ist im Active-Directory so aber gar nicht vorhanden.
Möchte man also einen LDAP-Filter nutzen um alle aktiven Benutzer zu listen geht das so:
(!(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)))
oder alle deaktivierten Benutzer:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))
SID-History mit PowerShell migrieren
Normaler Weise kann bei einer Migration das SID-History-Attribut nicht einfach mit der SID aus der alten Domäne eines zu migrierenden Benutzer beschrieben werden.
Auch wenn alle Berechtigungen korrekt gesetzt sind und an der Vertrauensstellung SID-Filter abgeschaltet ist kann man mit den Standardtools, oder selbst mit PowerShell wenig ausrichten.
Nur mit speziellen Migrationstools wie ADMT von Microsoft (kostenlos) oder Quest-Migration-Manager von DELL (sehr cool, aber teuer) ist dies möglich.
Es gibt jedoch von Microsoft auf die SIDCloner.dll, die schon völlig ausreicht um auch mit PowerShell die SID-History per Script zu befüllen. Was man dafür tun muss beschreibt dieser Artikel:
https://migration-blog.com/2013/11/05/how-to-write-or-migrate-sidhistory-with-powershell-2/
PowerShell Script um Quest-Migration-Manager Datenbank aufzuräumen
Das folgende Script löscht Einträge aus der Ressource Processing Datenbank des Quest Migration Manager, die älter als 3 Monate sind:
# Bitte unter dem Namen cleanQuestDB.ps1 abspeichern, damit das u.a. Beispiel passt
param(
[String]$Server=“localhost“,
[int]$Port=50000,
[int]$Month=3,
[String]$LogPath=“~\Desktop\DeletedQuestDBEntries.log“
)
Import-Module ActiveDirectory
$ErrorActionPreference=“SilentlyContinue“
Get-ADObject -filter * -server „$($Server):$($Port)“ -searchbase *
$Root=($Error[0] | select -expandprop Exception | select -expandprop message).split(„:“)[1].split(„,“)[-1].substring(1).trimend(„‚.“)
$ErrorActionPreference=“Continue“
$Project=(Get-ADObject -filter * -server „$($Server):$($Port)“ -searchbase $Root -searchscope Onelevel | ? {$_.ObjectClass -eq „aelita-Amm-Workspace“}).Distinguishedname
$ComputerLogCollection=Get-ADObject -filter * -server „$($Server):$($Port)“ -searchbase „cn=Computers,cn=ResourceProcessing,$Project“ -searchscope onelevel -properties aelita-Amm-LastOperationTime,aelita-Amm-Name
$TimeSpan=(get-date)-(new-timespan -days ($Month*30))
$ToDelete=@()
$TotalCounter=$ComputerLogCollection.count
$DeleteCounter=0
„Searching Database. Please be patient!“
foreach ($Item in $ComputerLogCollection) {
$Timestamp=$Item | select -expandprop aelita-Amm-LastOperationTime
if ($Timestamp -and $Timestamp -lt $TimeSpan) {
$ToDelete+=$Item
$DeleteCounter++
}
}
if ((read-host -prompt „$DeleteCounter from $TotalCounter to delete, proceed (Yes/No)“) -notlike „Y*“) {„Aborted!“;exit}
„Deleted Entries of Questdatabase“ > $LogPath
„Run from: $(get-date)“ >> $LogPath
foreach ($Item in $ToDelete) {
$Name=$Item | select -expandprop aelita-Amm-Name
$Timestamp=$Item | select -expandprop aelita-Amm-LastOperationTime
„Deleting $Name from $Timestamp“ | tee $LogPath -Append
$Item | Remove-ADObject -Recursive -confirm:$false
}
Im einfachsten Fall starten Sie einfach das Script. Zunächst wird geschaut wieviele Einträge insgesamt vorhanden sind und wieviele davon gelöscht werden würden. Dann fragt es, ob Sie den Vorgang durchführen möchten und listet Ihnen die entsprechenden Objekte auf. Nebenbei werden diese Angaben in eine LogDatei auf Ihrem Desktop protokolliert. Sie können das Skript natürlich auch mit anderen Parametern aus dem Parameter Block aufrufen, wie z.B.:
./cleanQuestDB.ps1 -Server QuestServer -Port 40000 -Month 2 -LogPath C:\Quest.log
Voraussetzungen:
PowerShell 2.0 oder höher
AD-Modul verfügbar
Der Benutzer unter dem das Script läuft benötigt Vollzugriff auf die Quest-Datenbank
Muss mit erhöhten Rechten (UAC – Benutzerkontensteuerung) ausgeführt werden
Active Directory Replication Status Tool
Das Active Directory Replication Status Tool liefert wertvolle grafisch aufbereitete Informationen zum Replikationsstatus von Active Directory Domain Controllern.
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!
Einfache Powershell-Befehle für den Active Directory Papierkorb und eine GUI
Hier ein kleines Powershellscript, dass die Powershell um einfache Befehle für die Verwaltung und Einrichtung des Active Directory Papierkorbs erweitert (sollte der Downloadlink nicht angezeigt werden, klicken Sie bitte auf die Überschrift des Artikels):
Um den AD-Papierkorb zu aktivieren muss das Script als Organisationsadministrator ausgeführt werden, da nur dieser berechtigt ist im gesamten Forest den Papierkorb zu aktivieren. Dieses Feature kann nicht auf Domänenebene aktiviert werden. Der Forestlevel muss auf 2008 R2 hochgestuft sein. Falls Sie befürchten, dass irgendwelche schädlichen Aktionen im Script versteckt sind, schauen Sie einfach hinein, oder lassen Sie es von jemand überprüfen der sich damit auskennt.
Wurde der Papierkorb bereits aktiviert, kann das Script zukünftig auch als Domänenadministrator aufgerufen werden.
Das Script selbst schafft zunächst nur die Voraussetzungen für die Befehle, damit diese auf der aktuellen Maschine in der aktuellen Domäne ausgeführt werden können und baut die Befehle als Funktion in Ihre aktuell laufende Powershell ein. Wenn Sie die aktuelle Powershell Konsole schließen sind die Befehle auch schon wieder vergessen. Sie müssen also jedes mal das Script starten, bevor Sie auf die Befehle zugreifen können. Selbstverständlich dürfen Sie das Script auch verändern, damit es zukünftig zu Ihrem Standardbefehlssatz gehört.
Der Papierkorb kann nur Objekte wiederherstellen, die nach seiner Aktivierung gelöscht wurden. Die Befehle können alle Objekte wieder herstellen, also nicht nur Benutzer ,Gruppen OUs und Computer.
Hier nun die 3 einfachen Befehle zur Verwaltung des Papierkorbs die sich automatisch an die Domäne in der Sie sich angemeldet haben anpassen:
Start-RecycleBin
Achtung! Ist der Papierkorb aktiviert, kann diese Funktionalität (generell – auch über die Standardwerkzeuge) nicht mehr zurückgezogen werden.
Einfach nur eintippen und der Papierkorb wird aktiviert. Ggf. fragt das Script noch ein paar Dinge ab. Auf jeden Fall informiert der Befehl darüber ob der Papierkorb aktiviert ist.
Show-DeletedADObjects
Aufruf auch hier ohne weitere Parameter. Zeigt alle sich derzeit im Papierkorb befindlichen Objekte an.
Restore-DeletedADObjects Suchbegriff
Dieser Befehl holt gelöschte Objekte aus dem Papierkorb zurück. Geben Sie den Befehl gefolgt von einem Suchbegriff ein. Der Suchbegriff verarbeitet keine Platzhalterzeichen wie z.B. ein *. Dies wird automatisch im Script vor und nach dem Suchbegriff eingesetzt. Sollten Sie nicht wissen was Sie gelöscht haben, können Sie sich mit Show-DeletedADObjects einen Überblick über den Inhalt des Papierkorbs verschaffen.
Wenn Sie eine komplette OU gelyncht haben, können Sie einfach den Namen der OU angeben. Alle enthaltenen Objekte werden automatisch mit angezeigt.
Der Befehl stellt nicht einfach alles wieder her was dem Suchbegriff entspricht, sondern listet erst einmal alles was er zum Suchbegriff findet und fragt dann nach ob er die Objekte wiederherstellen soll. Dies beantworten Sie dann mit Ja oder Nein.
Grafische Oberfläche für den AD-Papierkorb mittels Powershellscript:
Wenn Sie zu den Mausschubsern gehören, können Sie auch das folgende Powershellscript nutzen um per GUI (grafischer Oberfläche) den AD-Papierkorb zu verwalten:
Vorteile des Scripts:
- Multiple Domain tauglich
- Löschzeitraum kann angegeben werden
- Schneller als so manche kommerzielle .EXE Datei
- Kann mit etwas Glück sogar Objekte restaurieren, die vor Aktivierung des Papierkorbs gelöscht wurden.
Das ZIP-Archiv ist in einen Ordner Ihrer Wahl zu entpacken. Darin enthalten sind ein paar Icons und das Script selbst. Einfach nur das Script ohne Parameter starten.
Der Einsatz der Scripte für den AD Papierkorb ist auch für den gewerblichen Einsatz kostenfrei. Gegen eine Spende (siehe PowerShell-Buch) habe ich aber sicher nichts einzuwenden ;-). Eine Haftung bei evtl. auftretenden Schäden wird nicht übernommen. Verbesserungsvorschläge nehme ich gerne über Kommentare oder das Kontaktformular entgegen.
Terminalserverprofilepath mittels Powershell abfragen
Benutzer aus dem AD (Active Directory) mit Powershell auszulesen ist nicht besonders schwierig. Alles was man dazu braucht ist entweder einen DC (Domänencontroller) oder einen Client mit installiertem AD-Modul für Powershell aus den RSAT (Remote-Server-Administration-Tools) und natürlich die Powershell Version 2.0 oder höher.
Mit dem Befehl get-aduser Benutzername erhält man aber nur einen kleinen Teil der Benutzereigenschaften. Wenn Sie mal richtig aufdrehen wollen (alle Eigenschaften haben) müssen Sie erst noch einmal etwas nachhelfen: get-aduser Benutzername -properties *. Leider ist der Pfad, den mal eventuell im Terminalserver bzw. Remotedesktopdienste -Profilepfad angegeben hat dort nicht wirklich auszulesen. Es gibt im LDAP zwar extra das Attribut msTSProfilePath doch legt Microsoft dort überhaupt nichts ab!!! Der Profilepfad ist im Attribut userParameters mit viel anderem Krempel leider codiert hinterlegt. Nichts desto trotz kann man hier wenigstens feststellen ob der TS Profilpfad beim Benutzer angegeben wurde, oder nicht. Das unten aufgeführte Script sollte weiter helfen. Wünschen Sie Verbesserungen/Anpassungen hinterlassen Sie einen entsprechenden Kommentar.
function SetTSProperties()
{
$ou = [adsi]"LDAP://ou=mytestou,dc=nwtraders,dc=com"
$user = $ou.psbase.get_children().find($userDN)
$user.psbase.invokeSet("allowLogon",1)
$user.psbase.invokeSet("TerminalServicesHomeDirectory",$hDirValue)
$user.psbase.invokeSet("TerminalServicesProfilePath",$ppValue)
$user.psbase.invokeSet("TerminalServicesHomeDrive",$hdValue)
$user.setinfo()
} #end SetTSProperties
function QueryTSProperties()
{
$ou = [adsi]"LDAP://ou=mytestou,dc=nwtraders,dc=com"
$user = $ou.psbase.get_children().find($userDN)
foreach($property in $aryTSProperties)
{
"$($Property) value: $($user.psbase.invokeget($Property))"
} #end foreach
} #end QueryTSProperties
$userDN = "CN=My User"
$hDirValue = "\\Hamburg\TSUsers\Home\TestUser"
$hdValue = "t:"
$ppValue = "\\Hamburg\TSUsers\Profiles\TestUser"
$aryTSProperties="allowLogon","TerminalServicesHomeDirectory",
"TerminalServicesHomeDrive","TerminalServicesProfilePath"
SetTSProperties
queryTSProperties
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.