Tisku.net – Willkommen!

Ein Kollege von mir hat kürzlich per Logon Script einige Updates verteilt. Die Installationen hat er in ein freigegebenes Verzeichnis protokollieren lassen, in der Form %hostname%.txt.In dem Verzeichnis befand sich nun eine bunte Liste von Txt Dateien. Per Powershell habe ich das ganze mit einem simplen Befehl in eine verwertbare Client Liste konvertiert:

get-childitem “\\server\share” -recurse| % { [IO.Path]::GetFileNameWithoutExtension($_) }|Out-File C:\Clients_from_dir.txt

Bei der Migration eines Clients von Windows XP hin zu Windows 7 kann man sich durch den Einsatz des „User State Migration Tools“ einige Arbeit ersparen. Natürlich kann man Desktop Icons, Favoriten, Eigene Dateien usw. des Users nach dessen Erstanmeldung (vorher hat er ja keinen Profilordner…) händisch in dessen Profil kopieren. Einfacher und umfangreicher, da auch Einstellungen im Profil mit kopiert werden, ist hier der Einsatz des „USMT“.

Auf dem Client lässt sich dieses Tool grafisch starten, per Assistent wird man durch die Einstellungen geführt. Auf dem Neusystem lässt sich anschließend mit einem einfachen Doppelklick alles importieren.

Um sich den Gang und die Anmeldung an den Client zu sparen, habe ich ein kleines Tool entwickelt welches das ganze remote erledigt. Per CMD Parameter wird lediglich der Clientname übergeben, anschließend werden alle Profildaten auf ein vorher festzulegendes Netzwerk Share kopiert.

Im folgenden zeige ich euch alle erforderlichen Schritte und Vorbereitungen um das Tool einzusetzen.

1.)    Download des USMT , aktuell in der Version 2.6 unter http://www.microsoft.com/en-us/download/details.aspx?id=1411

Nach der Installation der MSI Datei in einen beliebigen Ordner, kopieren wir dessen Inhalt auf ein erreichbares Netzwerkshare, wobei Leserechte hier genügen

USMT Dateien

1.)    Ladet euch nun das StartMigration Paket herunter und entpackt es in einen beliebigen Ordner. WICHTIG: Das Tool nutzt psexec, solltet ihr es noch nicht haben ladet es euch herunter und entpackt es in einen Ordner , am besten C:\Windows, da es so automatisch im Pfad ist. Die MigrationPfad.ini Datei kopiert ihr in den Ordner migration im Windows Verzeichnis, also nach C:\Windows\migration.

 startMigration.zip

(MD5:    24d705c63d6bce0e6858f311ee54494d
SHA-1:  403818089235eb43cb282450747e935cfd3e4d56
Viren geprüft,check bei VirusTotal.com )

2.)    Erstellt euch nun ein weiteres Share, am besten versteckt durch anhängen eines $ an den Freigabenamen, und setzt die Freigaben und NTFS Berechtigungen lediglich auf den User der das Script später ausführen soll, bzw. auf die Admin Gruppe die dieses nutzen soll. So wird sichergestellt  das die Migrationsdaten nicht in falsche Hände gelangen.

3.)    Editiert nun die Datei MigrationPfad.ini und tragt in der ersten Zeile den Pfad zu eurer Migrationsfreigabe ein die ihm im vorherigen Schritt erstellt habt. In die zweite Zeile kommt der Pfad zu den USMT Dateien die ihr dort hin entpackt habt.

Pfade zu den entsprechenden Shares

4.)    Das Tool ist nun einsatzbereit. Öffnet nun eine cmd und wechselt in den Ordner in den ihr die startMigration.exe entpackt habt. Das Tool erwartet als einzigen Parameter den Hostnamen des Clients dessen Profil kopiert werden soll.

Start des Migration Tools

Als Passwort wird euer aktuelles Nutzerpasswort erwartet, da das Tool remote mit euren Userrechten gestartet wird. Natürlich benötigt euer aktueller Benutzer Admin Rechte auf dem Client!

Nach der Passworteingabe startet der Migrationsprozess…

Laufender Migrationsprozess…

Nachdem ScanState seine Arbeit beendet hat wird uns dies angezeigt:

Migration abgeschlossen!

Wir finden nun die Migrationsdaten in unserem Migration Share:

Migration Share

