MHeiss2003

Hallo liebe community,

Eure Meinungen und Erfahrungen würden mich interessieren.

An dem Hauptstandort des Projektes habe ich ein AD mit Servern 2019. Nun ist meine Idee, dass ich an einem zweiten Standort einen Exchange Server in Betrieb nehmen möchte. Der zweite Standort ist mit 100 Mbit/s. an das öffentliche Netz angebunden, während der Hauptstandort nicht einmal 16 Mbit/s realisieren kann.

Meine Idee war, dass ich an dem zweiten Standort mit Exchange ebenfalls einen Domaincontroller in Betrieb nehme. Die Anbindung wollte ich mit VPN an den Hauptstandort realisieren. Die Kommunikation mit Exchange soll aber ausschließlich über die öffentliche Anbindung laufen.

Wie sind Eure Erfahrungen und Empfehlungen? Ist der zweite DC sinnvoll? Fragen über Fragen...!

Danke und Grüße

Mario

Danke für den Hinweis und den Link.

SMTP nutzt aktuell das neue Zertifikat, der Fingerprint ist eindeutig korrekt. 

Jetzt stellt sich mir immer noch die Frage: Warum sehe ich den Dienst SMTP bei diesem Zertifikat nicht angehakt?

Hallo Seppelmore,

danke für den Hinweis. Versucht hatte ich das mit dem Zertifikat "Microsoft Exchange". Ich werde hier bei SMTP nach dem Überschreiben gefragt. Wenn ich die Frage mit JA beantworte, wird das Zertifikat dem Dienst SMTP dennoch nicht zugefügt.

Welches Zertifikat hattest Du verwendet?

Grüße

Mario

Hallo liebe community,

auf dem betroffenen Exchange Server ist das Wildcard Zertifikat ausgelaufen gewesen. Nun habe ich ein neues über Powershell importiert und dieses den beiden Diensten SMTP und IIS zugewiesen.

Während die Zuweisung zu IIS problemlos funktioniert hat, bekomme ich leider keine Zuweisung zu SMTP. Enable-ExchangeCertificate bringt keinen Fehler, führt die Zuweisung aber nicht aus. Den Beweis erbringt Get-ExchangeCertificate.

Unterdessen habe ich das alte abgelaufene Zertifikate über die MMC gelöscht, in der Hoffnung dann die Zuweisung vornehmen zu können, aber auch das funktioniert nicht.

Habt Ihr noch eine Idee?

Aktueller Fehler im LOG "Fehler 6, MSExchange Managament - Cmdlet failed".

Danke

Mario

Vielen Dank an Euch. Die Lösung war folgende, angelehnt an den Tipp von Phil:

1. Löschen des Outlook Profils über die Systemsteuerung

2. Bereinigung der beiden Ordner C:\%username%\AppData\Local\Microsoft\Outlook und C:\%username%\AppData\Roaming\Microsoft\Outlook

3. Neueinrichtung der Benutzerkonten

Als kleiner Tipp, der sich in der Konfiguration als hilfreich erwiesen hatte:

Deaktivierung des Exchange-Cache-Modus für das nach M365 migrierte Postfach, zumindest bei der Erstverbindung. Da das migrierte Postfach als sekundäres Postfach im Mailprofil eingerichtet ist, wurden die "alten" Verknüpfungen zu dem onPremise Postfach sofort nach dem Start aus dem Primärpostfach entfernt und durch die neuen ersetzt. Dieser Vorgang hatte mit aktiviertem Cache-Modus nicht sofort gegriffen. 

vor einer Stunde schrieb Gerber:

Alles klar, perfekt.
Genau, sonst würde die Migration sowieso fehlschlagen, wenn die Routing Adresse bei der Migration im Postfach (Benutzer) fehlt.

 

 

 

Korrekt.
So muss es auch sein. Der Autodiscover muss auf den lokalen Exchange zeigen (public IP vom Anschluss). Über die Routing Adresse wird dann das Postfach nach M365 aufgelöst.

Wie sieht es mit der Frage von "mirko" aus?
Hast du den Autodiscover nach M365 evlt zuvor verboten?

Hast du es mit einem neuen Profil getestet?

Ist dies ein Test Benutzer oder hast du mehrere Benutzer nach M365 migriert?

Grüße
 

Mit einem neuen Profil auf einem PC, der noch keine Outlook Einrichtung hatte, geht die Einrichtung völlig problemlos!

vor 4 Minuten schrieb mikro:

 

Proxy und Firewall geprüft?

Firewall ja, Proxy ist nicht vorhanden und auch nicht aktiviert.

vor 24 Minuten schrieb Gerber:

Na dann poste doch mal den kompletten Teil bitte.

 

