andrew

Hallo Sunny61 Auf diesem einen PC, bei welchem ich sicher vom Kunden gemeldet bekam, dass ab und zu die Verbindung vom Outlook zum Exchange 2016 verloren geht (äussert sich so: plötzlich erscheint einfach ein Passwort Fenster), arbeitet immer die gleiche Person. Jedoch gäbe es gemäss Kunde noch sicher Minimum 2 weitere Arbeitsplätze, an denen dieses Phänomen auch auftrete? Gemeinsamkeit aller Arbeitsplätze: Als OS ist Win7 im Einsatz, nur so am Rande erwähnt, Outlook Client ist Office 2016 STD. Soweit ich mich erinnere, hatte ich deine Lösung, den Cache 1x deaktivieren und wieder erneut aktivieren, dem Kunden bereits schon kommuniziert, weiss aber allerdinsg nicht mehr, ob diese drei Arbeitsplätze mit diesem Workaround schon behandelt wurden?! Meine persönliche Meinung dazu ist, wenn mehrere Arbeitsplätze betroffen sind, kann es fast nicht am Cache liegen, wie siehst Du/ Ihr das? cheers André

Aha, also eben doch mit einem Outlook Client :) und in welcher Form sollte man Deiner Ansicht nach sowas sonst "migrieren"? Würde auch gerne per Shell die Sache umsetzen, aber wenn es nun mal keine Bordmittel bei EX 2010 gibt? what else Ich kenne nur noch den Weg über Dritthersteller Tools, um Public Folders von älteren System wie Exchange 2010 migrieren zu können?! Dritthersteller Tools, welche sicher nicht gratis sind oder kennst Du eines, bei welchem man den vollen Funnktionsumfang hat und dabei keine Grössenbeschränkungen von Public Folders in Kauf nehmen muss?

Ich hatte den Export nicht gemacht :-) Darum nochmals, wie?

wenn ich die .PST finde, werde ich dies selbstverständlich tun, aber es sieht nicht danach aus ;( Angenommen, ich finde Sie nicht, wie exportiere ich via Exchange 2010 Shell den Public Folder erneut?

1. Ja, es ist der gleiche Kunde (in Bezug Mail Migration, SBS 2011 > Exchange 2016) 2. nun per remote auf der Workstation. Hat als OS Win7, Office STD 2016 (16.0.4549.1000) 32 Bit. Dass es am Build der aktuellen Outlook Version liegen könnte, glaube ich kaum, wie seht Ihr das? 3. CTRL Taste + rechte Maustaste auf Outlook Icon, im Kontextmenü Verbindungstatus zeigt unter anderem folgende Infos Servername: https://mail.domainKunde.ch/mapi/.. Status: hergestellt Protokoll: HTTP Verschlüsseln: SSL Anfr/ Fehler: Die Spalte Fehler beinhaltet keine Einträge, sprich, keine Fehler. Sitzungstyp: Hintergrund, Vordergrund, Cache Version: 15.1.1034.26 Knopf: Verbindung wiederherstellen bewirkt, dass A keine Zertifikatsmeldung erscheint und B, dass beim Outlook unten rechts steht: Alle Ordner sind auf dem neusten Stand | verbunden 4. CTRL Taste + rechte Maustaste auf Outlook Icon, im Kontextmenü E-Mail Autokonfiguration testen zeigt unter anderem folgende Infos (Reiter Ergebnisse) interne URL, externe URL für Outlook Web Access: https://mail.domainKunde.ch/owa (diese URL kann auch von extern verwendet, OWA funktioniert mit der gleichen URL, intern wie extern) Protokoll MAPI-HTTP: sowohl interner wie externe URLs werden hier aufgeführt, sprich: https://mail.domainKunde.ch/mapi bzw. https://mail.domainKunde.ch/nspi Protokoll: Exchange-HTTP, Server ist mail.domainKunde.ch, SSL=JA, alle URLs wieder auf https://mail.domainKunde.ch/EWS bzw. https://mail.domainKunde.ch/OAB , Authentifizierung = NTLM, Name des Zertifikat-Prinzipals: msstd:mail.domainKunde.ch Protokoll: Exchange-HTTP, Server:mail.domainKunde.ch, SSL=JA, Gegenseitige Authentifizierung=JA, URLs= Alle mit https://mail.domainKunde.ch/... beginnend. 5. CTRL Taste + rechte Maustaste auf Outlook Icon, im Kontextmenü E-Mail Autokonfiguration testen zeigt unter anderem folgende Infos (Reiter Protokoll) autodiscover.domainKunde.ch/Autodiscover/Autodiscover.xml Erfolgreich 6. Zertifikat für den Zugriff auf OWA via extern ist ein öffentliches Zertifikat im Einsatz. Prüfe ich die Seriennummer dies öffentlichen Certs, so stelle ich fest, dass in Bezug Dienste nur zwei Dienste an dieses Zertifikat gebunden sind, IIS und SMTP. als alternative Antragstellernamen sind noch zwei URLs eingetragen: *.domainKunde.ch und DomainKunde.ch Unter dem Punkt Zertifikate auf dem Exchange gibt es noch mehr Zertifikate, zu meinem erstaunen gibt es hier noch ein Zertifikat mit dem Namen Exchange Zertifikat, an welches 4 Dienste gebunden sind, nämlich IMAP, POP, ISS und SMTP. Des Weiteren lauten hier die alternativen Antragstellernamen: interner NETBIOS Name Exchange Server und FQDN interner Exchange Name. Bemerkung dazu: gemäss Punkt 4. Name des Zertifikat-Prinzipals: msstd:mail.domainKunde.ch ist das öffentliche Zertifikat im Einsatz bzw. in Verwendung, für welches auch nur zwei Dienste angebunden sind, nämlich ISS und SMTP, gehe ich richtig? Oder anders gefragt, wie weiss ich nun oder kann prüfen, welches Zertifikat für die Kommunikation mit dem Outlook verwendet wird?

Genau, das wäre sicher interessant, ob diese Mails überhaupt exportiert wurden? genau .. kannst du willst Du, kann Jemand, will Jemand noch Stellung zu meinen 3 Fragen nehmen? ;) Die Fragen zusammengefasst: 1. Wenn ich Stand heute, nochmals einen Export des Public Folders vornehme, welches Vorgehen soll ich wählen? via Shell auf dem Exchange 2010? wenn ja, Befehl? 2. Gibt es auf einem Exchange Server Richtlinien (Exchange 2010 und oder auch neuer, weil mich diese Frage nun gleich generell interessiert), welche verhindern könnten, dass beim Export von einem Public Folder aus welchen Gründen auch immer, auf Grund von Grössenbeschränkungen nicht exportiert werden? 3. Angenommen, ich tätige diesen Export nochmals, auf welche Art auch immer, laufe ich Gefahr, dass die bestehenden Mails, welche zurzeit im Public Folder sind, durch ältere Mails beim Import überschrieben werden? Nette Grüsse Andrew