WICHTIG: Eine erneute Migration der selben Daten ist nur möglich wenn der Ordner auf dem Share vorher gelöscht wird, andernfalls erscheint folgende Meldung:

Migrationsdateien noch auf Share vorhanden

Auf dem Windows 7 Client können wir nun die erstellte MIG Datei direkt starten

Erstellte USMT.mig

und per Assistant auswählen welche User wir importieren möchten

Easy Transfer Assistent

Die Migration der Profildaten ist nun abgeschlossen. Es ist auch möglich über das Tool loadState (ebenfalls im USMT enthalten) die Daten automatisiert in Windows 7 u importieren, allerdings bevorzuge ich den Weg über den Assistanten um bewusst die benötigen Profile auszuwählen.

Programme zur Verteilung von Softwarepaketen gibt es wie Sand am Meer. Neben vielen Funktionen bringen diese aber auch hohe Kosten mit. In kleineren Umfeldern genügt daher oft eine einfache Software mit einem geringeren Funktionsumfang. Ich nutze bereits seit einiger Zeit erfolgreich die Software “PDQ Deploy” der Firma Admin Arsenal, die ich im folgenden hier einmal vorstellen möchte.

Auf der Admin Arsenal Website laden wir uns als erstes das Programm herunter, hier genügt die normale Version, die “Pro” Variante ist nicht zwingend erforderlich. Ich habe sämtliche zu installierende Software auf einer Freigabe eines Servers abgelegt, von da kann ich die Software optimal aktualisieren und verwalten. Es ist aber auch möglich ein “Software Depot” auf dem eigenen PC zu hinterlegen.

Nach dem Start der Software, beginnen wir nun damit die erste Software zu verteilen. Als erstes möchten wir den Acrobat Reader XI im Netzwerk verteilen. Wir besorgen bzw. extrahieren uns dafür die Acrobat MSI Datei und legen sie in unser Software Share:

Wichtig ist neben dem MSI Paket eigentlich nur die Data1.cab Datei, ich lege aber auch die Setup.exe Datei gerne dazu um im Bedarf schnell vor Ort vom Hand installieren zu können.

Nun wechseln wir in das Hauptfenster von PDQ Deploy. Auf der linken Seite können wir uns Unterordner anlegen um unsere Software besser zu strukturieren. Ich habe mir den Ordner Installationen dort angelegt und klicke nun dort  mit rechts und wähle den Punkt “New Package”.

Wir vergeben einen Titel und wechseln dann auf der linken Seite zum Punkt “Step 1″. Dort tragen wir den Pfad zur Software ein wie in der Grafik zu sehen ist

Wichtig ist hier der Haken bei “Include Entire Directory” sonst hat die Software keinen Zugriff auf die Data1.cab Datei. Unser Softwarepaket ist nun angelegt, und kann mit einem Rechtsklick und der Auswahl von “Deploy Once” verteilt werden

Nun können gezielt Clients aus dem AD ausgewählt werden. Es ist ebenfalls möglich sich fest definierte “Target Lists” erstellen zu lassen, indem man per Rechtsklick nicht “New Package” wählt, sondern “New Target List”. Diese Schritte sind eigentlich selbsterklärend.

Nach der Zielauswahl beginnt das Deployment, im rechten Fenster kann man den Fortschritt verfolgen.

Mit einem erneuten Rechtsklick  kann man die Funktion “Redeploy to failed Computers” wählen um so zu einem späteren Zeitpunkt auch die Rechner erneut zu betanken die zum ersten Zeitpunkt nicht online waren.

In der knapp 200$ teuren “Pro” Version können mehrer Installationen in einem Punkt gebündelt werden. Mit dieser Option habe ich eine neue Windows Installation binnen 20 Minuten mit allen benötigen Programm installiert.

Unter Exchange Server 2007 (SP3) war es noch möglich über das Outook Web App ein Kennwort zu ändern. Seitdem SP1 ist dies auch unter Exchange 2010 wieder möglich, allerdings nur nach setzen eines Eintrages in der Registry

Im Pfad

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA

legen wir den Wert

ChangeExpiredPasswordEnabled

an und setzen den Wert auf 1.

Nun ist noch ein Neustart des IIS notwendig

Anschließend kann das Passwort auf “Änderung bei der nächsten Anmeldung” gesetzt werden und es funktioniert.

