NWC Services Blog
Beim Aufbau einer DSM Umgebung gibt es Computer-Eigenschaften, die grundsätzlich immer wieder implementiert werden. Eine Übersicht der folgenden Eigenschaften, die in jeder Umgebung Sinn machen, sollen folgende vorgestellt werden. Es handelt sich hier um Best-Practices die sich im Laufe der Jahre herauskristallisiert haben.
Jeder, der Rollouts koordiniert und durchführt, kennt folgende Thematik: Wie teste ich am besten das Update einer bestehenden Installation, ohne es unkontrolliert auszurollen.
Eine weit verbreitete Möglichkeit ist, eine Policy unkritisch zu aktualisieren und einzelne Instanzen auf den aktuellen Revisionsstand der Policy zu heben. Das hat natürlich den Nachteil, dass bei einer Neuinstallation eines Clients möglicherweise die neueste Version installiert wird, obwohl diese noch gar nicht durch die Tests durch ist. Auch neue Instanzen verwenden die neueste, noch nicht final getestete, Revision.
Eine weitere Möglichkeit, die man auch in der Praxis findet, ist es, alle Instanzen zu deaktivieren, solange die Tests nicht abgeschlossen sind. Hierbei wird jedoch bei einer Neuinstallation das Paket ggfs. überhaupt nicht ausgeführt. Das kann unter Umständen zu Folgeproblemen führen.
Es gibt noch einen weiteren Lösungsansatz, welcher jedoch relativ unbekannt ist und keinen der zuvor genannten Nachteile mit sich bringt:
Microsoft hat das Verhalten der UAC in Windows Server 2012 verändert. Um die UAC komplett zu deaktivieren, sind jetzt zwei Schritte erforderlich. Als erstes wird wie bereits bei Windows Server 2008 R2 die Benachrichtigungsstufe über die Systemsteuerung heruntergesetzt.
Nach einem Neustart arbeiten Administratoren jedoch nach wie vor Genehmigungsmodus. Anwendungen müssen also explizit „als Administrator“ ausgeführt werden, um wirklich mit administrativen Rechten zu arbeiten zu können.
Unternehmen investieren mittlerweile viel Zeit und Geld darin, Ihre Softwarepakete so zu gestalten, dass nach der Installation eines Computers die Compliance in der DSMC eine reale Aussage über den Zustand der Software auf dem Computer widerspiegelt. Umso schlimmer ist die Tatsache, dass ich wiederholt auf das Problem stoße, dass die Compliance eines Computer der grade frisch installiert wurde, schlichtweg ignoriert und dieser Computer an den Kunden ausgeliefert wird. Konsequenzen sind erhöhte Kosten im Helpdesk durch Folgefehler und auch das (durchaus hohe) Investment in saubere und qualitative Paketierungsprozesse, ist nicht mehr ganz zu rechtfertigen.
Erste Maßnahme ist in diesem Fall Aufklärungsarbeit. Die Compliance Informationen müssen dem technischen Personal, welches für die Installation von Computern zuständig ist, zur Verfügung gestellt werden (in Form von DSM Web, Wimera oder einer Eigenentwicklung). Mehr als einmal habe ich erlebt, dass ein Mitarbeiter ohne Zugriff auf die Informationen in der DSM Datenbank gemahnt wurde, einen Computer mit einer fehlerhaften Installation doch nicht so an seine Kunden auszuliefern.
Wer im Firmenumfeld Bitlocker einsetzt, kann den Schutz der verschlüsselten Geräte durch den Einsatz eines Startup Pins deutlich erhöhen. Ohne Pin greift nur noch der Windows Passwort Schutz. Jedoch gibt es auch beim Einsatz von Startup Pins ein paar Punkte zu bedenken.
1. Wie lange sollte der Pin sein?
2. Haben alle Geräte den gleichen Pin?
3. Wie lässt sich ein Pin ändern, ohne dem User administrative Rechte zu geben?
Eine neue Version von Wimera ist verfügbar und kann auf der NWC-Services Website heruntergeladen werden. Für den Betrieb von Wimera ist ein explizites Lizenfile notwendig, eine Demo Lizenz kann unter Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! oder https://www.nwc-services.de/service/wimera-trial-lizenz-beantragen-2 beantragt werden.
Neben einigen kleineren Neuerungen und Bugfixes sind einige wesentliche neue Features eingeflossen:
- Ein umfangreicher Namensgenerator auf Basis von konfigurierbaren Schemas und der DSM Datenbank
- Verschieben von Computern
- Umbenennen von Computern
- Protokollierung von Reinstall-Vorgängen
- Update von Policyinstanzen
Detaillierte Informationen zu Wimera im Allgemeinen und die Erläuterung der neue Funktionen können unter https://www.nwc-services.de/produkte/wimera in Form von Text, Bild und Videos abgerufen werden. Die Videos sind ebenfalls in YouTube unter dem Suchbegriff "Wimera" oder in meinem YouTube Channel http://www.youtube.com/user/davidkoenig09/videos verfügbar.
Hallo alle zusammen,
nach fast 3 Jahren hat der V6 Adminhelper nun endlich ein Update bekommen. Im Zuge dessen hat er auch direkt einen neuen passenderen Namen bekommen.
Nach der Installation starten Sie den neuen DSM Distrihelper einfach über das Startmenü wie bisher auch.
Eine kleine Bedienungsanleitung liegt der Installation bei. Ein Changelog ist im Anhang der Anleitung zu finden.
Wenn sich der erste User an einem frisch installierten Windows 8 Client anmeldet, läuft erstmal eine langwierige Startanimation. Hierbei werden ein paar neue Funktionen von Windows 8 in einem Tutorial erklärt. Diese mag für den ein oder andere Privat PC „ganz nett“ sein, kann jedoch im Firmenumfeld eher nerven, da das Tutorial für jeden User angezeigt wird. Auch wenn ein Profil gelöscht wird.
Sollte man sich entscheiden diese „Funktion“ zu deaktivieren, gibt es zwei Möglichkeiten.
Entweder über eine GPO oder über die Registry. Für die GPO werden die Windows 8 / Server 2012 ADM Templates benötigt.
Der Service Installer in DSM wird eingesetzt, um Software im Hintergrund zu installieren.
Viele Kunden stört es, dass der End User dabei nicht sehen kann, was auf seinem Rechner installiert wird.
Eine Möglichkeit wäre jetzt natürlich, Pakete nur noch durch den AutoInstaller ausführen zu lassen.
Die Idee sollte jedoch schnell wieder verworfen werden, wenn Clients auch ohne angemeldeten Benutzer verwaltet werden sollen. Dies ist ausschließlich über den Service Installer möglich. Out of the Box könnte man sich die Balloon Tips zu Nutze machen. Allerdings zeigen die nur an, wenn der Service Installer gestartet wird und falls ein Paket fehlschlägt.
Vielleicht also auch nicht die charmanteste Lösung. Zum Glück bietet DSM 7.2 einige tolle Möglichkeiten um sich eigene Benachrichtigungen zu bauen.
Die meisten Leser dieses Blogs dürften sich bereits mehr oder weniger intensiv mit FrontRange DSM (oder Vorgängerversionen davon) beschäftigen. Daher wird im Regelfall auch die Möglichkeit bekannt sein, Einstellungen aus der Konfigurationstabelle lokal zu überschreiben.
Das bekannteste und sicherlich auch meistgenutzte Szenario ist dabei, das in der Konfigurationstabelle eingestellte Loglevel lokal so zu modifizieren, dass ausführlichere und damit aussagekräftigere Logs erzeugt werden. Diese geschieht in der Regel durch Aufruf des NetInstall Monitors (nimoni.exe) und Auswahl des Menübefehls Protokolldatei-Optionen > Detailtiefe der Protokollierung einstellen. Dass durch diese Aktion im Endeffekt nur der Registrywert LogLevel im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\NetSupport\NetInstall\LogFileSettings gesetzt wird, ist auch noch geläufig. Dieser „überschreibt“ dann den zentral über die NCP-Datei vorgegebenen Wert NcpLogLevel.
Nun könnte man die Hoffnung haben, dass sich alle über die Konfigurationstabelle getroffenen Einstellungen auf diese Art und Weise überschreiben lassen. Dem ist jedoch (leider) nicht so...