Jump to content

koem@

Members
  • Content Count

    102
  • Joined

  • Last visited

Community Reputation

0 Neutral

About koem@

  • Rank
    Junior Member
  1. Das war auch meine Favoritenidee. Danke daabm! Das Equipment hängt zwar nicht direkt am PC, das bekomme ich aber hin. Ich werde wohl wirklich einen Benutzer auf den betreffenden (oder auf allen) Rechnern erstellen (per GPO?) und dann ein Abmeldescript erstellen, welches die generierten Daten auf einen Share der Domäne verteilt.
  2. Hallo zusammen. Ich habe folgendes Problem. Wir stellen Geräte her, mit welchen etwas getestet wird. Unser Service und unsere Produktion muss diese Geräte vor der Auslieferung ausgiebig testen und Kalibrieren. Diese Tests können schon mal mehrere Tage dauern. Nun kann es passieren, dass ein User, welcher diesen Test laufen lässt, ausfällt. Dadurch kann sich, würden die Kennwörter geheim gehalten werden, kein anderer am System anmelden und auf die Tests, die Ergebnisse und Ähnliches zugreifen. Aus diesem Grund hat mein Vorgänger auch keine Kennwortrichtlinie eingeführt. Dies möchte ich aber tun und dabei aber die Arbeitsabläufe der Abteilungen nicht beeinträchtigen. Aus diesem Grund überlege ich, Benutzerkennungen zu erstellen, welche von mehreren Usern genutzt werden. Diese haben dann nur die Berechtigung, auf ein Verzeichnis im Netzt zugreifen zu können. Oder es werden lokale Kennungen, die auch nur lokal schreiben können. Beides gefällt mir aber eigentlich auch nicht. Und nun kommt Ihr, gibt es noch andere Möglichkeiten und wenn ja, welche? Umgebung: AD, 2 DC, Win Server 2012 R2, WIN 7 und WIN 10 Clients, Ist hierfür noch was nötig? Dann Fragen. Danke allen im Voraus
  3. Habe ich, aber die Deinstallation ist wohl gelinde gesagt MIST. Der Agent war trotzdem noch da. Werde mal ein Wörtchen mit denen reden und den Mist kündigen. Jawohl. Werde ich machen
  4. Ich habe es gefunden und der Server läuft wieder. In meinem Fall war es der Avast Antivir. In der Exchange Management Shell findet man mit get-transportagent alle gestarteten Transport Agents. Ich habe, weil der Microsoft Transportdienst sich immer beendet hat den Avast verdächtigt. Hier fand ich "avast antispam for exchange" als Fehlermeldung im Eventlog. Diesen konnte ich aber mit disable-transportagent "avast antispam for exchange" beenden, weil er nicht dort war. Bei der suche fand ich aber den oben genannten Agenten, welchen ich mit disable-transportagent "avast plugin for exchange" beendete. Anschließend den Exchange Transportdienst starten und sofort wurden alle Mails zugestellt. Mit dem Exchange Toolkit konnte ich sofort sehen, wie sich die Warteschlangen geleert haben. Ich hoffe, das nützt anderen auch. Danke allen hier für die Hilfe. MFG Ingo
  5. Nein, auch nicht. Überhaupt kein Mail. Nicht rein, nicht raus, nicht von Kollege zu Kollege. Sonstige Konnektivität klappt. OWA, Outlook, Active Sync, Console
  6. Den Port sehe ich nur bei den Empfangsconnectoren unter "ClientProxy [SERVERNAME]" bei den Bereichsdefinitionen. Könntest Du Hellsehen, was ich für dich echt Cool fände, dann wärest Du wars***einlich DagobertDuckReich und würdest auf deiner eigenen Insel wohnen. *** bei wahrscheinlich? Was ich da wohl getippt habe???? Aaaah. ohne "h" entsteht ein a r s c h. LOL
  7. Norbert, DAS war meine erste Idee. Kannte den Fehler, weil ich den irgendwann mal bei Franky gelesen hatte. Reverse lookup läuft wie geschmiert. Fehler im Send Log lautet: 2018-11-13T10:22:01.488Z,Sendeconnector für Clientproxy,08D648D30CE3E545,1,,172.100.6.2:465,*,,"Failed to connect. Winsock error code: 10061, Win32 error code: 10061, Error Message: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 172.100.6.2:465" Beim Senden. Als DNS ist primär der erste DC als sekundär der zweite DC eingetragen. Haben weder den Router (FritzBox) oder einen externen als irgendeinen DNS eingetragen. Im DNS allerdings und natürlich eine Weiterleitung an den Router Die IP ist der Server selbst. Es geht um das interne senden. Scheinbar verweigert er sich gegen sich selbst (wie in jeder guten Ehe )
  8. Gut, das ist der Status Quo! Würde nun gerne, wenn das Update auf CU22 nicht unumgänglich ist (siehe meinen Post oben) mit dir durchgehen, ob ich etwas übersehen habe. Da der Server wieder auf dem Stand vor den Updates ist, befürchte ich, das er bei den beiden DC's liegt. Aber sicher bin ich mir nicht, weil die beiden meines Erachtens auch richtig funktionieren. Bin also für jede Idee offen und probiere gerne alles aus.
  9. Ja Nobby, das habe ich befürchtet. CU 22 habe ich schon einmal auf einer Testmaschiene versucht und das Ding dabei komplett zerlegt Von wegen perfekte Welt. Das Problem hier in der Firma ist Zeit. Die gibt es nicht. Noch nicht einmal um ein Update aus CU22 richtig zu testen. Meinst Du wirklich, dass kein Weg drum herum führt?
  10. Damit habe ich gerechnet. Ein Update auf CU22 ist zur Zeit nicht möglich. Keine Chance, aus betrieblichen Gründen. Er hat aber auch bist Freitag so funktioniert. Die Lösung mit POPcon ist hier durch das Unternehmen so entschieden worden. Kann ich nicht ändern. Muss ich auch nicht. Ist es wirklich relevant? Wäre diese Welt perfekt, müsste ich nicht Fragen, weil es perfekt wäre. Dann wäre dieses Forum auch obsolet. Du bist ein Profi, sogar ein wirklich guter, aber aus fast 30 Jahren IT Erfahrung weiß ich, und Du weist das auch, dass es auf jeder Baustelle anders ist. Da unser System am Freitag noch funktioniert hat, sollte es auch heute noch gehen. Auch mit CU11. Ich habe wirklich alles ausprobiert, was ich weiss, ohne erfolg. Deswegen Frage ich hier. Und Google spreche ich auch. Habe schon Sachen probiert, die eigentlich Unmöglich sind, weil sie im www standen. Nun Frage ich hier, weil Ihr gut seid und ich mit meinem Latein und meiner Erfahrung nicht mehr weiter weiss.
  11. Genau, ist hier so entschieden und wird auch nicht geändert. Die VM hat instgesamt 700 GB HDD, wovon genau 448 GB frei sind. Ein Laufwerk c:\ wo somit auch die Queue liegt
  12. Da Mails bei Hosteurope landen und per POPcon abgeholt und über Empfangsconnector (Port 25) zugestellt werden und dies unter anderem nicht mehr klappt, sind sie dort gepuffert und werde da gesichert. C hat fast 500 GB frei.
  13. Es wurde, weil Wochenende, nichts geändert. Deswegen hatten wir, wie immer, Wartung am Samstag gemacht. Mail per SMPT zustellen geht nicht, da kommt Fehler 451 4.7.0 Temporary Server error. Please Try Again Later. PRX Und zu dem gibt es viele Ideen im Internet. Habe alles geprüft, was ich dazu bekommen habe und wusste. Leider ohne Erfolg.
  14. 15.00.1156.010 also Exchange 2013 CU 11 Den Provider hatte ich als Idee auch, aber das erklärt Empfangen und internes Mailing nicht, oder? In welchen? Wir haben einfach da Backup von Freitag Nacht zurückgespielt und die VM überschrieben.
×
×
  • Create New...