Hi all Mir hat ein Kunde geschildert, dass es sicher Minimum zwei Arbeitsplätze gäbe, an denen ein OS mit Win7 sei (welche Office Version dort installiert ist, entzieht sich zurzeit meiner Kenntnis, werde ich aber heute am Morgen in Erfahrung bringen), bei welchen das Outlook ab und zu, am Mittag hätte man das schon festgestellt, die Verbindung verliere. Frage: 1. kann es daran liegen, dass z.B. Outlook 2010 weniger stabil läuft als Outlook 2013 und darum ab und zu die Verbindung verliert? 2. Wie soll ich dieses Problem am besten eingrenzen, meine, wenn gemäss User ab und zu mal die Verbindung verloren geht, wird es schwierig, ich müsste aus meiner Sicht genaue Zeitangaben vom User erhalten, damit ich ggf. auf der Workstation und oder auf dem Exchange irgendwo was feststellen könnte, in einem LOG oder so? Die Frage wäre dann, wo auf dem Exchange Server diese Verbindungsunterbrüche zu suchen sind? Netter Gruss Andrew

Hi all Situation: Wir haben bei einem Kunden eine EDV Migration vorgenommen. Ich beschränke mich nun hierbei nur auf den Exchange Teil und schildere kurz mein Problem. alte Umgebung: war ein SBS 2011 Server mit Public Folder (mehrere GB gross) neue Umgebung: Exchange 2016 Server, Public Folder Import von mir durchgeführt worden via eine Workstation in der neuen Umgebung mit Outlook 2013. Der Export wurde nicht von mir gemacht, wenn ich mich richtig erinnere, hatte ich beim Import eine .pst verwendet - ist schon ein paar Wochen her und erst jetzt bemerkte der Kunde, dass anscheinend Mails, welche eine gewisse Grösse hätten, die Rede war von 11 MB nicht exportiert bzw. importiert worden seien?! Meine Aufgabe ist nun, dafür zu sorgen, dass der Kunde alle Mails des Public Folders erhält. Meine Bedenken und Fragen dabei 1. Der Kunde hat in der Zwischenzeit gearbeitet, sprich, wenn ich jetzt den Export des alten Exchange Servers vornehmen würde und beim alten Server wieder importieren würde, was wäre dabei mit den neuen Mails, welche in der Zwischenzeit vom Kunde im Public Folder bearbeitet wurden? die dürfen nicht überschrieben werden (hilft mir dabei die Funktion des Outlooks, keine Duplikate importieren und oder soll ich generell via Outlook auf einer Workstation den Import (und wenn möglich, auch den Export machen? beim Export müsste ich ja eine alte Workstation haben, welche noch in der alten Domain ist?) 2. Generell Frage: Welches Vorgehen ist beim Public Folder das einfachste, das sicherste für meinen Fall? 3. Warum ist mir bzw. uns dieser Fehler unterlaufen, mir ist oder war bis dato nicht bekannt, dass es auf dem alten Exchange eine Policy gibt, welche genau für diesen Fehler Schuld sein könnte, Frage: gibt es eine solche, welche Policys muss ich auf dem alten Exchange in der Shell prüfen, damit der Export und Import nun ALLE Mails berücksichtigt? Vielen Dank für die Unterstützung ;) Andrew

