Doso

An mir ist dieser SSD Hype vorbei gegangen. Unsere Plattensysteme laufen halt einfach gut. Ansonsten: Software RAIDs sind meist Müll.

Wir setzen auf den SCCM als Teil des System Centers. Kann halt wirklich alles das Ding, braucht aber auch entsprechend personelle Ressourcen.

Vorteil bei uns ist auch das wir auch die Backup Lösung von Microsoft, DPM, nutzen. Damit konnten wir Backup Exec ablösen was uns mehr gekostet halt als das ganze System Center uns jetzt kostet. Das geht aber natürlich nur mit den vergünstigen Lizenzen die man als Bildungseinrichtung erhält.

Kam glaube ich mit Exchante 2016 CU7. Hier findest du mehr https://support.microsoft.com/en-us/help/4010182/archive-folder-is-automatically-added-to-your-office-365-mailbox

Statt löschen kannst du ihn halt verschieben.

vor 2 Stunden schrieb Jim di Griz:

Sehr selten kriegen einzelne Server einen Koller und switchen auf eine 169.xxx IP.

Dann hast du einen IP Adresskonflikt, der Server erkennt das die IP im Netz schon vergeben ist.

Das IPv6 bei einer Dual Stack Konfiguration bevorzugt wird ist kein Fehler, das ist der Standard - und das schon länger.

Dein Exchange 2010 GUI Problem kenne ich, ich glaube das hatte was mit irgendeinem Windows Update/.NET Framework Update zu tun oder so. Aber das ist schon vor vielen Monden gepatcht worden. Irgendwo SP2 rum, also vermutlich deine Exchange Server nicht mehr so ganz aktuell. Das solltest du mal beheben.

Exchange ist halt eigentlich eine total gute zu administrierende Software. Da kommt man halt schnell in die Versuchung mal eben schnell etwas zu machen...

Bei einer Migration von 2008R2 auf 2012R2 hatten wir mit SLES VMs ein Problem. Und zwar hat Linux die Festplatte nach der Migration unter einer anderen ID erkannt und dann hat der Bootmanager nicht mehr funktioniert nicht da er die HD per ID angesprochen hat. Konnte man beheben in dem man vorher den Bootmanager angepasst hat.

Auf selber Windows Server Version haben wir das aber schon mehrmals ohne Probleme mit Ubuntu gemacht.

Habe es bei uns auch getestet, Windows Server 2012R2 Host. Keine Problem.

Die Windows 7 Rechner haben bei uns sowieso IPs per DHCP, ggf. per Reservierung. Da ist es dann recht egal.

Echtzeitanwendungen werden glaube ich schlicht nicht visualisiert. Wobei das dann schon recht speziell sein muss. Mailserver und Webserver sind gute Kandidaten für eine Virtualisierung. Beim Streaming gibt es meist so viel Buffering da fallen die 1-2 Pings nicht auf.

Windows Server 2016/Windows 10 brauchen für das starten des Betriebssystem Minimum 1 GB, also den Start RAM entsprechend konfigurieren.

Wir haben eine Windows 10 VM unter Windows Server 2012R2 laufen und mit 1GB Start RAM keinerlei Probleme.

Wir haben ~35 Standorte über ein Stadtgebiet verstreut und an keinem der Standorte lokal irgendwas. Wenn nämlich was in der Zentrale ist, ist sowieso nicht mehr viel los an den anderen Standorten.

vor 3 Stunden schrieb zahni:

Damit kann man sogar im Betrieb viele der kleineren  Ontap-Updates durchführen.

Ich war jetzt bei unserem IBM DS3500 sogar so mutig und habe im laufenden Betrieb die Firmware unseres SANs und danach die Firmware der Festplatten aktualisiert. Beides ohne Downtime, ist schon schick was da mittlerweile alles geht :)

Wir hatten aber auch schon mal den Fall das unser SAN wegen eines Firmware Bugs komplett down war, und das gleich 2x in 3 Monaten. Downtime insgesamt etwa 5 Stunden. Ob so ein seltener Fall den Preis eines zweiten SAN wert ist muss jeder für sich entscheiden.

Gestern war Patch Tuesday, könnte man eigentlich gleich das nächste CU probieren. Bin mal gespannt wie lange Microsoft die Hinweise bezgl. der Registry Einstellungen zur Aktivierung/Installation der Patches mitziehen will. Das müsste ja theoretisch viele Jahre so gehen.

Replica mit DCs? Hört sich irgendwie nicht richtig an.

Geht sowas überhaupt, einen Cluster ohne Witness einrichten?

