In einer Domäne ist es recht einfach, einen Rechner remote heruterzufahren. Einfach an der Kommandozeile

eingeben und sofern der ausführende Benutzer innerhalb der Domäne die benötigten Rechte hat, führt der angegebene Rechner den Befehl klaglos aus.

Nicht so trivial ist das Szenario bei Rechnern im z.B. heimischen Umfeld, wo nur selten eine zentrale Benutzerverwaltung aktiv sein dürfte:

Als ersten Lösungsansatz stößt man meistens auf den Hinweis, sich zuerst mittels einer administrativen Netzerkverbindung gegenüber dem herunterfahrenden Rechner zu authentifizieren, wofür sich z.B. die Freigabe IPC$ anbietet:

Unter Windows XP war dies schon vollkommen ausreichend, unter Windows Vista und Windows 7 wird allerdings weiterhin der Zugriff verweigert. Wie der KnowledgeBase-Artikel “Description of User Account Control and remote restrictions in Windows Vista” erklärt, handelt es sich hierbei um ein Feature und keinen Bug:

When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection by using the net use * \remotecomputer\Share$ command, for example, they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks.

Um auch über das Netzwerk verbundenen, lokalen Benutzern entsprechende Berechtigungen zu erteilen, ist das setzen des Registry-Schlüssels “LocalAccountTokenFilterPolicy” innerhalb des Pfades

notwendig, dieser muß als DWORD mit dem Wert 1 angelegt werden.

Wirft man einen Blick in die Verbrauchsanzeige eines Smartphones, so fällt auf, daß neben dem Display vor allem das ständige Offenhalten der Daten-Verbindung am Akku nagt. Sofern man damit leben kann, daß nicht jede Nachricht sekundengenau aufschlägt, lässt sich genau an dieser Stelle ansetzen und die mobile Datennutzung zeitlich steuern was die Standby-Zeiten deutlich verbessert.

Hierzu können z.B. in Llama, den “Location Profiles für Android” drei Regeln angelegt werden, welche die automatische Steuerung übernehmen:

Mobiles Netz automatisch aus

• Wenn sich der Bildschirm ausschaltet

• Wenn Mobildaten aktiviert sind

• um 2 Minuten verzögern und dann Datennetzmodus deaktivieren

Diese Regel sorgt dafür, daß bei ausgeschaltetem Display und eingeschalteten Mobildaten diese nach 2 Minuten automatisch deaktiviert werden.

Mobiles Netz automatisch ein

• Wenn sich der Bildschirm ausschaltet

• Wenn Mobildaten deaktiviert sind

• um 13 Minuten verzögern und dann Datennetzmodus aktivieren

Diese Regel ist das Gegenstück zu “Mobiles Netz automatisch ein” und sorgt dafür, daß bei ausgeschaltetem Display und Mobildaten diese nach 13 Minuten aktiviert werden.

Mobiles Netz mit Bildschirm ein

• Wenn sich der Bildschirm einschaltet

• Wenn Mobildaten deaktiviert sind

• Datennetzmodus aktivieren

Die letzte Regel dient dazu im Bedarfsfall zusammen mit dem Bildschirm auch die Mobildaten einzuschalten.

Natürlich sind der künstlerischen Freiheit beim Gestalten der Regeln keine Grenzen gesetzt. So kann zum Beispiel über eine Llama-Variable die automatische Steuerung ortsbezogen ein- oder ausgeschaltet oder auch eine Ruhezeit definiert werden, in der die Datenverbindung überhaupt nicht aktiviert wird.

Standardmäßig ist bei Debian die NumLock-Funktion auf der Konsole nach dem Boot deaktiviert. Ist dies bei physikalischen Servern in der Regel kein größeres Ärgernis, da man nur selten direkt an der Konsole arbeitet und noch seltener neu startet, kann es bei einer auf dem lokalen Arbeitsplatz betriebenen virtuellen Maschine nerven: je nach verwendeter Virtualisierungslösung wird beim Boot der VM auch unter Windows die NumLock-Taste ausgeschaltet, was mehr als nervig ist.

bis Debian 7 “Wheezy”:

Die Lösung ist recht einfach - ein Skript namens “enablenumlock”

ins Verzeichnis “/etc/init.d” gepackt, ausfrührbar gemacht und dann mittels

in den Systemstart eingebunden. Beim nächsten Boot wird NumLock automatisch aktiviert.

ab Debian 8 “Jessie”:

Durch den Umstieg von sysvinit zu systemd funktioniert die oben geschilderte Lösung nicht mehr zuverlässig. Einfache Abhilfe schafft der Ansatz aus dem archlinux Wiki, welcher dem Dienst “getty@.service” zwei Zeilen hinzufügt:

Nach einen Neustart ist Numlock dann wieder standardmäßig aktiviert. Wer sich an dem angezeigten Hint stört, findet im Wiki auch eine Möglichkeit, dessen Ausgabe zu unterdrücken.

Interessant, was der Auswahlschirm zum “Exchange 2013 Bereitstellungs Assistent” so an Auswahloptionen bietet:

“Exchange 5.105,40 cm”? Klingt interessant!

Das Java Runtime Environment (JRE) hat sich in den letzten Jahren einen unrühmlichen Ruf als potentielles Einfallstor für Schädlinge aller Art ins System erworben, so daß - sofern nicht unbedingt benötigt - das JRE entweder erst gar nicht installiert oder zumindest im Browser deaktiviert werden sollte.

Um so ärgerlicher ist, wenn ohne entsprechende Information oder Abfrage eine veraltete JRE-Version über Drittsoftware auf den Rechner gelangt:

Im aktuellen Fall ist dies eine Adobe Photoshop CS5-Installation, in deren Verlauf im Ordner “C:\ProgramData\Adobe\CS5\jre” ein zum Installationszeitpunkt hoffnungslos veraltetes JRE 6.0.18 aus dem März 2010 abgelegt wird und die auch nach Einspielen aller für Photoshop CS5 erhältlichen Patches den ursprünglichen Versionsstand beibehält.

Umso ärgerlicher ist, daß das JRE weder in der Systemsteuerung angezeigt noch über diese aktualisiert oder deinstalliert werden kann, zumal fraglich ist, ob Photoshop unter Windows überhaupt ein JRE benötigt: laut einer kurzen Recherche mittels Google scheint dieses ausschließlich für die Flash-Kompontente der Creative Suite vorausgesetzt zu werden.

Und tatsächlich: nach Zippen und anschließendem Löschen des Ordners scheint Photoshop weiterhin problemos zu funktionieren, so daß zumindest auf diese Sicherheitslücke getrost verzichtet werden kann.