xola

Hallo, denke, wir haben das Problem gefunden. Wir hatten Device Guard aktiviert, wie von Microsoft empfohlen. Nach dem Deaktivieren haben wir keine Probleme mehr. Interessant ist, dass wir die Treiber (HPInstaller.exe) als MDT Application installieren lassen konnten, und damit das Problem ebenso gelöst werden konnte. Da hat also Device Guard keine Einwände gehabt. Grüße, xola

Hallo zusammen, für einen Kunden haben wir eine Analyse seiner bestehenden Computer Group Policies durchgeführt. Das Ergebnis haben wir konsolidiert und in 11 neue Policies logisch unterteilt. Es wurde eine neue OU angelegt (die am Namen erkennbar ist, nennen wir sie "Neuwelt") und die 11 neuen Policies dorthin verlinkt. User Policies sind nicht mit inbegriffen. Ständiger Abgleich mit der Altwelt bestätigt, dass es effektiv keine nennenswerte Unterschiede gibt. Zumindest keine, die auf unser Problem schließen lassen. Zur Neuinstallation der Clients wird MDT benutzt. Wir verwenden momentan noch Windows 10 1709. Testweise sitzen in der neuen OU zwei Maschinen. Eine (Dell) lässt sich ohne Probleme installieren. Die zweite (HP) zwar auch, hat aber in interessantes Phänomen. Zu Beginn werden alle Treiber MDT-seitig Out-of-the-Box geladen. Genau so wie es sein soll. Dann kommt irgendwann im Prozess ein Reboot, wonach das das UMTS Modul nicht mehr erkannt wird und nur noch als einzelnes Gerät "Unbekannter USB-Controller" auftaucht. Wir können nun auch nicht mehr die Treiber installieren, egal in welcher Konstellation, es schlägt fehl. Und das, bevor überhaupt eine Applikation aus MDT heraus installiert wird. Verschiebe ich den HP wieder in die Altwelt, und installiere ihn neu, funktioniert das tadellos wie gewünscht. Es sind das aktuellste BIOS und die aktuellsten Patches drauf. Ein Hardware-Defekt schließen wir aus, da das Modul problemlos funktioniert, bis der Reboot kommt. Uns ist bewusst, dass beim ersten Reboot nach dem Domain Join natürlich die Group Policies gezogen werden. Doch da ist effektiv kein Unterschied zur Altwelt zu finden. Die Policies werden auch sauber gezogen, laut Eventlog. In den Eventlogs und den Logs von MDT finden wir ebenso nichts, was erklärt warum der Treiber flöten geht. Das einzige Problem, das wir sehen, ist vermutlich ein Zeitzonen-Problem, das wir auch per GPO konfigurieren. Da müssen wir nochmal etwas korrigieren, aber darin sehe ich keinen Zusammenhang mit dem Treiber - zumal alle anderen Treiber keine Probleme bereiten... Habt ihr mit solchen oder ähnlich gelagerten Fällen schon Erfahrungen gemacht oder könnt uns einen Hinweis auf eine mögliche Ursache geben? Grüße, xola

Hallo, stehe vor einem kleinen Problem. Wir haben einen Server hinter einer Firewall. Auf dem läuft noch Win2003. Dort ist kein Powershell installiert. Wir müssen mehrmals täglich ein Script starten (dieses wird von außerhalb der Firewall aufgerufen), dass diverse Sachen auf diesem Server auswertet. Da das Script um einige Funktionen erweitert werden soll, und ohnehin schon relativ alt ist, schreibe ich es gerade neu. Unter anderem werden auch die lokalen Gruppen und dessen Mitglieder ausgelesen. Dafür gibt es nun ja mehrere Methoden. Die Methode per WMI (bzw. CIM) wird durch die Firewall blockiert. Die Methode über invoke-command funktioniert nicht mangels installiertem Powershell auf dem Server. Die einzige Methode, die zuverlässig funktioniert, ist ADSI. Leider tut sich hier ein Problem auf. Wir haben >320 Gruppen. Wenn wir das Script laufen lassen, müssen wir immer eine Zahl angeben (die entspricht einem Ordner, respektive Projektnummer). Auf diesem Ordner sind (meistens) vier Gruppen berechtigt, die alle mit <Projektnummer>_* beginnen. Um diese Gruppen auszulesen, muss das Script *alle* Gruppen des Servers auslesen und dann die gewünschten suchen: ([ADSI]"WinNT://"+$server+",computer").children | where { $_.SchemaClassName -eq "Group" } | where { $_.Path -like $projektnummer } Das dauert aber extrem lange, da es so viele Gruppen sind. Kann ich irgendwie einen Filter (mit Wildcards) setzen, damit bereits der Server das Filtern übernimmt? Das würde mein Script stark beschleunigen. Gibt es noch einen anderen Weg, remote an die Gruppen und dessen Mitglieder zu kommen? Irgendwas "eleganteres", aber am Besten etwas schnelles. Grüße, xola

