Weisheiten - der Netz-Weise Blog

Leider bietet das Powershell AD-Modul keine Möglichkeit, auf das Vorhandensein einer Organizational Unit zu testen. Diese Funktion lässt sich aber einfach nachrüsten. 

Grundsätzlich kann man die Existenz einer OU testen, indem man einfach das Cmdlet Get-OrganizationalUnit verwendet. Prüft man die Abfrage in einer IF-Bedingung, wird der Scriptblock des IF ausgeführt, wenn die OU existiert. Das Ganze hat allerdings einen Haken, denn Get-ADOrganizationalUnit bricht die Skriptverarbeitung mit einem unbehandelten Fehler ab, wenn die OU nicht existiert.

If ( Get-ADOrganizationalUnit -Identity "OU=test,DC=Netz-Weise,DC=DE" ) { $true }
get-adorganizationalUnit : Directory object not found

Dieses Verhalten kann man sich zunutze machen, indem man die Ausführung des Get-ADOrganizationalUnit mit Try-Catch ausführt. Wird ein unbehandelter Fehler ausgeführt, wird die Catch-Block aufgerufen und ausgeführt. In diesem muß man jetzt nur noch einen $False zurück liefern. 

function Test-ADOrganizationalUnit

Zum Vergeben eines Laufwerksbuchstaben muß man zuerst einmal evaluieren, welchen Laufwerksbuchstabe frei ist. Es gibt eine Reihe Ansätze, aber dieser hier ist für Lernzwecke ganz interessant. Die folgende Funktion wandelt die Asciicodes der Buchstaben C (Ascii 67) bis Z (Ascii 90) in Buchstaben um. Die Buchstaben werden der Reihe nach in einer Foreach-Schleife mit Test-Path gegen die vorhandenen Pfade überprüft. Sobald Test-Path False zurück gibt, wird die Schleife per "break" abgebrochen und der gefundene Buchstabe zurück gegeben. 

Interessant in diesem Zusammenhang ist auch die Invertierung der Suche. Um beim letzten Buchstaben zu beginnen, wird einfach der Startbuchstabe auf Z gesetzt und die Auflistungsreihenfolge umgedreht ( $Counter..67 bzw. $Counter..90). Allerdings ist der Default-Wert für den Startbuchstaben auf C gesetzt, so dass eine Invertierung der Suche ohne setzen des Startbuchstabens normalerweise kein Ergebnis liefert. Eine Lösung bietet die automatische Variable $PSBoundParameter. Diese Variable wird automatisch erstellt, wenn beim Aufruf einer Funktion Übergabeparameter vom Benutzer verwendet werden. Die Methode Containskey() überprüft, ob ein Parameter vorhanden ist oder nicht. 

function get-freedrive

