Powershell Sicherheitswarnung für PS1-Scripts trotz „unrestricted“ loswerden

Das man an der Kommandozeile nahezu keine selbst- oder Fremdgebauten PS-Scripts ausführen kann hat sich mittlerweile herumgesprochen. Das kaum ein Admin seine kleinen Helferchen einzeln und bei jeder Änderung signieren wird ist ebeso offensichtlich.

Umso ärgerlicher, als das der Script-aktive Admin ab und an über den doppelten Boden der Powershell-Ausführungsverhinderung stolpert. Trotz der ExecutionPolicy ohne Restriktionen:

Set-ExecutionPolicy Unrestricted

gibt es doch weiterhin Scriptausführungsverhinderungen die sich in deutlich nicht-aussagekräftigen Fehlermeldung an der Kommandozeile und ISE bemerkbar machen:

powershell-ise-warnung

 

…  an der Shell:

PS C:scripts> .format-c.ps1
Sicherheitswarnung
Führen Sie ausschließlich vertrauenswürdige Skripts aus. Skripts aus dem Internet können zwar nützlich sein,
stellen jedoch auch eine potenzielle Gefahr für Ihren Computer dar. Möchten Sie "C:scriptsformat-c.ps1"
ausführen?
[N] Nicht ausführen  [M] Einmal ausführen  [H] Anhalten  [?] Hilfe (Standard ist "N"):

Automatisierungen jeder Art sind so offensichtlich undurchführbar und auch das deutlichste „Als Stapelverarbeitungsauftrag anmelden“ Recht verpufft an diesem Scriptverhüterli wirkungslos.

Lösung

Seit Windows 8 und dem zugehörigen Server 2012 gibt es im Dateisystem ein magisches Flag, das die (telepatisch festgestellte) Herkunft des Scripts als lokal oder „Siebter Kreis der Hölle“ markiert. Das Flag lässt sich mit einem Klick auf „Zulassen“ in den Dateieigenschaften wie für die lokale Ausführung erwartet zulassen.

powershell-ise-warnung-loesung

Selbstverständlich ist der Vorgang irreversibel, denn die telepatischen Fähigkeiten von Windows sind über jeden Zweifel erhaben. Die Anwesenheit des Flags lässt sich durch kopieren/einfügen beibehalten, durch Snippletkopiererei (ein TOTAL ungewöhnlicher Vorgang beim scripten) reproduzieren und nicht automatisiert beheben.

Windows Phone 8 zeigt neue SMS nicht mehr richtig an

An meinem Lumia Windows-Phone durfte ich gestern einen seltsamen Effekt bewundern: seit einem Absturz (bewundernswerterweise erst der zweite in knapp zwei Jahren, also ungefähr ein tausendstel von meinem Android) kamen neue SMS irgendwie nicht richtig an. Also die Nachrichten kamen schon an, wurden auch ganze normal in dem Infostreifen oben angezeigt, die Kachel aktualisierte die Anzahl und die SMS öffneten sich korrekterweise beim draufdrücken auch … eigentlich alles richtig. Allerdings waren die SMS nicht im SMS-Eingang zu sehen. Zudem meldet der Appstore plötzliche Seltsamkeiten wie „Der Microsoft-Kontodienst ist zurzeit nicht verfügbar.“ und ähnliches.

Lösung: Das Datum und die Uhrzeit kontrollieren. Bei mehr als 15Minuten unterschied zum Server klappt die Synchronisierung nicht (mehr) und bei einem oder mehreren Tagen (bei mir waren es Jahr) Zeitverzug stimmt die Sortierung von SMS und E-Mails nicht mehr – dann sind die neuen Nachrichten halt nicht mehr „oben“ in der Liste. Natürlich gibt es weder eine aussagekräftige Fehlermeldung dazu (das wäre ja auch zuviel verlangt), noch eine zuverlässige Möglichkeit zur automatischen Synchronisation. Letztere ist Provider-, Feature- und offenbar auch launenabhängig; ich habe hier drei Lumias von der Telekom mit dem selben Softwarestand – zwei zeigen die Option „automatisch einstellen an“, eines nicht. Von denen die diese Option anzeigen, funktioniert sie bei keinem zuverlässig. Arrrgh.

#shitlikethis: Die Menschheit fliegt bald zum Mars, aber eine korrekte Uhrzeit auf einem Windows-Handy einzustellen das über Dauertinternet verfügt scheint ein ding der Unmöglichkeit.

Windows Server 2012 schwarzer Bildschirm nach der Anmeldung (sowohl RDS/RDP/Lokal)

Windows Server 2012 und Server 2008/R2 können dem gestandenen Admin ab und an auch mal neue Schrecken einjagen. Praktisch direkt nach der Installation, dem ersten Schwung Updates und vielleicht ein bisschen Rollen-Gewühle bleibt nach einem Reboot der fast-frische Serverbildschirm nach dem Login plötzlich schwarz. Sowohl via RDP als auch bei der loaklen Anmeldung – alles schwarz. STRG+ALT+ENTF zaubert zwar den Taskmanager-Auswahlbildschirm wieder in die sichtbare Realität, mehr aber auch nicht. Ich habe dieses Phänomen jetzt unter VMWare gesehen, unter Hyper-V und auf echter Hardware (selten, aber sowas gibt’s noch). Hardware ist nicht schuld.

