Akcent

Hallo,

ich möchte gerne mit der Windows Performance Analyse  (dem ADK) einen Windows 2012R2  beim Booten überprüfen, welche Dienste da sehr lange zum Starten benötigen.

Die ADK habe ich von der MS Seite heruntergeladen.
https://www.microsoft.com/en-us/download/details.aspx?id=34866

Leider kann ich den Recorder nicht starten und bekommen diesen Fehler:

Hat da ggf. jemand eine Idee?

Gruß Henry.

vor 10 Minuten schrieb cj_berlin:

Da der Host noch nicht lange an ist, wird der Neustart des Dienstes vermutlich nichts bringen. Aber er schadet auch nicht (sofern der Dienst wieder hoch kommt  )

 

Kannst Du mal probieren, ob der Zugriff auf die VM-Konsolen von einer anderen Maschine aus geht?

Gibt es einen Unterschied, ob Basic oder Enhanced Session Mode verwendet wird?

ich habe da leider nur den Host zur Verfügung.

Danke für den Hinweis mit dem "Enhanced Session Mode". Wen ich diesen deaktiviere komme ich direkt auf die VM

vor 5 Minuten schrieb Nobbyaushb:

Den Dienst vom Manger beenden und neu starten hilft meist.

Geht im Manager mit rechter MT

Wie lange ist der Host an?

Danke, Der Host ist oft nur ein paar Tage an, bis ich ihn übers WE neu starte.

Das mit dem Dienste Neustart teste ich mal.

Moin Moin,

wir haben hier einen Windows 2012R2 Server mit ein paar VM's (alles auch Windows 2012R2)

Wenn ich mich auf eine VM mit Rechtsklick --> Verbinden möchten, bekomme ich nur ein schwarzes Fenster  und dann kommt in der Titelleiste "reagiert nicht"

Per direktem RDP kommt man direkt auf die VM. Nur nicht mehr oder nach vielen Versuchen, über den Hyper-V Manager.

Hat da jemand eine Idee dazu?

Gruß, Herry

Hallo,

ich habe irgendwo gelesen, man sollte zwingen (MS Empfehlung) für den Host eine eigene LAN-Karte vorsehen und eine / die anderen LAN-Karten den VM's zuweisen. Diese würde sich positiv auf die LAN-Performance bei den VM's auswirken.

Aktuell habe ich zwei LAN-Ports per Team im Server-Manager eingerichtet und diesen im Hyper-V Manager einem virtuelle Switch für die beiden VM's zugewiesen.

Wenn man das nun wirklich trenne würde, sehe ich das richtig, dass ich dann unter den Netzwerkkkarte des Host die Team Netzwerkverbindung IPv4 deaktivieren, so dass diese nur noch für die VM's verfügbar ist und weise einer separaten LAN-Karte die IP-Adresse des Host's zu?

Oder wie macht Ihr das?

Wie könnte ich das nun im nachhinein ändern?

Gruß, Herry 

Wir haben hier einen alten Windows 2012R2 Hyper-V Host auf dem 4 Windows 2012R2 Server VM's laufen.

Diese sollen nun Step by Step auf dem neuen Hyper-V Host umgezogen werden.

Wie zieht ihr da die VMs um? Beide Hosts sind im gleichen LAN

- Export / Import 

- Herunterfahren, vhdx Dateien kopieren und eine neue VM anlegen und da die VHDX zuweisen?

Gruß, Herry 

Wenn ich im Servermanager (wie unter 2016 und 2019) ein NIC-Team mit 4 Ports einrichte, dann ich im Hyper-V Manager diesen ganz einfach auswählen.

Im Windows 2022er Server geht das wohl nicht mehr.  Hier bekomme ich dann diesen Fehler

Im Netz habe ich  gelesen, dass das mit dem LBFO nicht mehr so unterstützt wird.

Habe dann versucht mit 

New-VMSwitch -Name TeamNIC -NetAdapterName "LAN1", "LAN2", "LAN3", "LAN4" -EnableEmbeddedTeaming $true -AllowManagementOS $false

