cj_berlin

vor 47 Minuten schrieb zahni:

Wenn das das Thermopapier nicht gerade alle war

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

vor 13 Minuten schrieb mwiederkehr:

Fazit: Besser den Speicher am neuen Server anhängen und formatieren und die bestehenden Sicherungen per SMB kopieren.

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.

vor 56 Minuten schrieb t-sql:

Außerdem ist Best Practice eben keine SQL Authentifizierung zu nutzen.

"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,

vor 13 Minuten schrieb cheberdy:

Wieso nicht? Bei einer Gesamtanzahl von einer Stimme, ist eine Stimme die Mehrheit. Ein Knoten hat keine Stimme, fällt der aus, passiert ein Failover. Ein Knoten hat eine Stimme, fällt der aus, geht das Cluster offline.Das Cluster überlebt nur mit einer 50 % Wahrscheinlichkeit, Aber besser als 0% wenn es keine Mehrheit gibt.

Du beschreibst genau das Verhalten einer statischen 2-Node-Konfiguration ohne Witness. Eine dynamische 2-Node+Witness-Konfiguration mit ausgefallenem Witness verhält sich anders.

vor 22 Minuten schrieb NilsK:

HCI ist nicht WSFC. 

Was Compute angeht, schon. Bei Storage muss man aufpassen, da gibt es tatsächlich Unterschiede.

Generell jedoch ist eine 2-Knoten-Konfiguration, ob mit oder ohne Witness, nicht geeignet, um Clustering zu erlernen, wenn das Dein Ziel ist. Wenn Du dir sicher bist, für den Rest Deines Lebens nur 2-Knoten-Cluster zu bauen und zu betreiben, dann natürlich schon. Aber bei nahezu allen Clustering-Konzepten ist die 2-Knoten-Config ein Sonderfall. der mal besser, mal schlechter beschrieben ist.

vor 2 Minuten schrieb cheberdy:

Microsoft sagt aber:"Die Gesamtanzahl von Stimmen, die für das Quorum erforderlich ist, wird jetzt basierend auf der Anzahl verfügbarer Knoten bestimmt." 

https://learn.microsoft.com/de-de/azure-stack/hci/concepts/quorum

Genau. Nicht die Gesamtanzahl an Stimmen, die vergeben werden, sondern die Gesamtanzahl an Stimmen, die erforderlich sind  

Wenn jeder Knoten das Quorum sehen kann, denkt er, er ist der Beste.

Ansonsten ist es noch nie eine gute Idee gewesen, Cluster-Ausfall durch Konfigurationen an den Knoten selber zu simulieren. Wenn Du die Möglichkeit hast, das Netzwerk woanders zu unterbrechen, solltest Du damit arbeiten statt mit der lokalen Firewall.

Moin,

sie *müssen* nicht, wenn die Subnetze sich überlappen, aber tatsächlich wird zuerst versucht, auch im gegnerischen Forest mit der lokalen Site zu arbeiten, und erst dann einen vollständigen DCLookup durchzuführen.

Moin,

Probleme werden dann auftreten, wenn jemand diesen Namen tatsächlich verwendet  Wenn Du beispielsweise eine GPP mit Item Level Targeting am Start hast und das Targeting nach Site erfolgt, steht in der XML-Datei dann

<FilterSite bool="AND" not="0" name="HQ"/>

und ich bin mir ziemlich sicher, dass Domain Controller nicht die XMLs durchforsten und das korrigieren, falls Du die Site umbenennst. Skripte, die 

nltest /dsGetSite

aufrufen und mit dem Ergebnis was tun, sind auch solche Kandidaten.

Die Verknüpfung von GPOs an Sites wird hingegen nicht unter der Umbenennung leiden.

Dass der UPN sich ändert  Alle Systeme, die das Mapping per UPN machen, finden den User nicht mehr, falls Office 365, speziell OneDrive, im Spiel ist, findet der User seinen Content nicht mehr (das repariert sich irgendwann, aber nicht sofort). User, die sich angewöhnt haben, sich per UPN anzumelden, müssen nun einen anderen Namen eingeben.

Hat sich der UPN denn auch geändert? Eigentlich ziehen Office-Programme diese Daten aus 

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\ADUserName

Moin,

die primäre e-mail-Adresse (die Exchange verwenden wird) kannst Du in Exchange und im AD (proxy addresses, mail) nachschauen. Wenn die korrekt is, ist es nur die Anzeige im Outlook. Diese wird sich (supported) durch die Neuerstellung des MAPI-Profils ändern, oder (unsupported) durch zielgerichtetes Fummeln in dessen Registry.

Moin,

nein, es ist nicht in Stein gemeißelt, dass alle Sicherungen in die gleiche Datei gehen, nur wenn Du das in Deinen Befehlen oder in Deinem Wartungsplan explizit so angibst.