cj_berlin

Das heißt es in der Tat.

Moin, was ist denn mit der Public Folder *Mailbox*, wo der Ordner lebt? Vielleicht ist diese voll bzw. gegen Quota gelaufen?

Moin, was meinst Du mit "Zuweisung"? Wenn er dort Rechte hat, wird er den Ordner sehen, wenn er keine hat (also auch kein "Ordner sichtbar") wird er ihn nicht sehen. Weise die Rechte den Gruppen zu, und Du bist fertig.

Ich wüsste sofort zwei schwäbisch geprägte mittelständische Industriebetriebe, wo man locker zwei Tage diskutieren würde, ob man 11,70 pro Monat ausgibt.

Also, wenn es wirklich nur zwei User sind, und einer von denen braucht M365, gönn das dem anderen auch und spar Dir den Stress, den Ärger um nicht zugestellte mails, falsche Adressen usw. Ganz ohne Kosten wird es sowieso nicht ablaufen, denn Du bräuchtest für dieses Konstrukt eine Schattendomain für den Mailtransport, und die kostet was, und sei es nur 5 Euro im Jahr. Aber Du bist vermutlich andauernd am Troubleshooten, spätestens wenn die beiden User einen Termin miteinander planen wollen...

Moin, prinzipiell geht das, wird aber extrem fummelig und stößt irgendwann bestimmt an irgendwelche Grenzen, wenn weitere Funktionalität benötigt wird.

Sorry, aber was bedeutet das? Siehst Du genau den Eintrag, den Du kopiert haben wolltest, in der Ausgabe des Einzeilers oder nicht?

Wenn es ein dem Hersteller bekannter Bug ist, ist es ein Rückgabegrund. Würde ich auch machen und ein anderes Modell nehmen, es wurden ja bereits hier im Thread einige genannt.

Nö, das Ding bimmelt und die sendende Seite legt irgendwann auf, obwohl Auto-Annahme eingestellt ist.

Dann steht's aber trotzdem im Journal, welches später auf einer neuen Rolle ausgedruckt werden kann.

Moin, auf wieviele Rufzeichen ist die Fax-Annahme eingestellt? Ich hatte mit einem anderen HP-Modell die Problematik, das 4 Rufzeichen dazu geführt hatten, dass er nie angenommen hat, bei drei die Auto-Annahme aber funktionierte. Wenn es eine separate Faxleitung ist, spricht ja nichts dagegen, das auf 1 zu stellen.

Ein schönes Wochenende euch!

Moin, das Account, das Du verwendest, ist nicht zufällig in der Protected Users-Gruppe oder so? Ganz b***d gefragt: Wenn die Hosts schon im selben oder zumindest in vertrauten Kerberos-realms sind, warum nicht Kerberos nutzen?

Also, Du hast zwei "Main" Sites, alt und neu, die sich gegenseitig nicht sehen, und zwei "Satellite" Sites, die sich gegenseitig nicht sehen, dafür aber jeweils beide "Main" sites - richtig? Das hieße, für die Sub kannst Du die FSMO-Rollen in einen der Satelliten übertragen, in der "Main-Neu" in aller Ruhe einen DC aufbauen, was auch in Ruhe keine 4h dauert, und die FSMO-Rollen danach vom Satelliten in die "Main-Neu" schwenken. Bleibt also die Root. Ich würde vermutlich in einem der Satelliten einen temporären DC für die Root aufbauen und den Transfer genau so machen wie für die Sub. Geht das aus irgendeinem Grund nicht, dann mach es wie Du es beschrieben hast. Aber demote vorher alles Überschüssige.

Da Du den HTML-Quelltext offenbar per PowerShell generiert, kannst Du es an der Stelle tun, wo Du die Zeile in die Variable $table schreibst: <tr style="color:red;"><td>...</td></tr> oder halt das gleiche für ein einzelnes td-Element, wenn's nur die Status-Spalte sein soll.

Ja sicher Ist korrigiert

Moin, die überschüssigen DCs vor der Migration ordentlich demoten und aus dem Forest entfernen. Danach sollte alles funktionieren, zumindest nach der Änderung der DNS-Einstellungen und dem erneuten Reboot. Bei der Gelegenheit solltet ihr prüfen, wie aufwendig das ist, alles aus der Sub in die Root zu migrieren und die Sub zu entsorgen. Aber falls sie aus irgendeinem Grund bleiben soll, ändert es nichts an der Vorgehensweise für die Migration - alles, was später nicht kommunizieren könnte, vorher sauber entfernen.