Mit dem folgenden Script ändern wir das Kennwort eines lokalen Benutzers Admin. Im oberen Teil wird das zu setzende Kennwort definiert sowie der Ort der Logdateien. In der Zeile 1..200 | % { $ip = “192.168.1.$_” setzen wir den IP-Bereich sowie die IPs die das Script nutzt (in diesem Beispiel 192.168.1.1 bis 192.168.1.200).

$password=”GeheimesPasswort”
$LogPfad=”D:\Logs\”
$Erfolgreich=”PWDErfolgreich.txt”
$NichtErfolgreich=”PWDNichtErfolgreich.txt”

$LogDatum=(Get-Date -format d.M.yyyy)

$obj = New-Object system.Net.NetworkInformation.Ping
1..200 | % { $ip = “192.168.1.$_”
$ping = $obj.send($ip,100)
#write-host “.” -noNewLine
Write-Host “————————————————————”
Write-Host “Prüfe $ip auf Erreichbarkeit…”
if ($ping.status -eq “Success”){
pspasswd \\$ip Admin $password
$HostName = [System.Net.Dns]::GetHostByAddress($ip).HostName
$datum=(Get-Date -Format f)
Write-Output “Passwort für $HostName ($ip)am $datum geändert”|out-file $LogPfad$LogDatum$Erfolgreich -append
}
if ($ping.status -ne “Success”){
$datum=(Get-Date -Format f)
Write-Output “Passwort für $ip am $datum nicht geändert”|out-file $LogPfad$LogDatum$NichtErfolgreich -append

}}

Das Script nutzt das Tool pspasswd aus den pstools von Microsoft für die Passwortänderung, es solle daher vor der Nutzung ins Windows Verzeichnis kopiert werden.

Da der lokale “Administrator” Account immer über die gleiche SID verfügt, ist man gut bedient diesen Acount deaktiviert zu lassen und einen weiteren lokalen Account mit administrativen Rechten anzulegen und zu nutzen.

Windows Vista/7 verfügen übrigens über ein interessantes kaum bekanntes Feature. Wird auf einem nicht Domänen Rechner der letzte administrative Account neben dem Administrator Account gelöscht, so kann man sich im abgesicherten Modus über den Administrator Account anmelden. Erzeugt man einen weiteren lokalen Account mit administrativen Rechten, funktioniert dies nicht mehr.

Ist der Client Teil einer Domäne, funktioniert dieses Verhalten natürlich nicht, damit sich kein User durch eine einfache Anmeldung im abgesicherten Modus höhere Rechte verschaffen kann. Zugriff erhalten Domänen Admins über die cached Credentials, also die zwischengespeicherten Profile, nach einer vorherigen Anmeldung oder über den abgesicherten Modus mit Netzwerkzugriff. Wird der Computer z.B. auf Grund von Problemen aus der Domäne entfernt, gilt ab diesem Moment wieder das gleiche Verhalten wie für einen nicht domänen Client.

Exchange 2010 begrenzt ebenso wie Exchange 2007 die Anzahl der gleichzeitigen Zugriffe eines MAPI (Outlook) Clients um zu verhindern dass ein einzelner Client zuviele Server Ressour cen beansprucht.

Diese Begrenzung kann zu Problemen führen, z.B. nach einer umfangreichen Migration oder wenn viele freigebene Kalender zusätzlich geöffnet werden.

Der Client quittiert dies mit folgender Meldung:

Im Anwendungs Eventlog des Servers sollten sich daraufhin Einträge des Typs 9646 finden:

Abhilfe schafft das setzen eines Registry Keys in folgendem Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Dort legen wir den Schlüssel

MaxObjsPerMapiSession

an, führen einen rechtsklick darauf aus und erstellen einen neuen DWORD Wert mit dem Titel

objitMessage

Als Wert geben wir nun z.B. 500 an.

Nach ca. 5 Min. übernimmt der Server den neuen Wert automatisch. Im Eventlog sollte nun kontrolliert werden ob der Fehler weiterhin auftritt. Sollte dies der Fall sein, erhöht man den Wert solange bis der Fehler nicht mehr auftritt.

In manchen Fällen kann es notwendig sein den Wert bis auf 1500 oder 2000 Verbindungen zu erhöhen.

Leider ist es viel zu oft gängige Praxis, dass Systemdienste mit der Berechtigung eines Administrators, gerne sogar mit denen eines Domänen-Admins laufen, da dieser natürlich alle Berechtigungen hat und somit (fast) alles darf.

Vielen Admins ist hierbei jedoch nicht bewußt dass die so gespeicherten Kennwörter relativ einfach im Klartext ausgelesen werden können. Mit den folgenden einfachen Schritten kann sich jeder persönlich davon überzeugen wie einfach es tatsächlich ist Kennwörter auszulesen.

1.)    Wir konfigurieren uns einen Beispieldienst, so dass er als Domänen-Admin läuft und starten den Dienst anschließend neu (sollte der Dienst nicht starten ist dies für das Beispiel uninteressant )

