Kategorieauswahl

Translator

Google +1

Bitte teilen Sie Google mit, wenn Ihnen diese Seite gefällt.

Dateisystem

Alles was mit Dateien zu tun hat.

In PowerShell Remote-Session auf UNC Netzwerkpfade zugreifen

Hat man Windows Remoting konfiguriert und Enter-PSSession als auch Invoke-Command klappen problemlos, fängt man an diese tollen Möglichkeiten rege zu nutzen. Ab und an will man dann aber vielleicht auch einmal aus so einer Remote-Session heraus auf einen Netzwerkpfad in Form von \\Servername\Freigabename zugreifen und man bekommt immer so nette Fehlermeldungen wie:

Get-ChildItem : Cannot find path ‚\\Servername\Freigabename‘ because it does not exist.
+ CategoryInfo          : ObjectNotFound: (\\Servername\Freigabename:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Doch der Server ist online und wenn Sie am entfernten Computer lokal angemeldet versuchen darauf zuzugreifen ist alles fein. Was läuft hier schief? Das ist wieder einmal so ein „Sicherheitsfeature“.

Der Quick and Dirty Way ist einfach mit:

net use n: \\Servername\Freigabename

eine Netzlaufwerksverbindung herzustellen (tolle Sicherheit). New-PSDrive und andere Experimente können Sie sich sparen…habe ich alles schon ausprobiert. N: können Sie dann ganz normal ansprechen. Nun der offizielle Weg:

Mittels Gruppenrichtlinien müssen Sie unter Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Management (WINRM) bei den Unterpunkten WINRM Client als auch WINRM Service „Allow CredSSP authentication“ aktivieren. Des Weiteren müssen Sie unter Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation die beiden Einträge Allow Delegating Fresh Credentials und noch einmal der Eintrag mit Allow Delegating Fresh Credentials with NTLM-only Server Authentication mit so einem Eintrag schmücken:

wsman/NameDesRechnersAufDenSieSichRemoteDraufSchaltenMöchten

Diese Policy muss an eine OU gehängt werden welche die Computer enthalten von denen aus Sie Enter-PSSession bzw. Invoke-Command ausführen möchten.

Haben Sie keine GPOs (z.B. weil kein AD) dann geht es auch in der PowerShell auf den einzelnen Systemen (aber nicht remote 😉 ) mit:

Enable-WSManCredSSP –Role Server

und

Enable-WSManCredSSP –Role Client -DelegateComputer NameDesServers

Um sich dann mit dem Server zu verbinden, müssen Sie die zusätzlichen Schalter -cred und -auth mit angeben. Zuvor sollten Sie sich allerdings die Anmeldeinformationen in einer Variablen hinterlegen, z.B. so:

$cred=get-credential

Dann können Sie Ihr eigentliches Enter-PSSession in dieser Form ausführen:

Enter-PSSession Remoteserver -cred $cred -auth credssp

Verrückte Welt! Ich nehme net use 😉

Benutzer und Gruppenberechtigungen in Rechtelisten austauschen

Wenn Sie z.B. einen Benutzer in einer Domäne löschen und in einer anderen neu erstellen ist das ja nicht mehr derselbe Benutzer, trotzdem er vielleicht den gleichen Namen hat. Das hat natürlich auch Auswirkungen auf die ACL (Access Control Lists, die sich in DACL und SACL aufteilen). Nun möchten Sie Beispielsweise auf einer Freigabe, dass der Benutzer weiterhin zugreifen kann. Insbesondere bei NTFS kann das recht mühsam werden. Nicht mit SubInACL.exe, dass Sie bei Microsoft herunterladen können. Damit können Sie einfach ein Benutzer- oder Gruppenkonto aus der Rechteliste einer Verzeichnisstruktur gegen ein anderes austauschen lassen, ohne dabei die bestehende Rechteliste zu zerschießen. Nur da eine Konto wird gegen ein anderes ausgetauscht.

Alte Anwendungen unter Windows 7 zum Laufen bekommen

Sie haben eine Anwendung die unter Windows 7 nicht laufen will? In den meisten Fällen helfen ja schon die Bordmittel weiter. Darüber hinaus hilft das ACT (Application Compatibility Toolkit) von Microsoft weiter. Immer noch nicht? Dann gibt’s nur noch eine Geheimwaffe! Wenn Ihnen aber bereits ACT Schwierigkeiten bereitet vergessen Sie es, da das Tool mit ACT zusammen arbeitet. Das Spielzeug nennt sich LUA Buglight und ist im Internet nur schwer zu finden, daher hier gleich der Download dazu:

Lua Buglight

Starten Sie Ihr störrisches Programm von LUA Buglight aus. Dabei werden alle problematischen Zugriffe auf Dateisystem, Registry und ein paar andere Objekte mitgeschrieben. LUA Buglight sagt Ihnen nun welche Shims bzw. Compatibility Fixes benötigt werden um das Programm zum Laufen zu bekommen. Im schlimmsten Fall gibt es noch kein passendes Compatibility Fix. Dann müssen Sie eben selbst eines basteln. Wenn laut LUA Buglight Ihr Programm namens C:\Programme\AltesMistding\Mistding.exe versucht auf C:\Programme\AltesMistding\Mistding.config schreibend zuzugreifen (auf den Programmeordner gibt es nur noch Lesen Berechtigungen für normal sterbliche Benutzer) gehen Sie wie folgt vor:

1.) Kopieren Sie C:\Programme\AltesMistding\Mistding.config nach %APPDATA%\AltesMistding\Mistding.config. Ggf. müssen Sie erst die Ordnerstruktur in Ihrem Benutzerprofil unter Appdata (verstecktes Systemverzeichnis – erst Explorer Bescheid sagen!) anlegen.