Einen Team anzulegen, sehe dann aber in der VM, dass diese Karte nur 1GB anstatt 1GBit/s hat.

Hat dazu jemand schon Erfahrungen?

Gruß, Herry 

vor 9 Stunden schrieb Sunny61:

Die Updates für 2019 sind installiert? Nach der Installation der Updates hast Du mindestens einen Reboot gemacht?

ja habe ich und es fühlt sich alles etwas flotter an.

Habe auch die Info bekommen, daß Server-Eye beim Herunterfahren aktiv ist. 

Habe gestern mal 2 Server auf Windows 2019 aktualisiert und immer noch den gleichen Effekt.
Das Herunterfahren von einem Server hat dabei über 30min gedauert.

vor 2 Minuten schrieb Sunny61:

Die Reboots nach der Installation von Updates dauern bei W2016 sehr lange, aber das wird bei unseren zig Servern dabei nicht angezeigt. Findet sich etwas im Eventlog des Servers? Besteht das Problem auch, wenn Due GDATA *rückstandsfrei* deinstallierst?

ich denke es liegt in der Tat an den Updates. Mich hat nur gewundert, daß der Bildschirm da so extrem lange stehen bleibt.

vor 2 Minuten schrieb Dukel:

Was sind das für Server? Ich würde auch nicht in-Place upgraden sondern sauber migrieren.

was meinst Du mit "was sind das für Server?
Und was mit sauber migrieren? Eine Neuinstallation?

vor einer Stunde schrieb Nobbyaushb:

Auf Server 2019 updaten

 

Reboot sind selbst bei den kleinsten Änderungen am Server 2016 ein graus - wir haben für unsere Produktiv-Umgebung nur 2 2016er Server - bei fast 200 Maschinen

Alles neue wird - sofern die Anwendungen / Dienste das supporten - auf Server 2019 installiert

Wenn nicht, 2012R2...

hmm ... habe hier zwar 2019er Lizenzen (aus dem ActionPack), kann die aber nicht ohne Datenverlust und alles neu zu installieren als Update drüber installieren.

Mein ISO gibt mit nur die Auswahl "nichts behalten"

Die 2016er liefen eigentlich immer sehr gut.

vor 13 Minuten schrieb testperson:

"Gefühlt" wird das mit jedem Patchday in 2020 etwas besser.

das hast Du jetzt ironisch gemeint

Hallo,

habe einen Windows 2016 als VM unter einem 2016er Hyper-V laufen.

Wenn ich den Server neustarten oder herunterfahren möchte bleibt dieser ewig bei diesen Bild hängen

Auf dem Server läuft eine Video Management-Software go1984 und Server-Eye als RMM

Virenschutz = G DATA

Kennt das jemand und hat gg. eine Abhilfe / Lösung?

Gruß, Herry 

Am 30.4.2015 um 15:58 schrieb vanGraham:

Überprüf mal folgenden Parameter:

 

1. Logon a domain controller as a domain administrator in the affected domain.
2. Start Adsiedit.msc.
3. Connect to the default naming context.
4. Locate the following DFS Replication topology container: CN=Topology,CN=Domain System Volume,CN=DFSR-Globalsettings,CN=System,DC=Your Domain,DC=Domain Suffix
5. Delete the msDFSR-Member CN object that has the old computer name.

Ich haben den gleichen Fehler wie @santoooom

Es gab mal zwei DC's Server01 und Server03

Der Server03 wurde wie schon oben aus der AD entfernt.

Es ist auch nicht mehr im AD drin. Habe ich mal mit diesem Check überprüft https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup

Dennoch habe ich 4012 Fehler in der DFS Ereignisanzeige.