{

  <#

Die Windows-Powershell ist ein sehr mächtiges Werkzeug, und wie alle mächtigen Werkzeuge kann man Ihre Funktionen für gute wie für schlechte Dinge anwenden. Daher versuchen viele Unternehmen, die Ausführung von Powershell zu verhindern. Das die Ausführungsrichtlinie, die die Skriptausführung einschränken kann, kein echtes Hinternis ist, hat sich inzwischen herumgesprochen. Tatsächlich scheint der Stand der Dinge zu sein, dass man mit Windows Bordmitteln nur mit Applocker (ab Windows 7 Enterprise oder Windows 8.1 / Windows 10 Pro) einen ansatzweise hinreichenden Schutz vor der Ausführung von Powershell erreichen kann. Versuchen Sie aber gar nicht erst, mit Skriptregeln herum zu spielen - Skriptregeln verhindern das Ausführen von Skripten, aber nicht den Start von Powershell. Und da man in Powershell jedes Skript auch von Hand eingeben kann, erreicht man mit dem Verhindern von Skripten gar nichts. Man könnte jetzt noch argumentieren, dass lange Skripte nicht von Hand übertragen werden können, oder dass ein Hacker ohne physikalischen Zugriff auf den Server die Skripte nicht von Hand in die Konsole übertragen kann. Allerdings läßt sich Powershell auch manuell mit dem Parameter "-Command" starten. Und es ist sehr einfach, ein Skript von der Kommandozeile aus einzulesen und einfach über den Standard-Ausgabestrom an die Powershell.exe weiterzuleiten.

get-content c:\temp\meinSchadcode.txt | powershell.exe -command -

Hier fehlt im Übrigen nichts, es handelt sich in der Tat um einen Bindestrich hinter dem -Command. Der Bindestrich bewirkt, dass das auszuführende Kommando aus dem Ausgabestrom gelesen wird. Dadurch muß der Schadcode sich noch nicht einmal in einer .ps1-Datei befinden - Powershell.exe unterbindet die Ausführung von anderen Dateiendungen normalerweise.

Sie haben einen leere Festplatte und möchten direkt von VHD booten? Abgesehen von kleinen Stolperfallen eigentlich ganz einfach...

Wenn Sie eine neue Festplatte in Ihrem Rechner haben, auf der noch kein Betriebssytem vorhanden ist, können Sie den Rechner trotzdem ohne eine Installation in Betrieb nehmen - vorausgesetzt, Sie haben eine VHD-Datei zur Verfügung. VHD-Dateien sind Dateien, die intern eine Festplatte simulieren. Windows kann direkt von VHD booten - Windows 8.1 sogar von VHDX, einer deutlich performanteren Version von VHD. Sie könnten Beispielsweise die Beta-Versionen von Windows 10 oder Windows Server NG (Next Generation) als vhd bei Microsoft herunter laden. Oder Sie erzeugen sich mit Convert-Windowsimage eine eigene vhd in 5 Minuten.  Um eine Festplatte für den Boot von VHD vorzubereiten, legen Sie zuerst eine Startpartition mit 300 MB Größe an. Als Partitionsformat wählen Sie FAT32. Setzen Sie die Partition anschließend aktiv. Von Windows PE per Kommandozeile aus können Sie das mit Diskpart erledigen:

 diskpart
 create partition primary size=300
 format quick fs=ntfs
 assign letter=s
 active

Anschliessend richten Sie den Rest der Festplatte als eine große Partition ein:

 create partition primary 
 format quick fs=ntfs
 assign letter=c 
 exit

Nun können Sie die vhd-Datei auf den neuen Datenträger kopieren. Im letzten Schritt müssen Sie die Festplatte mit einem Boot-Bereich (BCD-Store) austatten. Hierfür müssen Sie die vhd-Datei mounten: 

 diskpart
 select vdisk file=C:\windows.vhdx
 attach vdisk

Nun müssen der VHD-Datei einen Laufwerksbuchstaben zuweisen, damit Sie Zugriff auf die Partition bekommen - im Beispiel der Laufwerksbuchstabe v:

"Windows 8 und Server 2012 bringen das Feature ""Primäre Computer"" mit, die Möglichkeit, ein Benutzerprofil nur auf bestimmten Computern zu nutzen. Bis Windows 8 bedeutete das Anlegen eines servergespeicherten Windows Benutzerprofils, dass ein Benutzerprofil immer auf jeden Computer heruntergeladen wurde, auf dem ein Benutzer sich angemeldet hat. Das kann nicht nur sicherheitstechnisch unglücklich sein - kritische Daten werden überall im Netz verteilt - sondern verlängert auch die Anmeldezeiten auf Sytemen, auf denen man sich nur selten anmeldet. Mit dem Feature primärer Computer kann man dem Benutzer nun einen oder mehrere Computer vorgegen, die das servergespeicherte Benutzerprofil ziehen. Alle anderen Computer nutzen ein lokale Profil. Voraussetzung dafür ist Windows 8 und das AD-Schema von Windows Server 2012, da die Funktion über ein neues Benutzerattribut implementiert wird - msDS-Primary Computer. Richten Sie primäre Computer einfach ein, indem Sie in den DN (Distinguished Name) des Computers kopieren und in das Attribut msDS-Primary Computer des Benutzerobjekts einfügen. Das können Sie über AD Benutzer und Computer machen (indem Sie die erweiterte Ansicht unter "Ansicht" aktivieren und dann im Benutzer den Attributs-Editor verwenden), oder über Powershell:

$computer=Get-ADComputer Computername
Set-ADUser Benutzername –Add @{‘msDS-PrimaryComputer’=”$computer”}

Im nächsten Schritt aktivieren Sie Ordnerumleitungen und / oder servergespeicherte Profile in einer Gruppenrichtlinie, indem Sie im Benutzer oder Computer und Administrative Templates\System\Folder Redirection gehen und ""Redirect Folders on Pirmary Computers only"" wählen. Für Profile heißt die Option ""Download roaming profiles on primary computers only"". "

"Benutzerprofile verwalten - augenblicklich und Betriebssystemversionst-unabhängig - ist das möglich? Ja, mit UE-V!

UE-V (eine kurzform von Microsoft User Experience Virtualization) ist eine Funktion, um Windows Benutzerprofile zu verwalten. Vor kurzem haben wir darüber geschrieben, wie man servergespeicherte Benutzerprofile verwalten kann, wenn man 2 verschiedene Windows-Versionen unterstützen muß. Normalerweise muß man dafür 2 verschiedene Benutzerprofile hinterlegen und die entsprechenden Benutzerordner wie Desktop, Eigene Dateien usw. aus dem Benutzerprofil ""herausziehen"" und auf einer Netzwerkfreigabe speichern. Mit Windows UE-V wird das Benutzerprofil (die Benutzereinstellungen, nicht die Dateien, die ziehen wir weiterhin aus dem Profil heraus) über einen eigenen Dienst verwaltet. Der UE-V Dienst überwacht die Registry und den App-Folder im Benutzerprofil und synchronisiert Änderungen an Anwendungseinstellungen auf ein Netzwerklaufwerk (Share). Diese Änderungen werden nach dem Beenden der Anwendung direkt gespeichert, so dass ein Abmelden zum Synchronisieren der Benutzereinstellungen nicht mehr notwendig ist. Auch Modern Apps (Windows 8 Apps) werden mit UE-V 2.0 unterstützt. Out of the Box bringt UE-V die Unterstützung diverser Anwendungen mit. Für Anwendungen, die nicht von UE-V unterstützt werden, können eigene XML-Konfigurationsdateien mit Hilfe eines mitgelieferten Tools erstellt werden. Das tolle an UE-V ist, dass nicht alle Einstellungen zwischen den Clients eines Rechners synchronisiert werden. Dadurch kann man die Benutzerprofile auch zwischen unterschiedliche Betriebssytemen ohne Verrenkungen verwalten. So, wo ist jetzt der Nachteil des UE-V? Es ist nur als Bestandteil des Desktop Optimization Kits zu bekommen (M-DOP). Warum nur, Microsoft, warum? Verdient ihr mit dem MDOP tatsächlich so viel Geld, dass es sich lohnt, diese Programme nicht zum Bestandteil des Betriebssystems zu machen?"

Ihre auf den Server umgeleiteten Benutzerprofile heissen alle "My Documents" oder "eigene Datien"? Die Desktop.ini ist Schuld! Ein Problem beim Kunden: die meisten der auf den Server umgeleiteten Verzeichnisse werden im Explorer als ""My Documents"" oder ""Eigene Dateien"" angezeigt. Sehr merkwürdig, denn eigentlich kann ein ordnername ja nicht mehrfach im gleichen Verzeichnis auftauchen. Das Problem ist die desktop.ini, die den Explorer anweist, Ordner mit einem bestimmten Symbol zu versehen oder eben umzubennen. Die Desktop.ini liegt im Benutzerordner, und löschen führt dazu, dass wieder der Originalname angezeigt wird. Leider ist das Löschen nicht von Dauer. Um das wiederanlegen der desktop.ini zu verhindern, gibt es verschiedene Möglichkeiten. Zum einen kann man den Schreibzugriff auf die Datei verhindern. Am besten hat mir allerdings der Tipp gefallen, durch einen Eingriff in die Registry (per gpo verteilt) das erstellen der Desktop.ini vollständig zu verhindern - mit der Nebenwirkung, dass der Explorer nun natürlich gar keine desktop.ini Dateien mehr erstellt.

Schlüssel: HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
Name: "UseDesktopIniCache"
Typ:dword
Value: 00000000

Auch das Benutzerprofil von Windows 10 ist wieder nicht mit den Vorgängerversionen kompatibel. Aber Microsoft hat vorgesorgt. Mit Windows 7 hat Microsoft zum ersten mal eine neue Verion des Benutzerprofils eingeführt, um zu verhindern, dass Benutzer mit servergespeicherten Profilen nicht beim Wechsel zwischen Betriebssystemversionen (z.B. auf RDP-Servern) ihr Profil zerschiessen. Dafür legt Windows 7 einen eigenen Profilordner mit der Endung .V2 an. Windows 8 und Windows 8.1 verwenden standardmässig das gleiche Verzeichnis wie Windows 7, nämlich .V2. Man kann allerdings aktivieren, dass auch Windows 8 (.V3) und Windows 8.1 (.V4) sich in eigenen Unterordern schreiben. Installieren Sie hierfür je nach Betriebssytem eines der beiden Hotfixes:

Für Windows 8 das in KB2887239 beschriebene.
Für Windows 8.1 das in KB2887595 beschriebene Hotfix Rollup. 

Danach setzen Sie den folgenden Schlüssel in der Registry:

Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\ProfSvc\Parameters
Name: UseProfilePathExtensionVersion
Wert: 1

Alternativ können Sie dieses Feature auch über Gruppenrichtlinien Einstellungen (Group Policy Preferences) setzen. 

Sie versuchen, ein Update für den CRM-Outlook-Client zu installieren, aber die Installation schlägt mit einer Fehlermeldung wie dieser

“The type initializer for 'Microsoft.Crm.LocatorService' threw an exception.
Cannot load Counter Name data because an invalid index '' was read from the registry.”

fehl? Dann könnte die Ursache fehlerhafte Performance-Counter sein. Klingt merkwürdig? Dachte ich mir auch, aber die Reparatur der Performance-Counter hat trotzdem geholfen. ;-) Geben Sie an der Kommandozeile mit administrativen Rechten einfach

