Smidddi

Hallo ihr beiden, sorry der verspäteten Antwort. @Nobby: Es sind schon einzelne Mailboxen. Allerdings werden Mailboxen der Domäne @C.de nicht direkt angesprochen sondern die E-Mails die dort eingehen direkt an das entsprechende Postfach der Domäne @B.de weitergeleitet. @Doso: Ja, ist korrekt. Unterschiedliche Dinge und unterschiedliche Berechtigungen. Allerdings meine ich, dass in beiden Fällen derselbe Unzustellbarkeitsbericht kommt, falls Berechtigungen nicht passen.

Moin Nobby, das zweite Konto ist garnicht eingebunden, da es eigentlich garnicht existiert. Dementsprechend gibt es eine Weiterleitung von E-Mails @C.de direkt in das Postfach von @B.de. Die Berechtigung Vollzugriff wurde auch nicht gesetzt, da diese beim 2010er auch nicht notwendig gewesen zu sein scheint.

Hallo zusammen, ich machs mal kurz: Server: Server 2012R2, Exchange 2016 (jeweils aktuelle Updates bis 08.03.2016) Clients: Windows 7 pro, Outlook 2010/2013 Infrastruktur: Microsoft Active Directory (Schema + Funktionsebene 2012R2) Problem: Einige User im Netz haben 2 E-Mail Postfächer, um E-Mails über eine andere Domäne verschicken zu können. Dementsprechend wurden per ECP (und schließlich auch nochmal per Powershell um Bugs auszuschließen) SendAs Berechtigungen für den entsprechenden User gesetzt. Folgender Ablauf: - User A ist mit seinem AD Konto angemeldet (Exchange Postfach A@B.de) - User A möchte eine E-Mail über A@C.de schicken und gibt dazu manuell die E-Mail Adresse A@B.de im "Von" Feld in Outlook ein - kurz nach dem Versand der Nachricht erhält er einen Unzustellbarkeitsbericht mit Fehlermeldung: Diese Nachricht konnte nicht gesendet werden. Versuchen Sie es später erneut, oder wenden Sie sich an den Netzwerkadministrator. Sie besitzen nicht die Berechtigung, die Nachricht im Auftrag des angegebenen Benutzers zu senden. Fehler: [0x80070005-0x0004dc-0x000524]. Nach einigen Tests gestern konnte ich nun ein Verfahren identifizieren, welches offensichtlich (Test via OWA) erstmal funktioniert hat: - User A ist mit seinem AD Konto angemeldet (Exchange Postfach A@B.de) - User A möchte eine E-Mail über A@C.de schicken und wählt nun das korrekte Postfach über das "Von" Feld aus - Die Nachricht erreicht den Empfänger Heute morgen dann meldet User A, dass obiges Verfahren genau ein Mal funktioniert, beim Versuch eine weitere Nachricht zu versenden erhält er wieder den Unzustellbarkeitsbericht. Abgesehen davon, dass der funktionierende Weg echt unkomfortabel ist hat die Eingabe der E-Mail Adresse und reine Auswahl dieser als Absender unter Exchange 2010 noch ausgereicht. Kann man eine entsprechende Anpassung am Exchange 2016 vornehmen, sodass auch hier wieder "einfach" gearbeitet werden kann? Oder gibt es eine Alternative zu den zwei Postfächern? (Habe es mit einem Postfach und Eintragung der E-Mail Adressen beider Domänen versucht, es kann offenbar auch weiterhin lediglich unter der primären SMTP Adresse verschickt werden). Besten Dank für jegliche Unterstützung.

Der Tipp von Sanches trifft es eigentlich ganz gut. Selbige Fehlermeldung habe ich am Wochenende erhalten, allerdings nur bei Clients, die nicht im Active Directory eingebunden waren (Homeoffice). Für diese musste bei Verwendung von Outlook Anywhere das Zertifikat der Zertifizierungsstelle, welches das Exchange Zertifikat ausgestellt hat, zu den vertrauenswürdigen Stammzertifizierungsstellen hinzugefügt werden -> Alles gut. Hast du also eine interne Zertifizierungsstelle oder verwendest du ein "sauberes" Zertifikat?