2.)    Nun starten wir uns eine CMD Konsole. Wichtig hierbei ist, dass diese im System Kontext läuft. Am einfachsten erreichen wir dies über das Tool psexec aufgerufen aus einer Admin Konsole (Strg+Shift beim starten der cmd gedrückt halten)

Der Parameter –s öffnet die CMD im System Kontext, -i sorgt dafür dass die Session interaktiv ist und –d wartet nicht auf ein beenden des Prozesses.

3.)    Wir laden uns nun den Service Account Passwort Dumper kurz SAPD.exe von http://zine.net.pl/Misc/SAPD.zip herunter und entpacken ihn.

4.)    Aus der System Account CMD rufen wir nun das Tool auf und übergeben ihm den Dienstenamen:

Erschreckend einfach oder?

 Wie kann ich nun verhindern dass meine Passwörter ausgelesen werden?

Antwort: Gar nicht!

Admins können jedoch einige einfache Richtlinien beachten um die Sicherheit von Dienstekonten zu erhöhen:

• Jedes Dienstekonto auf jedem Server sollte unter einer seperaten ID laufen
• Wenn möglich sollte das Konto nur die notwendigen Rechte auf dem Server haben und kein Domänen Account sein
• Das Passwort sollte eine gewisse Komplexität aufweisen. Reichten früher 8 Zeichen Länge aus, wird mittlerweile eine mindest Länge von 11 Zeichen, inklusive Zahlen und Sonderzeichen empfohlen um das Konto wirksam vor Brute Force Attacken zu schützen (siehe Grafik unten)
• Auch wenn es mühsam ist: Auch Service Account Passwörter sollen ablaufen und somit regelmäßig geändert werden
• Das Konto sollte nur die Rechte haben dies es unbedingt benötigt. Sollte das Konto kompromittiert werden ist es wesentlich weniger gefährlich als mit einem administrativen Account

Quelle: Paula Januszkiewicz, http://blogs.technet.com/b/plwit/

Die Migration von Windows XP zu Windows Vista oder Windows 7 wird einem mit dem User State Migration Tool von Microsoft stark vereinfacht. Mit Hilfe der beiden Kommandozeilen Tools scanstate.exe auf dem Quellsystem und loadstate.exe auf dem Zielsystem werden die Userdaten über ein Netzwerk Share migriert.

Die Move User’s Stuff Tool sind ein GUI Aufsatz und ersparen einem das umständliche tippen in der Kommandozeile

Als erstes laden wir uns das M.U.S.T inklusive aller benötigten USMT Dateien von der folgenden Seite:

http://webpages.csus.edu/~dung.truong/MUST/

Wir wählen den Punkt Version 1.0 – with USMT4 und laden das Paket herunter.

Anschließend entpacken wir das ganze Paket und kopieren es in eine erreichbare Netzwerkfreigabe in den Unterordner MUST.

Dort liegen nun folgende Dateien:

In den Ordner MUST erstellen wir uns nun noch einen „Migration“ Unterordner der anschließend die Migrationsdaten aufnimmt.

Nun wechseln wir per RDP auf das Quellsystem und starten ein cmd Fenster welches wir mit den folgenden Befehlen füttern:

Den Start von einer Freigabe quittiert das MUST zwar anschließend mit einer Fehlermeldung (List Index out of Bounds), es funktioniert aber trotzdem ohne Probleme.

Wir befinden uns nun im Startbildschirm des MUST.

Unter „Save Migration To“ tragen wir den eben erstellen Ordner Migration ein, wählen falls gewünscht ein Passwort zur Sicherung der Daten und selektieren unter „User Selection“ die/den gewünschten User.

Mit einem Klick auf „Begin Capture“ startet ScanState.exe seine Arbeit.

In unserem Migrationsordner findet sich nun eine Unterordner mit einer USMT.mig Datei.