lodctr /r

ein. Überprüfen Sie, ob der CRM-Provider aktiv ist, indem Sie

lodctr /q | find "CRM Client" 

eingeben. Sind die Performance-Counter enabled, können Sie die Installation starten. Ansonsten Registrieren Sie den Client mit

lodctr /e:CRM Client

Danach sollte die Installation des CU (hoffentlich) problemlos funktionieren.

Windows Server bringt eine Reihe von Migrationstools mit, die die Migration von Benutzern, Druckern und Dateien recht einfach machen Sie müssen lokale Benutzer, Gruppen, Drucker oder Dateien zwischen zwei Windows-Server migrieren? Kein Problem mit den Windows Server Migrationstools.

Szenario 1: Benutzer und Gruppen migrieren

Um Benutzer und Gruppen zu migrieren, verwenden Sie die Windows Migration Tools. Auf Windows Server 2008 R2 und 2012 (R2) installieren Sie diese über den Server-Manager oder über Powershell auf dem Quell- und auf dem Zielserver:

Install-WindowsFeature -Name Migration

Danach laden Sie in Powershell das Migrations Snap-In:

Add-PSSnapin Microsoft.Windows.ServerManager.Migration

Exportieren Sie nun zuerst auf dem Quellserver die Benutzer und Gruppen mit Hilfe des Cmdlets Export-SmigServerSettings. Über den Parameter User können Sie angeben, welche Benutzer exportiert werden sollen. Es stehen Ihnen die Optionen "All","Enabled" und "Disabled" zur Verfügung. Wenn Sie auch die lokalen Gruppen exportieren wollen, verwenden Sie den Parameter Group. Achten Sie aber darauf, dass Sie die Gruppen in einem Befehl mit den Usern exportieren, da Sie sonst ein weiteres Export-Verzeichnis benötigen. Das Export-Verzeichnis sollte sinnigerweise von beiden Servern aus erreichbar sein. Da der Export mit Kennwort erfolgt, müssen Sie die Daten mit einem Kennwort verschlüsseln.