2.) Legen Sie im Compatibility Administrator aus dem ACT eine neue leere Datenbank an und dann per Rechtsklick auf Create New\Application Fix erstellen Sie Ihren eigenen Compatibility Fix.

3.) Füllen Sie die allgemeinen Felder aus wie Sie mögen. Unter Program file location tragen Sie aber Ihre bockige Anwendung (z. B.: C:\Programme\AltesMistding\Mistding.exe) ein und klicken Sie 2 x auf Weiter.

4.) Wählen Sie nun min. bestehendes Compatibility Fix aus (z.B. CorrectFilePaths) und klicken Sie auf Parameters.

5.) Unter Command line tragen Sie nun den von der Anwendung gewünschten Pfad ein und danach die Umleitung durch Seminkolon getrennt. Beispielsweise so:
%PROGRAMFILES%\AltesMistding\Mistding.config;%APPDATA%\AltesMistding\Mistding.config
Das sollte wie hier gezeigt mit Variablen eingetragen werden, damit es auch problemlos auf anderen Computern und mit anderen Benutzernamen funktioniert. Mit Platzhaltern wie * dürfen Sie dabei nicht arbeiten. Sie können aber den kompletten Ordner mit dem gesamten Inhalt kopieren und umleiten.

Ähnlich verfahren Sie mit Registry-Einträgen (VirtualRegistry unter Compatibiliy Fix). Diese sollten Sie nach HKCU\Software\Classes\VirtualStore umleiten.

Haben Sie alle Beanstandungen von LUA Buglight verarbeitet können Sie den Fix einbauen. Dazu müssen Sie Ihre Datenbank aus dem ACT erst einmal als sdb Datei abspeichern. Über den Punkt Install können Sie Ihren Fix dann auf dem Computer anwenden. Man will natürlich nicht auf jedem Rechner mit der Anwendung das ACT installieren. Daher reicht es die Datenbankdatei mit dem Befehl sdbinst \\Pfad\und\NamezurSDBDatei.sdb aufzurufen. Mit dem Schalter -u kann Ihr Compatibility Fix auch wieder entfernt werden.