vor 9 Minuten schrieb mikro:

Moin was sagt Outlook wenn Du Email-Autokonfiguration testen klickst?

Hallo, 

4x GetLastError=0; httpStatus=401

AutoErmittlung für https://outlook.office365.com/autodiscover/autodiscover.xml Fehlgeschlagen (0x800C820E)

Die über den Datenverbindungspunkt gefundene URL https://autodiscover.MEINEDOMAIN.de/Autodiscover/Autodiscover.xml

AutoErmittlung für https://autodiscover.MEINEDOMAIN.de/Autodiscover/Autodiscover.xml gestartet

GetLastError=0; httpStatus=401

GetLastError=0; httpStatus=401

GetLastError=0; httpStatus=200

AutoErmittlung für https://autodiscover.MEINEDOMAIN.de/Autodiscover/Autodiscover.xml Fehlgeschlagen (0x800C8205)

Die Meldungen gehen noch weiter. 

vor 4 Minuten schrieb Gerber:

Alles klar, perfekt.
Genau, sonst würde die Migration sowieso fehlschlagen, wenn die Routing Adresse bei der Migration im Postfach (Benutzer) fehlt.

 

 

 

Korrekt.
So muss es auch sein. Der Autodiscover muss auf den lokalen Exchange zeigen (public IP vom Anschluss). Über die Routing Adresse wird dann das Postfach nach M365 aufgelöst.

Wie sieht es mit der Frage von "mirko" aus?
Hast du den Autodiscover nach M365 evlt zuvor verboten?

Hast du es mit einem neuen Profil getestet?

Ist dies ein Test Benutzer oder hast du mehrere Benutzer nach M365 migriert?

Grüße

#######

 

 

Nein, dieser Eintrag darf nicht gesetzt sein.
Mit diesem Eintrag wird Autodiscover nach M365 unterbunden.
 

OK, der Eintrag wurde nicht gesetzt, zumindest nicht per GPO oder anders wissentlich. 

Es handelt sich um einen Testbenutzer. Dieses Postfach liefert Vollzugriffsrechte für andere Nutzer, die das Postfach bearbeiten, info@meinedomain.de.

Neues Profil habe ich nicht nicht getestet. Werde ich gleich mal versuchen. 

Was mir auffällt, wenn ich Outlook öffne, dass der Hinweis kommt, Kennwort erforderlich. 

Weiterhin erhalte ich bei der Neurinrichrung des Postfaches kurz die M365 Anmeldemaske, der Kreis mit Punkten ist zu sehen, plötzlich schließt sich das Fenster. 

Hallo Phil, 

Danke für Deine Nachricht. 

Ein Postfach, das auf dem onPremise Exchange erstellt wurde und vorhanden war, ist nach M365 migriert worden. 

Routing Adresse ist vorhanden. 

Nachdem ich bei Microsoft in der Anleitung zur Vorbereitung des HCW gelesen habe, dass die autodiscover Einträge von extern auf den lokalen Exchange laufen müssen, habe ich auf dem externen DNS System den DNS-Eintrag autodiscover.MEINEDOMAIN.de auf die externe feste IP-Adresse geleitet, diese geht dann auf den lokalen Exchange. 

Weiterhin habe ich auf dem internen Exchange denselben Eintrag mit Verweis auf die interne IP-Adresse des lokalen Exchange. 

Grüße 

Mario

vor 16 Minuten schrieb mikro:

Moin,

 

 

 

hast du eventuell diesen RegKey per Group policy gesetzt?

 

https://support.mycomp.ch/569273-Disable-Autodiscover-Endpoint-Check-for-Office-365

 

 

 

Gruß mirko

 

Hallo Mirko, 

Vielen Dank für Deine Nachricht. Nein, diesen Eintrag habe ich nicht gesetzt. 

Ist dies Deiner Meinung nach notwendig, zumindest solange, bis ich den onPremise Exchange deinstalliert und von Netz habe? 

Gruß

Mario

Liebe community,

zu meinem Setup folgende Informationen:

1. onPremise Exchange Server 2016 CU21

2. Microsoft 365 Business Standard Lizenzen

3. Microsoft 365 Hybrid Configuration Wizard mit vollständiger Hybridkonfiguration und der Topologie klassisch erfolgreich durchgeführt

4. onBoarding eines Postfaches erfolgreich durchgeführt

5. Migrationsbatch entfernt

Zu dem Problem:

1. Keine Verbindung über Outlook im internen Netzwerk des Exchange Servers

2. "E-Mail-Autokonfiguration testen" über Outlook meldet zu der E-Mail-Adresse des Postfaches: 

4x GetLastError=0; httpStatus=401

AutoErmittlung für https://outlook.office365.com/autodiscover/autodiscover.xml Fehlgeschlagen (0x800C820E)

