Mirastarix

Jaein...wenn ich das richtig verstanden hab, haste jetzt auf D:\ das roaming profile liegen, welches beim Login auf c:\users synchronisiert wird. Löscht Du das auf c:\ resetteste nur das lokale Profil, welches beim nächsten Login wieder neu erstellt wird von D:\

Update die iPhones mal auf 10.2.1. Apple hat offensichtlich zurückgerudert und akzeptiert wieder sämtliche Zertifikate. Zumindest hab ich gestern bei nem weiteren Test wieder die Option bekommen, einem internen Zertifikat zu vertrauen. Welchen Fehler geben denn die iPhones aus? Können die Accountinfos nicht überprüft werden oder ist die Verbindung fehlgeschlagen oder, oder...

Moin, nein, die CRL ist nur von intern zu erreichen und Online Responder ist imho gar nicht installiert. Hm, auf den Gedanken bin ich noch gar nicht gekommen, dass es evtl. nur an der nicht erreichbaren CRL liegen könnte. Könnte man bei Gelegenheit mal testen - leider haben wir kein MDM, sodass unser internes root cert nicht automatisch ausgerollt wird. Damit und mit der von außen erreichbaren CRL könnten evtl auch die iPhones bei der Konstellation funktionieren. Ich mache nun aber erstmal mit SplitDNS weiter. Muss nur noch entsprechend die DNS Zonen basteln, weil die AD domain schon älter und noch ne .local ist. Heute würd ich auch gleich die TLD intern nutzen...hinterher is man immer schlauer :D

Moin, ja, es ist zurzeit ein öffentliches SHA1 gebunden und iPhones können normal verbinden - wird aber noch auf SHA256 gewechselt. Wichtig war den iPhones nur, dass sie eine öffentliche root CA erreichen können, um die chain bis dahin zu prüfen. Selbst beim Importieren des internen root Zertifikats konnte keine Verbindung hergestellt werden.

Super! Achsoo...ok, da wird er dicker^^

Hi zusammen, wie die meisten haben auch wir eine gewachsene Struktur und öffentliche Zertifikate waren meist nur für Websites interessant - kostet halt^^ Ich kann das Ganze nun auch leider nicht in einer Testumgebung nachstellen sondern muss am lebenden Patienten operieren. Bevor ich alles kaputt mache und hektisch backups einspielen muss, frag ich lieber nochmal nach^^ Folgendes Szenario: An Exchange war ein internes Zertifikat von der internen CA gebunden. Alles lief wunderbar bis die ersten Kunden mit iPhones auf iOS 10.1 upgedatet haben. Ab iOS 10.1 war ActiveSync mit dem internen Zertifikat nicht mehr möglich und es musste zwangsläufig ein Zertifikat von einer öffentlichen CA gekauft und gebunden werden. Soweit so gut...iPhones können wieder connecten aber jetzt bekommen interne Clients natürlich die Fehlermeldung, dass der interne Name nicht als SAN mit angegeben ist. Leider geht aus keinem Guide wirklich eindeutig hervor, wie Exchange genau für diesen Fall konfiguriert werden muss. Ich vermute, dass für die virtual directorys nun jeweils statt des internen FQDN bei interner URL die externe URL eingetragen werden muss, damit auch intern das öffentliche Zertifikat genutzt wird. So würde intern meinetwegen über https://mail.meinedomain.de und extern ebenfalls über https://mail.meinedomain.de verbunden werden wie z.B. hier beschrieben. Geh ich recht in der Annahme, dass nach dem Ändern der internen URL auf die externe URL auch von intern die Zertifikatsfehler verschwinden? Danke für´s Feedback

Probiers mal damit (das fett gedruckte), wobei ich gerade nicht wirklich verstehe, was Du meinst, wenn Du im Printserver unter "Drucker" keine Drucker siehst. Dort hast Du sie doch installiert, freigegeben und per GPO verteilt oder nicht?