OpenSource NAS System mit iSCSI Unterstützung

FreeNAS ist ein Opensourcesystem für die Verwaltung eines NAS basierend auf FreeBSD. Unterstützt werden alle gängigen Filetransferprotokolle wie CIFS, NFS, FTP, HTTP aber auch iSCSI. Die Konfiguration findet mittels Webinterface statt.

Hardlinks und andere Verknüpfungstypen per Rechtsklick im Explorer verwalten

Bei NTFS gibt es Hardlinks, Junctions, Mountpoints und Sympolic Links (normale Verknüpfungen). Diese können auf der Kommandozeile mit diskpart oder ln verwaltet werden. Wenn Sie das auch grafisch gerne im Explorer machen möchten können Sie sich die Link Shell Extension installieren. Einfach Rechtsklick z. B. auf einen Ordner, Link als Quelle festlegen und dann an einer beliebigen Stelle (Hardlinks funktionieren nur innerhalb einer Partition) erneut einen Rechtsklick und über Einfügen als auswählen, ob es ein Hardlink, eine Verknüpfung oder was auch immer werden soll. Eine detaillierte Anleitung finden Sie auch auf der oben bereits verlinkten Website.

Bootfähigen USB Stick aus einer bootfähigen ISO-Datei erstellen

Allgemein

Sie haben eine bootfähige CD/DVD vorliegen, möchten aber z.B. für ein Netbook ohne CD/DVD Laufwerk einen bootfähigen USB-Stick erstellen? Mit UNETBOOTIN ist das ein Kinderspiel. Sie brauchen dazu lediglich die ISO-Datei der CD/DVD. Meist liegt die schon vor. Wenn nicht können Sie die CD/DVD mit einem herkömmlichen Brennprogramm auslesen und als ISO-Datei auf einem PC ablegen lassen. Unter Linux geht das auch sehr bequem über die Bash indem Sie dd if=/dev/scd of=meine.iso eintippen. Je nach Distribution kann Ihr CD Laufwerk auf eine andere Gerätebezeichnung haben als /dev/scd, dann probieren Sie einfach einmal /dev/cdrom. Welche Betriebssysteme werden unterstützt? Falsche Frage! Alle! Egal ob Windows, Linux, oder was auch immer. Die Sache passiert noch bevor das eigentliche Betriebssystem damit in Berührung kommt.Sie können also Window Server 2008 genau so gut bootfähig machen wie Windows 7 oder ein Kubuntu.

Windows 7 – Ergänzung

Wenn Sie Ihren Windows 7 USB-Installations-Stick in einem UEFI Rechner benutzen müssen Sie noch folgende Änderungen machen:

1. Auf der Windows 7 Installations-DVD finden Sie im install.wim Archiv (auf der DVD also unter: \sources\install.wim\1\Windows\Boot\EFI\) die Datei bootmgfw.efi. Das WIM Archiv könnnen Sie mit den meisten Kompressionsprogrammen wie z.B. 7-Zip öffnen.

2. Kopieren Sie die Datei auf Ihren Stick in das Verzeichnis \efi\boot (CPU-Typ beachten 32/64 bit) und bennen Sie sie in bootx64.efi bzw. boot.efi um.

Shellscripte und Perl auf dem KDE 4 Desktop ausführen lassen

Damit Shellscripte (bei Bash z.B. Dateien mit der Endung .sh) beim Anklicken auf dem Desktop nicht zum Bearbeiten geöffnet werden, sondern ablaufen müssen Sie das Programm systemsettings (klick auf Systemeinstellungen) aufrufen. Dort findet man gleich in der ersten Reihe den Eintrag Dateizuordnungen. Unter application finden Sie den Eintrag x-shellscript. Bei Rangfolge der zugeordneten Anwendungsprogramme klicken Sie auf Hinzufügen und geben Sie /bin/bash in die weiße Zeile ein. Bestätigen Sie mit OK. Mit dem Nach oben Knopf sorgen Sie nun noch dafür, dass das öffnen mit der Bash bevorzugt geschieht.