Die über den Datenverbindungspunkt gefundene URL https://autodiscover.MEINEDOMAIN.de/Autodiscover/Autodiscover.xml

AutoErmittlung für https://autodiscover.MEINEDOMAIN.de/Autodiscover/Autodiscover.xml gestartet

GetLastError=0; httpStatus=401

GetLastError=0; httpStatus=401

GetLastError=0; httpStatus=200

AutoErmittlung für https://autodiscover.MEINEDOMAIN.de/Autodiscover/Autodiscover.xml Fehlgeschlagen (0x800C8205)

Wenn ich mich über einen Mailclient außerhalb des Netzwerkes mit dem Postfach verbinde, funktioniert die Anmeldung mit Autoermittlung tadellos.

Meine Vermutung ist, dass irgendetwas im internen Netzwerk noch konfiguriert werden muss.

Leider komme ich nicht weiter und würde mich über Eure Ideen sehr freuen. Das mit dem Wald und den Bäumen ist bei mir vermutlich gerade so. ;-)

Danke Euch.

Mario

Habe das gleiche Problem in einer SBS2011 Umgebung mit Outlook 2016. Nachdem ich vermutet hatte, dass es an Office 2016 liegt habe ich Office 2016 deinstalliert und Office 2013 installiert. Leider genau das gleiche Problem. Mir hat das Downgrade auf Windows 7 geholfen, allerdings nur mit Office 2013, mit 2016 gleiches Problem unter Windows 7.

Hallo zusammen,

ich habe einen Exchange 2013 mit CU14 laufen. Mir sind von Problemen bei der Suche in Öffentlichen Ordnern berichtet worden. Nun habe ich das Öffentliche Ordner Postfach mit einem Set-MoveRequest in eine neue Datenbankdatei verschoben, um eventuell vorhandene Fehler herauszufiltern. Die Übertragung hat problemlos funktioniert. Die 3 weiteren Datenbanken habe keine Probleme bei der Suche, das nur am Rande.

Wenn ich nun ein Test-ExchangeSearch -Identity "NAME DES ÖFFENTLICHEN ORDNERPOSTFACHES" mache, erhalte ich den Fehler MAPI-Fehler für Postfachdatenbank "DATENBANKNAME". Im Eventlog des Server finde ich zeitgleich keinen Eintrag.

Get-MailBoxDataBaseCopyStatus bringt für alle Datenbanken "Healthy".

Mir ist noch aufgefallen, dass das INDEX-Verzeichnis der Datenbank 16 Megabyte hatte, nachdem ich es angelegt hatte. Es hat immer noch die gleiche Größe nach dem Verschiebevorgang des Öffentlichen Ordner Postfaches. Die anderen Datenbanken haben mehrere hundert Megabyte in diesem Verzeichnis.

Wie bekomme ich die Suche im Öffentlichen Ordner Postfach wieder ans Laufen?

Danke und Grüße

Hallo zusammen,

auf einem Einzelserver habe ich CU14 für Exchange 2013 installiert. Einen Tag nach der Installation berichteten alle Benutzer, dass die Suche nicht mit funktionieren würde.

In der Tat sind alle drei Datenbanken im Status "failed" was die Indexierung angeht.

http://exchangeserverpro.com/fix-failed-database-content-index-exchange-2013/#comment-351674 habe ich bereits mehrfach versucht.

ContentSubmitter Gruppe war bereits angelegt vor der Installation von CU13.

Leider bekomme ich keinen INDEX mehr sauber hin. Mir ist auch aufgefallen, dass sich nach dem Neustart der beiden Dienste, der Dienst MSExchangeFastSearch alle 20 Sekunden unerwartet beendet, um sich dann wieder zu starten.

Zu der letzten Warnung im Event Log 1013 finde ich keinen Lösungsansatz. Die Fehlermeldung lautet:

"Indexierungsstatus nicht im FAST-Katalog für MDB DATABASE ID gefunden".

Es dauert dann ein paar Minuten und dann kommen einige Fehler. Der erste Fehler lautet:

