Prüfmöglichkeiten

Die neuen Vorbedingungen sind „universal“ einsetzbar und können folgende Eigenschaften prüfen:

• Registrierung
• WMI
• Datei
• Ordner

Ideen

Nachfolgend möchte ich nicht auf alle Möglichkeiten eingehen, euch jedoch ein paar Anregungen geben, die ich schon genutzt habe.

• Ist das .NET Framework in einer bestimmten Version oder neuer installiert?
• Hat das Windows einen bestimmten Versionsstand?
• Handelt es sich um einen bestimmten Hardwaretyp?
• Ist eine VPN Verbindung aktiv?

Ihr könnt auch mehrer Bedingungen „UND“ oder „ODER“ verknüpfen, wie ich das schon für Treiber gemacht habe. Vielleicht habt ihr auch coole Ideen oder Einsatzmöglichkeiten für Euch erkannt und wollt diese hier teilen. Ich bin gespannt und freue mich auf Feedback!

Beispiel

Zumeist habe ich bis dato auf Registry Werte geprüft, wie beim nachfolgenden detaillierteren Beispiel: „Ist das .NET Framework in einer bestimmten Version oder neuer installiert?“

Hier nochmals die Werte für eine einfachere Eingabe:

Registry Wert vergleichen
Registry Pfad: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\V4\Full
Wert Name: Release
Vergleichstyp: Nummer
Operator: Größer als oder gleich
Wert: 461808

Übertragen von Vorbedingungen

Die Vorbedingungen, wie z.B. eine .NET Framework Voraussetzung beim UEM Agent Paket, müssen bei einer neuen Versionen eines Paketes nicht auch erneut eingeben werden. Zur einfachen Übernahme der vorhandenen Vorbedingungen könnt ihr die Funktion: „Vorbedingungen kopieren“ und „Vorbedingungen einfügen“ nutzen.

Matrix42 Hilfe

Da ich hier jetzt nicht alle Möglichkeiten eingehen werde und eingegangen bin, möchte ich Euch den Eintrag in der Matrix42 Hilfe natürlich nicht vorenthalten.

Der Beitrag Erweiterte Paketvoraussetzungen erschien zuerst auf Workplace Management Blog.

Möglichkeit 1 – Der Endbenutzer darf seine Netzwerkeinstellungen verändern Ist ein Benutzer Mitglied der Gruppe „Network Configuration Operators“, so kann er die Netzwerkeinstellungen selbst verändern.

Möglichkeit 2 – Der Endbenutzer darf lokale Drucker installieren Damit ein Windows Benutzer auch lokale Drucker installieren darf, ist die Konfiguration einer Windows Gruppenrichtlinie (GPO) notwendig. Gruppenrichtlinien sind zumeist eine Veränderung von Registry Werten. Beispiele zur Veränderung der Registry sind unten aufgeführt.

Hier geht es zu weiterführenden Informationen zu diesem Thema:
Configure Computer Policy to Allow Non-Administrators to Install Specific Devices
http://technet.microsoft.com/en-us/library/cc725772(v=ws.10).aspx#bkmk_1

System-Defined Device Setup Classes Available to Vendors (Windows Drivers)
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx

Hier ein Registry Auszug, um dem Endbenutzer zu erlauben Drucker zu installieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions]
 "AllowUserDeviceClasses"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses]
 "1"="{4D36E979-E325-11CE-BFC1-08002BE10318}"

Der Beitrag Druckerinstallation für Windows Benutzer erschien zuerst auf Workplace Management Blog.

Dieser Problematik lässt sich zumeist in 3 Ursachen unterscheiden und somit mit unterschiedlichen Lösungen beheben. Lesen Sie dazu den Artikel bis zum Ende, damit sie sehr zielgerichtet ihr Problem einkreisen können.

Mögliche Ursachen für das Problem

1. Die Netzwerkkarte wurde nicht installiert
2. Der Benutzer für den Domain-Join
3. Namensauflösung