Ansonsten sollte man bei dem Fall "Strom weg" nicht denken das so ein Failover jetzt eine nette Sache ist. Strom weg ist Strom weg. Die VMs werden halt nur automatisch auf einem anderen Node hochgefahren. Das geht oft gut, muss aber nicht. An einem zweiten Netzteil mit ggf. eigenem Stromkreis sollte man jetzt nicht unbedingt sparen...

Habe das so verstanden das er nicht notwendig ist sondern optional. Habe das in unserem SQL Server 2012 nicht laufen und er funktioniert.

Haben wir seit Jahren im Einsatz auf Basis von Windows Server 2012R2 Hyper-V und SQL 2012. 2 Nodes. Wir nutzen für den Speicher Shared VHDX.

Zweiten DC aufsetzen, Eval Server zu normalen Server herunterstufen, Key eingeben und Edition Upgrade, Server wieder zum DC hochstufen. Ggf. zweiten DC wieder entfernen, jedoch möglichst behalten.

Die SQL Meldungem sind recht eindeutig. Sharepoint kommt nicht auf den SQL Server. Was ist der Farm Account, auch bekannt als "Database Access Account"? Weiter geht es mit der Fehlersuche auf dem SQL Server in der Ereignisanzeige. 

Das was das sinnvoller ist und das was das Business will. Was nun billiger ist lässt sich schwer sagen da wir eure Kostenstruktur nicht kennen, ähnliches gilt für regularische Sachen. Soll ja doch Bereiche geben die ein Problem damit haben das ihre E-Mails in der Cloud bei einer US Firma liegen.

Ich meinte mit meiner Frage eigentlich das .NET Framework den Exchange 2016. Da gab/gibt es ja Inkompatibilitäten mit den CUs und .NET Framework 4.7.0 (nie supportet) bzw. 4.7.1 (erst mit aktuellen CU supportet). Die Fehlermeldung lässt ja irgendwie auf .NET schließen.

Mit Downtime: VM herunterfahren, Verzeichnis der VM einfach zum neuen Host kopieren. In Hyper-V Manager importieren, ggf. Netzwerk anpassen. Fertig.

Ohne Downtime. Hmm.. schwierig?

Wenn ich spontan raten dürfte: Datenbankserver zersägt.

Schaltet mal in der IIS config die custom errors (=Sharepoint Fehler) wieder an - also das hier rückwärts: https://blogs.msdn.microsoft.com/voyage/2014/09/02/enable-debugging-and-set-custom-errors-off-in-sharepoint/

Oder halt dann entsprechend richtig aus. Nur so werdet ihr entweder direkt an die Debugging Infos kommen oder halt an die Correlation ID mit der man dann in den ULS Logfiles nachschauen kann. Die wichtigsten Fehler gibt es aber auch in der Ereignisanzeige der Server.

Des weiteren sei euch gesagt das Windows Updates, ja nicht einmal Sharepoint Updates, Verzeichnisse löschen und dadurch Webparts kaputt machen - was immer ihr damit auch genau meint.

Einen Sharepoint Suchdienst kann man löschen und neu anlegen, das sollte das Problem nicht sein. Ist halt etwas Powershell Fingerübung. Sollten die Daten in dem System wichtig sein, vielleicht einen Experten hinzuziehen. Sharepoint ist halt ein bisserle komplexer, wenn man da nicht viel Zeit rein steckt und nur so ein bisserl "rumwurstelt" macht man da schnell was kaputt.

Aktuell wäre CU8 auf dem Exchange Server 2016. Wie weit seit ihr bei dem Exchange 2010 hinterher?

Welches .NET Framework habt ihr auf eurem Exchange 2016 drauf?

*Alu Hut aufsetz*

Jede Verschlüsselung ist knackbar. Vor allem die von großen US Firmen, die stecken doch mit der NSA alle unter einer Decke!

Aber mal ernsthaft, wie soll das hier irgendwer beurteilen? Selbst Sachen die öffentlich einsehbar von Gremien mit vielen Experten erarbeitet wurden haben sich irgendwann als absolut trivial herausgestellt. Man denke nur an die alte WEP Verschlüsselung, heute knackt man in wenigen Minuten mit kaum Vorkenntnissen.

Man muss bei sowas auch immer an die Wiederherstellung denken. Wie kommt man dann an die Daten ran wenn man sie braucht? Willst du da erst mal irgendwo die Schlüssel aus dem Tresor ziehen? Der war halt leider auch in dem Gebäude das abgebrannt ist...