Interessant, was ich da lese. Also bei einem derart großen Betrieb wie Microsoft kann ich mir nicht vorstellen, dass bei ein "paar" Entlassungen von MAs dann plötzlich bestimmte Entwicklungsabteilungen Ihren Arbeiten nicht mehr nachkommen können? Auch wenn Microsoft das Cloud Geschäft pushen will, macht es doch?! Wegen dem könnt Ihr trotzdem die Hilfe in der Exchange Shell, z.B.für Befehle beibehalten wie in früheren Zeiten. Es wird sowieso immer Informatik Firmen geben, welche den Kunden Minimum 2 Offerten unterbreiten, eine O365, eine mit lokalem Exchange. Denn ab einer bestimmten Anzahl Postfächer wird es immer so sein, dass Kunden sich eben nicht immer für O365 entscheiden, sondern für eine lokale Exchange Version :-) Und weil es die lokale Exchange Version immer braucht (aus dem soeben genannten Grund, rein finanzieller Natur), macht es auch Sinn, wenn Microsoft die lokalen Exchange Versionen weiter ausbaut, updatet. Die lokale Exchange Version ist eine Lösung, O365 ist eine andere Lösung. Der Kunde, die Kunden haben somit die Wahl und können frei entscheiden, sowohl für den Kunden wie auch für Microsoft eine "Win Win" Situation oder nicht? Darum: Löst das Get-Help Problem, ich und zig Admins sind wieder voll zufrieden plus die Kunden, weil weil wir dadurch möglicherweise bessere Arbeit in Bezug Exchange Support leisten :-) Ja, liebe Microsoft, unsere Kunden sind auch Ihre Kunden und Ihr Microsoft wollt doch zufriedene Kunden oder nicht? :-) Cheers Andrew

Ich merke, man tut sich hier im Board gerade sehr schwierig, mir klar antworten zu wollen? Dann helfe ich mal etwas nach :-) @ In welche Richtungen gehen die Diskussionen? Stand? @ aus welchem Grund will man die Hilfe für Cmdlets abschaffen? @ ist ein Update Schuld, dass auf meinem und sicher aif Minimum 1 Kunden System (Exchange 2016) die Hilfe für Cmdlets in der EX Shell NICHT mehr funktioniert?

Hallo Board Veteran Leider habe ich das jetzt nicht ganz verstanden. Kannst Du etwas mehr Infos in deine Aussage fliessen lassen? :-) Diksussionen gibts, zwischen MVP und PG? Du bist der MVP und wer ist der PG? Wie gesagt, kapiere es nicht ganz *grins*. Ist es ein bekanntes Microsoft Problem, JA oder NEIN? Wenn ja, was macht man dagegen? Bin übrigens heute gerade auf einem Kunden Server herum gekurkt Und: wollte wissen, ob auf diesem Exchange das gleiche Problem wie auf meinem vorhanden ist und siehe da, fast das gleiche Phänomen wie bei mir. Mit dem kleinen Unterschied, dass es am Anfang so aussieht, als würde alles funktionieren, er begann mit den updaten, aber schlussendlich the same, seitenweise, in roter Schrift Fehlermeldungen dass es einem fast übel wird *lach*. cheers Andrew

Hi all Hat schon Jemand auf einem Exchange 2016 (oder ggf. mit einer anderen Exchange Version) beim Aufruf des Get-Help Befehls und anschliessender Eingabe des Befehls als Ausgabe seitensweise Fehler angezeigt bekommen? Wie bzw. mit welchen Benutzerrechten rufe ich diesen Befehl auf? - verbinde mich per RDP auf den Exchange Server in meiner LAB Umgebung (habe nur einen Exchange 2016, läuft separat auf einer VM) - mit dem Benutzer, mit welchem ich mich per remote anmelde, hatte ich ursprünglich den Exchange Server installiert. Habe ansonsten beim Ausführen von Exchange Befehlen keinerlei Probleme bzw. Fehlermeldungen. Egal, zu welchem Befehl ich Get-Help eingeben, nie erscheint so wie es sein sollte, eine Hilfe zum Befehl. Hier ein Beispiel: Get-Help Test-OutlookConnectivity -Online, generiert z.B. diese Fehler (Teilauszug bzw. die letzten paar Zeilen am Schluss der Fehlermeldung.) ------------------------------------------------------------------------- Error in TypeData "Deserialized.Microsoft.Exchange.Configuration.Common.PropertyBag": The member TargetTypeForDeserialization is already present. Error in TypeData "Microsoft.Exchange.Common.WeekDayAndTime": The TypeConverter was ignored because it already occurs. Error in TypeData "Microsoft.Exchange.Common.WeekDayAndTime": The member SerializationData is already present. Error in TypeData "Deserialized.Microsoft.Exchange.Common.WeekDayAndTime": The member TargetTypeForDeserialization is already present. Error in TypeData "Microsoft.Exchange.Common.ScheduleInterval": The TypeConverter was ignored because it already occurs. Error in TypeData "Microsoft.Exchange.Common.ScheduleInterval": The member SerializationData is already present. Error in TypeData "Deserialized.Microsoft.Exchange.Common.ScheduleInterval": The member TargetTypeForDeserialization is already present. Error in TypeData "Microsoft.Exchange.Cluster.Replay.PersistentDagNetworkConfig": The TypeConverter was ignored because it already occurs. Error in TypeData "Microsoft.Exchange.Cluster.Replay.PersistentDagNetworkConfig": The member SerializationData is already present. Error in TypeData "Deserialized.Microsoft.Exchange.Cluster.Replay.PersistentDagNetworkConfig": The member TargetTypeForDeserialization is already present. " At line:1 char:1 + Get-Help Test-OutlookConnectivity -Online + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Get-Help], MethodInvocationException + FullyQualifiedErrorId : RuntimeException ---------------------------------------------------------------------------------------------- Auf rasche Feedbacks würde ich mich extrem freuen, finde beim Googeln dazu nicht wirklich hilfreiche Inputs :-( cheers Andrew

