Forseti2003

mal ganz doof zwischengefragt, kann es sein das die User eine andere Zeitzone bei sich haben und daher der Client bei der Anmeldung nachträglich auf eine andere Zeit springt?

Also ich würde auch nicht unbedingt auf RoboCopy als Sicherungssoftware zurückgreifen wollen und mit Verlaub, der Einwand das PowerShell nicht zum Einsatz kommen soll, weil man kein Programmierer ist, aber sich dann gleichzeitig das Scripting mit RoboCopy anzutun ist nicht ganz nachvollziehbar. Um schon kleine brauchbare Ergebnisse mit PS zu bekommen, bedarf es lediglich zweier Trainings-Videos auf MVA und mal ein wenig Zeit um die Seite der Scripting-Guys durchzustöbern. Dann sollte der Umgang mit PS recht zügig von der Hand gehen. Habe anfänglich auch wie Du versucht mit Robocopy Daten zu "sichern" bin dabei aber recht schnell an Grenzen gekommen, deren Umsetzung einfach zu umständlich oder nicht beständig genug sind/waren. Sogar Exchange-Server kann man, wenn man möchte so sichern, aber es macht keinen "Spass" auf Dauer. Danach bin ich auch die Windows-Sicherungs-Software gestiegen, diese würde schon Dein Szenario sogar ohne PS weitgehend abdecken. Eine Sicherung des Fileservers bzw. der Datenlaufwerke geht ab 2012R2 ja ohne Problem. Die Sicherung kannst Du auf einen NAS auflaufen lassen und den NAS dann 1x am WE mittels großer USB-Festplatte quer sichern. Damit sollte schon ein ausreichendes Backupszenario vorhanden sein, wenn man noch keine großen Anforderungen/Ansprüche hat. Da wir aber im laufenden Betrieb auch mit den Windows-Server-Sicherungen einiges an Problemen hatten, bspw. die permanente Verfügbarkeit der FileShares, haben wir dann Veeam eingesetzt, bereits die Freeware deckt sehr viele Ansprüche ab, kann auch Shares nach dem Backup abtrennen so dass ein Virus/Trojaner am Server nicht direkt auf das NAS aufläuft. Achja, noch zur PS - ich würde es Dir dringend empfehlen - wenn man sich damit mal auseinandersetzt, wird man schnell Ansätze für seine tägliche Admin-Arbeit entdecken, die einem das Leben extrem erleichtern. Ein einfaches Skript ohne viel Aufwand und schon kann ich morgens prüfen ob ein User sich in der TS-Farm temporär angemeldet hat, den fehlerhaften Eintrag entfernen und der User kann wieder normal arbeiten. Manuell dauert das rund 10-15 Minuten pro User - mittels Skript bearbeite ich das in 10 Sekunden und ob das ein User oder 20 User sind, ist dann vollkommen egal. Ja, und ich hab kein PS-Admin im Namen oder der Signatur ;-)

Was haltet Ihr eigentlich von VeraCrypt? Auf den ersten Blick sieht und hört es sich ja zum Thema Datenverschlüsselung auch nicht uninteressant an, hat damit schon jemand Erfahrung?

Wenn ich das richtig lese, liegt das Problem eventuell nur an der Art Deiner Anbindung. Über Systemsteuerung - Neuen Drucker hinzufügen - Drucker im Netzwerk suchen - wird tatsächlich im Netzwerk nach Druckern gesucht. Werden diese erkannt, pflegt er diese dann so ein, wie sich er Drucker meldet. Wenn Du aber sagst, das Du Netzwerkdrucker hast, dann dürfte da ja auch ein Druckserver installiert sein? Dann reicht es schon aus, im Explorerer (Adressezeile) \\printserver\druckername (damit ist der Freigabename gemeint) einzutragen und der Drucker verbindet sich dann und zeigt den definierten Namen auch an. Wie Sunny61 dazu schreibt, die Freigabe sauber konfigurieren und auch den Drucker ins AD schreiben lassen, der Rest ist dann wirklich nur ein paar Klicks.

