goat82

Entschuldigung wenn ich euch alle total nerve aber ich bin mit meinem Latein an Ende und könnte MS in den Ar..... schießen. Ich will die Aussage mit der nicht funktionierenden aber vorhandenen Win 10 GPO "Installationszeit festlegen" nicht akzeptieren. Warum deaktiviert MS nicht diese Einstellung wenn Sie angeblich nicht funktioniert? Soweit ich mich erinnern kann hat dies unter 1809 bisher meistens (nicht bei allen) funktioniert. (Plus minus 1h) Testumgebung klappt nicht. Ich habe mehrere PCs in eine neue Zielgruppe gepackt und mehrere Updates in Wsus zum Entfernen markiert. Wenn ich am Client nun "usoclient startscan" ausführe, dann installiert der Client die zu entfernenden Updates sofort erneut anstatt sie zu entfernen! Einzige Änderung: Die Updates tauchen unter Updates normale auf und ich kann sie nicht mehr mit der rechten Maus manuell deinstallieren. Bei installierten Updates die nicht zur Entfernung markiert sind kann ich manuell deinstallieren, aber auch da erkennt das Wsus direkt und installiert diese neu. Kann ich den lokalen Windows Update Agenten über die Registry manipulieren damit meine Vorgaben (Zeitpunkt der Installation = 12:00, Kein automatischer Neustart wenn Benutzer angemeldet sind) erfüllt werden können? Wartungsmodus über nacht will die GL nicht. Kenne mich auch nur mit WOL aus. Hab da Bedenken das manche Pcs am Morgen an , anstatt aus sind, dann gibts erneut Ärger. Na toll! Aber ein kleiner Funken Hoffnung der TEstumgebung. Immerhin steht nun das da:

Wird das Update dann automatisch am Client entfernt oder sagt die Option nur aus, dass es nicht direkt wieder installiert wird wenn ich es manuelle deinstalliere? KAnn ich es so also erneut freigeben, damit ich das ganze testen kann? Warum kann ich den Installationszeitraum einstellen, wenn dieser nicht beachtet wird? Was hat sich MS da ausgedacht? So stelle ich den ganzen Wsus in Frage. Es kann nicht sein, dass ein User in die Pause oder zu einem Meeting geht und dann sein PC automatisch neu startet obwohl der PC gesperrt (nicht abgemeldet) ist. Wie kann ich den Installationszeitpunkt fix einstellen ? @Sunny: in einem anderen Blog schreibst du das der PC nicht neu startet wenn ich Benutzerkonfigurationen eingegeben habe. Ist da was dran? Ich habe zum Wsus ja nur 3 Benutzerkonfigurationen. Ich kann mir beim besten Willen nciht vorstellen, dass Firmen Ihre User zwingen den PC wegen Updates innerhalb der Nutzungszeit spätestens 60 Minuten nach Einspielen der Updates zum Neustart zwingen.

Hallo Sunny, vielen Dank erstmal für deinen Ratschlag welchen ich Umsetzen werde. Um mir temporär zu helfen werde ich den Installationszeitpunkt auf 17:00 Uhr anstatt auf 12:00 Uhr legen und den automatischen Neustart auf maximal 2h nach Installation auswählen. Das ist zwar immer noch nicht perfekt, wird aber die meisten User nicht tangieren. Wo finde ich heraus welche Einstellungen bei 1909 greifen und welche zu älteren OS gehören? Wenn der Installationszeitpunkt auf 17:00 liegt, der PC aber aus ist und der User am nächsten Tag um 7 den PC einschaltet, was passiert in diesem Fall? Wenn ich Updates auf dem Client entferne, werden diese direkt bei Reboot automatisch direkt wieder neu installiert (auch ohne Verbindung zu Wsus). Wie kann ich das ganze also genau testen wenn ich nicht auf neue Updates warten will und diese freigebe. Ich möchte ja den offiziellen Weg testen wie er später auch abläuft. Mein Problem hierbei: Installationszeitpunkt ist zwar auf XX:XX eingestellt. Die Testclients haben aber beliebig und nicht zur geplanten Uhzeit installiert. Vermutlich lag es daran dass die Updates zuvor deinstalliert wurden. Welche Funktion hat die Option in Wsus: Zur Entfernung genehmigen ? Auch dies habe ich ausprobiert das Update wurde aber immer wieder nach dem Neustart gezogen.