Genauso gut können Sie das natürlich auch mit Perl machen. Nur statt x-shellscript wählen Sie den Knoten x-perl aus und statt /bin/bash tragen Sie /usr/bin/perl ein.

Anwendungsinstallation unter Windows überwachen

TrackWinstall kann eine Anwendungsinstallation unter Windows (ab W2k -> Windows 2000,XP,2003,Vista,7,2008) überwachen. Jegliche Änderungen die während der Installation am Dateisystem oder der Registry vorgenommen werden schreibt TrackWinstall in eine Protokolldatei.

Deutsche Suchbegriffe für Windows 7 Indexdienst

Bei Windows Vista war es noch egal ob man Abfragebegriffe in Deutsch oder Englisch eingibt. Bei Windows 7 müssen Sie auf die jeweilige Sprachversion achten!

Die Suchsyntax in Englisch finden Sie hier erklärt. Da dies leider nicht auf Deutsch funktioniert (z.B. wenn Sie filename:*.exe eintippen findet er interessanter Weise nichts) hier ein paar wichtige deutsche Übersetzungen:

dateiname:*.txt größe:>2MB inhalt:Passage     Sucht nach allen Dateien im aktuellen Verzeichnis die größer als 2 MB sind und die Dateinamenerweiterung txt haben. Im Inhalt der Textdatei muss das Wort Passage vorkommen. Ob Sie größe oder grösse schreiben spielt dabei keine Rolle.

art:email suchbegriff     Sucht den Suchbegriff nur in E-Mails. Des Weiteren können Sie auch mit den Schlüsselworten an:, von: und betreff: Einschränkungen vornehmen.

art:email ordner:gesendete objekte     Sucht nur im Ordner gesendete Objekte. Genausogut funktionieren auch alle anderen wie z.B. posteingang usw. Mit Gelöschte Objekte hatte ich aber leider noch kein Glück. Wer es herausgefunden hat bzw. weiß bitte einen Kommentar ergänzen – vielen Dank.

 

Was ist beim IIS 7.5 unter Server 2008 R2 die Application Pool Identität?

Unter IIS 7 bei Windows Server 2008 ist die Standardidentität unter welcher der Workerprocess (w3wp.exe) ausgeführt wird der Netzwerkdienst. Die Identität des Workerprocess wird am Applicationpool bzw. zu Deutsch Anwendungspool eingestellt. Bei IIS 7.5 unter Windows Server 2008 R2 ist dies standardmäßig die Identität ApplicationPoolIdentity.

Diese Einstellung ist noch sicherer als Netzwerkdienst, aber auch etwas problematischer. Denn wie gebe ich dieser Identität Berechtigungen auf die Dateien? Diese Identitäten werden nämlich erst beim starten des jeweiligen Applicationpools von WAS erzeugt und dies wiederum passiert nur, wenn ein Benutzer auf die Website/Anwendung zugreift. Zudem werden die Identitäten immer wieder neu generiert und tauchen weder im AD noch in der lokalen Benutzerverwaltung auf.

Um der ApplicationPoolIdentity Berechtigungen am Dateisystem zu geben müssen Sie zunächst wie gewohnt vorgehen, wenn Sie dann den Benutzer/Gruppe auswählen möchten müssen Sie unter Pfad den lokalen Computer angeben (nicht AD) und dann „IIS APPPOOL\DefaultAppPool“ eintippen, da die Benutzer in der grafischen Auswahl nicht angezeigt werden. Je nachdem um welchen ApplicationPool es sich handelt müssen Sie natürlich „DefaultAppPool“ durch den Namen Ihrer selbst erstellen Applicationpools austauschen.