Auch noch ein Feedback von meinerseite, überwiegend haben wir nun das ganze in den Griff bekommen, Standarddrucker verstellen sich nun im Regelfall nicht mehr und Druck funktioniert auch. Wir gehen aktuell sogar über Druckserver und lassen die Aufbereitung über diesen und nicht am RDS laufen. Viele Fehler scheinen am Anfang so auszusehen, als gehören sie zusammen, was aber scheinbar überhaupt nicht der Fall ist. Man sollte sich am besten eine Checkliste zu legen und diese in jedem einzelnen Fall zwingend abarbeiten. Wir stellten dabei nämlich fest, das plötzlich, Stück für Stück und User für User, die Fehler abnahmen, einige bestimmte Fälle sogar recht rapide. Aktuell haben wir eigentlich nur noch zwei Arten von Fehlern, die aber auch nur noch gelegentlich auftreten: 1) Am Druckserver (!) verstellt sich bei einigen bestimmten Druckern (selber Hersteller) der Druckprozessor. Ist uns bisher 2x in den letzten 2 Monaten aufgefallen. Fehler lässt sich aber recht schnell beheben. 2) Einmal sporadisch will ein Drucker (meist einer der unter 1) sich bei einem Benutzer nicht mehr regulär anlegen lassen. Wird der Drucker neu verbunden sind die Eigenschaften doppelt und führt je nach Anwendung dazu, das kein Druck mehr erfolgt. Die Umstellung von einem NETBIOS-Namen auf einen FQDN erzielt dann aber die gewünschte Wirkung also anstelle von \\printserver\Drucker dann \\printserver.domain.tld\Drucker. Wer noch massive Probleme hat bei seinen Druckern kann mir auch gerne eine PN senden, allgemeine Erläuterungen find ich eher problematisch, da wirklich jeder Drucker und davon auch jedes Problem eine eigene Fehlersuche erfordert. Das reicht von Firmware am Drucker, über Universal-Treiber vom Hersteller, v3 und v4-Versionen müssen ein wenig getestet werden, auch hier gibt es starke Unterschiede. Die Benutzerprofile säubern, Registry reinigen, Druckwarteschlangen prüfen, Rechte nachsetzen, GPO prüfen und und und....es ist ein riesiger Rattenschwanz, wobei ich feststelle, je weniger Drucker-MischMasch vorliegt, desto niedriger sind auch die Probleme. Grüße Forseti

Bringt aber leider auch nicht wirklich viel. Wir haben versuchsweise die Drucker lokal aufgesetzt, die am meisten fehlerauffällig waren. Auch hier, ging eine ganze Zeit lang gut, so das wir dachten, okay Problem könnte damit umgangen werden, aber nach einigen Wochen haben sich dann auch da wieder Probleme eingeschlichen. Besonders auffällig, das die Druckgeschwindigkeit oder das Rendern bei der Vorschau in den Anwendungen sehr lang dauert. Irgendwie ist es derzeit so, als wenn man wirklich nur den Teufel mit dem Belzebub austreiben würde. Extrem frustrierend.

Ich glaub das wird mit 2012 R2 ein Klassiker. Also wenn man hier viele Lösungsvorschläge abarbeitet und die Updates einigermassen regelmässig auf die Server nachführt, genauso wie konsequent Treiberupdates durchführt, lassen sich einige Fehler dauerhaft eindämmen. Leider, nicht wirklich alle und einige tauchen immer mal wieder auf. Ein paar der Probleme, die immer irgendwie hängenbleiben: 1) Standarddrucker wird geändert (sporadisch, selten, unterschiedliche Benutzer) 2) Plötzlich mehrfach gleicher Drucker vorhanden, System erkennt nicht, das es der selbe Drucker ist 3) Registry-Eintragungen sind ein wenig wirr, führen nicht vorhandene Printserver auf oder falsche Eintragungen Lösungen dazu sind dann meist eh nur Registry-Bereinigen, Drucker entfernen neu installieren in der User-Session und bei 1) prüfen ob die MSTSC über den Sessionbroker das Deployment sauber zieht. Unter 2003 und 2008 hatte ich mit den ganzen Druckern nie derartige Probleme. Soll aber unter 2016, wie einige sagen, auch nicht besser werden.

