Vandro

Problem gelöst

Die Lösung habe ich hier gefunden:

https://community.spiceworks.com/topic/291388-windows-doesn-t-recognize-domain-until-60-seconds-after-startup

Netbios Domainname in DNS eintragen, Cache leeren und alles funktioniert auf den Rechnern tadellos. Es betrifft scheinbar nur PCs mit SSD, die zu schnell starten. Die jeweiligen GPOs haben bei mir bekanntlich nichts gebracht. Der einfache Host A Eintrag hingegen schon, die Erklärung was genau passiert und warum das die Lösung ist, bleibt aber leider aus. Vielleicht kann das von euch ja jemand aufklären?

Laut dem Link oben, ist dies eine Lösung aus einem Microsoft Call. 

Danke euch für die Hilfe.

Prüfen kannst Du das alles in der Registry direkt auf den betroffenen Clients. Ist denn auch ganz sicher der Schnellstart abgeschaltet? powercfg /hibernate off in einer administrativen Commandline hilft. Wir haben ~580 W10 Clients, bei keinem einzigen das von dir angesprochene Problem. Evtl. ist ja der AV-Scanner der Schuldige, der vieles verhindert.

 

BTW: Es heißt ERSETZEN, da ist ein t zu viel bei dir. ;)

Fastboot ist definitv abgeschaltet, habe es auch nochmals mit powercfg /hibernate off getestet. 

Der Regkey "SyncForegroundPolicy" mit dem DWORD Wert 1 ist gesetzt. Die GPO habe ich ebenfalls nochmals lokal gesetzt... Ihr könnt es euch denken --> keine Änderung.

Ich teste alles auf einem frisch installierten Windows 10 1703 Client mit allen Updates, ohne Virenscanner und Firewall. 

Moin,

 

 

da ich gerade letzte Woche wieder einen Kunden hatte, der das auch sagte, wo es aber nach langem, langem Troubleshooting dann doch nicht so war - ist das überprüft? Wirkt das entsprechende GPO auf diese Rechner?

 

Gruß, Nils

Sie wird mir zumindest im RSOP angezeigt, ob sie auch tatsächlich zieht weiß ich nicht. Wie kann ich das im Detail prüfen?

Erstellen und Ersetzen ist schlecht, aktualisieren ist die bessere Variante. Bei Erstellen wird in der laufenden Sitzung getrennt und wieder neu erstellt.

 

Welchen der Registrywerte hast Du gesetzt? Oder hast Du gleich ganz oben das Lesen aufgehört?

Ich habe heute wieder ein paar Tests gefahren und die GPPs auf AKTUALISIEREN geändert, kein Erfolg. So wie Du die Wirkweise von "ERSTELLEN" beschreibst, habe ich es nicht erfahren. Bei mir bewirkt ERSETZTEN genau das von Dir beschriebenen Vorgehen, dass es getrennt und neu verbunden wird. Beim ERSTELLEN prüft er nur ob vorhanden, falls ja macht er gar nichts, falls nein verbindet er. So ist zumindest meine Erfahrung. 

Ebenfalls habe ich erneut den Artikel gelesen und die GPO (Wartezeit für Richtlinienverarbeitung...) erneut gesetzt. Wenn ich es richtig verstehe, bringt der Trick mit der Abhängigkeit nur weniger Wartezeit für Geräten außerhalb des Netztes. Dennoch habe ich das am Testclient umgesetzt, keine Änderung. 

Es bleibt leider bisher dabei, wenn der User sehr schnell sein Kennwort eingibt, sind die Netzlaufwerke erst nach ca. 60 Sekunden verbunden.

Moin

 

Ich denke mal, beim schnellen Anmelden erfolgt diese cached, da die Netzwerkverbindung noch nicht vorhanden ist. Die klassische Abhilfe ist die Gruppenrichtlinie "...... immeer auf das Netzwerk warten".

Danke für deinen Kommentar. Steht schon im Eingangspost, diese GPO ist selbstverständlich gesetzt.

Alle GPOs und GPPs werden auch ordnungsgemäß verarbeitet, nur die Netzlaufwerke stehen eben nicht sofort zur Verfügung. 

