Jump to content

Hitsch

Members
  • Gesamte Inhalte

    38
  • Registriert seit

  • Letzter Besuch

Fortschritt von Hitsch

Enthusiast

Enthusiast (6/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

0

Reputation in der Community

  1. Gibt es eine Möglichkeit, diesen Upgrade auch mit einem Windows Server 2008 R2 und WSUS Version 3.2.7600.226 zu verteilen? Ich verstehe nicht, weshalb die Verteilung mit diesem WSUS mit der 1511-er Version problemlos geklappt hat, und mit 1607 geht es nur noch mit einem WinSrv 2012 ?
  2. Hab deinen Link angeschaut und den Inhalt gelesen, da wird aber von KB3159706 (Windows Server 2012 / R2) gesprochen? Ich habe Windows 10 Enterprise Version 1511 (Build 10586.494) im Einsatz. Die offizielle Version, keine Testversionen. Zudem wurde das Update ja vom WSUS erkannt und heruntergeladen. Ich frage mich, weshalb es nicht zutreffend ist für die Clients?
  3. Hallo zusammen Bei mir wird im WSUS das Update KB 3176919 (Kumulatives Update für Windows 10 1607) zwar angezeigt und bereit zur Installation, in der Spalte Erforderliche Anzahl steht aber 0, obwohl ich ca. 15 Maschinen im WSUS drin habe, welche mit Win10 Version 1511 (Threshold) laufen. Das Update ist für die erforderlichen OU-Gruppen freigegeben, wird aber im Statusbericht als "Nicht zutreffend" taxiert. Wieso ist das Update nicht zutreffend? Gruss Hitsch
  4. Hallo zusammen Ich habe in einer GPO unter Computerkonfiguration => Einstellungen => Systemsteuerungseinstellungen => Geplante Aufgaben... ...einen Eintrag gemacht. Ziel: Programm starten "cleanmgr" mit dem Argument "/sagerun:1". - Ausführen als (Domäne)\(Benutzerkonto) - Unabhängig von der Benutzeranmeldung ausführen - Konfiguieren für: Windows Vista oder Windows Server 2008 => Die GPO ist der richtigen OU verlinkt, wo sich auch der Computer drin befindet. => Einstellungen in der GPO: Verknüpfungen = richtige OU || Sicherheitsfilterung = Authentifizierte Benutzer (Standardeinstellung) => Der ausführende Benutzer ist auf dem Zielcomputer lokaler Admin. (in Gruppe Administratoren). Trotzdem erscheint im Eventlog des Computers folgende Warnung: Das Computer "DLA_cleanmgr_WinSrv2k8"-Einstellungselement im Gruppenrichtlinienobjekt "GPO_DLA_Alle_cleanmgr_regKeys {EB894833-CF34-4C6E-8040-D06D584DA2A4}" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070005 Zugriff verweigert" Dieser Fehler wurde unterdrückt. aufgetreten ist. Weshalb hat er hier "Zugriff verweigert"? Gruss Hitsch
  5. Hallo zusammen Ich habe ein Verzeichnis mit bmp's (Bitmap-Bilder) erhalten, von welchen ich die Herkunft (Dateisystem, OS) momentan noch nicht weiss. (Werde ich später ggf. noch erwähnen, sobald ich dies auch weiss) Die Berechtigungen (ACL's) für das Verzeichnis ist korrekt gesetzt, ich habe mit dem User, mit welchem ich das Verzeichnis per Windows-Explorer anschaue, Vollzugriff -Berechtigung. Wenn ich dann versuche, eine Mutation vorzunehmen (wegkopieren, ändern, etc.), bringt er mir folgende Meldung (siehe Anhang). Das kuriose ist: Ich selber bin der User DLA\cleadmin. Mein User ist sogar in der Domänen-Admin Gruppe drin. Es gibt keine Vererbungen bei den ACL's, welche eine Berechtigung "Verweigern" drin haben. Kann mir hier jemand helfen? Nachtrag: Interessant ist auch die grüne Farbe der Dateinamen. Was soll das bedeuten? Gruss Hitsch
  6. Hallo zusammen Wir haben einen alten HP ProLiant DL380 Gen7 Server mit Citrix XenServer 6.1 im Einsatz, mit diversen virtualisierten Windows 7 x64 Clients und einigen WinSrv 2008 R2 Server drauf. Nun haben wir einen HP ProLiant DL380p Gen8 mit Citrix XenSeerver 6.2 aufgesetzt und wollen diese virtuellen Maschinen auf den neuen Server zügeln. Netzwerktechnisch haben wir ein Netzwerk-Bonding aus 4x RJ-45 auf einen Gigabit-Switch realisiert. Alle virtuellen Maschinen befinden sich in einerWindows AD .local Domäne. Wir haben ein Subnetz 255.255.254.0 und in der Domäne einen einzigen DNS-Server, der auch DC und DHCP-Server ist (kleines KMU-Netzwerk mit ca. 30 Workstations) Für den Wechsel der virtuellen Maschinen sind wir folgendermassen vorgegangen: 1.) VM runterfahren 2.) XenCenter -> VM -> Netzwerk -> Schnittstelle gelöscht (damit kein Netzwerk beim importieren am neuen Standort vorhanden ist) 3.) VM exportieren als .xva-File 4.) VM auf neuem Server importieren 5.) neues Netzwerk-Interface (Add Interface) hinzugefügt, mit neuer MAC-Adresse 6.) VM starten Das Problem ist, dass er den Domaincontroller nicht findet und auch nicht mit dem Internet verbindet. Die IP-Konfiguration ist statisch und unverändert zum alten Standort. Selbstverständlich läuft die Maschine am alten Ort nicht mehr. Am Domänenbeitritt wurde nichts verändert. Wir haben dann aber den Domänen-Betritt neu gemacht (raus und wieder rein), hat nichts gebracht. Nach ein paar Stunden verliert er plötzlich die Netzwerk-Konnektivität. Hat mir jemand einen Input, was ich untersuchen soll? Gruss Hitsch
  7. Ich arbeite oft mit dem Befehl sc und bin sehr zufrieden damit - aber mit psexec geht es natürlich auch
  8. Hallo zusammen Den Anmeldebildschirm-Hintergrund kann man ja ganz einfach abändern, indem man das Bild unter C:\Windows\system32\oobd\info\backgrounds ändert. Wie kann ich aber den Anmeldebildschirm-Hintergrund für eine RDP-Session ändern, damit nicht der langweilige blaue Hintergrund erscheint? Gruss Hitsch
  9. Hi zusammen Ich muss die Installation via GPO zu einem späteren Zeitpunkt nochmals aufgreifen, weil ich aus Kapazitätsgründen momentan nicht dazukomme.
  10. Das MSI paketiert den Client unserer Software die wir ausliefern. Sie beinhaltet mehrere 1'000 dll's und pnl's, ein paar exe's, ini's usw. Zudem noch div. VCRedist-Pakete, den 7PDF-Maker, CrystalReports Runtime (SAP). Es werden div. vbs-Scripts ausgeführt, welche installierte Inhalte auf dem Client überprüfen. Zudem wird ein Registry-Key eingelesen, der zuvor via GPO auf den Clients verteilt wurde. Die vbs-Scripts sind aber kein Problem, weil ich bereits ein MSI mit einem Patch für unsere Software auf die selbe Art und Weise erstellt habe wie das grossi MSI - und dieses Patch-MSI liess sich problemlos publishen und per WSUS verteilen.
  11. Das MSI händisch installieren dauert je nach Performance des Clients etwa 10-13 Minuten.
  12. Wir erstellen das MSI selber, nicht ich, aber mein Kollege. Werde das mit ihm mal anschauen. Allerdings kann ich sagen, dass ein anderes MSI, das ca. 100 MB gross ist und mit der genau gleichen Vorgehensweise und der gleichen Software erstellt wurde (= AdvancedInstaller) problemlos funktioniert hat. Da bleibt irgendwie nur noch das Ding mit der Grösse...
  13. Ja klar, habe ich nun auch so gemacht, hab den AV für den WSUS-Server nun komplett abgeschaltet, trotzdem kommt noch der Zertifikatsfehler.
  14. Nein, auf dem gleichen Server ist auch die AMC installiert, welche die AV-Updates für die Clients intern bereitstellt. Die Clients beziehen die Update von diesem Server.
×
×
  • Neu erstellen...