Prüf mal als lokaler Administrator auf dem jeweiligen Terminalserver die Eintragungen in der Registry, auch die Eintragungen bei HKEY_USERS sind wichtig, da hier einige Einträge drin stehen, die später spontan Fehler auslösen können. Der Geisterdrucker ist meist ein Indiz für ein Fehler in der GPO oder Registry. Wenn es nur beim Chef und dann nur auf einem bestimmten TS auftritt, kannst Du Dir einiges an Arbeit sparen, wenn es auf allen TS vorkommt, musst Du am besten alle mal durchgehen. Empfehlen kann ich neben der Registry noch folgendes: 1) Universaltreiber - sofern mgl einsetzen. Darauf achten, je nach Drucker ob PS oder PCL - das kann schon für sich allein viele Fehler auslösen. Prinzipiell reagieren PS-Treiber besser, in einigen Fällen brauchen die Drucker aber PCL-Treiber 2) Firmware-Update der Drucker - HP ist da so ein Kandidat, der mit älteren FW gerne rumzickt 3) Druckwarteschlangen auf TS und Printserver prüfen, im Verzeichnis PRINTER ältere Aufträge entfernen. 4) Wenn alle User unten sind, über Druckserver alle Treiber rausfeuern und neu einlesen lassen. 5) Verzeichnis Spool Rechte für User einräumen 6) Vermeide die WSD-Anschlüsse bei Druckern und geh auf TCP 7) Stelle die Druckprozessoren auf WINPRINT ein Das sind mal so die Sachen, die uns am meisten geholfen haben. Gibt noch einige Detailsachen, aber das kommt dann auf das Fehlerbild direkt an. Wenn Du möchtest, kannst mich dazu ja gerne direkt anschreiben, dann können wir die Punkte mal durchgehen. Grüße Forseti

Der Windows Server 2012 R2 ist ein wenig eigen mit seinen Druckern - aber ein paar Punkte zu Deinem Setup, der HP LaserJet P2015 hat doch normalerweise auch eine LAN-Schnittstelle? Eventuell mal darüber ansprechen und die Geschwindigkeit im Vergleich testen. Ansonsten, sofern die ThinClients ein Winbasiertes OS haben, die Drucker dort anschließen und installieren und mittels Richtlinie auf den TS in die RDP-Sitzung nehmen, das kannst du über EasyPrint dann entsprechend konfigurieren. Der Netzwerkdrucker im Flur wird wohl deswegen schneller sein, da er über das LAN besser angesprochen wird, wir setzen bei uns prinzipiell nur LAN-Drucker ein und haben damit sehr gute Erfahrungen gesammelt. Entscheidend bei Deinen Treibern ist aber, vermeide Treibervielfalt, die nimmt Dir der 2012 schnell ganz krumm. HP bietet u.a. auch Universal-Treiber an, leider nur PCL Treiber, auch hier ein wenig aufpassen, einige Drucker arbeiten mit PCL5 besser, andere mit PCL6. Foxit hat bei uns auf den TS recht häufig gezickt, haben wir dann gegen PDFX-Change Viewer ausgetauscht, hiermit lief auch der Ausdruck größerer PDF's recht zügig. Solltest Du mit einem zentralen Printserver arbeiten, achte darauf, das die TS die Druckaufträge nicht verarbeiten, sondern zentral der Printserver, das vermeidet später Probleme in den Druckwarteschlangen. Auch nicht unwesentlich, solltest Du am TS direkt Drucker einbinden, gib das Spool-Verzeichnis für die User frei, da ansonsten öftersmal Zugriffsprobleme bei den Druckdaten entstehen.

okay, verstanden. Hab aber schon Rückmeldung vom Softwarehersteller, wir können das Scoring für den RBL höher setzen und später, wenn der Provider den SPF gemacht hat, die Software auf SPF umstellen. Dann sollte das erledigt sein, hoffe ich ;-) Danke für eure Mühen und Tipps.

Hab es mal an den Provider weitergeleitet, damit es nachgetragen wird. Der Verweis auf alle MX-Einträge sollte ja ausreichen um besser geschützt zu sein. Den Hersteller von der Anti-Spam-Software hab ich dazu auch mal angeschrieben, damit er hier evtl. was nachbessern kann. Wenn nicht kann ich die Blacklist ja auch direkt in den Exchange eingeben, dann lehnt er ja eh ab - wobei das mal vor längerer Zeit ein Problem war, da dann einige Mails uns nicht mehr erreicht haben. Ich beobachte mal weiter.

Ja, hier scheint der Hund begraben zu liegen, der SPF-Record fehlt. Soweit ich das jetzt weiss, muss das der Provider der Domain am Nameserver eintragen, korrekt? Oder muss ich da intern noch was setzen?

