soulseeker

Hi, da verstehst du mich falsch, wir nutzen kein DFS-R - und es geht nicht um das synchronisieren von verschiedenen Zielen. Wir wollen nur einen einfachen Namespace nutzen, weil die Fileshares auf verschiedenen Servern liegen. Und es gibt für jeden DFS-Ordner nur ein Ziel. Aber dabei gibt es ein Problem - wenn ein Mitarbeiter z.B. über seine Workstation auf \\contoso\dfs\fileshare zugreift, dann sieht er z.B. alle aktuellen Ordner (die z.B in der Freigabe \\fileserver\fileshare liegen). Wenn der gleiche Mitarbeiter z.B. auf den Terminalserver geht und wieder auf \\contoso\dfs\fileshare zugreift, dann "fehlen" jede Menge Ordner, obwohl das Ziel ja das gleiche ist (\\fileserver\fileshare). Das fällt aber nur auf, da dieser "fileshare" ein Temp-Ordner für unsere Mitarbeiter ist, wo jeden Tag viele Unterordner und Dateien erstellt werden und jeder Vollzugriff hat. Geht dieser Mitarbeiter dann direkt auf das Ziel \\fileserver\fileshare, dann sieht er wieder alles. Scheinbar ist das irgendein DFS-Cache-Problem, was aber alle Mitarbeiter sporadisch betrifft, was aber nur selten auffällt, denn meist arbeiten die Leute ja an einem Client. Es fällt nur auf, wenn mal jemand was zwischen Terminalserver und lokaler Workstation hin- und herschiebt.

Wir nutzen nur den DFS-Namespace ...

Hallo, wir haben in unserem Netzwerk hin und wieder das Problem, dass die Unterordner in einem DFS-Ziel nicht synchron sind. Dabei handelt es sich um ein Temp-Laufwerk, dass die Mitarbeiter nutzen, um Files auszutauschen. Dieser Share wird jede Nacht gelöscht. Manchmal legen Mitarbeiter dort Unterordner an und greifen dann neben ihrem Client auch über einen Terminalserver auf den DFS-Ordner zu. Ab und an fehlen dann aber einige der Ordner. Das passiert leider nur sporadisch, ich kann es selber nicht nachvollziehen. mit DFSutil finde ich keine Probleme, wir haben auch keine Replikationsprobleme. Der DFS-Stamm läuft noch im 2000-Modus. Macht es sind, diesen zu exportieren und im 2008-Modus neu zu erstellen? Die DFS-Nameserver laufen mittlerweile nur noch unter Win2008 R2 und sind gleichzeitig DCs. Grüße Marcel

Unser Dell-Vertriebler sagte nur "grundsätzlich müsste das laufen" ... die wollen sich daran auch nicht die Finger verbrennen. Die EXP3512 ist leider deutlich teurer. Das EXP2524-Enclosure mit 24 Slots kostet ca. 1,5 k, mit 12 X 900 GB 10k SAS 6,5 k. Ich habe mir noch kein Angebot von unserem Anbieter eingeholt, aber nur die 12-Slot-Enclosure scheint schon so 5k zu kosten.