Auf dem Zielsystem kann die Datei mit einem Doppelklick gestartet werden und man hat noch einmal die Möglichkeit einzele User auszuwählen bevor Windows Easy Transfer mit der Übetragung beginnt.

In Exchange 2010 ist es nicht mehr so einfach möglich sich die Postfach Grössen anzeigen zu lassen. Mit dem folgenden Script wird per Taskplaner automatisiert eine Log Datei verschickt, in der alle Postfach Grössen aufgelistet sind.

Als erstes legen wir das Script an:

Das Script speichern wir als .ps1 Script.Nun erstellen wir eine .bat Datei die wir über den Taskplaner aufrufen:

Nach der Ausführung des Scriptes befindet sich im Posteingang eine Mail, mit der Logdatei im Anhang:

Wie wir erkennen können, hat der User Peterchens Mondfahrt zwar das grösste Postfach, befindet sich jedoch noch im Limit, da seine Postfachgrösse manuell erhöht wurde. Der User Ansgar Ragentor hingegen hat sein Postfach Limit überschritten und kann keine neuen Mails mehr senden oder empfangen. Die User Lars Ricken und Elvis Presley sind innerhalb des Postfach Limits, hier ist alles in Ordnung.

Die Transaktions Logs von Exchange 2010 sind ein wichtiger Bestandteil des Servers. Die Logs stellen sicher, dass die Datenbank im Falle eines Ausfalles nicht inkonsistent wird. Exchange schreibt dazu alle Vorgänge erst in eine Logdatei bevor er sie anwendet. Es ist auf jeden Fall empfehlenswert, die Logs auf einer seperaten Partition abzulegen. Sehen wir uns einmal beispielhaft an was für Logytpen es nter Exchange 2010 so gibt:

E00 (bzw. E00.log) –> Hier speichert der Exchange aktuell seine Transaktionen. Erreicht die Datei eine Grösse von 1024 KB wird die Datei umbenannt. So wurde beim erreichen der 1024 KB Grenze bsp. aus der E00.log die Datei E0000000230.

E00.chk –> Dies ist das Checkpoint File, welches dazu dient dem Server mitzuteilen welche Logdatei zu welcher Mailbox gehört

E00temp –> ein neues Logfile welches gerade generiert wurde

Bei einer Migration oder vielen Kopier- bzw. Verschiebevorgängen auf dem Server sammelt sich schnell eine große Zahl an Logdateien.

Die Logdatei Partition läuft somit nach einiger Zeit voll, was zur Folge hat dass der Server ein- und ausgehende Mails nicht mehr zustellt und sie in der Warteschlange verbleiben. Abhilfe schafft hier eine Sicherung mit dem “Windows Server Backup”, dem Server 2008 R2 Nachfolger von ntbackup. Nach erfolgreicher Online Sicherung des Systems, werden die Logdateien sauber entfährt ohne die Datenbanken abzuhängen, was nötig wäre wenn man das ganze über eseutil lösen würde.

Wir starten “Windows Server Backup”und wählen unten “Unterschiedliche Optionen”…

Im nächsten Schritt wählen wir “Benutzerdefiniert”

Nun wählen wir die Datenbank Partition und die Logpartition…

Wichtig ist im nächsten Schritt unbedingt die “VSS Vollsicherung zu wählen, da sonst die Logdateien nicht abgeschnitten werden

Nach auswählen eines passenden Speicherortes startet die Sicherung. Nach erfolgreichem Abschluss des Sicherungsvorganges sind ein Grossteil der Logdateien entfernt.

Natürlich werden im Laufe der Zeit wieder neue Dateien angelegt, bei einer Log Partition von mindestens 50 GB sollte man aber eine ganze Zeit auf der sicheren Seite sein, zumal sicher auf Dauer niemand auf eine Server Sicherung verzichten möchte

Standardmäßig ist die globale Adressliste in Exchange nach dem Vornamen sortiert, ebenso wie im Active Directory selber:

Der entscheidende Eintrag im Active Directory ist hier der Anzeigename:

Mit dem folgenden Script ändern wir nun den Anzeigenamen so ab, dass er die Form Nachname, Vorname hat.

Nun stimmt die Anzeige und die Exchange Benutzer können ihre Mails nach dem Nachnamen sortiert adressieren

