peterg
-
Gesamte Inhalte
576 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von peterg
-
-
Hallo,
ich habe jetzt sogar eine renommierte IT-Firma (hat in vielen Städten eine Filiale) eingeschaltet. Der "Exchange-Mann" hat bisher auch nur im Nebel rumgestochert. Da war ich schon etwas enttäuscht. Er wöllte sich letzte Woche nochmal melden. Fehlanzeige.
Könnt Ihr mir einen Exchange-Experten empfehlen, der das Thema lösen kann? Natürlich gegen Bezahlung. Zugriff über Teamviewer ist kein Problem.
Gruß,
Peter
-
Nein, den gab es noch nie. Es funktioniert auch nicht mit einem anderen User.
-
STARTTLS, Port. 587, Passwort: normal
-
Hatte die erweiterten Features nicht aktiviert!
Selbst -> "Senden als" war aber schon aktiviert :-(
-
Hallo Norbert,
ich habe den User unter "Senden als" und unter "Vollzugriff" am Exchange eingetragen, was leider nichts brachte :-(
Es kommt die gleiche Fehlermeldung: 5.7.60 SMTP; Client does not have permissions to send as this sender
Das gibt es doch nicht....
Als SMTP-Server kommt nur "remote.ABC.de" in Frage, da hierfür auch das Zertifikat vorhanden ist. Richtig?
Beim srv-exch.XY.local als SMTP-Server kommt immer die Meldung, dass der Domainname nicht mit dem Zertifikat des Servers übereinstimmt.
Kann es was mit den akzeptierten Domänen im Exchange zu tun haben? Hier ist XY.local als "Autoritativ" und ABC.de als "Externes Relay" eingetragen.
Sollte ich mal einen neuen Empfangsconnector anlegen und nicht den „Client Frontend“ benutzen, wobei der ja eigentlich dafür da ist.
Unter https://www.fachinformatiker.de/topic/160354-exchange-und-smtp-von-anderen-clients ganz am Ende steht auch noch was, aber ich weiß nicht wie ich zu dieser Einstellung komme. --> So haben zumindest alle Email-aktivierten Benutzer unter "Sicherheit" neue Einstellungen wie zB: "Exchange Informationen lesen". Mit dabei ist dann auch das "Senden als" Recht. Postfachstellvertreter sind ein ganz anderes Thema ...
Gruß,
Peter
-
Hallo,
erstmal vielen Dank für die Tipps und das man hier im Forum immer superschnelle Unterstützung bekommt. Leider hat sich mein Problem nicht gelöst und falls ich es in dieser Woche nicht hinbekommen, dann hole ich einen Profi. Hilft ja nix.
Nochmal alles in einer Zusammenfassung, da die Lösung sicher nicht mehr so weit weg ist.
Ich habe auch einen neuen Testuser angelegt. Der Testuser ist nur lokaler Admin.
Domäne: XY.local (XY nur beispielhaft)
Exchange: srv-exch.XY.localE-Mail-Domain: ABC.de (ABC nur beispielhaft)
OWA funktioniert einwandfrei, Exchange erreichbar unter https://remote@ABC.de/owa
Zertifikat für remote.ABC.de und autodiscover.ABC.de am Exchange vorhanden
Testuser: test
E-Mail in Exchange: test@ABC.de (als Standard) und test@XY.localIn Thunderbird (immer gleich):
STARTTLS, Port 587, Passwort normalTest 1-1:
Anmeldung am Rechner: XY\test
Benutzername in Thunderbird: XY\test
SMTP-Server: srv-exch.XY.local
Fehler: Sichere Kommunikation mit der Gegenstelle ist nicht möglich. Angeforderter Domainname stimmt nicht mit dem Zertifikat des Servers überein.Test 1-2:
Anmeldung am Rechner: XY\test
Benutzername in Thunderbird: XY\test
SMTP-Server: remote.ABC.de
Fehler: Der Mail-Server antwortete:5.7.60 SMTP; Client does not have permissions to send as this senderTest 2-1:
Anmeldung am Rechner: test@XY.local
Benutzername in Thunderbird: test@XY.local
SMTP-Server: srv-exch.XY.local
Fehler: Sichere Kommunikation mit der Gegenstelle ist nicht möglich. Angeforderter Domainname stimmt nicht mit dem Zertifikat des Servers überein.Test 2-2:
Anmeldung am Rechner: test@XY.local
Benutzername in Thunderbird: test@XY.local
SMTP-Server: remote.ABC.de
Fehler: Der Mail-Server antwortete:5.7.60 SMTP; Client does not have permissions to send as this senderTest 3-1:
Anmeldung am Rechner: test@ABC.de (UPN-Suffix @ABC.de im AD ergänzt)
Benutzername in Thunderbird: test@ABC.de
SMTP-Server: srv-exch.XY.local
Fehler: Sichere Kommunikation mit der Gegenstelle ist nicht möglich. Angeforderter Domainname stimmt nicht mit dem Zertifikat des Servers überein.Test 3-2:
Anmeldung am Rechner: test@ABC.de (UPN-Suffix @ABC.de im AD ergänzt)
Benutzername in Thunderbird: test@ABC.de
SMTP-Server: remote.ABC.de
Fehler: Der Mail-Server antwortete:5.7.60 SMTP; Client does not have permissions to send as this senderGruß,
Peter
-
Hallo Norbert,
irgendein Domänenmitglied soll nur bedeuten, dass es sich einen Domänenuser mit Exchange-Postfach handelt. Bei "From" ist es die korrekte E-Mail-Adresse des Users, die man ja nicht öffentlich zeigen will.
Ok, dann melde ich mich mal mit einem Domänenuser mit Exchange-Postfach auf einem Rechner an, installiere Thunderbid und versuche mein Glück.
In der Software kann dann nur STARTTLS mit Port 587 richtig sein.
Thunderbird bekomme ich auch nicht hin. :-(
Ich bin am Rechner mit dem entsprechenden Domänenuser angemeldet.
Es kommt beim Senden die Meldung:
5.7.60 SMTP; Client does not have permissions to send as this sender
In Thunderbird:
STARTTLS, Port: 587, Passwort, normal, Benutzernahme: domäne\Domänenbenutzername
Als SMTP-Server habe ich "remote.xxx.de" eingegeben. Also nicht den realen Exchange srv-exch.xx.local
Muss ich ggf. noch folgendes konfigurieren?
Get-mailbox | Add-Mailboxpermission -user "NT AUTHORITY\SELF" -Accessrights FullAccess
Gruß,
Peter
-
Hallo,
wir haben hier eine Projektverwaltungssoftware, welche nun auch mit Exchange funktioniert.
In der Software sind alle User angelegt und die entsprechenden Daten unseres Exchange 2016 hinterlegt (IMAP, SMTP).
Der Posteingang des Users wird in der Software angezeigt und entsprechende Mails können einem Projekt zugeordnet werden. Dies funktioniert über IMAP, SSL/TSL, Port 993 mit dem entsprechenden Domänenbenutzernamen des Users und dem Passwort. Das haut auch hin.
Nun können aber auch E-Mails über die Projektverwaltungssoftware versendet werden. Dies soll über SMTP, verschlüsselt, Port 587 mit dem entsprechenden Domänenbenutzernamen des Users und dem Passwort funktionieren. Das funktioniert leider nicht ☹
Ich würde dafür gerne den „Client Frontend“ Empfangsconnector benutzen. Die aktivierten Sicherheitseinstellungen sind:
- Transport Layer Security (TLS)
- Standardauthentifizierung + Standardauthentifizierung erst nach dem Start von TSL anbieten
- Integrierte Windows-Authentifizierung)
- Berechtigungsgruppen: Exchange-Benutzer
Der Bereich ist bei Remotenetzwerkeinstellungen: 0.0.0.0-255.255.255.255,
bei Netzwerkadapterbindungen: Alle verfügbaren IPv4 und IPv6 auf Port 587Der FQDN ist der DNS-Alias (hier als Beispiel remote.xxx.de) auf dem der Server z.B. auch unter OWA erreichbar ist, also nicht der reale Servername (srv-exch.local).
Dem "Client Frontend" habe ich die Konfiguration des vorhandenen SSL Zertifikats zugeordnet.
$cert = Get-ExchangeCertificate -Thumbprint xxxxx
$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"
Set-ReceiveConnector "SRV-EXCH\Client Frontend SRV-EXCH" -Fqdn remote.xxx.de -TlsCertificateName $tlscertificatenam
Wenn ich nun über PowerShell „Send MailMessage“ probiere eine E-Mail zu versenden (vorher mit $credential = Get-Credential als irgendein Domänenmitglied mit Exchangepostfach angemeldet):
Send-MailMessage -SmtpServer remote.xxx.de -Credential $credential -From "test.test@xxx.de" -To "xxx@gmx.de" -Subject "Test email" -Port 587 -UseSsl
kommt die Fehlermeldung:
Send-MailMessage: Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender
In Zeile:1 Zeichen:1
+ Send-MailMessage -SmtpServer remote.xxx.de -Credential $credential - …
+ CategoryInfo: InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage] SmtpException
+ FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage
--> Das sollte ja erstmal als Voraussetzung funktionieren. Hier ist aber schon der Wurm drin.
In der Software komme ich gar nicht zum Test für das Senden, da der Port 587 oder Port 465 bei SSL/TSL nicht akzeptiert wird. Es kommt die Fehlermeldung:
Fehler/Error in page „Portletprocess“ 2: stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:1408F10B:SSL routines:ssl3_get_record:wrong version number-> Nur bei STARTTLS wird der Port 587 in der Software akzeptiert.
Was habe ich falsch gemacht?
Evtl. kann mir ja jemand helfen. Danke!
Gruß,
Peter -
vor 3 Stunden schrieb Weingeist:
Habe allerdings eine Lösung die dann geklappt hat. Da es scheinbar ein Timing-Problem ist, habe ich mal die Verzögerung eingebaut:
Das heisst: den Dienst nlasvc von "Automatisch" auf "Automatisch (verzögert)" wechseln.
--> Das wiederum ist eine simple Konfig z.Bsp. per GPO und Registry.
Habe eine Maschine nun 20x durchgestartet und jedes mal hats geklappt. Dann auf andere ausgerollt und tut auch. =)
Das habe ich anfangs probiert und hat nicht funktioneirt. Ich habe sogar Abhängigkeiten definiert. Scheinbar alles sehr individuell.
-
Ich führe 2 Minuten nach den Neustart ein Script aus um den NLA-Dienst neu zu starten. Das funktioniert einwandfrei. Danke für die weiteren Infos.
-
So soll es sein!
TNX,
Peter
-
Hi, scheinbar (zumindest seit dem Neustart in der früh um 8:00 nicht mehr). Habe ich auch gleich in der ersten Zeile geschrieben.
Ich habe auch schon ein paar Mal neu gestartet (nicht heute) und der Fehler ist nicht gekommen. Dachte schon an eine wundersame Selbstheilung
Gruß,
Peter
P.S. 192.168.x.8 ist der DC
(der eintzige DC)
-
Hallo,
nach einer neuen Installation eines virtuellen DC (Server 2019 Std.) unter Hyper-V kommt folgende Fehlermeldung. Die Meldung kommt nur nach einem Neustart
---
Bei der dynamischen Registrierung des DNS-Eintrags "xxx.local. 600 IN A 192.168.x.1" auf folgendem DNS-Server ist ein Fehler aufgetreten:
IP-Adresse des DNS-Servers: 192.168.x.1
Verbindungsantwortcode (RCODE): 0
Zurückgegebener Statuscode: 9502Dieser Eintrag muss in DNS registriert sein, damit Computer und Anwender diesen Domänencontroller finden können.
BENUTZERAKTION
Ermitteln Sie, was diesen Fehler verursacht hat. Beheben Sie das Problem, und initialisieren Sie die Registrierung der DNS-Einträge durch den Domänencontroller. Um festzustellen, was diesen Fehler verursacht hat, führen Sie "DCDiag.exe" aus. Weitere Informationen zu "DCDiag.exe" finden Sie im Hilfe- und Supportcenter. Führen Sie "nltest.exe /dsregdns" über die Eingabeaufforderung des Domänencontrollers aus, oder starten Sie den Anmeldedienst neu, um die Registrierung der DNS-Einträge durch diesen Domänencontroller zu initialisieren.Alternativ können Sie den Eintrag manuell zu DNS hinzufügen. Dieser Schritt wird jedoch nicht empfohlen.
ZUSÄTZLICHE DATEN
Fehlerwert: Ungültiges DNS-Paket.---
Bei dcdiag.exe /test:dns sind alle Tests bestanden
Bei dcdiag.exe /test:registerindns /dnsdomain:xxx.local /v sind alle Tests bestanden
Bei nltest.exe /dsregdns klappt auch alles
Ich habe einen Testclient an die Domäne angebunden. Hier scheint auch alles zu funktionieren (nslookup, ….)
Bei den im WEB gefunden Lösungsvorschlagen komme ich nicht wirklich weiter.
Hat jemand eine Idee?
Gruß,
Peter
-
Ja, ich habe mir schon ein Script gebastelt. Ja, es gibt nur einen DC.
-
Hallo,
wenn ich den neu installierten Domänenserver (MS Server2019 Std, als VM unter Hyper-V) neu starte, wird als aktives Netzwerk nicht das Domänennetzwerk, sondern das „private Netzwerk“ angezeigt.
Behelfen kann ich mir damit, dass ich im Netzwerk- und Freigabecenter -> Adaptereinstellungen, die Netzkarte kurz deaktiviere und wieder aktiviere. Dann wird das Domänennetzwerk angezeigt.
Oder ich starte den NLA-Dienst neu. Dann wir auch das Domänennetzwerk angezeigt.
Ich habe auch schon Lösungsansätze gefunden (LNA-Dienst abhängig des Anmeldedienstes zu machen, LNA und DNS-Dienst auf „verzögerten Autostart“, DNS mit 127.0.0.1 eintragen), welche aber nichts gebracht haben.
Gibt es noch andere Lösungsansätze?
Gruß,
Pit
-
vor 15 Minuten schrieb djmaker:
Ja!
Wie es ausschaut ist es das Problem, auf welches Gulp hinweist.
vor 19 Minuten schrieb Gulp:Erster Treffer mit "mmc snapin wsecedit.dll failed": (gut ist von heute der Artikel .......
)
Hi, Gulp hat die Problemlösung gefunden. Es ist das Update KB4577015. Nach der Deinstallation funktioniert das Snap-In wieder.
DANKE!
-
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\130\DTS\Binn\;C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps; PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC -
-
Auch wenn nur security policies betroffen sind, hilft mir das bei der Problemlösung ja leider auch nichts.
-
Hi, auf der Seite war ich leider auch schon. Der Pfad war schon vorhanden. Die MMC funktioniert ja generell. Nur bei den "Lokalen Richtlinen", die "Sicherheitsoptionen" nicht. Die beiden anderen Bereiche (Überwachungsrichtline und "Zuweisen von Beuntzerrechten") funktioneiren (siehe Bild). Wie gesagt habe ich das Problem bei zwei Neuinstallationen bei denene ich gleich alle MS Updates installiert habe, bevor ich mit der Konfiguration begonnen habe.
Aber danke.
Ich bin schon fast rein aus Neugierde soweit, dass ich nochmal eine Test-VM installiere und das Snap-In gleich nach der Installation teste.
Gruß,
Peter
-
Hallo,
ich habe hier ein Problem mit dem Snap-In „Sicherheitseinstellungen -> Lokale Richtline -> Sicherheitsoptionen“.
Wir haben heute (gestern, ist ja schon fast 2 Uhr) mit unserer IT-Firma einen neuen Backupserver (neuer ESXi-Host) mit einer Windows Server 2016 Std. VM und auf einem bestehenden ESXi-Host eine zusätzliche Server 2016 Std. VM unter VMware 6.7 installiert. Leider wurde es sehr spät und die reine Windowskonfiguration mit den Feinheiten wollte ich dann später machen. Nun habe ich festgestellt, dass auf beiden Systemen das Snap-In der Sicherheitsoptionen nicht funktioniert Es kommt die Meldung : Snap-In konnte nicht initialisiert werden (siehe Bilder).
Beide Server wurden standardmäßig installiert und dann die MS Updates installiert. Dass nun beide Server das Problem haben ist schon irgendwie komisch. Der Backupserver ist nicht in der Domäne, der andere Server schon.
Ich habe nun schon sehr lange gegoogelt und leider keinen Lösungsansatz gefunden. Die MMC selbst funktioniert (im Suchfeld MMC eingeben und öffnen). Kann man eigentlich über die MMC ein Snap-In der „Sicherheitsoptionen“ erstellen (habe es nicht hinbekommen)?
Hat evtl. jemand einen Tipp wie ich das Problem lösen kann?
Schöne Grüße und gute Nacht
Peter
-
Hi,
wenn die Exchange-Dienste deaktiviert sind und der Rechner neu gestartet wird, dann funktioniert das "Netzwerk" bei der VM einwandfrei. Irgendwie kommen die Dienste des Exchange bei einem Neustart in die Quere.
Ja, sobald im Netzwerk-/Freigabecenter wieder die Netzwerkkarte und die Domäne angezeigt wird, funktioniert auch der Exchange wieder.
Neuinstallation, etc. kommt nicht in Frage. Das ist mir zu viel Aufwand zumal wir auch nicht mehr genügend Festplattenspeicher für so eine Aktion haben. Da müste ich Festplattenspeicher hin und herschieben. Der Server ist ja schon über 5 Jahre alt und muss noch 1,5 Jahre durchhalten. Evtl. lass ich einfach alles so, solange man nach der ersten Anmeldung bei einem Neustart 5 Min warten muss und sich dann nochmal anmelden muss, damit alles funktioniert. Gefällt mir natürlich nicht so, aber scheinbar gibt es keine Lösung. Alles was ich im Internet gefunden habe hat leider nicht funktioniert. Ich habe bei den Updates eigentlich alles richtig gemacht und die Integrationsdienste sind aktuell.
Vielleicht löst sich das Problem beim nächsten Update der Integrationsdienste
Evtl. habe Ihr ja noch eine Idee? Ansonsten vielen Dank für Eure Zeit.
Gruß,
Peter
-
Ja, so ein Mist.
Evtl. doch den MS Support einschalten und die 400 € für die Problemlösung bezahlen?
-
Hi Norbert,
das Vorgehen gemäß dem Link brachte leider nichts. Gleiche Situation. Wie gesagt kann ich nichts "updaten" da die Integrationsdienste (6.3.9600.19456) schon aktuell sind (siehe Bild).
Da ich nicht vor dem Server sitze habe ich den Safe Mode über msconfig eingestellt und neu gestartet.
Jetzt könnte ich noch Updates deinstallieren, wie Du vorgeschlagen hast. Aber welche?
Kann man das letzte Update der Integrationsdienste deiinstallieren? Welches ist das (habe schon wie b***d gegoogelt) oder geht das über den "Datenträger für Integrationsdienste" und dann setup.exe /uninstall ?
Gruß,
Peter
Umstellung zu Office365 - generelles Vorgehen
in Windows Forum — Allgemein
Geschrieben
Hallo,
ich bin mir nicht sicher, ob es die richtige Gruppe ist.
Wir möchten von unserem Exchange 2016 auf Office365 wechseln. Aktuell haben wir wg. Teams schon ein paar O365 Benutzer, aber noch ohne E-Mail. Aktuell werden unserer Mails via POPcon bei unserem Provider abgeholt und an den eigenen Exchange-Server weitergeleitet. Es geht nur um 12 Konten.
Ich hatte mit O365 bisher nichts zu tun, daher sorry für evtl. "dumme" Fragen.
Meine Fragen wären:
1. Was müssen wir tun, damit unter O365 unsere E-Mail-Domain bei Microsoft als Managed Exchange unter Office 365 funktioniert? Wir haben ja schon eine E-Mail-Domäne, die wir natürlich weiterhin benötigen. Im O365 Admin-Center gibt es ein Setup für "Einrichten Ihrer Domäne"(Angeleitete Einrichtung) Das scheint das richtige Setup zu sein. Ich habe auch schon mal den TXT-Eintrag beim bisherigen Provider gemacht und unsere Domain somit validiert. Nun könnte ich alle Nutzer anlegen und letztendlich muss ich die Nameservereinstellungen (CNAME, MX und TX) beim bisherigen Provider anpassen.
War es das dann?
Kann ich zum Test auch erstmal nur einen User anlegen und "migrieren"?
2. Der bisherige E-Mail-/Webspace-Provider soll erhalten bleiben, da wir hier noch ein paar POP3 Konten behalten möchten. Das sollte funktionieren, oder?
Bzw. kann man unter Ofifice365 auch E-Mai-Adressen (innerhalb der E-Mail-Domain) anlegen, welche nicht am Exchange sind? Das sind reine Verwaltungsadressen. Office etc. wird nicht benötigt. Ist ja auch eine Kostenfrage.
3. E-Mail-Migration
Das ist dann der letzte Schritt. Erstmal möchte ich verstehen, was ich wegen unserem aktuellen E-Mail-Provider machen muss.
Aber mal generell. Kann ich bei nur 12 Exchange Konten nicht einfach via Exchange je eine PST-Datei erstellen, den Exchange abschalten, dann das Outlook-Profil löschen und ein neues Profil mit Office 365 verbinden (Nameservereinstellungen sind ja dann schon geändert) und dann die entsprechende PST-Datei importieren? Ist das zu einfach gedacht?
Schöne GrüßePeter