Letzteres kann ich Dir sofort beantworten: Wir setzen Exchange Server Toolbox als Anti-Spam-Programm ein, dort werden Scores anhand der einzelnen Prüfschritte ermittelt und dann entweder abgelehnt oder zugestellt. Problem in dem Fall dieser Mail besteht darin, das er den Score auf 2,9 setzt und somit ihn passieren lässt. Warum der Hersteller aber nicht erst eine Prüfung auf Blacklists durchführt und selektiert und danach den Rest in der nächsten Phase weiterprüft, kann ich nicht beantworten. Ist mir aber nun auch schon mehrfach aufgefallen, das er sich so verhält, muss mal mit dem Hersteller darüber sprechen, was er dazu meint. Aber zum ersten Teil, im Transportlog sehe ich auch nichts auffälliges Sender Recipients Recipient Count Message Subject Time Stamp Event Id Message Id Internal Message Id Client Ip Client Hostname Server Ip Server Hostname Connector Id Source Related Recipient Address Return Path Message Latency Recipient Status Total KBytes orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 DELIVER <38646AA6.206F8147@meine.domain.de> 67018669687083 Mail.meine.Domain.de Mail STOREDRIVER orders@meine.domain.de 00:00:11.5070000 311,69 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 HAREDIRECTFAIL <38646AA6.206F8147@meine.domain.de> 67018669687083 Mail SMTP orders@meine.domain.de 309,59 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 RECEIVE <38646AA6.206F8147@meine.domain.de> 67018669687083 192.168.4.40 Mail.meine.Domain.de Mail MAIL\Default MAILEX01 EMSC SMTP orders@meine.domain.de 309,59 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 AGENTINFO <38646AA6.206F8147@meine.domain.de> 67018669687083 Mail AGENT orders@meine.domain.de 311,6 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 SEND <38646AA6.206F8147@meine.domain.de> 67018669687083 192.168.4.40 Mail Mail.meine.Domain.de Organisationsinterner SMTP-Sendeconnector SMTP orders@meine.domain.de 00:00:11.5070000 250 2.1.5 Recipient OK 311,69

Die Mitarbeiter-Sensibilisierung läuft permanent, aber genau mit derartigen Mailadressen hab ich so mein Problem. "Copier" "Orders" "No-Reply" - alles mit der eigenen Domain versehen, wir hatten vor zwei Wochen auch SPAM der sich als Scannmail vom Hersteller SHARP ausgegeben hat, genau solche Scanner haben wir auch, aber nie auf Mailversand eingestellt, aber die Unsicherheit ist dann schon recht hoch. Dachte aber das beim Spoofing der Exchange-Server prüft ob der absender Server überhaupt für die Domain berechtigt ist und dann entsprechend ablehnt, ist ja schließlich seine eigene Domain die er da gerade untergejubelt bekommt. Auch das die Absenderadresse nicht bei ihm geführt ist, wäre ein klarer Hinweis, das da was nicht stimmt.

Hallo in die Runde, hab seit einigen Tagen ein recht merkwürdiges Problem. Ich erhalte in diversen Postfächern Mails aus meiner (angeblich) eigenen Domain. Diese Absenderadressen exisitieren aber nicht. Beispielsweise orders@meine.domain.de. Im Ereignislog meines Spam-Gateway wird der Eintrag so aufgeführt: 09.02.2016 16:54:24 [sPAM] RE: unpaid order orders@meine.domain.de meineMail@meine.domain.de 108.47.155.2 2,9 Die letzten beiden Werte sind die IP-Adresse des absendenden Mailserver und die 2,9 für das Scoring des SPAM-Filters. Der SPAM-Bericht wirft folgende Bewertung aus: Spam-Bericht * 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [108.47.155.2 listed in zen.spamhaus.org] * 1.0 OBFU_DOC_ATTACH BODY: MS Document attachment with generic MIME type * -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% * [score: 0.3472] * 1.6 XPRIO Has X-Priority header Soweit so gut, am Exchange-Server selbst (ein 2013) sind folgende Einträge unter SenderIDConfig gesetzt: SpoofedDomainAction: Reject TempErrorAction: StampStatus BypassedRecipients: {} BypassedSenderDomains: {} Enabled: True ExternalMailEnabled: True InternalMailEnabled: False Müsste nun nicht der Transportdienst bei Eingang dieser Mail feststellen, das der Absender gar nicht stimmen kann und diese komplett verwerfen? Oder hab ich da einen Gedankenfehler? Kleiner Nachtrag, im Header der Mail stehen folgende Kommentare vom Exchangeserver: Return-Path: orders@meine.domain.de X-MS-Exchange-Organization-PRD: meine.domain.de X-MS-Exchange-Organization-SenderIdResult: None Received-SPF: None (Mail.meine.domain.de: orders@meine.domain.de does not designate permitted sender hosts) X-MS-Exchange-Organization-Network-Message-Id: 80574b59-9375-4e0f-81a6-08d3316945d9 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 X-MS-Exchange-Organization-AuthSource: Mail.meine.domain.de X-MS-Exchange-Organization-AuthAs: Anonymous Also obwohl er den Mailserver auf der anderen Seite, als externen Mailserver ansieht, sagt er bei Received-SPF: none - als wenn er nicht merken würde, dass das nicht sein kann. Grüße Forseti