@ Norbert: In der neuen Exchange Datenbank wurden die Postfächer, die sich aus der alten nicht migrieren ließen, neu angelegt. Jo. Dabei kam es auch nicht zu Problemen, sondern lediglich beim Zugriff auf eines der defekten Postfächer, sei es nun durch Migrationsversuche oder Clientzugriff. @ Robert: Ich kann die Grundaussage schon nachvollziehen :-) Steht leider viel zu viel Schund im Netz. Ich selbst würde mich, mit mittlerweile knapp 8 Jahren Exchange Erfahrung, nicht als unerfahren bezeichnen und habe bislang auch schon die ein oder andere Reparatur, falls erforderlich, durchgeführt. Nur diesen Status der Datenbank hatte ich so eben noch nicht, das war schon recht heftig...Darum wurde auch als erstes eine Kopie der DB erstellt und erst dann "wild rumgedoktort" :-P Nicht ausgeschlossen, damit wird nächste Woche der Kaspersky Support konfrontiert, da wir dieses Produkt nicht nur bei einem Kunden einsetzen...

Hallo, ab Windows 7 hiier: C:\ProgramData\Microsoft\User Account Pictures

Server Error in '/wiki' Application. The resource cannot be found :-(

zu 1. Ja ist richtig. kA, wer den Kaspersky dort eingerichtet hat (leider wird man bei soetwas ja immer zu spät dazugerufen...). Ausnahmen sind bereits konfiguriert. zu 2. Wodurch der Defekt letztendlich entstanden ist, kann ich nicht nachvollziehen. Wenn ich das richtig verstehe sorgen fehlende / unvollständige Transaktionsprotokolle ja erstmal nicht für eine defekte Datenbank, sondern einen defekten Datenbestand? zu 3. Bei den Reparaturversuchen wurde, meiner Meinung nach, nicht wild rumgedoktort sondern an Hand diverser Technet Artikel Anweisungen befolgt, die auf Grund der aufgetretenen Fehlermeldungen als hilfreich betrachtet hätten werden können. zu 4. mein Fehler in der Kommunikation, die Datenbank konnte gemountet werden, allerdings ist der Informationsspeicher bei jedem Zugriff auf eines der defekten Postfächer abgestürzt. zu 5. Danke für die Korrektur, ist einleuchtend. Und der PST Import war leider der letzte Weg, ohne funktionierende Datensicherung Die Infrastruktur wird aktuell geprüft. Die Ausnahmen im Virenscanner sind bereits definiert. Das Monitoring und Testen der Datensicherung wurde bislang nicht durchgeführt. Das Backup selbst erfolgt via WBAdmin. Danke für den Link, das Thema werde ich mir bei Erstellung eines entsprechenden Konzepts nach Prüfung der Infrastruktur zur Brust nehmen. Gerade der Punkt Inkonsistenzen in Datenbanken und so :-)