Protokollname: Application
Quelle:        MSExchange Common
Datum:         14.10.2016 17:04:46
Ereignis-ID:   4999
Aufgabenkategorie:Allgemein
Ebene:         Fehler
Beschreibung:
Der Watson-Bericht steht kurz vor dem Versenden für die Prozess-ID: 24220, mit den Parametern: E12IIS, c-RTL-AMD64, 15.00.1236.003, M.E.Search.Service, M.E.Data.Directory, M.E.D.D.ScopeSet.GetOrgWideDefaultScopeSet, System.ArgumentNullException, 301, 15.00.1236.000.
ErrorReportingEnabled: True

Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="MSExchange Common" />
    <EventID Qualifiers="16388">4999</EventID>
    <Level>2</Level>
    <Task>1</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-14T15:04:46.000000000Z" />
    <EventRecordID>11845796</EventRecordID>
    <Channel>Application</Channel>
    <Security />
  </System>
  <EventData>
    <Data>24220</Data>
    <Data>E12IIS</Data>
    <Data>c-RTL-AMD64</Data>
    <Data>15.00.1236.003</Data>
    <Data>M.E.Search.Service</Data>
    <Data>M.E.Data.Directory</Data>
    <Data>M.E.D.D.ScopeSet.GetOrgWideDefaultScopeSet</Data>
    <Data>System.ArgumentNullException</Data>
    <Data>301</Data>
    <Data>15.00.1236.000</Data>
    <Data>True</Data>
    <Data>True</Data>
    <Data>Microsoft.Exchange.Search.Service</Data>
    <Data>
    </Data>
  </EventData>
</Event>

Und genau nach diesem Fehler folgt dann der Dienst Crash mit Beenden und Neustarten des Dienstes MSExchangeFastSearch alle 20 Sekunden. Ich finde dann noch folgende Events im LOG:

Protokollname: Application
Quelle:        Microsoft-Windows-Perflib
Datum:         14.10.2016 17:04:55
Ereignis-ID:   1008
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Die Open-Prozedur für den Dienst ".NETFramework" in der DLL "C:\Windows\system32\mscoree.dll" war nicht erfolgreich. Die Leistungsdaten für diesen Dienst sind nicht verfügbar. Die ersten vier Bytes (DWORD) des Datenbereichs enthalten den Fehlercode.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Perflib" Guid="{13B197BD-7CEE-4B4E-8DD0-59314CE374CE}" EventSourceName="Perflib" />
    <EventID Qualifiers="49152">1008</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-14T15:04:55.000000000Z" />
    <EventRecordID>11845800</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Security />
  </System>
  <UserData>
    <EventXML xmlns="Perflib">
      <param1>.NETFramework</param1>
      <param2>C:\Windows\system32\mscoree.dll</param2>
      <binaryDataSize>8</binaryDataSize>
      <binaryData>0200000000000000</binaryData>
    </EventXML>
  </UserData>
</Event>

und

Protokollname: Application
Quelle:        IISInfoCtrs
Datum:         14.10.2016 17:04:55
Ereignis-ID:   1001
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Der Indexwert "First Counter" konnte nicht aus der Registrierung gelesen werden. Der von der Registrierung zurückgegebene Fehlercode ist DWORD 0.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="IISInfoCtrs" />
    <EventID Qualifiers="49152">1001</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-14T15:04:55.000000000Z" />
    <EventRecordID>11845801</EventRecordID>
    <Channel>Application</Channel>
    <Security />
  </System>
  <EventData>
    <Binary>02000000</Binary>
  </EventData>
</Event>

und

Protokollname: Application
Quelle:        usbperf
Datum:         14.10.2016 17:04:56
Ereignis-ID:   2001
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Der Wert von "First Counter" unter dem Schlüssel "usbperf\Performance" kann nicht gelesen werden. Statuscodes wurden in den Daten zurückgegeben.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="usbperf" />
    <EventID Qualifiers="49152">2001</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-14T15:04:56.000000000Z" />
    <EventRecordID>11845806</EventRecordID>
    <Channel>Application</Channel>
    <Security />
  </System>
  <EventData>
    <Binary>02000000</Binary>

und

Protokollname: Application
Quelle:        Microsoft-Windows-IIS-W3SVC-PerfCounters
Datum:         14.10.2016 17:04:56
Ereignis-ID:   2002
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Fehler beim Einrichten der Webdienste-Leistungsindikatoren. Vergewissern Sie sich, dass die Webdienst-Leistungsindikatoren ordnungsgemäß registriert wurden.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-IIS-W3SVC-PerfCounters" Guid="{90303B54-419D-4081-A683-6DBCB532F261}" EventSourceName="W3CTRS" />
    <EventID Qualifiers="49152">2002</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-14T15:04:56.000000000Z" />
    <EventRecordID>11845808</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Security />
  </System>
  <EventData>
    <Binary>02000780</Binary>
  </EventData>
</Event>
  </EventData>
</Event>

und

Protokollname: Application
Quelle:        Microsoft-Windows-IIS-W3SVC-PerfCounters
Datum:         14.10.2016 17:04:56
Ereignis-ID:   2002
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Fehler beim Einrichten der Webdienste-Leistungsindikatoren. Vergewissern Sie sich, dass die Webdienst-Leistungsindikatoren ordnungsgemäß registriert wurden.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-IIS-W3SVC-PerfCounters" Guid="{90303B54-419D-4081-A683-6DBCB532F261}" EventSourceName="W3CTRS" />
    <EventID Qualifiers="49152">2002</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-14T15:04:56.000000000Z" />
    <EventRecordID>11845808</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Security />
  </System>
  <EventData>
    <Binary>02000780</Binary>
  </EventData>
