Hitsch

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 ?

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?

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

Super - hat funktioniert - vielen Dank!

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

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

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

Ich arbeite oft mit dem Befehl sc und bin sehr zufrieden damit - aber mit psexec geht es natürlich auch

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

Hi zusammen Ich muss die Installation via GPO zu einem späteren Zeitpunkt nochmals aufgreifen, weil ich aus Kapazitätsgründen momentan nicht dazukomme.

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.

Das MSI händisch installieren dauert je nach Performance des Clients etwa 10-13 Minuten.

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

Ja klar, habe ich nun auch so gemacht, hab den AV für den WSUS-Server nun komplett abgeschaltet, trotzdem kommt noch der Zertifikatsfehler.

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.

Ja, ich kann den AV Echtzeitscanner mal deaktivieren, kein Problem. Allerdings nicht den ganzen AV deinstallieren, denn die Clients erhalten über den gleichen Server auch die AV-Updates. Ich kann aus kostentechnischen gründen nicht für jeden Job einen neuen Server bereitstellen, das lohnt sich für 30 Clients nicht ;) Auf dem Server sind noch ca. 25 GB freier Speicherplatz auf C: wo auch der Wsus-Content liegt.

Hi lefg, Nein, es gab kein TimeOut, er hat auch geschrieben "CreateCab", dann "Publish..." und dann kam die Fehlermeldung mit dem Zertifikat. Er ist also normal durchgelaufen und hat dann auch geschrieben "Publish failed" auf der WPP-Oberfläche. Es gab kein Time Out.

BTW: Die Discussion bei Codeplex habe ich bereits gestartet: https://wsuspackagepublisher.codeplex.com/workitem/192 Hallo, ich kann das MSI leider nicht aufteilen, weil es in verschiedener Verteilsoftware funktioniert und bei mehreren Kunden von uns so erfolgreich eingesetzt wird. Das MSI ist so gross, weil die Sourcen entsprechend viele (etwa 4 Verzeichnisse mit je über 1'000) DLL's und PNL's enthalten. Was passiert genau beim Publishen? Werden dort einfach CAB-Dateien in den WsusContent erstellt?

Das MSI ist etwas mehr als 1.1 GB gross. Delta202C ist der WSUS-Server, welcher Member in der Domain ist. Auf diesem Server ist auch noch die AMC (Avira Management Console) und die Acronis-Console installiert. Das Zertifikat habe ich nun neu mit der Version .262 erstellt und per GPO auf allen Maschinen verteilt, wiederum in den zwei Verzeichnissen wie es sein muss. Dies habe ich auch per MMC (Konsole) lokal auf dem WSUS-Server kontrolliert, sogar ein gpupdate durchgeführt, Server neu gestartet. Beim Start des MPP erscheint keine Meldung von wegen fehlendem Zertifikat - alles in Ordnung. Nur das publishen dieses MSI's will einfach nicht klappen - obwohl sich das MSI problemlos von Hand auf jedem Client installieren lässt. Das MSI hat diverse vbs-Scripts integriert, welche gewisse Voraussetzungen für die Installation auf dem Client prüft (z.B. ob 32-bit/64-bit, welche Produkte installiert, welche Registry-Werte, etc.). Zudem werden noch weitere MSI- oder exe-Pakete (z.B. VCRedist-Pakete, Microsoft Visual C++ Runtime; 7PDF-Maker, etc.) mit diesem MSI ausgerollt. Hat jemand noch eine Idee?

So! Das MSI ist nun lokal unter C:\WSUS gespeichert. Funktioniert trotzdem noch nicht, nun kommt aber eine Fehlermeldung die ich noch nie gesehen habe und frage mich was das soll: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less 248 characters. .... das kann ja irgendwie nicht sein, ich bin unter C:\WSUS\(35 Zeichen inkl. Dateiendung) = 43 Zeichen. Kann es sein, dass ich im Update Creation Wizard noch etwas einstellen muss? Es gibt da ja viele Optionen, Rules, etc. Ich hab nur eine Rule drin und zwar "greater or equal" Windows 7 und "WorkStation". Hier noch die Screenshots des WPP Update Creation Wizards Update: Nun habe ich die Benennung des MSI gekürzt und nochmals versucht. Der Fehler kommt nicht mehr, dafür füllt es mir die interne HD des WSUS-Servers komplett und dann kommt (natürlich) die Meldung "Es steht kein Speicherplatz zur Verfügung". Na toll... Update 2: Nun kommt wieder der Fehler: Verfication of file signature failed for file: \\DELTA202C\UpdateServicesPackages\(Zeichenfolge)_2.cab