Im Eventlog, das via RPC erreichbar ist, offenbart sich der Effekt durch die Warnung:

The Windows logon process has failed to spawn a user application. Application name: . Command line parameters: C:Windowssystem32userinit.exe.

Lösung

Der Fehler liegt irgendwo zwischen der Erzeugung des Twintoken bei der Anmeldung und der UAC-Steuerung. Beides benötigt zur Anzeige rechte für die Interaktive Anmeldung; irgendetwas zerstört offenbar diese (lokal). Daher: Die lokale Gruppe „Benutzer“ verfüg über diese – und bekommt die beiden neuen Mitglieder „Authentifizierte Benutzer“ und „Interaktive Anmeldung“. Das ist remote möglich – reboot und der Bildschirm ist wieder da. Auf einem DC gibt es bekanntlich keine Lokalen Gruppen, daher müssen für solche Server die Domänen-Prinzipale in builtin herhalten. Einfach dort beide Prinzipale einfügen, fertig.

Samba (Debian) – Windows Offlinedateien (Offlinesynchronisation) abschalten

Nach langem Suchen bin ich nun doch fündig geworden. Die Offlinesynchronisation die sich im Windows-Dateiserver so wunderbar einfach pro Freigabe deaktivieren lässt, ist auch unter Linux durchaus konfigurabel.

Die zuständige Option heißt „CSC Policy“ und wird in die smb.conf im jeweiligen Abschnitt der Freigabe eingefügt, in der die Offlinedaten angepasst werden sollen.

In meinem Fall (eine Abas-ERP Freigabe für die Offline-Verfügbarkeit sperren) sieht das in der smb.conf so aus:

csc policy: disable

CSC steht für „Client-side caching“ und bietet analog zur Windows-Einstellung die Varianten „manual“, „documents“, „programs“ und „disable“. Mehr gibt’s in der manpage für Samba3.

Windows und Linux/Samba (3.0.x) Umlaute/Sonderzeichen Darstellung

windows-linux-samba-umlauteAn diesem Phänomen habe ich jetzt eine ganze Weile gebastelt – aber ich bin zufrieden mit der Lösung 🙂

Problem: Umlaute in Dateinamen werden Unter Windows anders angelegt als unter Linux (Shell/Konsole/X) und noch anders unter DOS. Einen brauchbarer Fileserver mit Umlauten in Dateinamen ist unter Samba praktisch nicht zu betrieben.

Lösung: Die meisten Phänomene mit deutschen Umlauten bekommt man in den Griff, indem man das Dateisystem weiterhin in UTF-8 betreibt (es gibt da die wildesten Anleitungen im Netz), aber die Umlaute durch Samba hart in Windows-Ansi (Codeseite 1252) schreiben lässt. Da Windows selber immer abwärtskompatibel zu DOS bleibt (die gute alte CP850), kann man 1252 in der Regel ohne Probleme zu Samba 3.0.3x (smb.conf)  hinzufügen:

[global]
unix charset = UTF-8
dos charset = cp1252

In Samba <3 lautet die Option (hier alternativ mit ISO8859-1 für Windows-ANSI):

character set = ISO8859-1

Ein schnelles

/etc/init.d/smb reload

läd die Config im laufenden Betrieb auch neu und alles ist gut.

AchtungBestehende Dateien werden dadurch natürlich nicht verändert. Schon geschriebene Umlaute bleiben so wirsch wie sie sind. Das gilt auch nur für den Zeichensatz CP1252, also nicht für den ganzen UTF-8 Zeichenraum. Da wird es so auch weiterhin diese lustigen Codierungsfehler geben.

windows-samba-linux

Bestehende falsche Umlaute im Dateinamen nachträglich (bulk) korrigieren

In der Shell kann man solche falsch benannten Dateien natürlich einfach einzeln umbenennen; zum Beispiek mit mv (oder dem rename-alias):

mv seltsamezeichen???.txt seltsamezeichenÄÖÜ.txt

Das Fragezeichen ist hier der Platzhalter für ’nur ein Zeichen, aber jedes‘. Achtung beim Escapen von Leereichen ( ), hier habe ich mich auch schon ein paarmal „Ganz sch?n ge?rgert.txt“ weil ich einen Backslash an der falschen Stelle eingebaut hatte.

Lösung: Bulk umbenennen mit „convmv“. Das ist bei allen großen Distributionen dabei oder im Repository (warum wohl?) und funktioniert so:

convmv -f iso-8859-15 -t utf-8 --notest /foo/bar

Damit werden in /foo/bar alle Dateinamen von ISO-8859-15 nach UTF-8 konvertiert. Mit -r geht das natürlich auch rekursiv.