</Event>

und

Protokollname: Application
Quelle:        Windows Error Reporting
Datum:         14.10.2016 17:06:32
Ereignis-ID:   1001
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
Fehlerbucket 127294039997, Typ 5
Ereignisname: E12IIS
Antwort: Nicht verfügbar
CAB-Datei-ID: 0

Problemsignatur:
P1: c-RTL-AMD64
P2: 15.00.1236.003
P3: M.E.Search.Service
P4: M.E.Data.Directory
P5: M.E.D.D.ScopeSet.GetOrgWideDefaultScopeSet
P6: System.ArgumentNullException
P7: 301
P8: 15.00.1236.000
P9:
P10:

Angefügte Dateien:
D:\Temp\7ce93049-b21f-4195-a2be-78e1172e7dd1\report.txt
D:\Temp\7ce93049-b21f-4195-a2be-78e1172e7dd1\report.xml

Diese Dateien befinden sich möglicherweise hier:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\NonCritical_c-RTL-AMD64_6b33c4a9bbf06b0dff11484d15cb39b8aa52_00000000_7db9e416

Analysesymbol:
Es wird erneut nach einer Lösung gesucht: 0
Berichts-ID: c9f05762-921f-11e6-810a-00155d01f906
Berichtstatus: 0
Bucket mit Hash: df6c0a6da1cd0a85b9acff111b5d9075
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Windows Error Reporting" />
    <EventID Qualifiers="0">1001</EventID>
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2016-10-14T15:06:32.000000000Z" />
    <EventRecordID>11845882</EventRecordID>
    <Channel>Application</Channel>
    <Security />
  </System>
  <EventData>
    <Data>127294039997</Data>
    <Data>5</Data>
    <Data>E12IIS</Data>
    <Data>Nicht verfügbar</Data>
    <Data>0</Data>
    <Data>c-RTL-AMD64</Data>
    <Data>15.00.1236.003</Data>
    <Data>M.E.Search.Service</Data>
    <Data>M.E.Data.Directory</Data>
    <Data>M.E.D.D.ScopeSet.GetOrgWideDefaultScopeSet</Data>
    <Data>System.ArgumentNullException</Data>
    <Data>301</Data>
    <Data>15.00.1236.000</Data>
    <Data>
    </Data>
    <Data>
    </Data>
    <Data>
D:\Temp\7ce93049-b21f-4195-a2be-78e1172e7dd1\report.txt
D:\Temp\7ce93049-b21f-4195-a2be-78e1172e7dd1\report.xml</Data>
    <Data>C:\ProgramData\Microsoft\Windows\WER\ReportArchive\NonCritical_c-RTL-AMD64_6b33c4a9bbf06b0dff11484d15cb39b8aa52_00000000_7db9e416</Data>
    <Data>
    </Data>
    <Data>0</Data>
    <Data>c9f05762-921f-11e6-810a-00155d01f906</Data>
    <Data>0</Data>
    <Data>df6c0a6da1cd0a85b9acff111b5d9075</Data>
  </EventData>
</Event>

Habt Ihr Erfahrungen und könnt Tipps geben?

Mario

Hallo zusammen,

ich habe eine intensive und schlaflose Nacht hinter mir danke eines Users, der eine "Bewerbung" im JS-Format angeklickt hat. cerber3 hat zugeschlagen. 

Nun habe ich die IT wieder soweit am Laufen, ein Server macht mir allerdings Probleme.

Dieser Server ist ein virtueller Win 2012 R2 mit 4 Partitionen alle NTFS formatiert. Auf den 3 Datenträgern mit Freigaben, ausgenommen Systempartition C:\, habe ich Schattenkopien aktiviert und zusätzlich Datendeduplizierung. Nun habe ich ohne die Folgen zu berücksichtigen, die Datensicherung über StorageCraft Shadowprotect gestern Abend als "Vollsicherung" gestartet, mit dem Erfolg, dass ich zwar eine Datensicherung der teilweise verschlüsselten Verzeichnisse habe, aber eben auch mit dem Erfolg, dass die inkrementellen Sicherungsdateien gelöscht wurden. StorageCraft war hier so eingestellt, dass es nur eine Kette mit einer Vollsicherung und 6 inkrementellen aufbewahrt und löscht. Dumm gelaufen!