Mit dem netsh Befehl lassen sich die kompletten DHCP Daten eines Servers sichern. Die erstellte Datei kann auf dem selben Server oder einem neuen Server einfach eingespielt werden. Das folgende Script exportiert die Einstellungen des alten Servers und ersetzt die Werte durch die des neuen Servers:

$AlterServer = “Server1″
$NeuerServer = “Server2″
$Dumpdatei = “D:\dhcp.txt”

netsh dhcp server \\$AlterServer dump >> $Dumpdatei
cls
Write-Host “Exportiere DHCP Daten von $AlterServer”
Write-Host “Ersetze $AlterServer durch $NeuerServer”

(Get-Content $Dumpdatei) | Foreach-Object {
$_ -replace $AlterServer, $NeuerServer} | Set-Content $Dumpdatei

Write-Host -ForegroundColor blue “Export abgeschlossen. Dumpdatei: $Dumpdatei”

Auf dem neuen Server lässt sich die Dumpdatei nun einfach über

importieren. Fertig!

Unter Windows 2008 R2 gibt es als cooles neues Feature einen nutzbaren Papierkorb für gelöschte Objekte. Dieser muss jedoch über die Powershell erst aktiviert werden:

importModule ActiveDirectory
Enable-ADOptionalFeature -Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Ser
vice,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com’ -Scope ForestOrConfigurationSet -Target ‘contoso.com’

Der Papierkorb ist nun aktiviert. Nun löschen wir einen beliebigen AD User:

Die Wiederherstellung ist nun über folgenden Befehl möglich:

Get-ADObject -Filter {displayName -eq “Max Mustermann”} -IncludeDeletedObjects #Anzeige des gelöschten Users
Get-ADObject -Filter {displayName -eq “Max Mustermann”} -IncludeDeletedObjects|Restore-AdObject #Wiederherstellung
Get-AdUser -filter {(Surname -eq “Mustermann”)} #Überprüfung

Einen Active Directoy User anzulegen ist nicht wirklich schwer. Jedoch dauert es ca. eine Minute bis man sich durch alle notwendigen Felder geklickt und getippt hat. Das folgende Script fragt lediglich die OU, sowie den Vor- und Nachnamen ab und erstellt anschliessend den entsprechenden User.

import-module ActiveDirectory

$Vorname = Read-Host “Vorname”
$Nachname = Read-Host “Nachname”
$OU = Read-Host “OU”

CD “AD:\OU=$OU,DC=contoso,DC=com”

$password = “Passwort09!” #hier wird das zusetzende Passwort eingetragen
$domain = contoso.com #hier wird die Maildomain eingtragen Bsp.: vorname.nachname@contoso.com

$secure_Password = convertto-securestring $password -asplaintext -force

$GanzerName = $Vorname + ” ” + $Name
$kompletteMail = ($Vorname+”.”+$Name+$domain)
$Anmeldename = ($Vorname.Substring(0,1)+$Nachname)
$Anmeldename = $Anmeldename.ToLower()

cls
Write-Output “————————————————————————————–”
Write-Output “Lege Benutzer $GanzerName mit Email Adresse $kompletteMail und Kennwort $password in $OU an!”
Write-Host -ForegroundColor blue Fertig!
Write-Output “————————————————————————————–”

New-Aduser -Name $GanzerName -DisplayName $GanzerName -GivenName $Vorname -Surname $Nachname -EMail $kompletteMail -SamAccountName $Anmeldename -UserPrincipalName $Anmeldename -Enabled $True -AccountPassword $secure_Password –ChangePasswordAtLogon $true

Das folgende Script liest User aus einer CSV Datei und legt diese in der abgefragten OU ab. Das Kennwort wird automatisch auf den in der Variable $password zugewiesenen Wert gesetzt. Als E-Mail Adresse wird Vorname.Nachname@contoso.de gesetzt. Die Maildomain kann in der Variable $domain angepasst werden.

import-module ActiveDirectory

$OU = Read-Host “OU”

CD “AD:\OU=$OU,OU=Fachbereiche,DC=herdecke,DC=local”
cls

$password = “Passwort09!” #hier wird das zusetzende Passwort eingetragen
$domain = “@contoso.com” #hier wird die Maildomain eingtragen Bsp.: vorname.nachname@contoso.com
$secure_Password = convertto-securestring $password -asplaintext -force