Die Netzwerkkarte wurde nicht installiert.

Diese Problematik kann am einfachsten festgestellt werden, in dem man einen Blick auf den Geräte-Manager des betroffenen Gerätes wirft. Häufig bleibt dann auch die Betriebssystem Installation am Ende „hängen“, wenn die Agent.bat bzw. EmpirumAgent.bat aufgerufen werden soll. Fehler 2 bzw. 5 – Die zuvor beschriebene BAT Datei kann nicht gefunden werden oder der Zugriff darauf ist nicht möglich.

Der Benutzer für den Domain-Join

Rund um den Benutzer für den Domain-Join kann es mehrere Probleme geben. Zuerst muss in der Betriebssystemvorlage nachgesehen werden, welcher Benutzer diese Aufgabe wahrnimmt. Häufig wird auch der „Diskettenbenutzer“ mit der entsprechenden Aufgabe versehen. Dann muss man in dem Active Directory oder anderem Verzeichnisdienst nachsehen, ob der Benutzer die erforderlichen Berechtigungen besitzt. Dem Benutzer können auf unterschiedliche Art und Weise die Berechtigungen gegeben werden. Manche machen es sich einfach und der Benutzer ist „Domänen-Administrator“. Das ist für meinen Geschmack etwas zu viel des Guten, aber das muss jeder Verantwortliche für sich entscheiden. Eine weitere Möglichkeit besteht darin den Benutzer zu den „Konten Operatoren“ hinzuzufügen, oder gar nur die Sicherheitseinstellung „Hinzufügen von Arbeitsstationen zur Domäne“ für den betroffenen Benutzer zu setzen. Das Wirken dieser Berechtigungen muss in dem Verzeichnisdienst an der richtigen Stelle überprüft werden.

Namensauflösung

Häufig verhindert auch die Namensauflösung den Domain-Join. Empirum versucht den Domain-Join durch Nutzung des „NetBIOS“ Domain Namens in den Computer Eigenschaften. Schlägt dies fehl, so kann man den Domain-Join während der Betriebssystem-Installation auch durch Angabe des FQDNs durchführen. Dazu kann man die Variable „FQDN“ eines Computers setzen. Dies geht über das Setzen von Variablen auf einem Computerobjekt in der Empirum Management Console (rechte Maustaste auf ein Computerobjekt, Variablen, FQDN, …) oder ab der Empirum Version 14.2 auch über die Eigenschaften eines Computers. Funktioniert der Domain-Join über diesen Weg, so muss man die Variable nicht für jeden Computer einzeln setzen, sondern kann die Variable auf eine entsprechende Konfigurationsgruppe setzen und mittels „Zwangsvererbung“ jedem Computer zuweisen.
Hinweis: Setzen sie nicht den FQDN Namen in dem Eingabefeld „Domäne“ bzw. „Domain“ der Computereigenschaften! Dies hat auch Auswirkungen auf die Softwareverteilung, die dann nach der Betriebssystem-Installation nicht mehr funktionieren wird!

Wie finde ich den Grund für „mein“ Problem?

Wenn Sie gezielt ihr Problem lösen möchten, so schauen sie auf dem betreffenden Computer in die Datei „%WINDIR%\Debug\NetSetup.log“. Hier lässt sich das Problem für den nicht funktionierenden Domain-Join ergründen. Falls Sie Probleme beim Lesen und Interpretieren der Datei haben, so können sie gerne Kontakt mit mir aufnehmen.

Achtung beim nächsten Versuch …

War es nicht die Netzwerkkarte, so wird der Computer am Ende der Betriebssystem-Installation inventarisiert und überschreibt ihnen die angegebene Domäne mit der „Arbeitsgruppe“. Dies führt häufig zu Folgefehlern. Also aufgepasst beim weiteren Versuch nach einer durchgeführten Änderung.

Der Beitrag Domain-Join während der Betriebssystem-Installation funktioniert nicht erschien zuerst auf Workplace Management Blog.