Hi, 1. @ Doso: /sign 2. vernünftige Backup Lösung = Software, die Geld kostet (oder aber Replication auf separaten, baulich getrennten, Standort mit Hyper-V Boardmitteln) Schau dir mal das Produkt VEEAM Backup & Replication oder aber das neue Symantec Backup Exec an. VEEAM erstellt dir Snapshots, die du problemlos zurückspielen kannst, auch einzelne Dateien aus den eigentlichen virtuellen Maschinen. Ganz cooles Produkt soweit. Mit Backup Exec kannst du zusätzlich noch Bandlaufwerke oder RDX Laufwerke direkt ansprechen. Inwieweit da Snapshots erstellt werden können: kA Was nun die Frage nach den AD-Servern angeht...Meinst du deine Domänencontroller? Falls ja: Für genau solche Fälle ist ein Domänencontroller in der Regel NUR Domänencontroller und es existiert ein zweiter Backup Domänencontroller, sodass du, im Falle eines Defekts der Hardware / VM, einfach einen zusätzlichen DC aufsetzt, den defekten aus dem AD entfernst und glücklich und zufrieden weiterlebst. Was grundsätzlich Redundanzen angeht: Microsoft Windows Server 2012 und Failover Cluster Services sind schon ne richtig nette Sache, die außer Dienstleistung (die du dir in die eigene Tasche wirtschaftest) nichts als die Windows Lizenz (Stichwort Datacenter) kosten und sauber funktionieren. In deiner aktuellen Struktur führst du einen Windows Server 2012 als DC, Exchange, DHCP, DNS, IIS RDP (? Remoteweb Arbeitsplatz ?) auf. Mal abgesehen davon, dass diese Konfiguration von Microsoft nicht empfohlen ist (http://technet.microsoft.com/de-de/library/ms.exch.setupreadiness.warninginstallexchangerolesondomaincontroller%28v=exchg.150%29.aspx) wirst du beim Wiederherstellen der Snapshots tatsächlich ggf. inkonsistente, wenn nicht defekte Einträge in deiner AD DB als Resultat erhalten. Was du nun damit machst ist deine Sache, ich empfehle dir alles nach Funktionen zu splitten Server 1: DC, DHCP, DNS Server 2: DC, DHCP, DNS Server 3: Exchange (+ ggf. deine IIS Anwendung, weil der IIS eh schon mit installiert wird) Server 4: FS Server 5: DATEV + SFirm Server 6: TS Server 7: Debian mit deiner Faxlösung Bleibt noch die physikalische Hardware...Steht die noch da, weil du die ISDN Karte nicht an die VMs übergeben kannst? Da gibts diverse Möglichkeiten, dies über ein entsprechendes Faxmoden (bspw. ein Gerät von LANCOM) zu realisieren. Der physikalische DC ist, meiner Meinung nach, immer eine gute Sache, falls die VM Struktur mal neu gestartet werden muss, etc. Nichtsdestotrotz haben Dienste außer den oben aufgeführten, auch wieder nur meiner Meinung nach, auf DCs nichts zu suchen. Du siehst: Wenn du von "einer vernünftigen Lösung" sprichst hängt da deutlich mehr dran als "nur ein bisschen Backup".

Ich meine da etwas im Hinterkopf zu haben bzgl. E-Mail Client des Absenders...meine, das wäre damals ein Mac gewesen. Aber leider noch beim alten AG, sodass ich den entsprechenden Leistungsnachweis nicht mehr einsehen kann. Sind alle Systeme auf aktuellem Patchstand, was MS Updates angeht? Exchange Caching Modus an? Wenn ja: Mal entfernen, wie schaut es dann aus? Wenn nein: siehe oben

Nagut, die müssen eben auch angepasst werden. Soetwas "triviales" vernachlässigt man doch gern mal, oder? :-P Aber dazu hab ich grad durch Zufall beim Stöbern noch folgenden Beitrag gefunden, der ggf. helfen könnte (wobei ich auch hier bei 3 "Kleinstunternehmen" manuell rangehen würde...) http://www.mcseboard.de/topic/192404-script-oder-tool-f%C3%BCr-dom%C3%A4nen-wechsel-gesucht/?hl=%2Bscript+%2Bdom%C3%A4nen+%2Bwechsel&do=findComment&comment=1191542 Leider wurde ja die Frage, wie Kleinstunternehmen zu interpretieren ist, noch nicht beantwortet :-)

Hallo, wurde ein anderes E-Mail Konto / ein anderer PC getestet? Ein ähnliches Problem hatte ich Montag auch, das lag allerdings an einer defekten Exchange Datenbank. OWA funktioniert, Outlook nicht. Prüfe deine Datenbank mal mit ISINT und den Powershell CMDLets (bspw. New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView -DetectOnly)

350MB Systempartition? Meinst du die Recovery Partition oder die, welche bei der Installation von Windows angelegt wird? In letzterem Falle hatte ich bislang nie Probleme.

Hallo zusammen, Ausgangssituation: - SBS 2011 -> Exchange 2010 (alle Wizards bei Erstinstallation ordnungsgemäß durchlaufen) - Kaspersky verschiebt Exchange DB Transaktionsprotokolle in Quarantäne - Server wird (nicht von mir) hart neu gestartet -> Exchange Datenbank defekt. -> Reparaturversuche mit ESEUTIL, ISINT und Powershell CMDLets scheitern - Neue Exchange Datenbank wird erstellt (Datensicherung ebenfalls korrupt, Fehler scheint also schon länger bestanden zu haben) - Postfächer werden, sofern möglich, in die neue Datenbank migriert. Nicht migrierbare Postfächer werden am Client (zum Glück Caching-Modus an) exportiert, deaktiviert, neu erstellt und am Client wieder importiert Soweit so gut. Das Verfassen externer E-Mails bereitet keinerlei Probleme. Der Empfang funktioniert auch wieder störungsfrei (ganz merkwürdige Verhaltensmuster bei einigen Postfächern...) Über die WebApp funktioniert ebenfalls soweit alles. Problemstellung aktuell im Outlook der Mitarbeiter: - interne E-Mail Weiterleitungen laufen in einen Unzustellbarkeitsbericht - interne E-Mails laufen in einen Unzustellbarkeitsbericht Habe ich vergessen, etwas in der Exchange Konfiguration auf die neue Datenbank umzustellen? Was ich noch nicht getestet habe, gleich aber noch tun werde, ist die manuelle Synchronisierung des Exchange Adressbuchs auf Client-Seite. Falls auch das keine Besserung bringt führe ich die SBS Assistenten nochmals durch (wobei ich das Problem eher auf Client-Seite sehe). Hallo zusammen, die Fehlerursache lag tatsächlich auf Client-Seite: Outlook -> Datei -> Optionen -> E-Mail -> AutoVervollständigen-Liste leeren -> OK -> Outlook neu starten Scheinbar passen die IDs der Postfächer, auch nach Migration in eine neue Datenbank, nicht mehr...

Hi, am Exchange kannst du: - mehrere Datenbanken einbinden - mehrere Domänen konfigurieren Dementsprechend solltest du die Datenbanken der Firmen in einem Exchange zusammenfassen können. Vorsicht bei der Migration wegen Transaktionsprotokollen, etc.. Die File Services wirst du wohl nur manuell umziehen können, da ich auf Anhieb keine Möglichkeit wüsste, die ACLs zwischen verschiedenen Domänen zu migrieren. Sauberer ist wohl allerdings eine komplett neue Installation: - DC + Backup-DC aufsetzen und konfigurieren - Exchange aufsetzen und konfigurieren - Fileserver aufsetzen und konfigurieren - Berechtigungen auf den alten Servern sichern - Daten auf den alten Servern sichern - Exchange Daten via Client export sichern - alles in der neuen Struktur importieren - beim jeweiligen "alten" Provider E-Mail Weiterleitungen auf die neue, gemeinsame Domäne (so verstehe ich dich zumindest) einrichten - alles ausgiebig testen - glücklich sein :-)

