NorbertFe

Was steht denn im eventlog des clients?

Denkt denn niemand an die Kinder? ;)

Andere Konten als Exchange landen nicht in ost. Da is immer ne pst beteiligt.

Das geht nicht. Wenn überhaupt dann mit dism und wenn dann geht auch nur von niedrig zu hoch und nicht zurück.

Mit welchem Nutzer versuchst du das denn? und in welchen Gruppen ist der Mitglied?

Vielleicht weil ein Tippfehler in der internen steckt. ;)

Der cn wird ausgewertet, ist aber nur gültig, wenn der identische Name auch im san steht. Das machen alle aktuellen Browser so und man kann per policy das Verhalten bei einigen beeinflussen.

Häh ? Auch 2012r2 kann das. oder hat hier jemand was anderes behauptet? Unabhängig davon sind natürlich modernere os meist sinnvoller.

Wo? Du musst deiner ca erst erlauben san mit ins Zertifikat zu schreiben. https://www.vkernel.ro/blog/configure-internal-windows-ca-to-issue-san-certificates

Kein Problem. :) falls noch fragen sind oder mehr Wände auftauchen... ;)

Was is daran denn so "schwer" ;) Der CAS des 2016 baut eine https Verbindung zum CAS 2010 auf. Deswegen mußt du ja auch Outlook Anywhere für 2010 aktivieren und konfigurieren.

Nein muß man nicht zwingend konfigurieren und würde dir jetzt sowieso nichts helfen, denn ein RPC CAS Array ist für RPC Zugriffe zuständig und in der Migrationsphase stellst du sowieso alles auf https um. Das RPC CAS Array macht RPC und hat damit _nichts_ im https Zertifikat zu suchen. Technisch sollten das zwei komplett andere Namen sein. Siehe oben. Bye Norbert PS: Lies dir doch mal die Whitepaper bzw. MIgrationsanleitungen so durch, die es gibt. Da erledigen sich viele deiner Fragen :)

Ja, in einem der zwei Policieszweige. War gestern zu faul noch den zweiten zu listen. Danke für die Konkretisierung.

Ja ich weiß was ich geschrieben habe. Aber das hat der to ja offensichtlich auch schon in ähnlicher Form umgesetzt. ;)

Immer diese Ungeduld ;) ist das ein Domain Controller?

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time

JAHAAAAAA. DAs ist normal, weil die Policy in einen anderen Zweig der Registry schreibt. Schrub ich aber auch schon oben.

Du kannst schauen, welche Profile mit welchem Datum auf den Rechnern existieren.

Gelten für die anderen Client, Member und DCs irgendwelche Richtlinien, die am Timeservice rumpopeln?

Logisch, aber eben unter "Policies" Das was du das siehst sind halt die Registry-Daten ohne Policy. Wenn da Unterschiede sind, dann klappt irgendwas nicht so, wie es soll. Also ja, einfach mal schauen, dass dein PDC per GPO korrekt die Daten von deiner Firewall holt und dann schauen wir weiter.

Handwerkermentalität: geht doch. ;)

Nein erkennt man nicht. Und schon gar nicht auf der clientseite.

Toll ein Import mit batch und Klartextpassword. Ich denke es wird klar, warum Nils und ich unsere Aussagen getroffen haben.

Er will EIN Zertifikat an viele Nutzer verteilen. Und zwar garantiert ein externes. Da hilft dir die eigene ca gar nix. Und Skripten würde ich sowas auch nicht, denn das widerspricht irgendwie dem Sicherheitsgedanken wenn man private keys irgendwie „verteilt“.

Ja aber nur für öffentliche Schlüssel und die Anforderung klingt nach private keys, was aber per goo nicht funktioniert.