Hallo Reingucker, meld mich dazu extrem spät, aber das ist ja nicht direkt mein Problem. Der RDWeb-Access funktioniert und wenn das Passwort abläuft, kann ich über RDWeb-Access auch ganz normal das Passwort erneuern. Der Beitrag von RDSGuru dazu ist korrekt, man muss im RDWeb-Access die Einstellung dazu manuell setzen. Mir geht es aber darum die MSTSC-Datei/RDP-Datei zu nutzen. Sprich der User hat auf dem Desktop seine RDP-Datei (Terminal) die verweist auf den FQDN des Sessionbrokers. Soweit klappt alles, sobald aber das Passwort abgelaufen ist und ich mich nun morgens am RDHost anmelden will, erscheint der Windows-Sicherheit Dialog und sagt nur lapidar "Der Anmeldeversuch ist fehlgeschlagen". Wenn ich nun die FQDN auf IP-Adresse stelle, erhalte ich zwar eine bessere Fehlermeldung "Kennwort abgelaufen, bitte erneuern" - aber ich erhalte nicht die Möglichkeit das Kennwort dort zu ändern. Auch werde ich nicht, wie früher direkt auf den Server geleitet wo ich dann mein Kennwort eintrage, da ich ja bereits das Credential-Prompt unter Win7 angezeigt bekomme (auch bei Win8.1 und Win10 identisch). Alle PC's sind zwar keine Domänenmitglieder, aber das sollte ja nicht das Ding sein, würde ich XP oder Linux einsetzen, kann ich mich ganz normal am System anmelden und auch das Kennwort ändern. In der RDP-Datei hab ich die Option prompt for credentials on client von 1 auf 0 gesetzt - aber auch das zeigt keine Wirkung. Kennt jemand das Problem und wie wurde es gelöst? Grüße Forseti

Richtig, drum steht da auch "prinzipiell", also das es möglich ist, verbunden mit dem Hinweis mit was. Sollte er nämlich die Absicht haben, diesen Weg weiterzuverfolgen, kann er sich Gedanken machen ob er dann auch in entsprechende Hardware investiert oder nicht und dann einen anderen Weg geht.

Klar, wenn Du keinen passenden Treiber hast, geht es eh nicht, egal ob Server oder anderes OS. Aber beim Printserver wird eben nicht der Drucker durch den RDP-Client geschliffen sondern direkt am WTS verbunden, insofern bringt es was, wenn ein Treiber verfügbar ist.

oder einen lanfähigen Drucker an den Printserver anklemmen ;-)

bedingt, kommt halt auf den NAS selbst an. Wir nutzen bei uns einen QNAP TVS-1271U-RP und lagern darauf einiges an Dateien aus. Haben sogar mal hier und da ganze Server zeitweise darauf ausgelagert zwecks Wartungsarbeiten. Also rein prinzipiell ist es machbar und muss nicht zwangsläufig ein Performance Problem sein.

