NIERO@net e.K. – Corporate Blog

Ihr Weg zu strategischer SMB IT beginnt mit Managed Services

Lessons Learned: automatische (unbeaufsichtigte) Installation des Java Runtime Environment unterstützt keine UNC-Pfade im den Pfad zur Konfigurationsdatei

Aufgrund eines Fehlers in unserem Patchmanagement waren wir kürzlich gezwungen, das Java Runtime Environment mit “traditionellen” Mitteln unbeaufsichtigt auf einigen verwalteten Clients zu installieren.

Das Verfahren wird von Oracle in der Java Documentation gut beschrieben.

Sowohl das das JRE-Windows-Offlineinstallationsprogramm, als auch die Konfigurationsdatei für das Installationsprogramm haben wir auf einer administrativen Netzwerkfreigabe abgelegt.

Für die eigentliche Installation benutzen wir die folgende Syntax:

\\[DeploymentServer]\[DeploymentShare]\[jre] INSTALLCFG=\\[DeploymentServer]\[DeploymentShare]\configuration_file.txt

In unserem Test verursachte dies den folgendem Fehler:

—————————
Java-Installation nicht abgeschlossen
—————————
Java kann nicht installiert werden
In den folgenden Switches sind Fehler vorhanden:
"INSTALLCFG=\\[DeploymentServer]\[DeploymentShare]\configuration_file.txt";.
Stellen Sie sicher, dass die Befehle gültig sind, und versuchen Sie es erneut.
—————————

Auch das Tauschen der Dateiendung .txt durch .properties, bzw. .cfg führte zum gleichen Fehler.

Die Konfigurationsdatei funktionierte jedoch ordnungsgemäß auf der lokalen Maschine.

Dies ergab den Ausschlag es einmal mit einem verbundenen Netzwerklaufwerk zu probieren. Auch hier funktionierte die automatische (unbeaufsichtigte) Installation wie gewünscht.

Hieraus konnten wir nun den Schluss ziehen, dass der Pfad der Konfigurationsdatei für das Installationsprogramm einen Laufwerksbuchstaben voraussetzt und keine UNC-Pfade unterstützt.

Die Lösung war nun die unbeaufsichtigte Installation ohne Konfigurationsdatei zu parametrisieren:

\\[DeploymentServer]\[DeploymentShare]\[jre] INSTALL_SILENT=ENABLE AUTO_UPDATE=ENABLE REBOOT=DISABLE SPONSORS=DISABLE REMOVEOUTOFDATEJRES=1

Dieses Vorgehen war erfolgreich.


Aktuelles finden Sie stets auch auf der Website, oder auf Twitter.

NIERO@net e.K. versteht sich als “Solution Innovator” und “Enterprise Architect”, indem wir unser Angebot auf Management Consulting, Mobile- /Cloud-Lösungen, Geschäftsprozess-Lösungen und Managed Services verlagern. Lesen Sie unsere Corporate Statements und erfahren Sie, wofür NIERO@net e.K. steht.

Experten machen den Unterschied: Lesen Sie, weshalb die Zusammenarbeit mit einem Mitgliedsunternehmen der MSPAlliance die Wettbewerbsfähigkeit Ihres Unternehmens erhöht.

Sollten Sie aktive Unterstützung benötigen, können Sie sich jederzeit an uns wenden und nach unseren Managed Services, Managed Public Cloud Solutions, Hosted Software Services und Hosted System Services für kleine und mittelständische Unternehmen in der Metropolregion Hamburg fragen.

Unsere Aufgabe ist es, Ihnen bei der Verwaltung Ihrer Netzwerke zu helfen, damit Sie sich um Ihr Geschäft kümmern können.

Lassen Sie uns Ihnen helfen, die Methoden und Richtlinien zu entwerfen, die Ihr Unternehmen noch erfolgreicher machen.

Unser Ziel: “Enterprise Solutions and Quality for Small Business”

Unsere Kerndienste: Managed Networks – Managed Workstations – Managed Email – Managed Cloud – Managed Continuity – Managed Security – Managed Mobile – Managed Backup & Disaster Recovery

31. Mai 2017 Posted by | Lessons learned: Notes from the field | , , , , , , , , , | Kommentare deaktiviert für Lessons Learned: automatische (unbeaufsichtigte) Installation des Java Runtime Environment unterstützt keine UNC-Pfade im den Pfad zur Konfigurationsdatei

