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.

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.

Download

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...

Als Nutzer des NWC Credential Providers ist es naheliegend, den Registry Key zum Sperren oder Entsperren des NWC Credential Providers über User-defined Tasks der DSMC zu steuern. Verwendet werden kann hier die Komponente reg.exe, die bei allen gängigen Windows Installation im Verzeichnis "%windir%\system32" zu finden ist. Allerdings ist dabei auf x64 Systemen zu beachten, dass die DSMC selbst ein 32-Bit Prozess ist und somit die korrekten Pfadangaben verwendet werden müssen, um die "richtige" 64-Bit reg.exe zu nutzen. Wird nämlich aufgrund der Windows Redirection die 32-Bit reg.exe verwendet, wird im Zielclient auch der 32-Bit Pfad (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node) genutzt, während der Credential Provider seinen Daten im 64-Bit Pfad der Registry ablegt.

Den Ausweg aus der Misere bietet der virtuelle Pfad "%windir%\sysnative" der ausschliesslich für 32-Bit Prozesse sichtbar ist und den Zugriff auf das 64-Bit-System32 Verzeichnis bietet. Die gesamte Konfiguration der 2 User defined Tasks zum entsperren und sperren des NWC Credential Provider sieht für ein x64-System wie folgt aus:

Microsoft hat nun Group Policy Templates für Windows 8 / Windows Server 2012 sowie den Internet Explorer 10 released. Dieses Templates müssen auf allen Pre-Windows 8 Computern eingespielt werden, auf denen Group Policies für Windows 8 /IE 10 konfiguriert werden müssen. 

Die Templates für Windows 8 / Windows 2012 können unter http://www.microsoft.com/en-us/download/details.aspx?id=36991 heruntergeladen werden. 

Die Templates für Internet Explorer 10 können unter http://www.microsoft.com/en-us/download/details.aspx?id=37009 heruntergeladen werden.

In einem älteren Blogartikel habe ich beschrieben, dass mit DSM 7 wieder das alte – aus NetInstall 5.x bekannte – Verhalten eingeführt wurde, dass letztlich die lokale Registry des gemanageten Clients entscheidend ist, ob Pakete installiert oder nicht installiert werden und der Status der zugehörigen Policy-Instanz nicht mehr die entscheidende Rolle spielt, wie das noch unter Enteo v6 der Fall war.

In einem konkreten Kundenszenario wurde nun aber kürzlich ein Verhalten beobachtet, dass Pakete doch nicht neu installiert wurden, wenn zur Reinstallation eines Clients ein Image zurückgespielt wurde und Pakete im Image nicht installiert waren, die vorher über DSM 7 verteilt worden waren und daher eine grüne Policy-Instanz besaßen.

Dies scheint dem beschriebenen Verhalten zu widersprechen. Und in der Tat wurde in diesem Zusammenhang eine Information bekannt, die so vorher nicht dokumentiert war...

 Die Installation der Microsoft Patche wird in den meisten Fällen mit 2 Job Policies auf den Patch Management Execution Packages (PMExec) getriggert. Ein Job steht auf wöchentlich und "Scan only" der andere Job auf täglich und "InstallAndScanIfNeeded". Dies sorgt dafür, dass der Scan eines Systems auf einmal wöchentlich begrenzt ist,die Installation der Patche durch den zweiten job aber relativ zeitnah geschieht. Für den produktiven Betrieb auch eine meist sinnvolle Konstellation. Um die Patch Installation während der OS Installation durchzuführen, wird i.d.R. ein dritter Job geschrieben, der als Schedule "Nach der OS Installation" eingetragen hat. Dies führt zwar zu einem Update der Betriebbsystemkomponenten, lässt aber die folgenden Anforderungen ausser Acht:

1) Alle Patche sollen auf einmal am Stück installiert werden.
2) Patche sollen zu einem definierten Zeitpunkt installiert werden. 
3) Die Patche sollen nach den Paketinstallation laufen. 
4) Es sollen alle Patche die freigegeben sind, auch auf dem PC installiert werden. 
5) Der Benutzer darf sich erst anmelden, wenn alle Patche installiert sind.

Kürzlich kam ein Kunde auf mich zu mit der Frage, warum bei dem Versuch im Discovery ControlCenter das Ergebnis einer Abfrage zu exportieren, die Meldung "Keine zu exportierenden Daten vorhanden." ausgegeben wurde. Das konnte ja nicht sein, da der Kunde die Datensätze markiert und per Kontextmenü-Befehl "Daten exportieren..." den Export angestoßen hatte.

Desweiteren hat mir der Kunde glaubhaft berichtet, dass er ein ähnliches Phänomen bereits häufiger beobachtet hatte, nämlich dass erstellte Reports weniger Rechner-Objekte enthalten hätten, als die entsprechenden Abfragen im ControlCenter. Damit wären die Reports, seiner Aussage nach, unbrauchbar. Es ist verständlich, dass der Kunde hier auf Centennial "sauer war", die Lösung ist jedoch sehr einfach – wenn man sie weiß...