Danke Dir für deine detaillierte Hilfe! Hat mich sehr gefreut :) Ja, den SwDistribution Ordner hab ich schon ein paar mal gelöscht, werde ich auch diesmal tun. Ich bin den Hauptrelease (MSI) nun als Update im WPP am generieren, er ist momentan mit CreateCab dran. Wenn das nicht funzt, dann werde ich wie von Dir empfohlen das MSI lokal auf den WSUS-Rechner nehmen und nochmals versuchen. Rückmeldung kommt dann gleich im Anschluss

Hallo Alles so gemacht wie oben beschrieben: - Serverbereinigungsassistenten 4mal laufengelassen -> i.O. - Serversynchronisierungen per Script gelöscht -> i.O. - Alle Dienste von Acronis und Avira beendet und deaktiviert -> i.O. - Systemstart alle Dienste ausser BGINFO deaktiviert -> i.O. - Neu gestartet, cmd-Fenster als Admin gestartet, lodctr /r ausgeführt -> i.O. - Update "WSUS-KB2734608-x64.exe" (Build: 3.2.7600.256) als Admin ausgeführt, folgender Fehler: Produkt: Windows Server Update Services 3.0 SP2 - Update "Hotfix for Widows Server Update Services 3.0 SP2 (KB2734608)" konnte nicht installiert werden. Fehlercode 1603. Weitere Informationen sind in der Protokolldatei C:\Users\ADMINI~1.DLA\AppData\Local\Temp\2\wsuspatch25895.log enthalten. Hier das Log: MSI (s) (84:94) [10:46:12:899]: Produkt: Windows Server Update Services 3.0 SP2 - Update "Hotfix for Widows Server Update Services 3.0 SP2 (KB2734608)" konnte nicht installiert werden. Fehlercode 1603. Weitere Informationen sind in der Protokolldatei C:\Users\ADMINI~1.DLA\AppData\Local\Temp\2\wsuspatch25895.log enthalten. MSI (s) (84:94) [10:46:12:899]: Ein Update wurde durch Windows Installer installiert. Produktname: Windows Server Update Services 3.0 SP2. Produktversion: 3.2.7600.226. Produktsprache: 0. Hersteller: Microsoft Corporation. Updatename: Hotfix for Widows Server Update Services 3.0 SP2 (KB2734608). Erfolg- bzw. Fehlerstatus der Installation: 1603. MSI (s) (84:94) [10:46:12:899]: Note: 1: 1729 MSI (s) (84:94) [10:46:12:899]: Produkt: Windows Server Update Services 3.0 SP2 -- Die Konfiguration ist fehlgeschlagen. MSI (s) (84:94) [10:46:12:899]: Das Produkt wurde durch Windows Installer neu konfiguriert. Produktname: Windows Server Update Services 3.0 SP2. Produktversion: 3.2.7600.226. Produktsprache: 0. Hersteller: Microsoft Corporation. Erfolg- bzw. Fehlerstatus der neuen Konfiguration: 1603. MSI (s) (84:94) [10:46:12:899]: Attempting to delete file c:\Windows\Installer\27de5.msp MSI (s) (84:94) [10:46:12:899]: Unable to delete the file. LastError = 32 MSI (s) (84:94) [10:46:12:899]: Deferring clean up of packages/files, if any exist MSI (s) (84:94) [10:46:12:899]: Attempting to delete file c:\Windows\Installer\27de5.msp MSI (s) (84:94) [10:46:12:899]: MainEngineThread is returning 1603 MSI (s) (84:50) [10:46:12:915]: RESTART MANAGER: Session closed. MSI (s) (84:50) [10:46:12:915]: No System Restore sequence number for this installation. === Protokollierung beendet: 21.05.2014 10:46:12 === MSI (s) (84:50) [10:46:12:915]: User policy value 'DisableRollback' is 0 MSI (s) (84:50) [10:46:12:915]: Machine policy value 'DisableRollback' is 0 MSI (s) (84:50) [10:46:12:915]: Incrementing counter to disable shutdown. Counter after increment: 0 MSI (s) (84:50) [10:46:12:915]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2 MSI (s) (84:50) [10:46:12:915]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2 MSI (s) (84:50) [10:46:12:915]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1 MSI (s) (84:50) [10:46:12:915]: Restoring environment variables MSI (s) (84:50) [10:46:12:915]: Destroying RemoteAPI object. MSI (s) (84:F8) [10:46:12:915]: Custom Action Manager thread ending. MSI (c) (94:F4) [10:46:12:915]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1 MSI (c) (94:F4) [10:46:12:915]: MainEngineThread is returning 1603 === Verbose logging stopped: 21.05.2014 10:46:12 === Das andere Update "WSUS-KB2828185-amd64.exe (Build: 3.2.7600.262) ist mit dem gleichen Fehler ebenfalls fehlgeschlagen. UPDATE: Mit dem lokalen Administrator des WSUS-Servers (nicht Domain-Admin) wurden die Updates erfolgreich installiert!