Wie werden die Laufwerke verbunden? Per GPP? Wenn ja, Ersetzen, Aktualisieren oder Erstellen? Oder doch per Scirpt?

 

Schau dir auch diesen Artikel dazu an: https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/

Per GPP mit der Option Erstellen. 

Bei Aktualisieren hatten wir immer Schwierigkeiten, dass sich die geöffnete Ordnerstruktur der User immer zum Aktualisierungszeitpunkt der GPO geschlossen hat. 

Den Link kenne ich, die GPO ist gesetzt und der Registrywert bringt keine Besserung.

Hallo liebe MCSE Gemeinschaft,

ich komme bei einem kleinen, aber nervigen Problem derzeit nicht weiter.

Aktuelle Clients haben reproduzierbar das Problem, dass wenn der User den Clients startet und sobald es möglich ist sein Kennwort eingibt und sich anmeldet, die Netzlaufwerke nicht verbunden sind. Er erhält eine Meldung und die Laufwerke haben ein rotes X. Wartet er nun ca. 60 Sekunden, kann er auf die Laufwerke zugreifen. 

Wenn der User den PC startet und mit der Kennworteingabe ein paar Sekunden wartet, läuft alles problemlos.

Packe ich z.B. Outlook in den Autostart, funktioniert der Zugriff auf den Exchange perfekt, während die Netzlaufwerke noch nicht funktionieren. Ein Ping geht ebenfalls an alle Server sofort nach der Anmeldung, während die Netzlaufwerke die besagten 60 Sekunden benötigen, bis der Zugriff möglich ist. Das Netzwerk scheint also bereit zu sein. 

Das Phänomen tritt nur auf neuen PCs auf und auch nur, wenn User wirklich sehr schnell sein Kennwort eingibt. 

Die Ereignisanzeigen sind sauber, keine Fehler die auf Netzlaufwerke oder nicht bearbeitete GPO hinweisen. Alle Dienste starten vernünftig und die GPOs werden auch korrekt verarbeitet. Virenscanner und Firewall testweise deaktiviert, keine Änderung. 

Folgende GPOs / GPPs sind gesetzt:

Fast Boot deaktiviert (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled)

Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie\Wartezeit für Richtlinienverarbeitung beim Systemstart angeben (60 Sekunden)

Computerkonfiguration\Administrative Vorlagen\System\Anmelden\Beim Neustart des Computer... immer auf das Netzwerk warten

Hier bin ich mir unsicher, ob ich diese Richtlinie überhaupt benötige, da wir nicht mit Login Skripten arbeiten - aktiviert sind derzeit folgende:

Computerkonfiguration\Administrative Vorlagen\System\Skripts

--> Anmeldeskripts gleichzeitig ausführen

--> Maximale Wartezeit für Gruppenrichtlinienskripts angeben (0 Sekunden, also solange warten, bis das Skript abgeschlossen ist)

--> Startskripts asynchron ausführen

GPP für die Laufwerke

Option Erstellen mit dem jeweiligen Pfad auf den DFS Share. 

Eckdaten:

Clients alle homogen auf Windows 10 Pro, IPs via DHCP (mit fester IP selbiges Problem), DNS, WINS arbeiten sauber

2x DCs 2012R2 DFS-Namespaceserver

1x STORAGE 2012R2 worauf die Shares liegen

Hat jemand von euch ein ähnliches Problem und eventuell eine Lösung?

Ich könnte natürlich die Kennwortrichtlinie auf 14 Stellen setzen, aber da steigen mir meine User sicher aufs Dach :-)

Grüße

 

Darüber hinaus finde ich, dass wir hier den Bereich verlassen, in dem ein Forum sinnvoll etwas beitragen kann. Ein Forum ist gut für technische Hilfestellung. Designfragen sind dort i.d.R. prinzipbedingt nicht gut zu diskutieren.

Dann widmen wir uns doch einmal der technischen Frage aus dem Eingangspost, welche hier bisher kaum Beachtung gefunden hat.

"2.) Welches RAID erstelle ich am besten für die VHD’s?

Alle 8 Platten zu einem RAID10? Oder zwei RAIDs, eins für die DCs und Filserver und eins für Exchange und SQL?