Hallo zusammen, ich bin mir nicht sicher, ob meine Frage hier reingehört, aber ich versuche es trotzdem einmal. Wir nutzen derzeit einen (1 Jahre alten) IBM-Server 3640 mit M5110e/5120e Raid-Controllern und zwei DAS-Disc-arrays, ebenfalls von IBM (EXP3000 mit jeweils 12 Slots 15k SAS). Eine davon ist 3 Jahre alt, die andere jetzt 5 Jahre. Letztere Storage würde ich ganz gerne demnächst austauschen. Der Speicher dieser Storage wird von unseren zwei esxi 5.1-Servern verwendet. Unser Storage-Dienstleister kann nur noch die EXP2524 anbieten, mit 24 Slots für 10k SAS ... allerdings ist auch dieses Modell EOL, ebenso die Festplatten (wir wollten für's erste nur 12 Platten kaufen). Mir gefällt zum einen nicht, dass das angebotene Produkt end of life ist und angeblich das einzige noch erhältliche Disc-array ist, das mit unserem HBA kompatibel ist und von Datacore/IBM freigegeben. Zum anderen werde ich wohl auch kompatible HDDs in 1-2 Jahren kaum noch bekommen und außerdem sind das nur 10k SAS-Platten. Ich würde eher dazu tendieren, eine Dell 3420 zu verwenden, ggfs mit einem weiteren HBA. Das wäre laut unserem Storage-Dienstleister aber eine nicht unterstützte Konfiguration. Ist das wirklich so problematisch? Welche Kompatibilität wäre da ggfs. gefährdet? Datacore ist es ja eigentlich ziemlich egal, was man ihm als Speicher vorsetzt. http://www.datacore.com/products/technical-information/compatibility/Storage-Device-Compatibility.aspx Vielen Dank für euren Input! Marcel

Das ist nur ein Testserver für interne Zwecke, wo siehst du da das Problem?

Hallo, diese Meldung bekomme ich heute seit einem Reboot eines Win2012 R2-Servers während des Logins. Die Lösung "Domäne-raus/rein" funktioniert hier leider nicht, da dieser Server eine Zertifizierungsstelle ist :(. SPNs für host\fqdn sind vorhanden. Gibt es noch eine andere Lösung, außer die Cert-Authority zu sichern, die Rolle zu entfernen, dann den Server aus der Domäne zu werfen? Backup ist nicht vorhanden, das ganze ist nur ein develop-Testserver ohne produktive Aufgabe. Danke und VG Marcel [edit] Hab es selber herausgefunden ... der SPN für den hostnamen war doppelt vergeben, weil auf dieser Maschine noch ein ADFS läuft und dieser legt auch einen SPN an. Wenn man dort den gleichen Namen wie den des Servers als Host verwendet, kann es zu diesem Problem kommen ...

Danke, war mir nicht bewusst ... ich habe auf den MS-Seiten nur über den Standard-Weg 410, 411, 412 gelesen ...

Hallo zusammen, ich lerne schon eine Weile für den MCSA Server 2012 ... dafür sind m.E. 70-410, 411 und 412 nötig. Abgelegt habe ich die 410 und 411 ... die 412 sollte eigentlich demnächst folgen. In der Zwischenzeit habe ich noch zwei Office365-Prüfungen abgelegt, die für den MCSA Office365 notwendig sind. Beide Prüfunden waren relativ easy. Heute habe ich mal einen Blick in mein MCP-Portal geworfen und wollte kontrollieren, ob meine Prüfungen alle dort eingetragen sind, da sehe ich auf einmal, dass ich den MCSA Windows Server 2012 schon erreicht habe, und zwar durch die Prerequisites 70-410, 411 und eine der Office365-Prüfungen (70-346). Das kann ich mir irgendwie kaum vorstellen, da diese Prüfungen weder den Bereich von 70-412 streifen, noch besonders schwierig sind. Ist das ein Fehler im Portal oder hat sich MS da absichtlich was bei gedacht? Da kann ich mir die 70-412 ja eigentlich sparen und mich evtl. auf andere Themen konzentrieren (evtl. SQL/Sharepoint) VG Marcel

Bedankt :)

Hi@all, ich habe vor einiger Zeit schon einen Central store eingerichtet, um einfacher Gruppenrichtlinien für aktuelle Betriebssysteme/Office-Versionen anlegen zu können. Im Sysvol-Verzeichnis sind aber unter Policies neben dem neuen Policydefinitions-Store noch die alten Gruppenrichtlinien-GUID-Ordner vorhanden. Ist zwar nur eine geringe Dateigröße, aber ich würde trotzdem gerne verstehen, wie "man" damit umgeht, vor allem in großen Umgebungen, wo sich im Laufe der Jahre viele GPO-GUIDs angesammelt haben. Laut http://deployhappiness.com/creating-the-group-policy-central-store-updated-for-windows-8-12012r2/kann man alte adm-files löschen, die man nicht selber importiert hat. Soweit mir bekannt, wurden vor dem Central store nur Richtlinien für OS/Office-Einstellungen erstellt ... also keine ADM-Templates für irgendwelche speziellen Anwendungen/Einstellungen importiert. Bedeutet das, man kann im sysvol dann alles an alten GUID-Ordnern löschen? Wenn ich das richtig verstehe wird beim erneuten Editieren einer GPO doch dann das admx-Template verwendet (sofern es vorhanden ist). Danke und viele Grüße Marcel

edit - habs gefunden ... warum auch immer, in den DFS-Option war" exclude targets outside of the clients's site" aktiv ...

Nachdem ich die Dienste neugestartet hatte, ging es ja (scheinbar) erst wieder ... aber sobald der Anmeldeserver der neue DC ist, kann ich nicht mehr über den Namespace auf das DFS zugreifen, weil er dann versucht, auf die dfs-Freigabe des neuen DC zuzugreifen (die natürlich nicht existiert, da der DFS-N auf den beiden alten DCs liegt). Mir wäre neu, wenn ich alle DCs zu DFS-Nameservern konfigurieren müsste ... ist das denn so?

Hi@all, ein gar merkwürdiges Problem: ich habe einen Server in der azure-Cloud zum DC heraufgestuft, seitdem kann ich den Server nicht mehr RDPen. Ich sehe nach der Anmeldung kurz ein Fenster mit den please wait for local session manager, danach ist alles schwarz. Der Server läuft aber, ich kann mit einem anderen 2012er über den Servermanager darauf zugreifen - nur kein RDP. Wenn man nach blackscreen rdp und 2012 googelt, findet man ganz viele ähnliche Fälle, aber die Lösungen funktionieren bei mir nicht. Strg+Alt+Ende kann ich z.B. wählen, danach sehe ich auch wieder ein Bild, aber wenn ich lock und unlock wähle - schwarz Diverse Parameter im rdp-File habe ich auch getestet (Auflösung etc) - keine Änderung. Es ist keine Core-Installation. Dienste sind alle gestartet. Nach einem remote reboot ändert sich auch nichts ... Ach ja, andere Domainadmins können sich gar nicht anmelden, da sieht man kurz nen Blackscreen und dann ist das Fenster weg. MTU hab ich mal ausgeschlossen, indem ich außerhalb des VPN-Tunnels versuche zuzugreifen ... Zum Mäusemelken :( LG Marcel

Hallo zusammen, wir haben folgende Topologie: 2 DCs im 0er-Netz Clients im 12er-Netz Alles getrennt durch vlans, Routing zu den einzelnen Netzen funktioniert. Nun hat sich unsere GF in den Kopf gesetzt, einen dritten DC im Microsoft Azure aufzusetzen. Gesagt, getan, ich habe ein VPN aufgesetzt, einen Server installiert, Routing funktioniert, soweit alles prima. Dann habe ich in unserem existierenden AD ein neues Subnet und eine weitere Site eingerichtet und das hat dem DFS wohl nicht gefallen. Dummerweise habe ich anschließend den neuen Azure-Server als DC promoted und während der Installation festgestellt, dass das DFS nur noch aus dem Server-Netz funktioniert. Also hat wohl die Einrichtung der neuen Site/des neuen Subnets die Erreichbarkeit des DFS aus dem Client-Netz gestört. Bin gerade etwas ratlos, wie kann ich das wieder hinbiegen? Die DFS-Namespace-Server sind übrigens unsere beiden "alten" DCs ... muss ich den neuen DC auch in den DFS-Namespace aufnehmen? Würde mich jetzt wundern, da das Problem ja schon aufgetreten war, bevor der neue Server zum DC wurde. VG Marcel ok ich antworte mir mal selber ... mittlerweile gehts wieder, ich hab die DFS-Dienste neu gestartet.

Das ist ein zweiter DC ... von daher ist das schon richtig so. Ich hab's herausgefunden - das Zertifikat des NLS-Servers (gehört zur AD-Topologie) war auch abgelaufen. Natürlich hatte die Daten niemand in einem Kalender eingetragen, so dass ich erstmal selber suchen durfte. Nachdem ich die Zertifikate verlängert habe, ging es wieder. Das hier hat mir geholfen: http://www.ivonetworks.com/news/2012/09/mark-your-calendars-for-directaccess-certificate-expiration/ Danke auf jeden Fall für die Hilfe :) ... sowas braucht Montags echt kein Mensch.

Ich glaube ich bin dem Rätsel auf der Spur. Wir setzen auch Direct access ein, da habe ich gerade gesehen, dass das interne Zertifikat abgelaufen ist. Ich habe nun per autoenrollment ein neues "abgeholt" und im DA hinterlegt. Aber es funzt immer noch nicht :(. Aber es kann ja nur daran liegen, am Freitag, den 29.8 gings noch, zum Ablauf dieses Certs. Die Notebooks sind derzeit nicht mit dem WLAN verbunden. 1. DC 2. Client

Hallo, ich habe seit heute früh ein äußerst unangenehmes Problem. Und zwar haben einige Clients keinen Kontakt mehr zum DC. Netzwerkkonnektivität ist gegeben, die DCs können auch über die IP-Adresse erreicht werden. Allerdings trägt Windows 8 bei der Netzwerkidentizierung nicht "Domänennetzwerk" sondern privat oder öffentlich ein. Außerdem bekommt der Ethernet-Adapter auch noch den Namen eines WLAN-Gastnetzwerkes zugewiesen. Dadurch kann das AD nicht kontaktiert werden und DNS funktioniert nicht. Es ist nur ein Teil unserer Geräte betroffen, bisher scheinbar nur Notebooks. Win7-Clients (bisher) scheinbar auch nicht Ich habe folgendes getestet: Netzwerk-Karten deinstalliert, neuinstalliert, Notebook aus der Domäne geworfen, neugestartet - danach konnte ich das NB nicht mehr in die Domäne aufnehmen weil er den DC nicht findet. Nachdem ich das Netzwerkkabel nochmals gezogen hatte, war auf einmal wieder das Domänennetz da, ich konnte dieses eine NB aufnehmen. Nach dem nächsten Neustart wieder das gleiche - Netzwerk war privat und keinen Kontakt zum DC. Ich bin absolut ratlos im Moment :( Danke für Tipps Marcel

Sorry, kam nicht früher zum Antworten ... die Tunnel sind WG zu WG, dahinter dann noch eine geroutete Switchlandschaft. Ich habe derzeit ein Ticket mit Watchguard offen, ich berichte, falls es was interessantes ergibt. Derzeit fällt denen leider auch nur "an der MTU rumschrauben" ein ;). Ich häng bei Gelegenheit auch mal ein Notebook direkt an einen freien Port ...

Ok, das war ein Vorschlag aus dem Watchguard-Forum ... aber woran kann die lahme RDP-Performance denn sonst noch liegen? Grüße Marcel

Hi zusammen, wir nutzen mehrere Watchguards in unserem Unternehmen, dabei u.a. DIALin-SSLVPN und Ipsec-Tunnel ... hin und wieder auch IPsec-Dialin. Leider ist die RDP-Performance relativ schlecht, man sieht bei Verbindungen zu Win2012-Terminalservern auch oben in der RDP-Leiste nur 1-2 Balken und das ganze ist sehr laggy. Allerdings in erster Linie bei SSL-Dialin (über einen OpenVPN-Dialer) und dem IPsec-Tunnel. Die Performance ist bei IPsec-Dialin am besten, aber da haben wir nur 5 Lizenzen. Ich vermute mal, dass es an der MTU liegen könnte ... ich habe diesen sowohl auf dem Client, als auch dem Server auf 1400 mit netsh interface ipv4 set subinterface xyz mtu=1400 store=persistent festgelegt, aber ich sehe keine wirkliche Änderung. Muss ich die MTU sowohl eigentlich auf dem Client als auch dem antwortenden Server festlegen? Woran kann es evtl. noch liegen? VG Marcel

Hmm war doch mal wieder ne banale Sache - die Windows 2012R2-Updates waren noch nicht approved ;) ...

"windowsupdate" ist ein cname und verweist aus den WSUS ... der wird per GPO an alle Clients und Server verteilt und alle anderen holen sich Updates ab ... auch die Win8.1er. Ja, die Server-Version ist 262 ... Danke für die Scripte, das richte ich mir auch mal so ein!

Hey, danke ... ich schau mal in die Logs, das Script lass ich dann auch mal täglich laufen. @sunny61 Was meinst du mit cleanup-Script. Das re-index-Script von der Technet-Seite? Das hatte ich offenbar auch schonmal benutzt, ich hab es gerade auf dem WSUS entdeckt ;). Ich habe es aber damals nur einmalig laufen lassen. Ersetzt das Script eigentlich die Aufgabe, hin und wieder mal die superseeding Updates zu cleanen, damit die Datenbank nicht zu groß wird? Im Log steht:

Hallo zusammen, eigentlich schon ein alter Hut, mein WSUS 3 auf Win2008R2 erkennt Win2012R2 als Win2000 Datacenter. Laut Microsoft nur ein kosmetisches Problem, aber tatsächlich bekommt der Server keine Updates. Ich habe alle erhältlichen Patches und Hotfixes bereits installiert (war ja hier auch schon mal ein Thema), also KB2734608 KB2828185 Windows 8.1 wird auch nur als 6.3 erkannt, aber erhält so weit ich weiß Updates ... Auf dem 2012R2-Server habe ich nach einem WSUS-Neustart folgendes ausgeführt: Net stop wuauserv rd /s %windir%\softwaredistribution\ Net start wuauserv wuauclt /resetauthorization /detectnow wuauclt /detectnow wuauclt /reportnow Aber bringt auch nichts ... Soll ich den Client nochmal aus der WSUS-Konsole löschen und nochmal detectnow reportnow ausführen? VG Marcel