Hallo Sunny61 Den Wert in der Registry hats nicht gegeben. Ebenso gibt es kein wininit.ini im Windows-Verzeichnis. Hab der Server trotzdem schon mehrere Male neu gestartet. Nun habe ich die komplette Maschine restored. Ich bin nun auf der WSUS Version 3.2.7600.251. Jedes mal wenn ich versuche, die KB's 2734608 und 2828185 zu installieren (gemäss Angaben in http://www.wsus.de/faq -> Frage 44), damit ich auf die Version 3.2.7600.262 komme, bricht er mir während der Installation ab der KB's ab und WSUS ist nicht mehr startbar. Natürlich habe ich die KB's "als Administrator" ausgeführt. Allerdings mit einem Benutzerkonto, das zwar in der lokalen Admingruppe liegt - aber nicht mit dem lokalen Administrator selber eingeloggt. Was mache ich falsch, weshalb die Updates immer scheitern? Weshalb lädt mit der WSUS die Updates nicht selber in der Update-Ansicht "WSUS-Updates"? Achja: Im Systemstart habe ich folgende Tools: - Acronis Scheduler Helper - Acronis Backup - Acronis Tib Mounter - Avira Server Security - Acronis Backup - bginfo

Hallo zusammen Ist es möglich, die GPO so zu definieren, dass nur "Sicherheitsupdates" automatisch installiert werden (Option 4), und die restlichen Updates für einen entsprechenden Rechner nach einer anderen Option, z.B. Option 3 (so wie ich es momentan definiert habe). Oder hat jemand einen Lösungsansatz, wie man das Ziel sonst bewerkstelligen könnte? Domänenstufe: Windows Server 2008 R2 SP1

Weisst du auch, wie ich zu dieser Version 3.2.7600.262 komme? Ich hab die KB's von Microsoft bis anhin irgendwie vergeblich durchsucht oder ich bin unfähig :suspect: Habs gefunden, WSUS.de FAQ -> Frage 44 stehts drin ;) Update: Ich habe nun dieses Ding hier geladen: http://www.microsoft.com/de-ch/download/details.aspx?id=38429 Er will es aber nicht installieren und bringt den Fehler: Es liegt ein dieses Windows Installer-Paket betreffendes Problem vor. Ein Programm, das im Rahmen der Installation ausgeführt wurde, wurde nicht erfolgreich abgeschlossen. Wenden Sie sich an das Supportpersonal oder den Hersteller des Pakets. Mein System: Windows Server 2008 R2 SP1 x64. Folgenden Fehler habe ich im Eventlog gefunden: Produkt: Windows Server Update Services 3.0 SP2 -- Fehler 1722. Es liegt ein dieses Windows Installer-Paket betreffendes Problem vor. Ein Programm, das im Rahmen der Installation ausgeführt wurde, wurde nicht erfolgreich abgeschlossen. Wenden Sie sich an das Supportpersonal oder den Hersteller des Pakets. Aktion: ExConfigureDb, Pfad: C:\Windows\Installer\MSI19F7.tmp, Befehl: -S DELTA202\SQLEXPRESS -F SUSDB -i "c:\Program Files\Update Services\Database\CreateDatabase.sql;c:\Program Files\Update Services\Database\mwus_database_schema.sql;c:\Program Files\Update Services\Database\ServerSync.sql;c:\Program Files\Update Services\Database\ClientWebService.sql;c:\Program Files\Update Services\Database\Setup.sql;c:\Program Files\Update Services\Database\Reporting.sql;c:\Program Files\Update Services\Database\ReportingSummarization.sql;c:\Program Files\Update Services\Database\ReportingRollup.sql;c:\Program Files\Update Services\Database\AdminAPI.sql;c:\Program Files\Update Services\Database\popdb.sql;c:\Program Files\Update Services\Database\EvtNamespaceImport.sql;c:\Program Files\Update Services\Database\SqlSettings.sql;c:\Program Files\Update Services\Database\Inventory.sql;c:\Program Files\Update Services\Database\PublicViews.sql" -l "C:\Users\cleadmin\AppData\Local\Temp\MWusCa.log" Hinweis: Ich habe die SUS-DB nicht standardmässig eingerichtet, sondern die DB in einer vorhanden SQL-Instanz auf einem anderen Server (DELTA202\SQLEXPRESS) eingerichtet. Hatte bis anhin ja auch nie Probleme mit dem Deployen von Updates mit dieser DB... Ich hab das Update natürlich auch "als Administrator" ausgeführt.