Danke Dir Habe den SPF Eintrag (DNS Record) abgeändert und werde umgehend die Sache testen. Wenn Du nichts mehr hörst, hat es funktioniert ;)

​Hi all ​Frage an euch alle Ein Kunde von uns hat O365. Mailfluss eingehend bzw. ausgehend funktioniert wunderbar. Für diesen Kunden haben wir im DNS folgenden SPF Eintrag zurzeit vorhanden: v=spf1 a include:spf.protection.outlook.com -all Der Kunde besitzt vor Ort ebenfalls eine FW, welche von Haus aus in der Lage ist, Mails empfangen zu können bzw. auch Mails zu versenden. Wenn ich jetzt möchte, dass ein Gerät, welches aus dem internen Netzwerk Mails an die FW sendet und diese wiederum die Mails an eine Mailadresse des Kunden weiterleitet (an eine O365 Mailadresse), so müsste ich ja nun unter anderem den SPF Record so anpassen, dass auch z.B. der öffentliche Name der FW, z.B. smtp.domainkunde.ch im SPF Record enthalten ist. Wie kann ich den SPF Record v=spf1 a include:spf.protection.outlook.com -all so anpassen, dass Microsoft beim Empfang vom Mails der Firewall smtp.domainkunde.ch nicht reklamiert und die Mails akzeptiert? :-) Netter Gruss Andrew

ok, alles klar. Danke für das Feedback, ist nett.

Soweit ich im Bilde bin (habe es selber noch nicht verifiziert, sind Aussagen des Kunden), werden die Drucker ausschliesslich vom RDP Client in die Session durchgereicht

Merci Board Veteran für das schnelle Antworten. Es scheint so (habe es selber noch nicht überprüft), als hätten die User am Standort A auf Ihrem lokalen Windows PC unter Drucker jeweils die Drucker hinterlegt, welche auf dem Printserver am Standort A (als an Ihrem Standort) eingerichtet sind. Wenn ich auf dem Print Server am Standort A nun in den Druckereigenschaften eines Druckerobjektes nachprüfe, wie die Porteinstellungen lauten, stelle ich folgende Konfiguration fest: - Portname: 192.168.w.x.z - Druckername oder IP-Adresse: 192.168.w.x.z - Protokoll: RAV (man könnte auch LPR auswählen) - RAW-Einstellungen. Portnummer: 9100 - SNMP-Status aktiviert, Communityname: public - SNMP- Geräteindex 1 Daraus interpretiere ich nun folgendes Mitarbeiter Hans Muster druckt verbinden sich mit dem RDS Server am Standort B, öffnet auf diesem eine Anwendung und druck via Druckerobjekt HP LaserJet XY (mit der IPv4 Adresse 192.168.w.x.z), welches auf dem Printserver am Standort A eingerichtet ist. Das heisst, damit der oder die Mitarbeiter am Standort A aus der Anwendung auf dem RDS Server am Standort B ohne Fehler drucken können, braucht es zusammengefasst - FW technisch von Standort A zu Standort B TCP/ UDP Port 3389 - Und: vom Remote Desktop Session Host (RDSH) am Standort B zum Printserver am Standort A den RAV Port 9100 habe ich das richtig verstanden :-) ?

hello together In Bezug drucken via RDS Server habe ich mir spontan die Frage gestellt, wie eigentlich genau der Mechanismus ist in Bezug: Netzwerk und Firewall. Angenommen, wir haben zwei Standorte (Standort A und Standort B), welche via einen VPN Tunnel verbunden sind. Standort A - Windows 7, 8.x und oder Win10 Clients - interne Domain vorhanden mit einem physikalischen Server (Active Directory, DHCP, DNS usw.) - diverse Drucker steht in der Firma herum, via Netzwerk verbunden. - Mitarbeiter verbinden sich via RDP auf Standort B auf den RDS Server (der Drucker von den Mitarbeitern wird via Drucker mapping in die RDP Session verbunden) Ablauf beim Drucken via RDP Mitarbeiter Hans Muster verbindet sich via RDP von Standort A aus auf einen freigegebenen Desktop (RDS Server), arbeitet per remote auf einem RDS Server, welcher physikalisch am Standort B vorhanden ist. Frage Wenn der Mitarbeiter Hans Muster per remote wie vorhin erläutert druckt, muss auf Seite Standort A und Standort B auf der FW irgend etwas konfiguriert werden, damit das Drucken ohne Probleme funktioniert? Habe hierzu leider beim Suchen im Internet noch keine passende Erklärung gefunden (z.B. von Microsoft selber oder ähnlich) Danke schon jetzt für die zahlreichen Inputs von euch :-) Greez Andrew