Blocksize im RAID10, welche Blockgröße ist empfohlen, wenn auf dem RAID nur die VHDs liegen"

Nein. Der magische Peter ist nicht mein Ansprechpartner :-D

Ich fasse zusammen:
Die Lösung "zwei HyperV Hosts mit jeweils lokalen Platte und Replika für den Fileserver" ist euer Meinung nach Unsinn?

Ich sollte ein Blech für DC, ein Blech für HyperV und ein Blech für Backup nehmen. Fällt mir der HyperV-Host aus, muss schnellstmöglich Ersatzhardware beschaffen oder 4Std. SLA  und einen Restore aus dem Backup anschieben. Genau den Stand habe ich jetzt bereits und davon wollte ich weg!

Entschuldigt, aber mir ist einfach nicht ganz klar, warum die vorgeschlagene Lösung derart "verteufelt" wird.
 

Du sprachst einmal von Replika und einmal von Live Migration. Beide haben unterschiedliche Implikationen auf die Lizenzierung. Software Assurance für SQL oder auch für die CALs hast Du bisher nicht erwähnt. Falls Du Exchange 2013 gekauft hast und per Downgrade 2010 nutzt, brauchst Du möglicherweise auch SA für Exchange.

Mit jeweils einer Datacenter-Lizenz pro Host ist doch sowohl Replica als auch Live Migration für alle installierten virtuellen Maschinen mit Server 2012R2 korrekt lizensiert?

Sorry, aber ich bin jetzt verunsichert.

Aus dem Thread von NilsK:

Man könnte es also folgendermaßen zusammenfassen:

Im Fall von Hyper-V Replica ist der Ziel-Host, auf den die VMs für Zwecke des Disaster Recovery repliziert werden, dann richtig lizenziert, wenn entweder

1. die Windows-Server-Lizenzen auf dem Quell-Host sowie die zugehörigen CALs über aktive Software Assurance verfügen (in diesem Fall ist keine Windows-Server-Lizenz für den Ziel-Host nötig) ODER
2. auf dem Ziel-Host ausreichende Windows-Lizenzen (Datacenter oder mehrere Standard-Lizenzen) vorhanden sind, um alle VMs zu betreiben (in diesem Fall ist keine Software Assurance nötig)

Im Fall von 1. darf der Ziel-Host keine produktiven Aufgaben übernehmen, sondern dient nur als Replikationsziel sowie zeitlich begrenzt für das Disaster Recovery.

Im Fall von 2. darf der Ziel-Host produktive Aufgaben (z.B. weitere aktive VMs) ausführen, solange die zugewiesenen Lizenzen ausreichen.

In beiden Fällen kann allerdings Software Assurance für die Server-Applikationen nötig sein (z.B. SQL Server, Exchange Server).

 

Kommt das so hin?

 

 

Daniel -MSFT- Antwort darauf:

"das kommt genau so hin."

 

Ich plane zwei Datacenter ein, warum wird das nicht reichen? In dem Thread unter Punkt 2 bestätigst Du diese Konstellation?!

Oder sprichst Du von den CALs? Diese sind selbstverständlich berücksichtigt.

Hilf mir doch bitte mal auf die Sprünge :-)

Nochmal: Wie sind denn die genauen Anforderungen für die Umgebung?

Ziele des Projekts ist folgendes:

Konsolidierung der Hardware

Skalierbarkeit, für einen Zeitraum von 6 Jahren keine „größeren“ Serverinvestitionen mehr

Flexibles Hinzufügen von neuen Serversystemen, ohne erneute Anschaffungskosten für Hardware.

Ausfallzeit beim Fileserver  <= 4 Stunden

Datenverlust beim Fileserver <= 4 Stunden

Wiederherstellungszeiten: ASAP

Derzeit sind die Wiederherstellungszeiten miserabel, da keine Ersatzhardware zur Verfügung steht und die bestehenden Maschinen kein SLA haben.

Daher fand ich die Idee mit zwei HyperV Host und Replika ganz reizvoll. Ein großes Thema spielt eben die Flexibilität, da unser Wachstum und künftige Projekte schlicht nicht absehbar sind.

Daher rührt auch die recht große Dimensionierung im Vergleich zum Ist-Zustand.