MS15-094: Fehler bzgl. der inetres.admx beim Öffnen von Gruppenrichtlinien mit der Gruppenrichtlinien-Verwaltungskonsole

Wir hatten vor Kurzem das Problem, dass wir unter Windows Server 2008 R2 beim versuch Gruppenrichtlinien zu bearbeiten, bzw. einen Ergebnissatz anzuschauen die folgende Fehlermeldung bekamen:

Fehler beim Analysieren der
Ressourcen-$ (String. SiteDiscoveryEnableWMI) ‚ (Verweis durch das Attribut DisplayName) konnte nicht gefunden werden.
Datei C:\Windows\PolicyDefinitions\inetres.admx, Zeile 34686 Spalte 235

Nach kurzer Recherche fanden wir auf dem Blog des japanischen IE-Teams die Lösung.

Microsoft hat es augenscheinlich versäumt, mit dem am 09. September 2015 veröffentlichtem MS15-094, die benötigten adml-Dateien für das aktualisierte admx-Template auszuliefern.

Wir konnten das nach Lesen des Blogbeitrags auch insofern nachvollziehen, als dass unter “%windir%\PolicyDefinitions” zwar die “inetres.admx” und die “inetres.adml” für en-US das Datum vom 13.09.2015 trugen, allerdings nicht die “inetres.adml” für de-DE. Diese war noch aus Juli, also von der letzten Aktualisierung.

Die Japaner empfehlen den Austausch der entsprechenden lokalisierten “inetres.adml” und der “inetres.admx” von einem Windows 8.1 / Windows Server 2012 R2. Auf diesen Plattformen tritt der Fehler nicht auf.

Bei uns reichte es, die deutsche Sprachdatei auszutauschen.

Wie die Japaner weiter ausführen, ist der Fehler wohl in Redmond bekannt und soll mit einem der nächsten Updates beseitigt werden.

Hier die Bing-Übersetzung des Blogbeitrags als Referenz: http://www.microsofttranslator.com/bv.aspx?from=&to=de&a=http%3A%2F%2Fblogs.technet.com%2Fb%2Fjpieblog%2Farchive%2F2015%2F09%2F14%2F3654614.aspx


Aktuelles finden Sie stets auch auf der Website, oder auf Twitter.

NIERO@net e.K. versteht sich als “Solution Innovator” und “Enterprise Architect”, indem wir unser Angebot auf Management Consulting, Mobile- /Cloud-Lösungen, Geschäftsprozess-Lösungen und Managed Services verlagern. Lesen Sie unsere Corporate Statements und erfahren Sie, wofür NIERO@net e.K. steht.

Experten machen den Unterschied: Lesen Sie, weshalb die Zusammenarbeit mit einem Mitgliedsunternehmen der MSPAlliance die Wettbewerbsfähigkeit Ihres Unternehmens erhöht.

Sollten Sie aktive Unterstützung benötigen, können Sie sich jederzeit an uns wenden und nach unseren Managed Services, Hosted Software Services und Hosted System Services für kleine und mittelständische Unternehmen in der Region Hamburg fragen.

Unsere Aufgabe ist es, Ihnen bei der Verwaltung Ihrer Netzwerke zu helfen, damit Sie sich um Ihr Geschäft kümmern können.

Lassen Sie uns Ihnen helfen, die Methoden und Richtlinien zu entwerfen, die Ihr Unternehmen noch erfolgreicher machen.

Unser Ziel: “Enterprise Solutions and Quality for Small Business”

Unsere Kerndienste: Managed Networks – Managed Workstations – Managed Email – Managed Cloud – Managed Continuity – Managed Security – Managed Mobile – Managed Backup

23. September 2015 Posted by | Lessons learned: Notes from the field | , , , , , , , , , , | Kommentare deaktiviert für MS15-094: Fehler bzgl. der inetres.admx beim Öffnen von Gruppenrichtlinien mit der Gruppenrichtlinien-Verwaltungskonsole

Error 0x80070569 (‚VM_NAME‘ failed to start worker process: Logon Failure: The user has not been granted the requested logon type at this computer.)

Im Zuge eines Migrationsprojekts bei einem unserer Klienten haben wir den o.g. Fehler erhalten, nachdem wir den neuen Hyper-V Host der Domäne als Mitgliedsserver hinzugefügt haben.

Das fiel auch erst auf, nachdem wir den Server aus seinem Container “Computers” in seine OU verschoben haben und die VMs heruntergefahren haben, um einige Konfigurationsänderungen vorzunehmen.