Nun zu meinem eigentlichen Problem. Nach dem ersten Restore gestern der drei Partitionen habe ich alle Schattenkopien auf den Freigaben gesehen, sogar bis in den August hinein. Von diesen Punkten konnte ich einiges an Daten wieder herstellen, allerdings hatte ich bereits zwei Mal das Problem, dass bei mehreren Kopiertasks Windows Server plötzlich wegen zu hoher I/O Last oder fehlendem Speicherplatz alle Schattenkopien gelöscht hatte. Deshalb dachte ich mir, dass ich heute nochmals einen Versuch unternehme. Nach dem Zurückspielen der Sicherung von gestern sehe ich aber keine Schattenkopien mehr, Windows sagt mir auch, dass keine vorhanden wären, schaue ich mit TreeSize in das Verzeichnis "System Volume Information" sehe ich nach der Wiederherstellung die Punkte mit Datum Größe und einer ID.

Wie soll ich den Server denn am besten wiederherstellen, damit die Schattenkopien auch nach der Wiederherstellung funktionieren und zugänglich sind? Soll ich C:\ auch mit wiederherstellen? Das hatte ich bisher nicht getan? Mir ist aufgefallen, dass nach einer gewissen Zeit die Punkte physisch gelöscht werden.

Danke und Grüße

Mario

Der andere Norbert, ja die eingerichteten URL stimmen überein.

Norbert ich gebe Dir recht, Vorteile habe ich durch die Trennung aus Sicht Exchange keine. Allerdings betreibe ich Remote Desktop Gateway Server und CAS auf einem Server mit zwei Netzwerkkarten. Seltsam ist, dass es bis zur Installation CU12 problemlos funktioniert hat. Habe auch die LOGS durchgesehen, finde da keinen Hinweis auf Probleme. Die "Umgebung" läuft tadellos trotz dieses Fehlers bzw. dieser Veränderung. Wäre ja nicht das erste Mal, dass MS was generelles verändert wie bei den PF's. :-)

Hallo zusammen,

ich habe eine Exchange Umgebung mit einem CAS und einem Mailboxserver. Beide Server haben den aktuellen Patch Stand Exchange 2013 (Version 15.0 Build 1178.4) und Windows 2012 R2.

Auf dem CAS Server kann ich problemlos auf den Administrative Center zugreifen. Auf dem Mailboxserver erhalte ich die Fehlermeldung HTTP-Fehler 404.0 - Not Found die gesuchte Ressource wurde entfernt oder umbenannt, oder sie steht vorübergehend nicht zur Verfügung. Angeforderte URL https://localhost:443/ecp/?ExchClientVer=15.

Nach meinem Verständnis liegt auf dem Mailboxserver nur das Backend. Auf dem IIS ist in der Default Web Site nur der Ordner aspnet_client und die Seite PowerShell enthalten. Von ECP oder dergleichen nichts zu sehen.

Ist der Zugriff auf den Administrative Center vom Mailboxserver aus generell nicht möglich?

Danke für Eure Antworten.

Mario

Hallöchen zusammen,

kurz vor Weihnachten, habe ich ein merkwürdiges Phänomen.

Alle Win7 Clients sind mit Office 2013 Pro Plus bestückt inkl. aller Updates, der Exchange Server 2013 Enterprise hat das aktuelle Update CU7, es ist alles aktuell.

Nun erscheinen die öffentlichen Ordner in keinem Outlook, in OWA sehe ich diese sofort.

Außerdem habe ich herausgefunden, dass wenn ich, was ich eigentlich nur zu Testzwecken nach der Migration durchgeführt hatte, ein öffentliches Ordnerpostfach als "Standardpostfach" einem Exchange Konto zuweise, die Darstellung schon nach wenigen Sekunden bzw. einem Schließen und erneuten Öffnen von Outlook korrekt erfolgt.

Ich verwende den Befehl Set-Mailbox -Identity POSTFACH -DefaultPublicFolderMailbox "NAME PF Mailbox".

Habt Ihr eine Idee, wie ich die Ordner für meine 55 Mailboxen sichtbar machen kann?

Danke und Grüße

Mario

Danke Dir Doso.
 
Habe folgende Registry Werte überprüft:

1. HLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\

2. HCU\Software\Microsoft\Windows NT\CurrentVersion\Devices\

3. HCU\Software\Microsoft\Windows NT\CurrentVersion\PrinterPorts\

4. HLM\SYSTEM\ControlSet001\Control\Print\Printers\

5. HLM\SYSTEM\CurrentControlSet\Control\Print\Printers

6. HCU\Printers\Connections

In keinem dieser Schlüssel ist der Drucker aufgeführt.

Ich finde diesen über eine Suche in der Registry allerdings in folgenden Schlüsseln:

1. HLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\SRV02\Printers\

2. HLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Providers\Servers\SRV02\Printers\

3. HLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Drivers\Version-4\

4. HLM\SYSTEM\ControlSet002\...

5. HLM\SYSTEM\CurrentControlSet\...

Stutzig macht mich der Eintrag mit Client Side Rendering Print Provider, SRV02 ist der Printserver im Netzwerk.

Kann ich diese Registry Einträge löschen? Was haltet Ihr davon?

Hallo zusammen,

mein Problem bezieht sich auf das Vorhandensein eines alten ausrangierten Druckers Laserjet HP, der über Netzwerk eingebunden war. Der Drucker war an einem 2012 R2 Server eingerichtet, bis er vorletzte Woche abgebaut wurde. Dort ist dieser Drucker über eine Benutzer GPO den angemeldeten Remotedesktop-Benutzern zugewiesen worden, sowie den Benutzern, die sich an Phat Client mit Windows 8.1 anmelden.

Nun verschwindet dieser Drucker nicht mehr, weder vom Server, noch von den Windows 8.1 Clients, er lässt sich zwar entfernen, ist aber nach einer erneuten Anmeldung wieder da. Ganz gleich welcher Benutzer, sogar das abklemmen vom Netzwerk - getestet mit dem Remotedesktopserver und einem Phat-Client - führt zu der Erstellung eines Gerätes im Gerätemanager unterhalb von Druckwarteschlangen.

Nachgestellt habe ich dieses Verhalten mal an einem Win 8.1 Rechner aus einem ganz anderen Netzwerk, der ebenfalls auf Druckerobjekte auf einem Windows 2012 R2 Printserver zugreift. Auch hier kann ich zwar im Gerätemanager das Warteschlangenobjekt entfernen, aber wenn ich dann "nach neuer Hardware suche", wird der Drucker wider erstellt und erscheint auch wieder nutzbar.

Ach, der Drucker ist auf dem Printserver ja gar nicht mehr vorhanden. Und obwohl er automatisch unter Drucker und Geräte erstellt wird, ist er nicht auswählbar, wenn ich in irgendeiner Applikation in die Druckerauswahl gehe.

Was könnt Ihr mir hierzu sagen? Irgendwas muss ich noch löschen, worauf ich aber nicht komme.

Danke und Grüße

Hallöchen,

leider muss ich das Thema nochmals aufwärmen. Die Probleme haben sich leider nicht aufgelöst. Folgende Probleme existieren momentan noch:

1. Outlook 2013 meldet beim Einrichten eines neuen E-Mail Profils mit Exchange Konto in der Domäne folgendes: "Fehler beim Anmelden. Überprüfen Sie die Netzwerkverbindung sowie den Server- und Postfachnamen. Es steht keine Verbindung mit Exchange zur Verfügung. Outlook muss im Onlinemodus oder verbinden sein, um diesen Vorgang abzuschließen".
2. Einige bereits eingerichtet Konten über Outlook 2013 keine Kalendereinträge anderer Benutzer sehen, trotz Berechtigung, oder aber Sie können den Abwesenheits Assistenten nicht benutzen.
    Über OWA funktioniert der Assistent problemlos und ohne Fehler.

zu 1.: Wenn ich in die manuelle Konfiguration des Exchange Kontos gehe, dann fehlen bei "Weitere Einstellungen | Verbindungen" sämtliche Einträge bzw. ist erst gar kein Haken gesetzt bei "Verbindung mit Microsoft Exchange über http herstellen. Setze ich den Haken und ergänze die Informationen "Exchange-Proxyserver" mit "remote.kundendomain.com" und "Prinzipalnamen" mit "msstd:remote.kundendomain.com", dann klappt die Verbindung zum Exchange sofort und ohne Probleme.

Was muss ich tun, damit diese Einträge auch gesetzt werden? Offensichtlich braucht das Konto die Einstellungen zum Zugriff selbst intern. Von Exchange 2010 bin ich das zwar anders gewohnt, vielleicht liegt aber auch ein Konfigurationsfehler vor?

Wäre dankbar für Hilfe.

Danke Euch.

Mario

Problem gelöst.

Die Lösung enthalte ich Euch nicht vor.

Get-ClientAccessServer | ft

Hier war AutoDiscoverServiceInternalUri auf https://remote.kundendomain.com gestanden

Set-ClientAccessServer -Identity 'SERVERNAME CAS' -AutoDiscoverServiceInternalUri "https://remote.kundendomain.com/Autodiscover/Autodiscover.xml"

Brachte den gewünschten Erfolg. Outlook verbindet sich nun automatisch intern mit dem Postfach, Kalendereinträge sind ebenfalls aus einem anderen Postfach sichtbar und der Abwesenheits-Assistent funktioniert auch.

