NorbertFe

vor 1 Minute schrieb Ralph_S:

weiß ich aktuell noch nicht genau 2010 oder 2013

Ginge beides. Nein, das funktioniert dann über die Free/Busy Kennungen. Ist aber insgesamt logischerweise deutlich sicherer, weil du eben wirklich nur diese Infos nach aussen zugreifbar machst. BEi einem AD Trust wär da schon mehr Aufwand sowas wieder abzusichern. Mal davon ab, dass ich stark überlegen würde ob ich einen AD Trust zu einer Tochterfirma aufbaue, wenn ich die gesamten Faktoren nicht kenne.

vor 3 Minuten schrieb Ralph_S:

Und zwar wäre die Frage ob es bei Exchange 2016 möglich ist eine Externe (Firmen Tochter) Organisation zu berechtigen das auf Exchange Kalender zugegriffen werden darf. 

Setzt die Firmentochter denn auch Exchange ein? Dann wäre das Federation Gateway/ Azure AD authentication system der einfachste Weg.

https://www.msxfaq.de/konzepte/calfed/mfg.htm

https://technet.microsoft.com/en-us/library/dd335047(v=exchg.150).aspx

Da brauchst du auch keine AD Vertrauensstellung. (Also muß dir das auch nicht klar sein. ;))

Bye

Norbert

es sei denn, man schaltet die Prüfung im Client ab, was leider gar nicht so selten ist. Einziger Dienst mir gerade bekannter Dienst bei dem das nicht funktioniert, ist der DA Client.

Hast du evtl. Deadlines für deine Updates im WSUS konfiguriert? Kannst du ggf. am Client direkt in der Registry mal nachschauen ob sich diese und ggf. widersprüchliche Einstellungen wiederfinden?

vor 2 Minuten schrieb RalphT:

Ich bin bislang davon ausgegangen, dass alles in einer Sperrliste vorhanden ist.

Schau doch rein in die Listen. Da siehst du doch dann was drin steht. :)

Das solltest du die Entwickler des Addins fragen. Ich könnte mir vorstellen, dass sie diese Frage öfter zu hören bekommen.

vor 13 Minuten schrieb Norfok:

Da wir niemanden bei uns im Unternehmen haben, der sich wirklich mit solchen Sachen beschäftigt, muss ich halt herhalten..

Es gibt also aus organisatorischer Sicht überhaupt keinen Grund "so jemanden" im Unternehmen zu haben. Du erledigst doch alles "irgendwie". ;)

Wieso sollte man die denn dort auch löschen können? Die wird doch irgendwo veröffentlicht. Üblicherweise im ldap und/oder per http. Dort kannst du sie löschen und das ist auch der einzig entscheidende Ort, denn woanders holt sie sich der client ja auch nicht.

Raid Treiber und nic Treiber wenn man nicht ne 3com 509 oder 905b hatte. ;) aber ja ich weiß, dass es nicht so smooth lief wie man dann seit 2000 gesehen hatte mit pnp und vernünftiger treiberunterstützung.

jetzt aber gut für heute hier. ;)

vor 11 Minuten schrieb Dukel:

Aber das wird glaube ich zu viel OT

Stimmt. Aber ich glaub das tut nicht so weh hier im Thread. ;)

Und gibt es ein Rpc Client access Array und auf welchen Namen hört das?

Ja das liegt aber an hyper-v wenn du das auf entsprechender Hardware installiert hättest ginge es erstaunlich schnell und selbst in vpc lief die Installation und der Server erstaunlich flüssig sogar ohne die ganzen Voraussetzungen von hyper-v, bei dem ich dann auch irgendwann aufgegeben habe. ;)

vor 6 Minuten schrieb NilsK:

Moin,

 

boah, das ist ewig her. Solches Wissen verschwindet. Ich hab ja mal aus Spaß NT4 in Hyper-V installiert, dabei kamen dann nach langem Kramen auch ganz dunkle Erinnerungen wieder hoch ...  

 

Gruß, Nils

Aber die Installation ging schnell und brauchte nicht mal 1gb afair. ;)

Naja dann eben Skript welches die gewünschten registry Werte in die Clients pumpt, was sonst per gpo passieren würde.

der Hinweis auf Samba 4 war auch eher spaßig gemeint. Mir ist schon klar, dass man das nicht mal eben in der Mittagspause erledigt. :)

Naja Update Samba auf Samba 4 (?) und dann WIndows DC dort reinpacken. Ist jetzt nicht so "schwer" :p

Na dann probiere und berichte. :) Learning bei doing, wenn man weiß was passieren könnte, ist doch recht einprägsam.

Ist doch ne Testumgebung. ;) Da würd ich jetzt aber verifizieren ob ich Recht habe. :P Wie sagte die Omi? Zum Üben, nicht als Strafe. ;)

Na wer kann noch poledit bedienen?

Nein die Edge und Mailboxserver müssen sich gegenseitig mit dem korrekten Namen auflösen können. Welchen auch immer du da gesetzt hast. Allerdings dürfte nach der INstallation das ändern des DNS Suffixes auf den Edgeservern nicht mehr möglich sein, weil dann dein AD/LDS nicht mehr mitspielt. Also kannst du maximal deinstallieren und neu installieren oder damit leben und es als Erfahrung abheften. ;)

Samba gibts auch mit simuliertem AD. ;) Und selbst bei NT4 gabs schon Policies. 

Warum setzt du denn interne FQDNs für einen Server der normalerweise ja genau eben NICHTS mit der internen Domäne zu tun hat, ausser eben per EdgeSync und SMTP Daten zu empfangen?

Der Edge ist hoffentlich nicht Mitglied der selben Domain wie dein Mailboxserver. Ansonsten hättest du ihn nämlich auch gleich so nennen können wie er extern angesprochen wird, dann wäre der Step nicht mal notwendig gewesen. Aber ja, das meinte ich mit anpassen des EHLO Strings. Sorry für die Verwirrung.

Bye

Norbert

Du müßtest das dann im SendeConnector auch gleich noch anpassen. ;) Und dann kannst du dir auch gleich noch die HeaderFirewall anschauen, die dann die internen Received from Header beim Versand nach extern entfernt.

Get-SendConnector „Dein Sendeconnector ins Internet“   | Remove-ADPermission -User „Nt-Autorität\Anonymous-Anmeldung“   -ExtendedRights „ms-Exch-Send-Headers-Routing“

Bye

Norbert

Wer setzt denn eine sophos ein, wenn er einen Edge nutzt? Evtl. Solltest du dir klar werden, was du da üben willst. ;) was genau hast du jetzt geändert?

Naja sicherer wird’s dadurch auch nicht, aber wahrscheinlich liegt’s daran, dass du ihn nicht geändert hast. Nutzt du einen Edge Server oder nur einen Mailboxserver? Bei ersterem kannst du den ehlo String im receive connector einfach ändern. Bei letzterem musst du dir erst einen eigenen connector anlegen, weil du den Namen sonst nicht ändern kannst ohne die Authentifizierung abzuschalten.

Versuch doch erstmal per Telnet von extern eine Mail zuzustellen. Danach kannst du bei Erfolg weitersuchen. ;)