GPO neu erstellt. (ADMX Files nicht neu kopiert, da Dateistempel identisch von MS) 5 Clients in einer Testgruppe gepackt, GPOs gemäß Anhang neu erstellt Nutzungszeitraum auf 6-18 Uhr eingestellt (Wird am Client in der Gui und in der Registry auch so angezeigt Installationszeitraum auf 15:00 Uhr geändert. Clients beobachtet: Alle Clients installieren selbstständig beliebig nicht erst nach 15:00 Uhr und starten ohne Info sofort neu. KATASTROPHENALARM. Habe diesmal Anhänge des GPOs und der Clientregistry angehängt in der Hoffnung dass hier ein Experte wie Sunny oder jemand anderes den Fehler findet. PS: gpedit.msc auf den lokalen Client zeigt alle Wsus Einstellungen/für Unternehmen als "Nicht konfiguriert" an ! PS2: Ändere ich eine Einstellungen der GPO auf dem DC,z.B: Nutzungszeit und führe GPupdate am Client aus wird die Wsus Gui am Client sofort aktualisiert. Scheinbar funktioniert hier alles, bis auf die Einstellung: Nutzungszeit und kein Neustart ausführen wenn Benutzer angemeldet sind. Deinstalliere ich Updates am Client werden diese beim Neustart automatisch sofort wieder installiert. Findet einer den Fehler so erhält dieser von mir 1000 Likes? Bitte,bitte Hilfe CC_WSUS XXXXX TEST-NEU.pdf Client Export.pdf

ok, in Zukunft werde ich nur Anhänge anhängen. Ich hoffe trotzdem dass ich irgendwann hierfür eine Lösung finde.

Hallo Sunny, ich werde verrückt. Klar habe ich mit der original Gruppenrichtlinienverwaltung auf dem Domainecontroller gearbeitet. Deine angefragte Option ist im Bild markiert! GPOS 1909 (https://www.microsoft.com/en-us/download/100591) befinden sich auf den DCs unter C:\Windows\SYSVOL\sysvol\meine Domain\Policies\PolicyDefinitions. Aktuelles Datum der ADMX Files ist 18.03.2019, neue finde ich im Web nicht! Unter Policies befindet sich noch ein alter Ordner "PolicyDefinitions-vor-1903". Das WSUS GPO wurde nicht neu erstellt, eventuell zeigt es noch auf den 1903 Ordner? Wie könnte ich das überprüfen ? Wenn ich die WSUS GPO editiere sehe ich ja "vom zentralen Computer abgerufen" also greift er direkt auf den Ordner PolicyDefinitions zu. Wenn ich die Nutzungszeit in der GPO ändere und den Client neu starte, dann kommt die Änderung am Client auch direkt an. Also scheinen die GPOs ja ansich auch zu laufen. Ich habe nun eine Test OU erstellt und werde die GPO neu machen und nur wenige PCs hinzufügen und warten bis neue Updates von MS kommen und diese in WSUS dann nur in der Testgruppe genehmigen, sonst reißen mir alle anderen den Kopf ab. Wenn die Clients nach 15 Minuten einfach so neu starten. Es muss doch irgendwie gehen, dass die PCs während 6.00 - 18:00 Uhr nicht neu starten. Wenn ich es nicht hinbekomme lege ich den Installationszeitpunkt auf 15:00 Uhr. Zwischenlösung (Test) 1: Richtlinie "Neustart immer zur geplanten Zeit aktivieren" und auf 180 setzen, dann startet der PC immerhin erst nach 3 Stunden also gegen 18 Uhr (vorausgesetzt die GPO greifft). Fahren die Clients vor 18 Uhr herunter ist somit alles ok, dann gehe ich davon aus, dass er die Updates beim herunterfahren oder Neustart am nächsten Morgen aktualisiert. Diese Richtlinie "Neustart immer zur geplanten Zeit aktivieren" ist nicht konfiguriert, da ich die Richtlinie "Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind!" aktiviert habe. Mein Problem: Diese Richtlinie "Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind!" greift nicht! Installationen werden um 12 Uhr automatisch durchgeführt und wenn der Benutzer zum Neustart aufgefordert. Kommt er dem nicht nach und klickt nicht auf "Nicht jetzt" startet der Client nach exakt 15 Minuten automatisch neu und alle ungespeicherte Arbeit ist futsch. @Sunny: Wenn ich die defekte Richtlinie editiere steht da bezüglich Unterstützung nichts von Windows 10. Ist das vielleicht das Problem? Bei anderen GPOs steht teilweise Windows 2016/2019 oder mindestens Windows xx oder explizit auch Windows 10 : PS: Kein Client nimmt am Insider-Program teil. Der Screenshot zeigt immer Beispiele: Sie nehmen am Insider-Program teil. Ohne verknüpftes MS Konto ist das meines Wissens nicht möglich und wir haben kein Client der ein MS Konto nutzt. HIer meine aktuellen GPO Einstellungen

Problem: Updates werden installiert. Klickt der User nicht innerhalb von 5 Minuten auf nicht jetzt, startet der PC neu. schön wärs, Ms doof killt alles und speichert nix.

Es funktioniert immer noch nicht nicht, leider. Mit dem Fenster kann ich gut Leben, wenn die User auf jetzt nicht klicken aber nicht dass er nach 10 Minuten automatisch, WÄHREND der Nutzungszeit neu startet. Die wenigsten User sind kontinuierlich am Platz und kommen verägert wieder, wenn die ganze Arbeit futsch ist. Was ist nenn nun falsch? Anbei dei Registryeinstellungen die er von der GPO gezogen hat.

Das wäre ja alles in Ordnung. Der Client kann ja neu gestartet werden, aber halt nicht wenige Minuten nach dem Einspielen der Updates! Wenige User lassen halt ihr PC mehrere Tage an (inklusive nicht gespeichertem Inhalt). Welche Einstellung regelt also nun dass der PC von 6.00 Uhr bis 21 Uhr nicht neu gestartet wird, egal wie wichtig das installierte Update auch ist. Updates werden immer um 12:00 Uhr installiert. Solange der PC nach dem Einspielen von 6:00 -21:00 Uhr nicht automatisch neu startet, kann ich gut damit leben. An WSUS komme ich nicht vorbei, sonst muss ich 80 Pcs manuell pflegen, dazu habe ich keine Zeit.

Hi Sunny61, vielen Dank für deine Hilfe. Also Kontrolle läuft über die Registry, auch gut. Nutzungszeiten habe ich absichtlich nicht angegeben, denn dann gilt die Maximale Nutzungszeit. Glaubst du dadurch ist mein Problem behoben ? Ich will einen automatischen Neustart ja verhindern, sondern nicht einstellen. Nach wichtigen Updates erscheint: Neustart erforderlich. Wenn ich Hier auf später Neustarten oder Abbrechen klicke, dann erscheint ein Counter" PC wird nach xx Minuten" automatisch neu gestartet. Der Hinweis kann kommen, aber der automatische Neustart darf niemals durchgeführt werden, egal wie wichtig das Update oder egal wie lange der Client nicht neu gestartet wird.

Hallo Zusammen, ich habe eine Problem mit GPOs für das neue Windows 10 1909. AD DC sind 2019 und 1x 2016. ADMX Templates sind neu, zentraler ADMX Speicher ist eingerichtet. Problem: Clients starten nach Updates automatisch neu. gpresult /r zeigt an das die GPO angewendet wird. Unter Updates sehe ich auch das der Administrator Konfigurationen eingestellt hat. GPO erzwingen bringt leider auch nichts. Irgendwo muss ein (Denk-) Fehler sein. Folgende Fragen: LSDOU Regel sagt doch aus, dass die lokale Sicherheitsrichtlienie zuerst angewendet wird und von der verknüpften Gruppenrichtlinie überschrieben wird. Der wo zuletzt schreibt, gewinnt, also in dem Fall die verknüpfte GPO auf die OU und nicht die lokale GPO. Wie kann ich sehen welche Policys in der lokalen Richtlienie am Client aktiv sind? unter gpedit.msc sind alle Policys auf nicht konfiguriert. Egal welche GPo übder die Domaine angewendet wird. Ist das normal? Da GPOs über den Domainecontroller am Client angewendet werden, muss ich das doch irgendwie sehen können? (ich meine nicht die GPO, diese bekomme ich ja durch gpresult/r sondern die einzelnen Einstellungen wie ich Sie im GPO Editor auf dem Domaincontroller sehe) Vielen Dank erstmal. Lg Goat

@4077 den hatte ich bei 2008R2 immer, eventuell ist dies bei der Migration auf 2019 verlorengegangen @NorbertFee: Es stand genau der Pfad drin und das hat unter 2008R2 aich so gepasst, Habe ihn nun auf \\domain.local\netlogon\.... umgestellt und nun funktioniert es. Gibt es denn schon admx Vorlagen für Windows 10 1909 ?

Danke 4077. ich weiß nicht warum mir das nicht aufgefallen ist. Bei der Migrierung der DCs wurden auch die Domaincontrollernamen geändert und darum hat MS automatisch den Standardskriptpfad genommen, da der alte ja nicht mehr gültig war! Daran hatte ich nicht gedacht, also (m)ein Admin-Anwenderfehler Eine letzte Frage habe ich aber noch. Bei 2008R2 wurde mir das cmd Fenster mit dem Script nach dem Login immer kurz angezeigt, das fande ich eigendlich immer ganz ok. Unter 2019 ist das nicht mehr so. Folge Einstellung habe ich gefunden und auch aktiviert, das Scriptfenster erscheint aber dennoch nicht. Ist alles nicht so schlkimm, denn das Script wird nun ausgeführt. Hat trotzdem jemand eine Idee. Ich Danke euch allen bei der Hilfe von meinen Problemchen, das ist echt ein super Forum! Schöne Feiertage, falls wir nichts mehr von einander hören. LG Goat

Hallo Zusammen, ich habe unsere 3 DCs von 2008R2 auf 2019 umgezogen. Domain und Forestfunctional level ist nun 2016! Alles läuft einwandfrei aber ein verflixtes Problem bleibt jedoch, ein wichtiges logonscript "netstart.cmd" wird unter 2019 nicht mehr ausgeführt. Ich finde den Fehler leider nicht und bitte hier um Hilfe! Führe ich den Befehl manuell am Client aus, wird die Datei einwandfrei kopiert. Gpresult /r sagt auch das UC_Netstart ausgeführt wurde, es wird aber keine Datei kopiert. Auf dem alten Server hat dies einwandfrei funktioniert. Irgendwo muss ein Fehler sein. Andere GPOs (nicht Startupscript) funktionieren. Lg Goat

Die Domaine soll bestehen bleiben. Einige Dienste werden in der Domaine xy noch benötigt werden. Ein Trust wird aber in Zukunft dennoch eingerichtet werden wegen SSO. Habe nun ein Script gefunden das sauber läuft: import-csv C:\import.csv | New-ADUser -PassThru | Set-ADAccountPassword -Reset -Newpassword (Read-Host -AsSecureString "Account Password eingeben") -PassThru | Enable-ADAccount Was hier noch fehlt sind die Sicherheitsgruppenmitgliedschaften. Hast du hierbei einen Tipp ?

Es ist ein Produktivsystem und keine Spielewiese! Firma A (Domaine xy) wird von Firma B (Domaine: Hans) gekauft (es besteht kein Forest/Domain Trust, nur VPN zwischen den DCs). Die User von Firma A sollen nun Remote über Firma B arbeiten. Hierzu müssen alle User im AD auf Firma B neu angelegt werden, was ich mir ersparen will. Sämtliche identische Sicherheitsgruppen habe ich bereits auf Firmas B angelegt, nun fehlen nur noch die AD Benutzer. Toll wäre wenn man beim Import die Gruppenmitgliedschaften gleich via Script mit angeben kann.

Ich habe 70 AD User in der Domaine A welche ich auf einem DC in Domaine B importieren muss. In der Domaine A ist der Login name ein Kürzel, in der Zieldomaine B der Vorname+Kürzel. Domainenamen sind natürlich unterschiedlich. Das müsste ich dann manuell vor dem Import in der exportierten CSV abändern. Zudem sollen alle Accounts auf dem Zielsystem der Member of Gruppe "Domain Users und XYZ" angehören und das Passwort auf TEST gesetzt werden. Das muss also in der Import CSV ebenfalls eintragen. Get-AdUser -filter * -SearchBase 'OU=User,OU=Freiburg,OU=XX,DC=xxx,DC=xxxx' | Export-Csv -Encoding UTF8 -Path .\user-exports.csv -NoClobber -Delimiter ";" funktioniert einwandfrei. Hiermit habe ich Vorname, Nachname, Displayname und Anmeldename abgehackt, es fehlen aber noch die oben genannten informationen. Den Import habe ich noch nicht getestet, da die Daten ja noch nicht komplett sind

ok, aber wie kann ich z.b. Userlogin name, member of gruppen, passwort never expire rauffinden ? Die ganzen Befehle geben immer nur die wichtigsten Infos raus Was ich brauche ist ein Export für: -first name -last name -display name -E-Mail -Member of (Gruppen) -user login name / Domaine - Windows 2000 Domaine und user login name Danach ein Import mit definierten Passwort für alle neu eingelesenen Accounts auf einem anderem System

Hallo Zusammen, ich muss ca. 50 AD User exportieren, die Namen in der csv umbenennen und in einer anderen Domaine importieren. Anleitungen habe ich einige gefunden, allerding haben wir viele Umlaute und auch ohne Umlaute kommt häufig das ? zum Vorschein. Wie kann ich die User einwandfrei ohne Fehler exportieren und importieren?

Hallo Zusammen, ich habe einen Windows Server 2019 1809 (17763.864) mit einem WSUS 10.0.17763.1. Office 365 Client kann angewählt werden und es werden auch jede Menge Updates syncronisiert, allerdings steht da immer das es nur mit SCCM geht, welchen wir nicht haben. Gibt es keine klassischen Office 365 Client updates ohne SCCM für Wsus mehr ? Gibt es irgendeine ALternative ohne den teuren SCCM ? Eventuell ein Script das lokal auf den Clients läuft? Alle Rechner manuell updaten ist echt langwerilig. LG Goat

Also ich lasse lieber 2 parallel laufen und den einen ausbluten oder aktiviere die alten Updates auf dem neuen Server. Kann mir jemand nun noch sagen was servicing drivers sind? Reicht Windows 10 1903 für Netframe Updates und Windows 10 Updates vollkommen aus? Und nun die letzte Frage: Gibt es viele Vorteile für SQL Express anstatt WID?

Hallo Zusammen, ich verwende einen produktiven Wsus Server auf einem 2016 Server. Nun habe ich einen neuen Wsus auf einem 2019 Server (als Replika) dazuinstalliert damit er sich die Einstellungen zieht. Diesen werde ich nun ebenfalls mit MS syncronisieren lassen und den alten nach dem Supportende von Windows 7 und Office 2010 abschalten. Der alte Server soll die Windows 7 Clients bis Februar versorgen, während der neue nur Windows 10 1903 Clients parallell versorgen soll. Außer etwas mehr Speicher und natürlich doppelte Bandbreite, sehe ich hier kein Problem. Über GPO Zielgruppen funktioniert das einwandfrei. Ich möchte gerne noch einige alte wenige 1809 Clients über den alten Wsus Server laufen lassen, der neue soll nur Updates für 1903 oder höher liefern. Hier möchte ich gerne so wenig wie möglich Updates laden. Was bedeutet denn hier genau das Produkt Windows 10 ? Reicht "Windows 10 1903 and later"aus oder wo liegt genau der Unterschied gegenüber Windows 10? Was sind genau Servicing Drivers? 99% aller Clients haben 1903, sodass ich hier kein Upgrade von 1806 oder so laden möchte, denn das mache ich dann lieber manuell über das Web. Vielen Dank für eure kurzen Erklärungen LG Goat

IIS... Internet.... ich glaube bei 2019 heißt der IIS Dienst nun WWW-Publishingdienst. Da ich mir aber nicht sicher bin, frage ich lieber mal nach

Hallo Zusammen, ich habe einen Server 2019 Datacenter mit IIS welcher für eine Software (Lansweeper) verwendet wird. Hier möchte ich nun von SQL compact DB zu SQL Express 2017 wechseln. Hierbei muss man den IIS Express Service stoppen unhd neu starten. Obwohl IIS istalliert und aktiv ist, finde ich den IIS Dienst unter Server 2019 nicht. Kann es sein, dass ich IIS unter Server 2019 nur manuell deaktivieren kann oder heißt der Dienst hierbei wahrscheinlich anders? Sorry, aber ich habe mit 2019 wenig praktische Erfahrungen.