hello together Testumgebung Hyper-V Host mit div. VMs, unter anderem einen Server 2012R2 DC mit separater VM als Offline RootCA frisch installiert. Damit die zukünftige RootCA div. Einstellungen bei der Installation mit auf den Weg bekommt, habe ich auf der zu installierenden RootCA im Verzeichnis C:\Windows folgende CAPolicy.inf Datei erstellt: ---------------- [Version] Signature="$Windows NT$" [Certsrv_Server] RenewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=20 CRLPeriod=weeks CRLPeriodUnits=26 CRLDeltaPeriod=days CRLDeltaPeriodUnits=0 LoadDefaultTemplates=0 AlternateSignatureAlgorithm=1 [CRLDistributionPoint] [AuthorityInformationAccess] --------------- Bevor ich die Installation der RootCA via PowerShell angestossen habe, zuerst via PowerShell folgende Kommandos abgesetzt --------------- Set-ExecutionPolicy RemoteSigned -Force Install-WindowsFeature Adcs-cert-Authority –IncludeManagementTools Install-WindowsFeature RSAT-ADCS-Mgmt --------------- Danach die Installation anbei via folgenden PowerShell Befehl durchgeführt (dazu das hierzu verwendete PowerShell Skript editiert, sieht dann so aus): --------------- Install-AdcsCertificationAuthority -CAType StandaloneRootCA ` -CACommonName "IT-NetX Root CA" ` -KeyLength 4096 ` -HashAlgorithmName SHA512 ` -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" ` -DatabaseDirectory "C:\RootCA\DB" ` -LogDirectory "C:\RootCA\LOGs" ` -ValidityPeriod Years ` -ValidityPeriodUnits 20 --------------- Im nächsten Schritt habe ich via rechte Maustaste auf RootCA/ Eigenschaften/ Reiter "Erweiterungen" folgende Anpassungen vorgenommen Punkt: Sperrliste-Verteilpunkt angepasst > alle URLs entfernt bis auf einen: C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl Die Option > Sperrlisten an diesem Ort veröffentlichen und die Option > Deltasperrlisten an diesem Ort veröffentlichen habe ich so belassen, damit die RootCA das RootCert und die Sperrliste an diesem Ort hier veröffentlicht C:\Windows\System32\CertSrv\CertEnroll\ Danach zusätzlich einen weiteren Sperrlisten-Verteilpunkt aufgeführt, als HTTP URL, in der Form: > http://ca.meineDomain.ch<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl und hierbei folgende zwei Optionen angekreuzt > In Sperrlisten einbeziehen. Wird zur Suche von Deltasperrlisten verwendet > in CDP Erweiterung des ausgestellten Zertifikats einbeziehen Punkt: Zugriff auf Stellen-Informationen (AIA) Hier bin ich analog dem soeben geschilderten Vorgehen (Sperrlisten-Verteilpunkt) vorgegangen Und: habe für die manuell hinzugefügte HTTP URL die Option angekreuzt > in AIA-Erweiterung des ausgestellten Zertifikats einbeziehen So, nun ging es noch darum, sowohl das RootCA und die vom RootCA ausgestellte Sperrliste auf die zukünftige SubCA zu kopieren bzw. vorerst mal in eine Freigabe auf dem Domain Controller (Die Dinger braucht man für die spätere Installation, bin ja noch lange nicht fertig, die zweistufige PKI in meiner Testumgebung einzurichten) Somit > RootCA Cert > RootCA Sperrliste auf einen Share kopiert Danach habe ich versucht, sowohl RootCA Cert und auch RootCA Sperrliste im AD zu veröffentlichen. > RootCA Cert konnte ich erfolgreich im AD veröffentlichen, via Befehl  certutil –dspublish –f MaschineSRV03_MusterFirma-RootCA.crt RootCA (die hier gewählten Namen sind erfunden) Jedoch scheitere ich daran, die RootCA Sperrliste im AD zu veröffentlichen Anbei der Fehlertext (habe zwei Versuche gestartet, nachdem es beim erstem Mal nicht funktionierte, hatte ich auf der RootCA händisch die Sperrliste nochmals veröffentlicht und nochmals versucht, diese neue Sperrliste im AD zu veröffentlichen (darum zwei verschiedene Fehlermeldungen) Fehlermeldung beim Veröffentlichen der RootCA Sperrliste ----------------------- PS D:\Admin\Backup\CAs\Root-CA\CertEnroll Export> certutil -dspublish -f "Muster Root CA.CRL" ldap:///CN=Muster Root CA,CN=MaschineSRV04,CN=CDP,CN=Public Key Services,CN=Services,DC=UnavailableConfigDN?certificateRevo cationList?base?objectClass=cRLDistributionPoint?certificateRevocationList ldap: 0xa: 0000202B: RefErr: DSID-0310082F, data 0, 1 access points ref 1: 'unavailableconfigdn' CertUtil: -dsPublish-Befehl ist fehlgeschlagen: 0x8007202b (WIN32: 8235 ERROR_DS_REFERRAL) CertUtil: Eine Referenzauswertung wurde vom Server zurückgesendet. PS D:\Admin\Backup\CAs\Root-CA\CertEnroll Export> certutil -dspublish -f "Muster Root CA.CRL" Eine erforderliche CRL-Erweiterung ist nicht vorhanden. CertUtil: -dsPublish-Befehl ist fehlgeschlagen: 0x80070490 (WIN32: 1168 ERROR_NOT_FOUND) CertUtil: Element nicht gefunden. ---------------------------- Hat Jemand schon dieses Problem gehabt oder ist diesem Fehler begegnet?