Der DFS-Replikationsdienst hat die Replikation für den Ordner unter dem folgenden lokalen Pfad "C:\Windows\SYSVOL\domain" beendet. Dieser Server wurde von anderen Partnern für 420 Tage getrennt. Dadurch wird die im Parameter "MaxOfflineTimeInDays" zulässige Dauer überschritten (60). Aus diesem Grund geht der DFS-Replikationsdienst davon aus, dass diese Daten veraltet sind, und dieser Ordner wird vom Server erst nach Korrektur dieses Fehlers wieder repliziert. 
 
Verwenden Sie zum Fortsetzen der Replikation dieses Ordners das DFS-Verwaltungs-Snap-Ins zum Entfernen dieses Servers aus der Replikationsgruppe, und fügen Sie ihn dann der Gruppe erneut zu. Dadurch führt der Server einen ersten Synchronisierungstask aus, wodurch die veralteten Daten durch aktuelle Daten der Mitglieder der Replikationsgruppe ersetzt werden. 
 
Weitere Informationen:  
Fehler: 9061 (Der replizierte Ordner war zu lange offline.)  
Name des replizierten Ordners: SYSVOL Share  
ID des replizierten Ordners: 7ED04525-2E13-4728-AFAE-D611E5718E2B  
Replikationsgruppenname: Domain System Volume  
ID der Replikationsgruppe: 251E226C-6D91-4D70-88D4-CBF9A221F958  
Mitglieds-ID: F102CF27-5552-4F44-B347-91C700F5A4F3

Deinen Weg @vanGraham habe ich auch geprüft, aber da gibt es nur den einen, letzte DC

Gibt es noch eine andere Stelle, die man überprüfen kann?

Update 13:00 Uhr:

Habe diesen Artikel gefunden https://www.mcbsys.com/blog/2018/12/dfsr-error-4012-on-stand-alone-domain-controller/

Bis jetzt sind die Fehler weg.

Gruß, Herry 

//abgetrennt von hier:

https://www.mcseboard.de/topic/203023-dfsr-fehler-4012-dfs-replikation/

Beitrag aus 2015

vor 4 Minuten schrieb tesso:

Hast du den Artikel zur Uhrzeit vollständig umgesetzt? Auch die zweite Gpo die auf den Clients die Zeit definiert?

ja auch diese 2.GPO und die kommt auch an 

vor 11 Minuten schrieb NorbertFe:

Hast du auch Clients, die korrekt die Zeit holen?

auf den PCs die ich mir eben mal angeschaut habe das gleiche Fehlerbild beim Resync.

Uhrzeiten bei allen unterschiedlich

1 PC passt

1 PC 8 geht min vor

1 PC 4 geht min vor

vor 13 Minuten schrieb NorbertFe:

Starte mal auf dem dc den Zeitdienst neu. Hast du mehr als einen dc?

danach mal am Client ein w32time /resync

Wir haben nur einen DC

Habe ich gemacht und auch wie tesso vorgeschlagen hat den Client neu gestartet und ein neues Sync angestoßen.

Ergebnis:

C:\>w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.

Dieser Client geht 5min vor

vor einer Stunde schrieb NorbertFe:

Genau.

unverändert

vor 17 Minuten schrieb tesso:

Raus mit dem Haken. 

ist jetzt raus. Jetzt warten wir mal ob was passiert.

vor 27 Minuten schrieb NorbertFe:

Auf dem Server ist in den vm Eigenschaften aber die Host timesync abgeschaltet oder?

Hi Norbert.

da sieht das so aus:

Ich befürchte, daß hier der Haken noch raus muß.

Hallo,

zufällig ist uns aufgefallen, daß die Clients in unserem Netzwerk unterschiedliche Zeiten haben.

Wir haben einen DC (als Hyper-V VM) und 10 phy. Windows 10 Clients (1909)

Die GPO wurde überprüft und gemäß einer Empfehlung von @NorbertFe überprüft / gesetzt.

Diese greifen auch, aber die Clients haben unterschiedliche Zeiten (Delta 2 - 5 Min)

Überprüft man auf den Clients per w32tm /query /source bekommt man nicht den DC (PDC Emulator) als Quelle zurück sondern