Diese konnten wir weder durchführen, noch die VMs wieder starten.

Schlussendlich stellte sich heraus, dass eine fehlgeplantes GPO auf Domänenebene hieran Schuld war, indem einigen bestimmten Accounts das Recht “Logon as a Service” gegeben wurde. Dieser historisch entstandene Sachverhalt führte dann zwangsläufig dazu, das “NT Virtual Machine\Virtual Machines” auf dem Hyper-V Host dieses Recht nun eben nicht hatte.

Der Grund für unsere Schwierigkeiten war also, dass die lokale Richtlinie durch die Domänenrichtlinie überschrieben wurde.

KB 2779204 beschreibt dass Problem:

This issue occurs because the NT Virtual Machine\Virtual Machines special identity does not have the Log on as a Service right on the Hyper-V host computer. Usually, the Virtual Machine Management Service (VMMS) replaces this user permission at every Group Policy refresh to ensure it is always present. However, you may notice that Group Policy refresh does not function correctly in certain situations.

Die Lösung hieß demnach, dieses GPO vom Host aus zu bearbeiten, den entsprechenden Eintrag hinzuzufügen und ein “gpupdate /force” auszuführen.

Dieser Vorfall liefert zum Ende auch Diskussionsstoff auf die Frage “domain join or not domain join?”. Microsoft empfiehlt das Hinzufügen von Hyper-V-Hosts zur Domäne, währen Kollegen, wie beispielsweise Philip Elder, es vorziehen den Host in der Workgroup zu belassen.

Wie man hier sieht, kann der “Domain Join” durchaus seine Fallstricke haben.


Aktuelles finden Sie stets auch auf der Website, oder auf Twitter.

NIERO@net e.K. versteht sich als “Solution Innovator” und „Enterprise Architect“, indem wir unser Angebot auf Management Consulting, Mobile- /Cloud-Lösungen, Geschäftsprozess-Lösungen und Managed Services verlagern. Lesen Sie unsere Corporate Statements und erfahren Sie, wofür NIERO@net e.K. steht.

Experten machen den Unterschied: Lesen Sie, weshalb die Zusammenarbeit mit einem Mitgliedsunternehmen der MSPAlliance die Wettbewerbsfähigkeit Ihres Unternehmens erhöht.

Sollten Sie aktive Unterstützung benötigen, können Sie sich jederzeit an uns wenden und nach unseren Managed Services, Hosted Software Services und Hosted System Services für kleine und mittelständische Unternehmen in der Region Hamburg fragen.

Unsere Aufgabe ist es, Ihnen bei der Verwaltung Ihrer Netzwerke zu helfen, damit Sie sich um Ihr Geschäft kümmern können.

Lassen Sie uns Ihnen helfen, die Methoden und Richtlinien zu entwerfen, die Ihr Unternehmen noch erfolgreicher machen.

Unser Ziel: “Enterprise Solutions and Quality for Small Business”

Unsere Kerndienste: Managed Networks – Managed Workstations – Managed Email – Managed Cloud – Managed Continuity – Managed Security – Managed Mobile – Managed Backup

15. April 2015 Posted by | Hyper-V, Lessons learned: Notes from the field | , , , , , | Kommentare deaktiviert für Error 0x80070569 (‚VM_NAME‘ failed to start worker process: Logon Failure: The user has not been granted the requested logon type at this computer.)

Verteilen von EMET via Gruppenrichtlinien

Die aktuelle 0-Day-Lücke im Internet Explorer bringt uns zu der Frage, wie man EMETv3 mangels SCCM via Group Policies verteilt.

Das Benutzerhandbuch von EMET beschreibt nur einen kleinen Teil des Weges:

EMET 3.0 comes with group policy support. When you install EMET, EMET.admx and EMET.adml files are also installed to the “Deployment\Group Policy Files” folder. These files can then be copied onto \Windows\PolicyDefinitions and \Windows\PolicyDefinitions\en-US folders respectively. Once this is done, EMET system and application mitigation settings can be configured via Group Policy.

There are three sets of policies that EMET exposes. Below is a description of each. More information can be found at the policy editor for each policy.
1. System Mitigations: Named ASLR, DEP and SEHOP, these policies are used to configure system mitigations. Please note that modifying system mitigation settings may require a reboot to be effective.
2. Default Protection Profiles: There are three: Internet Explorer, Office applications and other popular software. Protection Profiles are pre-configured EMET settings that cover common home and enterprise software. Apply these policies to enable them.
3. Application Settings: This leads to a freeform editor where you can configure any additional applications not part of the default protection profiles. The syntax is application executable name followed by an optional list of mitigations you don’t want to enable. If you don’t specify any mitigation, all seven EMET application mitigations will be enabled.