hello together Habe auf meiner zweistufigen CA auf der SubCA, rechte Maustaste Eigenschaften, Reiter (Register) Erweitert, Punkt: Zugriff auf Stelleninformationen zwei URLs hinterlegt => http://aia.domainXY.ch/crl/...... angekreuzt habe ich hierbei: "in AIA-Erweiterung des ausgestellten Zertifikats einbeziehen" => http://ocsp.domainXY.ch/ocsp angekreuzt habe ich hierbei: "In Online Certificate Status-Protocol(OCSP)-Erweiterungen einbeziehen" Mit dem Kommandozeilentool Certutil habe ich dann mein neue generiertes Exchange Zertifikat auf OCSP Tauglichkeit getestet, wie folgt certutil -verify -urlfetch -v PfadZumExchangeCert.cer dabei war unteranderem betreffend OCSP eine Fehlermeldung aufgetaucht, welche leider nicht wirklich aussagekräftig ist Frage: Was habe ich für Möglichkeiten, um herausfinden zu können, wo oder warum genau die Meldung erscheint, OCSP Prüfung nicht erfolgreich - gibt es OCSP LOGs oder sonst Tools, mit welchen ich mehr Details zur OCSP Prüfung erhalte? ---------------- Zertifikat-OCSP ---------------- http://ocsp.domainXY.ch/ocsp/MFQwUjBQME4wTDAJBgUrDgMCGgUABBS2KUBXeVRxGHM%2fXVq9ne JilQK%2fjAQU%2byCMJb1UTlKiALx43stiFHuEYxgCExIAAAAFlIeybqG%2fjjMAAAAAAAU%3d?Conte nt-Type: application/ocsp-request Nicht erfolgreich "OCSP" Zeit: 0 [0.0] http://ocsp.domainXY.ch/ocsp -------------------------------- CRL 08: Issuer: CN=domainXY-RootCA, DC=domainXY, DC=CH ThisUpdate: 04.01.2016 12:11 NextUpdate: 03.01.2017 00:31 46de5d4ee5ff9ad75e1a81f884fe4e934c7aa93e CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=domainXY-RootCA, DC=domainXY, DC=CH NotBefore: 12.07.2015 11:27 NotAfter: 12.07.2045 11:37 Subject: CN=domainXY-RootCA, DC=domainXY, DC=CH Serial: 2ee48052524dfc9f4ac6c1bf64d76b90 bfca801e7257e89cd254d6873e9868208e548ea2 Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Zertifikat abrufen ---------------- Keine URLs "Keine" Zeit: 0 ---------------- Zertifikat abrufen ---------------- Keine URLs "Keine" Zeit: 0 ---------------- Zertifikat-OCSP ---------------- Keine URLs "Keine" Zeit: 0 -------------------------------- Exclude leaf cert: c08f85ea8754e0fb37b42bcdc6a3800743b14268 Full chain: 276e28eaba62d0ec06c810af58a77eeaf1a0290f ------------------------------------ Verfizierte Ausstellungsrichtlinien: Kein Verfizierte Anwendungsrichtlinien: 1.3.6.1.5.5.7.3.1 Serverauthentifizierung Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlosse n. CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