Hallöchen,

nun läuft mein Exchange Server schon einige Wochen und nachdem ich ca. 15 Postfächer anfänglich eingerichtet hatte, wollte ich ein neu erstelltes Postfach in Outlook 2013 einrichten. Nur leider klappt die automatische Einrichtung nicht mehr. Das Postfach wird zwar vom Einrichtungs Assistenten von Outlook 2013 gefunden, kann dann aber mit einer Fehlermeldung nicht final konfiguriert werden.

Wie ich festgestellt habe, liegt es an den Exchange-Proxyeinstellungen. Denn trage ich diese in den erweiterten Konfigurationsoptionen ein, dann lässt sich das Postfach problemlos verbinden und funktioniert einwandfrei.

Ich hatte an den Einstellung für Autodiscover etwas verändert. Dafür habe in der Domäne im DNS-System eine neue Zone eingerichtet die auf die konfigurierte externe Domain lautet hier remote.domain.de

Hierunter befindet sich der Verweis auf den Exchange Server, sprich die interne IP-Adresse des Exchange. Dann habe ich alle virtuellen Verzeichnisse umgestellt. Alle internen und externen URL's verweisen auf remote.domain.de

Was fehlt an der Konfig bzw. ist falsch? Muss ich eventuell noch einen SRV-Record für _autodiscover einrichten?

Danke und Grüße an Euch.

Mario

Danke auch Dir RobertWi. Ist der CAS01 der Exchange Server selber?

Ich beantworte meine Frage gleich selber, sorry: Nachdem wir einen Exchange Server mit Client Access haben, ist es in unserem Fall der Exchange Server, der hier zu verwenden ist. Habe den Set-ClientAccessServer Befehl abgesetzt.

Wenn ich nun Get-ClientAccessServer -Identity "Cas-01" | ft AutoDiscoverServiceInternalUri eingebe erhalte ich:

https://remote.kundendomain.com

Die virtuellen Verzeichnisse bis auf Powershell habe ich alle auf https://remote.kundendomain.com angepasst.

Sollte es das gewesen sein?

Vielen Dank an Euch.

Hi,

danke erst mal für Deinen Ansatz.

Auf dem DNS-Server existiert bereits eine eigene Zone, die auf den externen Namen lautet, also "remote.kundendomain.com" in der sich wiederum ein Host mit der internen Server IP befindet, das sollte die Split.-DNS Konfiguration sein. Kläre mich bitte auf, wenn ich hier irgendwas falsch verstehe. Pinge ich von intern die externe Url "remote.kundendomain.com" erhalte ich die korrekte interne IP-Adresse zurück.

Meinst Du mit URL der virtuellen Verzeichnisse alle? Die sollen dann wohl alle auf "remote.kundendomain.com" laufen und keine Unterscheidung mehr nach intern und extern vornehmen?

Grüße

Hallöchen,

leider komme ich bei einem Kunden nicht weiter. Das Szenario sieht wie folgt aus: 2012 R2 DC, 2012 R2 Server mit Exchange 2013 Standard, 20 Win 8.1 Pro Client mit Outlook 2013.

Ich habe bei DF ein Wildcard Zertifikat geordert, dass auf *.kundendomain.com lautet. Den Antrag hierzu habe ich über die Exchange Verwaltungskonsole durchgeführt. Ausgewählt hatte ich das Platzhalterzertifikat mit der Stammdomäne kundendomain.com

Nachdem ich das Zertifikat wieder über die Exchange Verwaltungskonsole eingespielt hatte, fingen die Probleme bei den Clients an. Es erscheint in regelmäßigen Abständen, vor allem aber kurz nach der Anmeldung bzw. dem Öffnen von Outlook, ein Sicherheitshinweis, der mit sagt, dass der Server nicht mit dem Namen der Webseite auf dem Zertifikat übereinstimmt. Das ist auch so bestätigt, denn die Meldung spricht ganz oben in diesem Hinweisfenster von dem internen Server srv05.internedomaene.local und auf dem Zertifikat steht ja der externe Name.

Über Get-Outlookprovider bekomme ich als Server srv05.internedomaene.local und Als Prinzipalname msstd:*.kundendomain.com

Habe auch schon den Artikel auf www.it-dienstleistungen.de mit dem Thema "MS Exchange Problem: Servername und Name im Zertifikat stimmen nicht überein" durchgearbeitet, allerdings kann ich den Punkt "AutoDiscoverVirtualDirectory" nicht ausführen, da es diese Funktion offensichtlich in Exchange 2013 nicht mehr gibt, wie ich in einem TechNet gelesen habe.

Was kann ich tun, damit diese Meldungen endlich verschwinden?

Danke und Grüße

Mario