Local CMOS Clock

Hat dazu ggf. jemand ein Idee warum die Clients nicht alle die gleiche Uhrzeit haben?

Gruß, Herry 

vor 12 Minuten schrieb tesso:

Jetzt liest den schon geposteten LInk zum Setzen der Zeit GPOs und setzt das um. Dann wird auch alles funktionieren.

 

BTW: gpupdate hast du ausgeführt?

hatte doch geschrieben, daß ich gpupdate bereits gemacht und nun auch gpresult funktioniert

Den Link zu den GPO's hatte ich doch schon 1:1 übernommen :-( 

vor 7 Minuten schrieb NorbertFe:

Ich war das gar nicht. ;)

oh .... Danke @tesso

vor einer Stunde schrieb tesso:

Dann versuche auf einem Client das windows Management zurückzusetzen.

Danach gpupdate und schaur was das gpresult sagt.

WOW .... da war in der Tat das WMI defekt.
Habe zuerst mit diesen Befehlen geprüft

winmgmt /verifyrepository

winmgmt /salvagerepository

Beide gaben alles OK zurück.

Dann habe ich den WMI Deinst beendet und das Reposity Verzeichnis umbenannt

Danach mit Winmgmt /resetrepository zurück gesetzt.

PC neu gestartet und gpupdate /force und gpresult /h c:\temp\r.html 

Und nun kam kein Fehler und der Bericht wird auch erzeigt.

Auch über die Gruppenrichtlinienverwaltung kann nun ein Bericht erzeugt werden und hier sieht man auch das die GPO für die Zeiteintsellung angewendet wurde.

Klasse und Danke Norbert.

Das Problem mit der unterschiedlichen Zeit habe ich aber immer noch (auch nach Restart des Zeit-Dienstes)

w32tm /query /status
Sprungindikator: 3(nicht synchronisiert)
Stratum: 0 (nicht angegeben)
Präzision: -23 (119.209ns pro Tick)
Stammverzögerung: 0.0000000s
Stammabweichung: 0.0000000s
Referenz-ID: 0x00000000 (nicht angegeben)
Letzte erfolgr. Synchronisierungszeit: nicht angegeben
Quelle: Local CMOS Clock
Abrufintervall: 10 (1024s)

vor 25 Minuten schrieb tesso:

Geht es etwas ausführlicher?

gpresult als welcher NUtzer ausgeführt? mit "ausführen als admin"-Konsole oder nicht?

 

Ihr habt anscheinend etwas mit wmi verbogen. Vielleicht hilft reset von wmi auf einem Client.

 

Die Zeitunterschiede würde ich erstmal hinten anstellen. Löse erst einmal dein GPO Problem. Wenn das wieder funktioniert, dann das Zeitproblem.

Reden wir von physischen Clients oder VMs? Sind auch Server betroffen?

 

gpresult als Admin (cmd als Admin ausführen) durchgeführt.

WMI haben wir noch nie was gemacht und sehen auch normal aus

Der Fehler ist auf mehreren Clients und alle Clients sind physikalisch. Nur der DC ist virtualisiert.

vor 5 Minuten schrieb tesso:

Was ist denn der Stand?

 

GPOs kommen an oder nicht?

Funktioniert das Report der GPO remote und/oder (nur) lokal?

Zeitabgleich funktioniert oder nicht?

 

Uhrzeiten sind immer noch 5min unterschiedlich.
gpresult /h rr.html liefert:
FEHLER: Zugriff verweigert.

GP Result über die GPO Verwaltung bringt "Unbekannter Fehler"

vor 34 Minuten schrieb NorbertFe:

Versuch mal auf einem der Clients:

https://www.tecchannel.de/a/windows-zeitdienst-reparieren,2033008

leider keine Änderung.

Kurze Info noch. Alle Server und Clients werden per Server-Eye gemanaged und gepatched. Alle haben die aktuellen WIndows-Patches.

Durch Server-Eye ist das Problem auch festgestellt worden.