$a = get-content D:\User.csv
Foreach ($Zeile in $a) {
$Text = $Zeile.split(“;”)
$Vorname = $Text[0]
$Nachname = $Text[1]
$GanzerName = $Vorname + ” ” + $Nachname
$kompletteMail = ($Vorname+”.”+$Nachname+$domain)
$Anmeldename = ($Vorname.Substring(0,1)+$Nachname)
$Anmeldename = $Anmeldename.ToLower()

Write-Output “————————————————————————————–”
Write-Output “Lege Benutzer $GanzerName mit Email Adresse $kompletteMail und Kennwort $password in $OU an!”
Write-Host -ForegroundColor blue Fertig!
Write-Output “————————————————————————————–”

New-Aduser -Name $GanzerName -DisplayName $GanzerName -GivenName $Vorname -Surname $Nachname -EMail $kompletteMail -SamAccountName $Anmeldename -UserPrincipalName $Anmeldename -Enabled $True -AccountPassword $secure_Password –ChangePasswordAtLogon $true
}

Die Inalte in der CSV Datei müssen das folgende Format haben:

Wenn nicht anders konfiguriert, syncen standardmäßig alle Clients im AD mit dem DC, der die Rolle des PDC-Emulators inne hat. Eine Zeitabweichung von mehr als 5 Minuten kann dabei verheerende Auswirkngen auf den Kerberos Dienst haben. Diese Probleme können z.B. entstehen, wenn der w32time Dienst nicht läuft.

Wie an dem roten Text  zu erkennen ist, synct der Client nicht mit einem DC, sondern mit der lokalen Bios Uhr. Solange diese richtig funktioniert ist alles super, allerdings wird es schwierig wenn es Abweichungen gibt. Vorteilhaft ist es den PDC-Emulator DC von einer externen NTP Quelle snycen zu lassen:

Auf weiteren DCs sollte anschliessend ebenfalls noch der Befehl W32TM /resync /rediscover abgesetzt werden. Der gleiche Befehl hilft auf Clients deren Zeit abweicht.

Das folgende Script ermittelt den freien Speicherplatz auf lokalen Festplatten. Netzlaufwerke, Disketten- und CD-ROM/DVD-Laufwerke werden nicht berücksichtigt. Die Ausgabe erfolgt in GB mit 2 Nach-Komma Stellen.

$Laufwerk = Get-WmiObject -class win32_logicalDisk
ForEach ($Element in $Laufwerk){
if ($Element.DriveType -eq 3){

$Laufwerk2 = $Element.FreeSpace/1GB
$Laufwerk3 = $Laufwerk2|Out-String

Write-Output (“Laufwerk ” + $Element.Name + ” hat ” + $Laufwerk3.SubString(0,5) +” GB freien Speicherplatz”)
}
}

Import-Module ActiveDirectory
Set-Location ad:\
Set-Location “OU=Benutzer,DC=contoso,DC=com

$User = Get-ADUser -Filter * -SearchBase “OU=Benutzer,DC=contoso,DC=com”

foreach ($Benutzer in $User){

$kompletteMail = (($Benutzer.GivenName)+”.”+($Benutzer.Surname)+”@contoso.com”)

Set-ADUser $Benutzer -EMail $kompletteMail }

Nach der Installation des Patches KB2501584 gibt es leider einige Probleme mit dem öffnen von Excel Dateien auf Netzlaufwerken. Nach 3-10 Minuten erscheint eine Fehlermeldung und die Datei wird nicht geöffnet. Schuld ist die neue eingeführte Office File Validation. Microsoft beschreibt das ganze hier:  http://support.microsoft.com/kb/2570623. Abhilfe schafft die manuelle Deinstallation des Patches KB2501584 oder alternativ der folgende Befehl lokal oder im Startup Script:

Mit dem folgenden kleinen Script kann man über einen längeren Zeitraum einen Server oder Client pingen und bekommt eine Logdatei mit Angabe von Zeit und Datum und kann so bequem kontrollieren ob es zu Ausfällen kam:

Mal eben schnell eine Software Inventur durchführen, ist generell kein großes Problem. Natürlich gibt es eine Reihe von (oft teuren) Softwareprodukten die dies durchführen können. Neben dem Preis sind diese Produkte aber oft überladen. Basierend auf psinfo aus den PSTools von Microsoft habe ich ein kleines Programm zur Softwareinventur geschrieben.

Das Programm besteht aus 3 Bestandteilen:

Die Clientliste (clients.txt)