moin together Danke Norbert für die Inputs. Habe die Lösung gefunden, anbei aber zuerst noch eine Frage in Bezug GPO für Zertifikatsdienste Wie ich oben erwähnt hatte, habe ich mich beim Einrichten der RootCA (AD integriert) auf folgenden Blog Artikel hier gestützt: http://asichel.de/2013/03/06/active-directory-zertifikatsdienste-ad-cs-grundkonfiguration/ Dieser erwähnt auch unter Schritt 5 - Gruppenrichtlinie, dass eine GPO auf Domain Ebene verknüpft werden soll und zwei Punkte angepasst werden sollen => Zertifikatsclient - automatische Registrierung => Einstellungen der automatischen Zertifikatsanforderungen Das Problem, welches ich hier habe ist: => Verbinde mich per RDP auf den Exchange 2016 via EMC (GUI) => rufe Punkt Server/ Zertifikate auf => nachdem ich die oben erwähnte GPO auf dem AD Server erstellt hatte, das GPO Objekt auf Domain Ebene verknüpft wurde Und: auf dem Exchange ein gpupdate/ force aufgerufen wird, passiert folgendes (wegen dieser GPO): der Exchange listet gleich ein neues, weiteres Cert auf, welches auf seinen eigenen Namen lautet > Exchange.domain.ch Und: dieses Cert hat keinen Anzeigenamen und dem wurden auch keine Dienste zugewiesen, somit ist das für mich eher störend, da dieses ohne zugewiesene Dienste eh nicht funktionsfähig ist. Daher habe ich ein WMI Filter erstellt, welcher bewirkt, dass die GPO auf alle Computer Objekte angewendet wird ausser auf den Exchange und mir somit NICHT automatisch ein Cert auf dem Exchange installiert wird, welches auf Ihn selber lautet. Nachdem ich das OS neu installiert hatte, danach obendrauf den Exchange 2016 neu installierte, hatte ich zuvor selbstverständlich mit dem ADSI-Edit Tool den Exchange 2016 komplett aus dem AD gekickt. Grund: Dies, damit beim neu installieren des Exchange 2016 keine Fehlermeldungen erscheinen. Wie ich weiter unten in diesem Beitrag hier gleich meine Lösung erklären werde, lag es schlussendlich nicht am Exchange bzw. an dessen Installation, daher war dieser Schritt (Exchange neu aufsetzen) völlig überflüssig gewesen (im nachhinein ist man immer schlauer) Die Umgebung wird eine produktive Umgebung, welche ich zurzeit am Aufsetzen bin - also keine Test Umgebung. Das Problem war folgendes bzw. die Lösung lautet: 1. Auf dem Server, welcher die RootCA beherbergt, war unter dem Punkt Sperrlisten-Verteilungspunkt mir der Fehler unterlaufen, dass auf einen UNC Pfad verwiesen habe und am Schluss das .crl vergessen hatte, hinten anzuhängen Sieht nun korrekt so aus \\crl.domain.ch\<crl$\CaName><CRLNameSuffix><DeltaCRLAllowed>.crl << (dieses .crl hatte ich vergessen) 2. Weil ich beim Punkt 1 für diesen UNC Pfad hinterlegt habe > Sperrlisten an diesem Ort veröffentlichen > Deltasperrlisten an diesem Ort veröffentlichen Wurden zwar die Sperrliste von der RootCA vom Ordnerpfad C:\Windows\System32\certsrv\CertEnroll korrekt in die Freigabe (auf einem anderen virtuellen Server) \\crl.domain.ch\crl$ kopiert, jedoch hatten die kopierten Dateien nicht die Endung .crl, was natürlich beim Überprüfen der Sperrlisten zu einem sehr logischen Fehler führt, die CA sei Offline :-) Wie wäre es, wenn beim Überprüfen mit certutil -verify -URLfetch D:\Speicherpfad-zum-Zertifikat\ExchangeZertifikat.cer beispielsweise eine Fehlermeldung erschienen wäre mit dem Inhalt: falscher Dateityp? kurz, prägnant Und: vor allem Aussagekräftig! (mit der heutigen Programmiertechnik wäre dies absolut kein Problem, das Certutil Tool dazu zu bringen, eine schlauere Fehlermeldung auszuspucken :-) Nun funktioniert die CRL Überprüfung, super Sache :-)

moin, muss den obigen Board Eintrag wieder aufleben lassen, da Problem noch immer vorhanden, Situation aber nicht mehr genau gleich wie vorher: Zuerst vorweg: Ja, ich habe den Eintrag von Norbert gelesen, vielen Dank Norbert für die damals gelieferten Tipps/ Ratschläge :-) In der Zwischenzeit habe ich folgendes gemacht, betreffend RootCA => RootCA komplett von Board geworfen, neu installiert (RootCA > AD integriert) => RootCA: In den Eigenschaften der RootCA/ Reiter Erweiterungen: > Sperrlisten-Verteilungspunkt (URLs angepasst) > Zugriff auf Stelleninformationen angepasst P.S. Habe mich hierzu auf folgenden Blog Eintrag bezogen http://asichel.de/2013/03/06/active-directory-zertifikatsdienste-ad-cs-grundkonfiguration/ Das einzige, was ich nicht so gemacht habe wie er hier im Blog beschreibt ist: Zum Abschluss der Konfiguration noch eine GPO erstellt, welche das RootCA im AD verteilt. Hierzu kann ich sagen, dass eine AD integrierte AD das RootCA ohne zu tun automatisch an die Geräte in der AD verteilt (siehe hierzu auf jedem Gerät eine MMC, Snap-In Zertifikate hinzufügen) Und: man prüfe den Punkt: Vertrauenswürdige Stammzertifizierungsstellen/ Zertifikate Genau hier habe ich nach der Installation meiner RootCA auf jedem Server lokal das entsprechende RootCert vorgefunden, ohne dass ich wie der hier im Blog eine GPO erstellt hat, welche dieses Cert verteilt (nur am Rande erwähnt, hat oben auch Norbert so mir mitgeteilt, dass dies automatisch geschehen muss) > Langer Rede kurzer Sinn: die RootCA neu installiert, die Sperrliste so angepasst, dass diese auf http://crl.domain.ch/crl/ verweist. > sichergestellt, dass wenn ich zum Beispiel vom Exchange aus den Internet Explorer aufrufe, mich ohne Fehlermeldung auf http://crl.domain.ch/crl/ zugreifen kann, genau. In der Zwischenzeit habe ich folgendes gemacht, betreffend Active Directory => via ADSI- Edit alle Exchange Einträge entfernt In der Zwischenzeit habe ich folgendes gemacht, betreffend Exchange 2016 => das OS, auf welchem der Exchange 2016 laufen soll, neu aufgesetzt => die Exchange 2016 Installation ohne Fehler installiert => eine neue Zertifikatsanforderung auf dem Exchange erstellt => auf der RootCA via http://localhost/certsrv die Zertifikatsanforderung eingereicht und das daraus resultierende, für den Exchange gedachte Zertifikat (SAN mit drei URLs) heruntergeladen (von der RootCA) und dem Exchange 2016 gefüttert (versucht, die noch offene Anfrage abzuschliessen) => genau nach diesem Schritt erscheint der Status des soeben neu eingepflanzten Cersts in der Exchange 2016 GUI (Webkonsole) folgendes: Sperrungsüberprüfung fehlgeschlagen Betreffend: Sperrungsüberprüfung fehlgeschlagen => getestet, ob ich auf die CRL per Internet Explorer zugreifen kann, Antwort: Ja, das kann ich, ohne Fehlermeldung => certutil -verify -URLfetch D:\Speicherpfad-zum-Zertifikat\ExchangeZertifikat.cer hat unter anderem folgende Zeile(n) im Resultat enthalten Fehler beim Abrufen der URL: Nicht gefunden (404). 0x80190194 (-2145844844 HTTP_E_STATUS_NOT_FOUND) http://crl.domain.ch/crl/Kunde-RootCA.crl und hier Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offli ne war. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) ------------------------------------ Sperrungsüberprüfung übersprungen -- Server ist offline FEHLER: Die Sperrstatusüberprüfung des untergeordneten Zertifikats hat Die Sperr funktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0 x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) zurückgegeben. CertUtil: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. CertUtil: -verify-Befehl wurde erfolgreich ausgeführt. Habe hier ein paar dicke Fragezeichen, warum um Gottes Willen soll denn mein Gerät, welches via installierten IIS das virtuelle Verzeichnis CRL enthält angeblich OFFLINE sein??? => siehe hierzu ein paar Zeilen weiter oben, den Punkt: Betreffend: Sperrungsüberprüfung fehlgeschlagen