Ich muss dazu sagen, dass es uns KEIN Geld kostet wenn die Hardware mal für einen halben Tag nicht verfügbar ist. Es ist ärgerlich und es wäre eben schön wenn das nicht passiert.

Daher gibt es keine Diskussionen "was kostet uns eine Stunde Ausfall- somit stellen wir folgendes Budget zur Verfügung"

Ich habe einen Betrag X für eine neue Serverlösung, den ich sinnvoll investieren möchte.

Ich kenne Deine aktuelle Situation nicht.

 

Wenn es Dir um Verfügbarkeit geht und das Backup-Thema zufriedenstellend gelöst ist, wäre ein Cluster für mich die nächste Stufe.

Statt zwei Server mit lokalen Platten und Hyper-V Replika, gibt es für ein paar Euros mehr auch ein Shared SAS Enclosure. Damit kannst Du schon einen kleinen Cluster bauen und die Vorteile nutzen.

 

Warum in eine zusätzliche DR Lösung investieren, wenn es für wenig mehr eine vollwertige HA Lösung gibt?

Und genau deswegen frage ich hier. Der oben genannte Vorschlag kommt von meinem betreuenden Systemhaus und ich wollte hier eine zweite Meinung hören.

Danke dafür. Mit diesem Vorschlag komme ich doch in meiner Recherche weiter und kann die "vollwertige HA-Lösung" anfragen.

:thumb1:

BTW: Mach Dir auch mal Gedanken über die Lizenzierung. Stichwort Anzahl der notwendigen Windows Server-Lizenzen, "Lizenzmobilität", "Disaster Recovery Rights" für die Replikation und "Software Assurance"... Sind Dir die Konsequenzen hier alle klar?

Wir haben zwei 2012R2 Datacenter Lizenzen mit SA eingeplant. Laut meiner Recherche sind damit alle für uns denkbaren Fälle abgedeckt. Bin ich auf dem richtigen Pfad?

Was wir künftig benötigen sind Exchange und SQL-Lizenzen, aber hier kommt die DR bzw. DAG Lösung erst später in diesem Jahr.

Ach du meinst Shared Nothing Live Migration?

 

Ich glaube es ist sinnvoller die 10 GB Karte für Replika / Live-Migration zu nutzen und zwei 1GB Karten (wenn benötigt) für Management und zwei 1GB Karte für den Zugriff der Clients.

 

Ist keine Verfügbarkeit des Systems gewünscht? Wird die Verfügbarkeit durch Guest Cluster / Replikation gelöst?

"Almost" Shared Nothing, richtig :-)

Aber die LiveMigration ist für mich ja nur relevant, wenn am HyperV-Host Wartungen / Updates durchgeführt werden.

Die Replika soll doch angeblich so ressourcenschonend arbeiten, daher habe ich damit gerechnet, dass 1gb reichen wird. Ich danke Dir für den Tip und werde deinen Vorschlag berücksichtigen.

Die erhöhte Verfügbarkeit bzw. DR-funktionalität möchte ich über Hyper V Replika erreichen.

Kritischster Dienst ist neben den DCs der Fileserver, welcher möglichst schnell wiederhergestellt sein sollte. Daher meine Frage im Anfangspost unter Punkt 3 - HyperV Replika oder DFS?

Exchange würde ich, sobald ich auf 2013 migriere, via DAG verfügbar machen wollen - aber damit muss ich mich noch detallierter auseinandersetzen.

Eine Antwort auf Punkt 2 bzwl. der RAID-Konfiguration und der Blockgröße im RAID & auf der NTFS Partition, würde mir noch sehr helfen

Moin,

 

Bei der geplanten Last würde ich eher einen physischen DC, einen Host und einen Server fürs Backup einsetzen.

Die nächste Stufe wäre dann ein Cluster mit Shared Storage und Hyper-V Replika ganz am Ende der Prioritätenliste.

 

Ein RAID6 aus 12 Spindeln für die VMs.

 

Weder noch.

Bei einem Small Business Setup sollte der Fokus zunächst auf einem vernünftigen Backup & Restore Konzept liegen. Danach kann man über Weiteres nachdenken.