Dem Programm selbst (softwarelog.exe)

psinfo.exe

Zur Verwendung entpacken wir alle Dateien in einen beliebigen Ordner und starten anschließend das Programm in einer CMD Shell mit dem Parameter der Software für die wir uns interessieren.

Das Programm durchsucht nun alle Rechner aus der Clients.txt und erstellt anschließend eine Logdatei mit dem Namen der Software und dem aktuellen Datum.

In der Datei sind nun alle Officekomponenten aufgelistet.

Download: Softwarelog.zip

Viel Spaß bei der Benutzung

Oft steht man vor dem Problem, dass man eine ganze Reihe von Ordnern auf einmal anlegen muss. Dies geht einfach über eine kleine Batchdatei mit folgendem Inhalt: Diesen Beitrag weiterlesen »

Wer kennt es nicht…. Mal eben schnell eine Einstellung als Admin vornehmen, während der User noch angemeldet ist. Ein anderes bekanntes Problem ist, der User ist zur Pause und nicht am Platz. Natürlich können wir uns als Admin anmelden bzw. mit “Ausführen als” arbeiten. Allerdings hat auch “Ausführen als” seine Grenzen. Stellen wir uns z.B. vor dei NTFS Berechtigungen eines Ordners müssen geändert werden. Ein kurzer Eingriff, aber dafür den User abmelden, als Admin anmelden und anschließend den User erneut anmelden lassen? Nein!

Folgender Trick erleichtert uns das Leben ungemein:

1.) Wir starten den Task Manager und beenden die Explorer.exe (die momentan im User Kontext läuft)

Anschließend bleibt uns erstmal nichts weiter als der leere Desktop. Herrlich diese Ruhe und Entspannung!

2.) Über Strg+Alt+Entf starten wir nun erneut den Taskmanager und wechseln unter Datei zu dem Punkt “Neuer Task (Ausführen…)”

3.) Nun starten wir die Explorer.exe als Admin neu. Dies geschieht mit dem folgenden Befehl:

Nun haben wir einen kompletten Administrator Desktop und können alle Einstellungen vornehmen, installieren usw.

Um zur Explorer Instanz des Users zurück zu kehren, melden wir uns einfach als Administrator ab und nach einigen Sekunden erscheint der Desktop unseres Nutzers wieder (sollte dies nicht geschehen starten wir im Task Manager einfach nur die explorer.exe nach (siehe unten), schon kann der User wieder arbeiten ohne sich neu anzumelden.

Das Leben eines Admins ist ja schon schwer genug. Ich habe mir daher angewöhnt, soviel wie eben möglich remote zu erledigen (man wird ja schließlich auch nicht jünger :p)

Ein häufiges Problem ist die Installation eines Druckers auf einem Remote Rechner. Klar, wir können uns aufschalten bzw. mit RDP ne Session aufbauen. Bequemer und einfacher geht das ganze mit Hilfe des

Kommandos. Der folgende Befehl öffnet den Standard “Drucker hinzufügen” Dialog auf unserem lokalen Client und fügt den Drucker auf dem UNC Client hinzu:

Auch das bequeme hinzufügen eines Netzwerkdruckers ist ohne Probleme möglich. Dazu bedienen wir uns dem folgendem Kommando in Verbindung mit psexec:

Anschließend ist der Netzwerkdrucker Kyocera1300 auf dem remote Computer DEWS546 eingerichtet.

Soweit so gut! Der Befehl ist allerdings schwer zu merken und bis er eingetippt ist, ist schon wieder kostbare Zeit vergangen. Aus diesem Grund habe ich eine kleine .exe Datei geschrieben die uns das ganze erleichtert.

Der Aufruf ist denkbar simpel, wir übergeben als Argument einfach den Clientnamen auf dem wir den Drucker hinzufügen möchten:

Anschließend öffnet sich der gewohnte “Drucker hinzufügen” Dialog.

Die addprinter.exe kann hier heruntegeladen werden:   Addprinter.exe

MD5: 764fd35d8cdba30cf62355adf0665407
SHA-1: 3d9e546129f61803326a5a6a06e24d1d44330c8b

Herzlich Willkommen auf Tisku.net!

Auf dieser Seite findet ihr einige interessante Infos, selbstgeschriebene Powershell Scripte sowie einige Tips & Tricks rund um das Thema IT!

Viel Spaß!

Timo