Vielen Dank für die diversen Ratschläge und Tipps - konnte das Wichtigste daraus extrahieren Und: habe festgestellt, was ich in Zukunft anders machen muss :-) P.S. Nachtrag: Das Problem mit dem Einloggen des Administrator Benutzers in der Exchange Admin GUI habe ich so gelöst, dass ich via Exchange Shell das Postfach vom Administrator getrennt habe (die obige Fehlermeldung sagt aus, dass damit was nicht mehr im grünen Bereich ist), danach habe ich dem Administrator ein neues Exchange Postfach zugewiesen und siehe da, das Einloggen hat ohne Fehlermeldung funktioniert, das gilt auch für OWA ;)

Nein, Du musst nicht die mögliche Frage erraten, es reicht, wenn Du mir schreibst, was ich machen muss, dass keine Warnungen mehr beim Einloggen im Exchange Admin Center erscheinen :-) Welche Warnungen? siehe meinen Beitrag oben

Habe den Exchange 2016 neu installiert (auf einer VM) @ Hierzu die VM per SnapShot zurückgesetzt: Dieser Status entspricht einem frisch installiertem Server 2012R2 mit installierten Windows Updates @ Danach so gut wie möglich versucht, das AD von allen Exchange Einträge via ADSI-Edit zu befreien (Säuberung) @ Exchange 2016 Systemvoraussetzungen/ Systemvoraussetzungen geschaffen/ installiert @ Exchange 2016 wurde ohne Fehler installiert Am Exchange noch gar nichts konfiguriert, einfach mal in die Ereignisanzeige geschaut und unter anderem folgenden Eintrag gefunden --------------- Prozess w3wp.exe (OWA) (PID=11808). Objekt [CN=Administrator,OU=Admins,OU=Benutzer,DC=domain,DC=ch]. Eigenschaft [AddressListMembership] ist auf Wert [domain.ch/Configuration/Deleted Objects/Mailboxes(VLV) DEL:17a22d33-77f3-4b02-9854-a071754e71e3] festgelegt und zeigt auf den Container "Gelöschte Objekte" in Active Directory. Diese Eigenschaft muss so schnell wie möglich korrigiert werden --------------- Anscheinend hat der Exchange gemerkt, dass vorher schon Mal ein Exchange 2016 installiert war und irgendwo wohl noch im AD einen Eintrag gefunden, welcher falsch ist? Festgestellt habe ich des Weiteren auch, wenn ich mich das erste Mal im Admin Center einlogge (https://localhost/ecp) folgende Meldung erscheint: (verwende den Domain Administrator) Es sind mehrere Warnungen vorhanden, Klicken Sie hier, um weitere Informationen anzuzeigen. Details hierzu: ------------------ Das Objekt "domain.ch/Benutzer/Admins/Administrator" wurde beschädigt oder ist mit Microsoft-Supportanforderungen nicht kompatibel und befindet sich in einem inkonsistenten Zustand. Folgender Überprüfungsfehler: 'Database' ist für 'UserMailbox' verbindlich.