Once you enable EMET Group Policies, they will be written out to the registry at HKLM \SOFTWARE\Policies\Microsoft\EMET. To make them effective in EMET, you have to run the following command using the EMET Command Line Tool.

EMET_Conf –refresh

Please note that when you apply a Group Policy in Windows, there is often a short delay before Group Policy writes them out to the registry.
You can run this command separately, at startup or at logon time according to your deployment strategy.
To view the Group Policy controlled EMET settings, run the following command using the EMET Command Line Tool.

EMET_Conf –list

The settings controlled by Group Policy start with the ‘>’ character. In this example, we have 2 settings and the Internet Explorer one has been configured by Group Policy, while the program.exe setting has been configured either through the EMET Graphical User Interface or the EMET Command Line Tool.

It is important to note that the settings configured via Group Policy take precedence over the settings configured locally using the EMET GUI or the EMET Command Line Tool. Also, Group Policy controlled settings can only be modified or deleted via Group Policy. For example, running

EMET_Conf –delete_all

in the situation above would only delete the program.exe settings, and leave Internet Explorer settings intact.”

Wir haben aber sicherlich mehrere Computer auf denen wir EMET installieren wollen und – wie man oben sieht – müssen wir zur Übernahme des vorher konfigurierten EMET-GPO ein “EMET_Conf –refresh” auf jeder Maschine ausführen. Genau das ist die Krux.

Die Lösung ist – neben einem Startskript – das kleine Tool psexec von Sysinternals. Mark erklärt in einem Artikel die Benutzung.

Angemerkt sei hier, das “EMET-Conf –refresh” als Administrator ausgeführt werden muss.

Welche Schritte haben wir nun?

1. Herunterladen von EMET

2. Installation von EMET auf einem Referenzcomputer

3. Konfiguration des EMET-GPO:

Diese befinden sich – wie oben geschrieben – im Ordner /EMET/Deployment/Group Policy Files und müssen in den Ordner /Windows/PolicyDefinitions kopiert oder besser in einen Central Store unter sysvol.

EMET GPO

Weiterlesen

21. September 2012 Posted by | Lessons learned: Notes from the field | , , , , , , , , , , , , , , , , , , | Kommentare deaktiviert für Verteilen von EMET via Gruppenrichtlinien

"Achtung: Beim Validieren des Zertifikats, das zum Erstellen dieser Signatur verwendet wurde, sind Probleme aufgetreten." — "Achtung: Die Zertifikatssperrliste, die zur Überprüfung des Signaturzertifikats benötigt wird, ist entweder nicht verfügbar oder nicht mehr gültig."

Ausgangslage: Microsoft Office 2010 Professional Plus SP1 32-Bit auf Windows 7 Ultimate SP1 64-Bit unter Benutzung einer SigntrustCard des Trustcenter Deutsche Post Com GmbH – Signtrust zusammen mit Openlimit CCSign.

Fehlermeldungen in Outlook: "Achtung: Beim Validieren des Zertifikats, das zum Erstellen dieser Signatur verwendet wurde, sind Probleme aufgetreten." und "Achtung: Die Zertifikatssperrliste, die zur Überprüfung des Signaturzertifikats benötigt wird, ist entweder nicht verfügbar oder nicht mehr gültig."

Lösung: Es fehlt in der Registry unter HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Security der Wert “UseCRLChasing”.

Registry

Das entspricht der Gruppenrichtlinien-Einstellung “Abrufen von Zertifikatssperrlisten” in den Benutzereinstellungen

gpo1

Mehr hierzu findet man in der TechNet unter http://technet.microsoft.com/de-de/library/cc179061.aspx.

1. Juni 2012 Posted by | Lessons learned: Notes from the field | , , , , , , , , , , , , | Kommentare deaktiviert für "Achtung: Beim Validieren des Zertifikats, das zum Erstellen dieser Signatur verwendet wurde, sind Probleme aufgetreten." — "Achtung: Die Zertifikatssperrliste, die zur Überprüfung des Signaturzertifikats benötigt wird, ist entweder nicht verfügbar oder nicht mehr gültig."