Hi, ich versuche mal, das für den SBS möglichst einfach zusammen zu fassen: Der Exchange-Informationsspeicher nutzt den maximal verfügbaren Arbeitsspeicher um Abfragezeiten auf die Datenbank durch das Auslagern der Ergebnisse in einen schnellen Speicher zu optimieren. Dementsprechend ist es nicht unbedingt ratsam, zusätzlich zu den integrierten Anwendungen, weitere Anwendungen auf einen SBS zu packen. Von der Begrenzung der Arbeitsspeichernutzung des Informationsspeichers (bspw. beschrieben in http://eightwone.com/2010/03/25/limiting-exchange-2010-database-cache/, getestet von mir, also ohne Garantie auf Funktion) rate ich auch ab. Mein Tipp: Erweitere den SBS einfach um RAM, so teuer ist der im Moment ja nicht.

Hi, wird der Mitarbeiter die PCs manuell mit dem Image bestücken? Falls ja, solltest du dir ggf. mal die WDS (Windows Deployment Services) anschauen. Da kannst du zumindest ein Präfix vor dem PC Namen vergeben, inwieweit du bspw. durchnummerieren könntest, weiß ich gerade nicht.

Hi, ich stimme Daniel zu. Besorg dir einen kleinen Server, falls noch keine virtualisierte Struktur entsteht. Dort installierst du einen Hypervisor deines Vertrauens und konvertierst alle physikalischen Server, die du testen möchtest (Tipp: Wenn du Exchange einsetzt, nimm diesen auch mit) auf den Hypervisor. Nun erstellst du dir ein Testnetz und verbindest die Netzwerkkarten aller VMs mit diesem. Vorsicht: IP-Adresse müssen ggf. neu konfiguriert werden, da die virtualisierten Systeme andere, virtuelle, NICs verwenden. Über Snapshots und Sicherungskopien kannst du hier dann schön arbeiten und, vor allem, du arbeitest in einer Testumgebung, die tatsächlich deinem Active Directory entspricht. Bei möglichen Export-Versuchen werden ggf. Fehler, die im AD bestehen, nicht mit exportiert. Du testest, gehst produktiv und fällst auf die Nase. Das wäre dann so ziemlich das unschönste Szenario.

Danke für das Script! Leider war ich zur Zeit deiner Antwort nicht mehr beim Kunden vor Ort, habe mir aber anderweitig (siehe unten) helfen können. Keine Ahnung, was da falsch gelaufen sein könnte, ich hab den WTS vor der Office Installation in den Installationsmodus versetzt und dann so installiert, wie ich es bei Office 2003-2010 auch getan habe... Ich habe dieses Thema allerdings nun anderweitig gelöst. Mein Lösungsansatz via GPO: - Löschen des Registrierungsschlüssels HKCU\Software\Microsoft\Office\15.0\Common\Identity\Identities\administrator@domain.tld_AD - Anpassen des Werts UserInitials auf " " im Schlüssel HKCU\Software\Microsoft\Office\Common\UserInfo - Anpassen des Werts Username auf "%username%" im Schlüssel HKCU\Software\Microsoft\Office\Common\UserInfo Jeweils ohne führende und beendende ". Nach Änderung dieser Werte wird ein neues Office Profil angelegt, welches die Anwenderdaten automatisch aus dem AD übernimmt. Vielleicht hilft das dem ein oder anderen ja noch.

Hallo zusammen, Szenario: 2 x W2k8R2 TS mit Brokerserver Ordnungsgemäß lizensiertes Office 2013 Standard Open NL für entsprechende Anzahl Terminaserver Benutzer kein Exchange (Kerio Mailserver) Problem: Im Bereich der Kontoinformationen der Office Anwendungen (Datei->Konto) wird dem Benutzer zwar der richtige Benutzername, jedoch die falsche Emailadresse (jeder Benutzer sieht administrator@domain.tld) eingetragen. Fragen zur Ursache: Liegt's am Mailserver? Liegt's ggf. an einer falschen Art der Installation am Terminalserver? Lässt sich die Option "Konto" gänzlich aus dem Office Menü ausblenden? Any ideas? Danke! Edit: Zusätzlich erscheint beim Öffnen einer, von einem anderen Anwender bereits geöffneten, Datei die Meldung "Die Datei wird bereits durch Benutzer "administrator" bearbeitet..."

Es gibt in den Gruppenrichtlinien eine Einstellmöglichkeit zur Anzahl Remote-Sitzungen, die auf einem Server erlaubt sind ( für W2k8R2: Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Remotedesktopdienste -> Remotedesktopsitzungs-Host -> Verbindungen -> Anzahl der Verbindungen einschränken). Somit schränkst du die Anzahl Verbindungen ein. Eine Benachrichtigung, welcher User allerdings gerade arbeitet, ist hier nicht enthalten.

Wurden evtl. merkwürdige Weiterleitungen (Urlaubsvertretung oder Ähnliches) auf einem der Postfächer eingerichtet?

Wurde in den Sicherheitsberechtigungen der Zertifikatvorlagen etwas geändert? Wurden die DCs aus der OU Domänencontroller verschoben oder den Maschinen ggf. die Mitgliedschaft in der Gruppe Domänencontroller der Organisation genommen? Die Zertifikatvorlagen kannst du mit certtmpl.msc einsehen und dort auch die Sicherheitsberechtigungen kontrollieren.

Hi, als erstes würde ich mal google zu dem Fehler befragen. Da gibt es einige Ansätze, die ursächlich für deinen "hängenen" Gruppenrichtlinienclient sein können. Grundsätzlich würde ich, aus Eitelkeit, vor der google Befragung, zuerst aber mal mein Active Directory prüfen. Anschließend die DNS und DHCP Konfiguration. Die unterschiedlichen Einstellungen in den Gruppenrichtlinien wären auch interessant, evtl. gibt es konkurrierende Einstellungen (Loopback mit Zusammenführen, bspw.), die nicht eindeutig übernommen werden. Dann stellt sich natürlich die Frage, inwieweit Windows Updates eingespielt werden. In der Regel tauchen max alle 2 Wochen Updates auf, die einen Neustart erfordern. Ebenfalls könnte man die Antivirus-Software prüfen, Windows Firewall Einstellungen, etc. Ohne weitere Protokolle, ein wenig Eigeninitiative (viel Fehlersuche scheint ja noch nicht erfolgt zu sein) lässt sich da außer Mutmaßungen keine Pauschallösung äußern.

Hi, als erstes würde ich schauen, was google zu deinem Fehler sagt. Dort würde ich unter den ersten 5 Suchergebnissen bereits 2 Einträge aus der Microsoft KB bzw. dem Technet finden. Anhand dieser könnte ich Rahmenbedingungen prüfen und ggf. die dort vorgeschlagenen Maßnahmen einleiten. Da leider keine weiteren Informationen vorliegen, wie zum Beispiel Umfang der Sicherung und Sicherungsziel, könnte ich in diesem Fall nur mutmaßen. Anschließend würde ich mir die Exchange Konfiguration anschauen, ggf. verfügbare Updates einspielen, eine Datenbankprüfung durchführen, etc.