Die Lösung war etwas schwierig herauszufinden. Es liegt daran, dass auf der Maschine, die geklont werden soll, ein Registry Key gesetzt werden muss: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Sysprep\Settings\sppnp Den Eintrag PersistAllDeviceInstalls auf "1" setzen. Dann den sysprep Befehl ausführen. Und dann klappt das. Der Key sagt, dass die Treiber "behalten" werden, wenn syspresp eingesetzt wird. Dazu gehört auch der VMWare Netzwerktreiber, der mit den VMWare Tools mitkommt.

Hallo, meine kleine virtuelle Testumgebung: AD: Name localdomain.com, eine OU "ENTW", fünf Sub-OUs "Server", "Clients", "Users", "Admins", "Groups", ein Adminaccount "Adm1" und ein Benutzeraccount "Ben1". Zwei Gruppen "Benutzergruppe" und "Admingruppe" mit dem jeweiligen Account drin. Eine GPO, die die Firewall und UAC abschaltet. Server: WIN-NET-01, IP 192.168.203.2 (statisch), DHCP, DNS und AD Rolle installiert (Konfiguration s.o.), Win2k8 R2 SP1 komplett durchgepatcht, Eval-Version Client: WIN-CLT-01, IP 192.168.203.5 (per DHCP), Win2k8 R2 SP1 komplett durchgepatcht, Eval-Version. Adminrechte für Admingruppe und Userrechte für Benutzergruppe. Lokaler Administrator aktiviert. Ich habe zuerst den Server aufgesetzt und konfiguriert. Dann habe ich ihn mit c:\windows\system32\sysprep\sysprep.exe /oobe /generalize /shutdownbehandelt, wonach der Server herunterfuhr.Habe ihn dann dupliziert -> daraus wurde der Client. Zur aktuellen Situation: Die Rollen und Server sind funktional und laufen flüssig. Allerdings habe ich ein Problem festgestellt. Sobald ich den Client in die Domäne aufnehme, kann er nicht mehr pingen. Das exakte Problem wurde hier schon von einem anderen User bemerkt: http://social.technet.microsoft.com/Forums/windowsserver/de-DE/f540904d-3892-47c2-9061-db370dccf9a1/rechteproblem-beim-pingen?forum=windows_Serverde Allerdings wirkt diese Lösung bei mir nicht. Wenn ich den Client wieder in Ursprungszustand mit sysprep versetze und dann wieder in die Domäne aufnehme, geht das Pingen wieder nicht. Könnt ihr mir vllcht helfen? Grüße xola

Hallo zusammen, hab es selbst herausgefunden. Der Host-Only Adapter der VMWare verwaltet nur Adressen mit 203.x. Sobald eine 204-Adresse sich am Adapter (Gateway) meldet, wird dieses Netzwerkpaket verworfen. Habe aber jetzt noch eine weitere Frage in einem neuen Thread im Active Directory. Vielleicht könnt ihr euch die mal anschauen. Grüße, xola