Hallo in die Runde, mal eine kleine Frage, schätze das es nur ein Einstellungsproblem ist. Habe eine RD-Collection mittels 2012R2, 4 Hosts, 1 Sessionbroker, 2 DC. Wenn ich mich nun von einem Client anmelde (Windows7/8/10 kein Domänenmitglied) - die Anmeldung erfolgt über die Datei die im RDWeb-Access abgerufen werden kann (lokal auf dem PC gespeichert) - und das Passwort des jeweiligen Benutzers ist abgelaufen, erhalte ich die Meldung "Anmeldung fehlgeschlagen" - er leitet mich aber nicht an das Fenster weiter um das Kennwort neu einzutragen. In der RD-Sammlung steht Aushandeln und Clientkompatibel drin, der Haken bei Netzwerk fehlt. Wenn ich mittels OWA mich anmelde, kann icih das Kennwort ändern und danach ganz normal die Session starten, es müsste doch aber auch möglich sein, entweder den lokalen Anmeldedialog zu nutzen oder ohne lokalen Anmeldedialog direkt auf den Server sich anzumelden - von dort aus kann ich nämlich das Kennwort ändern, wenn ich nicht die RDWeb-Access-RDP Datei nutze sondern einfach eine normale mstsc Verbindung starte. Vorab schon Danke für eure Hilfe Grüße Forseti

Hast Du mal von allen Einheiten einen Ping auf die Datenbank und den Domaincontroller gemacht? Erhälst Du in jedem Fall immer auch den FQDN sauber zurückgemeldet?

Guten Morgen in die Runde, mal eine Frage zur Funktion des "Schatten" bzw. der Sitzungsspiegelung. Habe mehrere Terminalserver im Einsatz und öffne öfters mal einen Spiegel zu einer Benutzersitzung. Dabei fällt mir aber auf, das ein Server sofort mit der Fehlermeldung: Spiegelungsfehler Die angegebene Sitzung ist nicht verbunden Die Spiegelung starte ich über den Server-Manager - wo die RDS-Sammlung aufgeführt ist (bei anderen Servern klappt dies auch) Im Ereignislog wird dazu weder am WTS noch am ConnectionBroker angezeigt. Nun zur Frage, kennt jemand so ein Verhalten? Grüße Forseti

JA, den Beitrag hab ich gelesen - hat mir auch gestern bereits bei der Arbeit ein wenig geholfen und nein, es wurde kein Snapshot aus der VM genutzt. Hab ja mal bereits in der Vergangenheit gelesen, das Snapshots für Exchange Gift sein sollen und daher nie einen angelegt, sondern nutze die Windows Server Sicherung für Exchange und erstelle täglich damit ein Image. Wir haben im Prinzip eine leere neue VM erstellt und das Sicherungslaufwerk beim installieren angebunden, dadurch wurde der Exchange auf diesen Zustand gesetzt. Dauer bei rund 210 GByte Volumen knapp 45 Minuten. Ich gehe aber davon aus, das sich das ähnlich auswirkt, wie ein Snapshot, der Server ist ja nach Herstellung dann wieder auf CU6, während das AD die Informationen durch das Setup der CU8 bekommen hatte. Aber wie gesagt, nach einem Setup /PrepareAD und einem Testlauf durch DCDiag lief es dann wieder. Kurios ist nur, das mir auch gestern von Technikern erklärt wurde, das man mittels VM und Snapshot das machen kann, ich hatte dann dazu die Bedenken geäußert, wie Du und NorbertFe ja auch gemacht haben, aber man sagte, das wäre kein Problem (heißt aber ja nicht, das es supportet ist).

Hallo Datmox, danke - haben wir bereits gestern vormittag veranlasst und einen Dienstleister gefunden, der uns betreut. Ergebnis war, das wir dann erstmal eine Sicherung wiederhergestellt haben um den Zustand vom Samstag herzustellen. Das hat soweit auch gut funktioniert und Dienste wie OWA und ECP waren dann wieder erreichbar. Einzig die Transportrolle läuft nicht sauber (sehe aber, das es hierzu auch bereits einen Beitrag mit Routing 5016 gibt, scheinbar bin ich nicht der Einzigste) - hierzu haben wir bei MS nun ein Ticket eröffnet, damit geprüft werden kann, was das Problem auslöst. Update: Der Versand und Empfang von Mails läuft nun auch wieder, der Fehler Routing 5016 ist soweit behoben. Lösung war ein Setup /PrepareAD und anschließend ein DCDIAG - danach konnte die Transportrolle sich im AD wieder anmelden. Nur noch das Autodiscover von Outlook zickt rum, aber Hauptsache Mails laufen wieder sauber.