Ja, meine WSUS-Empfehlung ist ähnlich: - min 16 GB RAM - 4 Worker - 10.000 queue depth - 0 private memory limit - reindex sicherlich nicht jeden Tag, aber zumindest 1-2 mal im Monat

Ich würde eher sagen, wenn das SAN das hergibt, einmal ein Volume an den 2012er präsentieren, Backup verschieben, dann dieses Volume UND ein neues Volume an den neuen Server präsentieren und lokal kopieren.

Du kannst die Volumes mit ziemlicher Sicherheit mounten. Allerdings sind reichlich Versionen, Bugfixes und Features dazwischen, so dass ich es lieber lassen würde.

Moin, als Anregung vielleicht: in der IT-Dienstleistung gibt es meistens einen variablen Gehaltsanteil, der von der Erfüllung individuell mit dem Vorgeetzten zu vereinbarender Ziele abhängt. Sehr häufig sind es bestimmte Schulungen und Zertifizierungen, unabhängig von ihrer formalen Einstufung als Fort- oder Weiterbildung. Verhandlungen über die Erhöhung des fixen Anteils sind natürlich etwas anderes, aber auch hier kann eine wiederholte Erfüllung - oder eben Nichterfüllung - der Jahresziele eine Rolle spielen. Ansonsten würde ich die Gegenfrage stellen, ob ich neben dem höheren Gehalt auch tatsächlich andere Aufgaben bekäme, wenn ich mich WEITERbilde, und was diese denn wären. Denn dann reden wir ja nicht mehr über eine Gehaltserhöhung, sondern über eine Beförderung. Dann ist vielleicht nicht Exchange-Admin, sondern Teamleitung oder Wissensmanagement als Weiterbildung angebracht

Moin, ich weiß nicht, was Dir bei Deiner Recherche begegnet ist, aber die Idee ist, die Verwaltung von EfB vom Client-Management (GPO/MDM) zu entkoppeln und über eine separate Web-API bereitzustellen. Damit wird auch EfB mit dem separaten Cookie - und Memory-Space für privat und beruflich auch auf ungemanagten Geräten möglich. Ohne MS-Anmeldung kann die EfB-Richtlinie nicht an Benutzer ausgerollt werden, sondern ist für alle gleich. Den Gedanken, den nicht-forBusiness-Browser wieder unverwaltbar zu machen, habe ich noch nicht gehört.

"Best Practice" ist ein starkes Wort. Das Microsoft-Dokument dazu listet 5 Advantages und 4 Disadvantages der SQL-Auth auf, somit hätte nach Business Consultant-Logik die SQL-Auth gewonnen . Auch wenn dort am Anfang steht, man solle wo möglich Windows-Auth verwenden. Der einzige wirkliche Vorteil der Windows-Authentifizierung ist, dass Kerberos verwendet werden *kann*. In Realität jedoch funktioniert dies nur, wenn zwischen SQL-Server und dem zugreifenden User eine Vertrauensstellung existiert. Und in gehärteten AD-Umgebungen müsste man das auf "...und dem User sowie dem Client" verschärfen. sind SQL-Server *und Clients* oft fehlkonfiguriert, so dass selbst innerhalb eines AD-Forests auf NTLM zurückgefallen wird. bei der Notwendigkeit, andere Credentials als die angemeldeten zu verwenden: Die Anwendung muss Impersonation verwenden, das heißt Windows-seitig am Client den Context wechseln. bei der Notwendigkeit, Credentials zu speichern: mit SQL-Auth sind es Credentials, die im Zweifel nichts außer ihre Berechtigungen auf dem SQL-Server missbrauchen können, bei Windows Auth ist es ein Account, das auch woanders Permissions hat, und sei es nur Permissions sich anzumelden. bei Betrieb von SQL auf Linux: der Linux-Server muss in den Kerberos-Realm von AD integriert werden, um Windows Auth zu verwenden Und da sind wir noch nicht im Dev-Test-Integration-Teil angekommen, wo es bei Windows-Logins nicht möglich ist, die Datenbank lustig hin und her zu transportieren und dabei Berechtigungen zu erhalten. Ich will damit keine Diskussion vom Zaun brechen, sondern nur den Ton der bereits begonnenen Diskussion ein wenig mäßigen, denn was des einen Best Practice ist, kommt bei dem anderen aus zwingenden technischen Gründen gar nicht in Frage.

Moin, die Fehlermeldung sagt, dass $ImportCert.Thumbprint leer ist. Ist es vielleicht wirklich so?

Sorry, ich bin raus,