Hallo zusammen, baue mir gerade eine virutelle Testumgebung auf. Diese besteht momentan aus einem zentralen Server (W2k8 R2 Sp1, komplett durchgepatcht). Dieser läuft im HostOnly Modus. Darauf sind momentan DNS und DHCP als Serverrolle installiert. Die IP ist fest eingetragen (192.168.203.3). In der DHCP Serverrolle habe ich zwei Bereiche definiert: 192.168.203.3 - 192.168.203.5 und 192.168.204.10 - 192.168.204.15 Als Client habe ich auch einen W2k8 R2. Auch der läuft im HostOnly Modus. Dieser bekommt seine Adresse über DHCP. Momentan bekommt der Server nur aus dem Bereich 1 seine Adresse zugeteilt. Selbst wenn ich die MAC-Adresse fest ("reserviert") in den Bereich 2 eintrage. Wo findet die Zuordnung des Clients in den jeweiligen Bereich statt? Wie kann ich das konfigurieren? Leider finde ich nirgends dazu eine Möglichkeit... Freundliche Grüße xola

Ich weiß dass du den SYSTEM-Account gemeint hast. Der Serviceaccount hat keine Rechte, sich interaktiv anzumelden. Das wäre auch gegen den Sinn eines Serviceaccounts. Der Serviceaccount hat nur "Log on as batch job"-Rechte (per local policy). Ich habe ab und zu ausnahmsweise ein cmd offen unter dem Serviceaccount um zu testen. Aber ohne dass der Account als lokaler Admin eingetragen ist, hat das noch nicht funktioniert. Dies ist aber jetzt nicht mehr erlaubt.

