Jump to content

RobertWi

Expert Member
  • Gesamte Inhalte

    4.985
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von RobertWi

  1. Moin,

     

    besser (wenn auch nicht ganz sauber) ist es, den externen Namen als normalen Namen (nicht Dyndns) zu nutzen und einen CNAME-Eintrag auf den Dyndns zu machen.

     

    Aber technisch wäre es auch möglich, intern die Dyndns-Namen zu benutzen.

     

    Aber: Wenn Du Dir dann eh ein internes Zertifikat machst (externe signieren i.d.R. keine Dyndns-Domänen), warum nimmst Du dann nicht mehrere Namens ins Zertifikat auf?

  2. Hallo,

     

    vorab: Ein Forum kann auf detailierte Fragen gut eingehen, aber kein Grundlagenwissen verschaffen.

     

    Momentan ist es so geregelt das jeder Benutzter , sich überall anmelden kann.

     

    Das ist Standard, dank Active Directory.

     

    Dabei haben wir aber ein Problem das wenn ein Benutzer sich an einem "fremden" PC mit seinen Daten anmeldet alles übernommen wird Eigene Datein (etc) bis auf die voher vergeben Netzlaufwerke.

     

    Es gibt mehrere Möglichkeiten, Ordnerumleitungen und Dinge, die das Profil betreffen, einzurichten. Es gibt auch mehrere Möglichkeiten, Netzlaufwerke zu verbinden.

     

    Hier müsstest Du schon genauer sagen, was Du eingerichtet hast.

     

    Kann man diese für Benutzter Einzeln festlegen damit dieser sie überall besitzt?

     

    Sicher - wie erwähnt, mit mehreren Möglichkeiten.

     

    Oder. Ich sie für jeden Benutzter einmalig einrichte und diese dan auf jeden weiterangemeldeten PC übernimmt?

     

    Dan selbe Problem nur mit Outlook: Jeder Benutzer besitzt bei uns eine eigenes Email Postfach. Outlook läd auch an jedem PC das Outlookkonto brav mit...auser die Signatur.

     

    Wenn ihr Roadming Profiles ("servergerspeicherte Profile") benutzt, dann wird auch die Signatur des Benutzers mit übertragen.

     

    Kann ich die Signaturen auf dem Server hinterlegen und jedem Benutzter zuweisen?

     

    Du kannst keine individuellen Signaturen machen, aber mit Hilfe von Transportregeln welche anfügen (MSXFAQ.DE - E2K7/E2010:Disclaimer).

     

    Und das letzte Problem:

    Unser Email verkehr mit Kunden ist recht hoch.

    Ich würde gerne meinem Outlook sagen das er Jede Email die reinkommt folgendermaßen verwaltet wird: email trifft ein ( abcd@edf.de ) -wird in Ordner verschoben-> Ordnername E--wird weiter in Ordner verschoben--> edf.de--> in unterordner --->abcd

    Sodass Emails immer Quasi Firma...Mitarbeiter

    (schritt oder E ist nicht so wichtig)

    Selbige mit Ausgang.

    Damit der Schriftverkehr einfacher Nachzu verfolgen ist bzw. übersichtlicher wird.

     

    Das übersteigt die Möglichkeiten von Outlook. Du müsstest für jede Mail-Adresse eine eigene Regel bauen.

  3. Na ja, schau Dir mal die Anführungszeichen an, -ne müsste -notlike heißen, das Plus-Zeichen ist vollkommen verkehrt. Außerdem ist Emailaddresses ein mehrwertiges Feld, d.h. wenn man es als einen Text behandelt und filtert, kommt am Ende natürlich gar nichts mehr raus.

     

    Kurz gesagt: Da ist so viel verkehrt, dass kann gar nicht funktionieren. :)

     

    Eine funktionierende Variante könnte so aussehen:

     

    Get-Recipient rwille -filter { RecipientType -eq "UserMailbox" } | ForEach-Object {$_.EmailAddresses} | Where-Object {$_.AddressString -notlike "*@dom1.de" -and $_.AddressString -notlike "*dom2.de" } | Select-Object AddressString

  4. Ich denke, das größte Problem ist, dass erstmal definiert werden muss, was der Kunde unter "Hochverfügbarkeit" verstehen. Oder anders formuliert: Wie lange darf ein System ausfallen.

     

    Ohne diese Definition ist alles nur Spekulation.

     

    Eine DAG macht Exchange noch lange nicht Hochverfügbarkeit und kann auch mit einem guten Backup Konzept realisiert werden.

     

    Auch Du wirfst HA und Backup durcheinander. Beides hat unterschiedliche Ansätze und ein Backup wird niemals an die Verfügbarkeit einer sauber funktionierenden DAG rankommen. Dafür habe ich mit einer DAG keine Möglichkeit, eine gelöschte Mail wiederherzustellen (mit Single Item Recovery schon, aber das ist kein Werkzeug einer DAG).

     

    Ein wichtiger Merksatz ist: Desaster Recovery (das "Ergebnis" von Backup) setzt dann ein, wenn Hochverfügbarkeit versagt hat. Und so muss man das auch sehen.

     

    Das Exchange Datenbanken kaputt gehen ist auch eher selten geworden.

     

    DAG schützen aber nicht nur vor defekten Datenbanken. Sie helfen auch bei Reboot (Patchday), BS-Fehlern, Fehlkonfigs eines Servers, etc.

     

    Man muss das mit dem Kunden klären was er erwartet und was wirklich Sinn macht. Dieser Satz hier signalisiert mir das da noch Klärungsbedarf mit dem Kunden besteht.

     

    Das ist der entscheidende Satz.

     

    Und, um es mal ganz deutlich zu sagen: Er braucht dafür einen kompetenten Ansprechpartner. Dem OP gizi waren am Anfang des Thread nicht mal ganz einfache HA-Prinzipien von Exchange bekannt (NLB, usw.). Das ist eine schlechte Grundlage für eine gute Beratung. ;)

  5. Moin,

     

    schreib doch das nächste Mal, dass Du alle DAG-Knoten runterfahren willst. Das ist eher unüblich und meine Anleitung brauchst Du dann auch nicht. Die gilt für den Standard-Fall, dass die DAG-Knoten wechselseitig neugestartet werden.

     

    es gab probleme mit dem witness server und dem MS FCS ..

    konnte es aber fixen

     

    Bei kompletten Reboot muss man auf die korrekte Reihenfolge achten:

    - beenden: Zuerst die DAG-Knoten + danach den FSW

    - starten: Umgekehrt, erst den FSW, und warten bis er sauber online ist + danach die DAG

     

    Auf welchem Rechner liegt bei Dir das FSW?

     

    Am besten wäre es, wenn es ein Geräte ist, dass auch bei einem totalen Exchange-Ausfall noch in Betrieb bleiben kann.

     

    die ms scripte start/stop maintanance sind nur da um alle rollen von server a->b zu schieben...

     

    Nein, sie schalten auch die Knoten in einen Wartungsmodus (darum muss man sie mit lokalen Admin-Rechten starten, da sie die cluster.exe bedienen). Das verhindert, dass im Failover-Fall auf den abgeschalteten Knoten zurückgeschwenkt wird.

     

    Sinnvoll benutzt man sie aber nur, wenn mind. ein DAG-Knoten online bleibt. Wenn alle ausgeschaltet werden, sind die Scripte egal, dann gibt es ganz am Ende nach dem Neustarten nur das Neuverteilen-Script.

  6. Moin,

     

    Ressourcenpostfächer funktionen in den Kalenderberechtigungen nicht wie normale Postfächer.

     

    Du musst daher die Kalenderberechtigungen auf die Standard-Einstellungen zurückstellen.

     

    Die einzige "echte" Art der zusätzlichen Berechtigungen sind Vollzugriff und der Stellvertreter.

     

    Warum genau das so ist, ist nicht beschrieben, aber es hat vermutlich was mit dem Stellvertreter zu tun. Auf jeden Fall findest Du auch in diesem Forum genügend Berichte, dass Kalenderberechtigungen bei Ressourcen-PF nicht korrekt funktionieren.

  7. Scipting Agent gibt es erst mit Ex 2010. Allerdings funktioniert der bei Vollzugrifft auch gar nicht, weil der Scripting Agent ausgeführt wird, bevor die Berechtigungen gespeichert worden sind.

     

    Ein geplanter Task wäre eine Lösung, eine andere ein eigenes Script zu schreiben, dass die Mailbox anlegt und Vollzugriff setzt. Dann kann aber nur noch dieses Script benutzt werden, um neue Mailboxen anzulegen.

  8. Moin,

     

    wenn wir 2 nodes - members haben, aber beide herunterfahren müssen

     

    Dann ist keiner mehr da und man muss natürlich auch keine Scripte vorher starten. Aber der Fall, dass beide Server gleichzeitig runtergefahren werden müssen, kommt ja in der Praxis nur sehr selten vor.

     

    was passiert, wenn ich auf den zweiten member herunterfahren

    und das script bemerkt, dass keiner DAG Member mehr online ist?

     

    Das Script läuft auf den DAG-Knoten. Wenn beide Offline sind, gibt es kein Script mehr.

×
×
  • Neu erstellen...