NorbertFe

Die Tests könntest du auch mit einer/mehr 1g Karte/n und auf einem anderen System durchführen. Logisch, oder? ;)

Einfach die eine Karte raus und die andere rein. Per Powershell oder per GUI, wie du gerne magst. Wenn du alle einbindest wird dir halt ein Fehler beim Team angezeigt, weil ja kein Link auf den Ports ist. Bye Norbert PS: Selbst mal was zu testen ist jetzt nicht so deine Vorliebe oder?

Richtig. Nicht so schwer vorstellbar, oder?

Das ist einer der wenigen Prozess, der ein gpupdate /force erforderlich macht, und den man immer mal wieder braucht. Wenns trotz /force nicht ankommt (ohne dass man das per GPO verteilt), dann ist irgendwas anderes im Busch und man sollte mal schauen wo das Problem liegt.

Im Moment 2012R2. Natürlich wurden meine Zertifikatsvorlagen geändert. Wer verwendet denn bitteschön freiwillig die Default Templates (evtl. mal von den Domaincontroller Vorlagen abgesehen)? ;)

Ist das eine Enterprise CA? Da sollte man das Root CA per Default doch nicht verteilen müssen, da es übers AD doch eh verteilt wird. Insgesamt ist mir persönlich das Problem aber noch nicht untergekommen. Hast du denn mehr Infos gesammelt?

Wieso denn eine dritte? Du sollst ja aus der bisherigen dann einen Port ungenutzt lassen. So schwer zu verstehen ist das ja nicht. ;) Genau.

Was schlußfolgerst du daraus? ;) Falsches SLA oder falsche Konfiguration oder falsche Erwartungshaltung? Grundsätzlich sollte man auch einen 1G Adapter als Standby konfigurieren können, aber soweit ich weiß, geht das nur wenn du nur einen 10G Adapter im Team hast (also 1x1G und 1x10G im Team). Alternativ würde ich eben von den 2Port 10G Karten auf 2x 1Port 10G wechseln bzw. jetzt einfach noch eine 1Port 10G dazustecken.

Nein, wäre mir jetzt keine bekannt und würde ich auch nicht anpassen. Manche haben während der Migrationsphase einfach einen Task laufen, der den IIS AppPool alle 15 Minuten resettet. Dürfte die praktikabelste Lösung sein. Wenn die Migration fertig ist, stört das ja dann nicht mehr und der Task kann entfernt werden.

Steht doch im von dir geposteten Artikel: https://support.microsoft.com/en-us/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange "After the mailbox move is completed, Exchange Server 2013 or 2016 continues to proxy the autodiscover request to Exchange Server 2010. Exchange Server 2010 responds with a 302 redirect back to Exchange Server 2013 or 2016 (depending on the upgrade)." Ist halt ein Cachingproblem. Bye Norbert

Zur Info, warums das dann eben bspw. für Server nicht mehr gab: https://cloudblogs.microsoft.com/windowsserver/2013/01/12/fix-available-for-root-certificate-update-issue-on-windows-server/ Wenn man den Links dort folgt kommt man bspw zu: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn265983(v=ws.11) Vielleicht wäre das ja eine Lösung für dich. ;) HTH Norbert

Eben ;) Und wenn man die dann eh "ungesehen" übernimmt, dann kann mans auch gleich automatisch regeln. Vorteil bei GPO Verteilung ist, dass die Dinger auch verschwinden vom PC, wenn man sie aus dem GPO entfernt. :)

Ja solche Netzwerke gibt es, die sowas begrenzen und evtl. will man ja auch nicht einfach jedes RootUpdate zulassen. Dann bleibt eben nur der "manuelle" Weg, herauszufinden, welche Root-Zerts man tatsächlich benötigt und diese dann entsprechend an seine Clients zu verteilen. Eine "Wasch mich aber mach nicht naß" Policy gibts an der Stelle eben tatsächlich nicht. :) Nein das Offline Paket gibts afaik nicht mehr. Und wenn du sowieso "pauschal" alles was MS zuläßt an der Stelle zuläßt, dann kannst du auch den Zertifikatsagent die Root-Zerts laden lassen.

Klar. Root Certificates per GPO an alle verteilen. :P Ist eben manuell.

Ja.

Ich konnte mich an den "mistigen" Workaround auch noch erinnern, weil ich den auch mal benötigte. ;) Schön, dass ich das offenbar nicht allein mal benötigte.

Ja. Das automatische Root Zertifikatsupdate gibts seit XP SP2 meine ich: https://gpsearch.azurewebsites.net/Default.aspx?PolicyID=4716

Hier gibts diese Probleme nicht. Weder mit dem Computerzertifikat für DirectAccess noch mit dem für RDP. Also würde ich nicht von einem grundsätzlichem Problem/Bug ausgehen.

Hier hast du noch einen anderen beschrieben. ;) https://www.mcseboard.de/topic/211221-dhcp-option-60-vendor-class-identifier-identifizieren/?do=findComment&comment=1338985 Bye Norbert PS: Ja eine VLAN Trennung ist eigentlich das sinnvollste und sauberste.

Welche? Wenns irgendwas mit wsus zu zunäht, wird’s wohl an der selben Stelle zu finden sein. ;)

Das sagt auch jeder der nen Unfall baut. ;) ich würde versuchen das was nicht auf einen exchange gehört runterzuziehen auf einen eigenen Server. Danach kann man weitersehen.

Backup anfertigen. Das ist keine Raketentechnik.

Wenn du jetzt sowieso schon 4.7.1 drauf hast dann einfach direkt auf cu9!

Also kommen die nicht „direkt“ zum Server. ;)

Die wsusid ist nicht die sid.