Oh, Entschuldigung, das habe ich total übersehen.... Nein, es ist bei uns Konzernrichtlinie, dass bestimmte Mechanismen über Serviceaccounts laufen müssen. Da geht es z.B. um Mailfreischaltungen etc. Es ist aber auch Konzernrichtlinie, dass ein Serviceaccount kein lokaler Admin sein darf. Das Script wird ja jedesmal erneut angetoßen, wenn ein Error ins Applicationlog mit der ID 1500 geschrieben wird. Das Script kann mit eventtriggers leider nur parameterlos angestoßen werden, daher holt das Script den letzten passenden Eintrag selbst aus dem Applicationlog: PsLogList -n 1 -i 1500 -s Application Den Output splittet er auf, und holt sich Domain, Username und Zeitpunkt raus. Im Anschluss schaut das Script im WMI nach der Quota des Users und holt dort die aktuelle Belegung, Warning Level und Limit heraus. Und genau an der Stelle, an der der WMI-Query ausgeführt wird, bricht das Skript ab (wenn ich es unter dem Kontext des Serviceaccounts laufen lasse). Die Zeile lautet wie folgt: Set objQuota = objWMIService.Get _ ("Win32_DiskQuota.QuotaVolume='Win32_LogicalDisk.DeviceID=""C:""'," & _ "User='Win32_Account.Domain="""+g(1)+""",Name="""+g(0)+"""'") g(0) ist der Username, g(1) die Domain (wir haben User aus verschiedenen Domänen auf dem Server). Anschließend bereitet das Script die Daten auf und legt die Informationen in einer Datei "temp.txt" an. Auf einem anderen Server läuft parallel ein weiteres Script, welches diese Datei abfragt - und zwar alle 30 Minuten. Sobald die Datei vorhanden ist, holt er sich den Inhalt und verpackt das schön in eine Mail. Die Mail wird dann an eine bestimmte Empfängerliste gesendet. Danach löscht er die temp.txt. Dieses zweite Skript läuft übrigens problemlos, daran liegt es nicht. Grüße, xola

Hallo, danke für die Antwort. Ja, das taucht als Scheduled Task auf, das habe ich schon bemerkt. "Mit höchsten Berechtigungen ausführen" sehe ich dort nirgends - es handelt sich um einen W2k3 Enterprise Server. Grüße xola

Hallo, auf einem unserer Terminalserver soll ein Serviceaccount über ein vbs-Skript auf das lokale WMI zugreifen. Das ganze läuft wie folgt ab: User möchte sich anmelden, stößt aber an seine Quota-Grenze. Dabei wird ein Event ins Applicationlog geschrieben, welches die ID 1500 hat. Auf dem Server läuft ein "eventtriggers", welches das Script im Kontext des Serviceaccounts startet, sobald das Event 1500 im Log auftaucht. Sobald das Script aber auf cimv2 zugreifen möchte, kommt oben genannter Fehler (welcher übrigens nur "Call failed" bedeutet => http://msdn.microsoft.com/en-us/library/windows/desktop/aa394559%28v=vs.85%29.aspx). Das Script läuft wunderbar, wenn ich es von Hand starte (ich bin Administrator). Wenn ich den Serviceaccount als lokalen Administrator berechtige, kommt trotzdem der Fehler. Der Serviceaccount ist in der Local Policy "Log on as batch job" berechtigt. Hier (http://social.technet.microsoft.com/Forums/en-US/winserverManagement/thread/05205b52-0e43-4ce3-a8b8-58ec4c2edea5/) hat ein User das Problem gelöst, indem er den Profilordner seines Serviceaccounts gelöscht hat. Das funktioniert bei mir aber nicht, der Profilordner kommt immer wieder, und der Fehler auch. Könnt ihr mir weiter helfen? Grüße xola

Hallo zusammen, ich scripte gerade per Powershell ein Programm zusammen, dass Dateien auf mehrere definitierte Systeme kopiert. Die Oberfläche dafür ist per .NET-GUI aufgesetzt. Bei Klick auf einen Button wird eine zweite Powershell-Datei aufgerufen. Diese hat nur ein Formular mit einer Multiline-Textbox: [void] [system.Reflection.Assembly]::LoadWithPartialName("System.Drawing") [void] [system.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") $objForm = New-Object System.Windows.Forms.Form $objForm.Text = "Verteilung von Softwarepaketen" $objForm.Size = New-Object System.Drawing.Size(470,440) $objTXTresults = New-Object System.Windows.Forms.TextBox $objTXTresults.Multiline = $true $objTXTresults.Size = New-Object System.Drawing.Size(430,350) $objTXTresults.Location = New-Object System.Drawing.Size(10,35) $objForm.Controls.Add($objTXTresults) [void] $objForm.ShowDialog() Der Prozess, der angestoßen werden soll, besteht aus mehreren Steps, deren Ergebnis in diese Textbox eingefügt werden sollen. Und zwar während die Oberfläche schon geladen ist. Wie ist das machbar? Freundliche Grüße xola

Hallo zusammen, ich habe mir eine kleine Testdomäne mit AD aufgesetzt (W2k8R2 SP1 Enterprise, 100% aktuelle Patches, installierte Rollen sind "DNS" und "Active Directory", DHCP wird von VMWare gemacht). Seit ich die ActiveDirectory-Rolle installiert habe, fehlt in der Computerverwaltung der Punkt "Lokale Benutzer und Gruppen". Ich habe herausgefunden, dass ein DC keine SAM-Datenbank mehr hat, sondern nur die Domain-Datenbank. Zugriffsrechte kann ich somit nur über die lokale GPO vergeben. Habe ich das soweit richtig verstanden? Wenn ja, dann folgende Fragen: - Welche der beiden GPOs ("Default Domain Policy" und "Default Domain Controller Policy") ist diejenige, die aktiv ist, bzw. höher priorisiert ist? (Werden bei Konflikten die niedriger priorisierten einfach verworfen?) - Wie kann dann ich einen lokalen Administrator einrichten, der Software installieren und Wartungsarbeiten vornehmen kann? Vielen Dank für die Informationen xola

Hallo, wir haben einen Printserver hinter einer Firewall, die kein WMI zulässt. Häufig müssen wir dort das Sharing der Printer deaktivieren (ohne die Printer zu löschen). Bisher haben wir das manuell gemacht, aber die Firewall bremst das stark aus, so dass es kein Vergnügen ist. Deshalb möchten wir das nun per Powershell-Skript erledigen (mit Kommentarfunktion in das "Kommentar"-Feld des Printers) auf unseren lokalen Maschinen. An die Auflistung der Printshares kommen wir per ADSI ohne Probleme ran. Und das geht auch sehr schnell, trotz Firewall: $adsi = [ADSI]("WinNT://$server,computer") $list = $adsi.psbase.children | where { $_.psbase.schemaclassname -eq "PrintQueue" } Allerdings finden wir nirgends eine Funktion/Methode, mit der wir das Sharing deaktivieren können. Hier wird auch nichts darüber ersichtlich. Geht das irgendwie ohne WMI?

Ich möchte diesen Thread noch einmal hervorholen, da das Problem noch nicht behoben ist.