Marco31

In der Regel laufen Server 24/7, zumindest bei uns. Schon alleine wegen Datensicherung und Mail Server. Und es würde ne halbe Stunde dauern alles hochzufahren. Man sollte auch bedenken dass Server Hardware für Dauerbetrieb ausgelegt ist.

Wenn das alles sooo kritisch und geheim ist - wer administriert das? Hat der BR nen eigenen Admin? Bei einem derartigen Misstrauen...

Wenn du mich fragst ist das was du da schilderst nicht umsetzbar. Das Dateisystem speichert immer wer zuletzt am Dokument war und windows loggt wer sich wann an/abmeldet. Das was du willst lässt sich digital nicht abbilden, da hilft eine mechanische Schreibmaschine.

Gerade deswegen mit dem HPE Support telefoniert. Laut Auskunft des Mitarbeiters erhalten betroffene Kunden automatisch einen Rückruf von HP mit weiteren Infos. Bin mal gespannt... Unsere MSA läuft erst seit März 2018, da sollten wir erstmal Safe sein...

Also ich halte in so einem Umfeld VDI für overkill. Zumal der TO ja vermutlich auch keine Erfahrung mit sowas hat...

Datacenter über eBay... weißt du eigentlich was so ne Datacenter Lizenz regulär kostet?

Kann man auch per GPO einstellen/abschalten falls AD vorhanden

Ja, über das was du da sagst habe ich auch schon nachgedacht und sehe es ganz ähnlich. Die Sicherung beim starten fällt aus den von dir genannten Gründen raus, ich habe schlichtweg keine Lust wegen Updates und/oder Neustarts jedesmal an die Arbeit zu fahren... Das Szenario "Diebstahl der Anlage" ist ein sehr unwahrscheinliches, das ist mir bewusst. Wobei es aber das Szenario ist, wo durchaus Fragen kommen können/werden wie ich das absichere. Firewall liegt nicht in meinem Bereich (Rechenzentrum), und einen Datendiebstahl durch Mitarbeiter halte ich a) für unwahrscheinlich (öffentlicher Dienst) und b) haben die meisten User schon Schwierigkeiten mit Windows Grundfunktionen. Ich mache mir da auch nichts vor - FALLS jemand sowas tatsächlich wegen den Daten klaut, dann hat er in der Regel eh die Mittel und das Knowhow an das ranzukommen was er will. Es geht mir eher um den Fall, dass das ganze geklaut wird, die Hardware wird verkauft und der Käufer des ganzen liest dann fröhlich die Daten aus...

Hallo Leute, ich habe hier folgendes Problem bzw. Aufgabenstellung. Ich möchte verhindern, dass nach einem Diebstahl der Server- und Storage Hardware auf Laufwerke mit Personenbezogenen Daten zugegriffen werden kann . Also primär Fileserver und Datenbanken. Das ganze ist ne sehr kleine Umgebung (2 ESXI 6.5 Hosts, 1 SAN), die VM's sind Windows 2012R2 und Windows 2016, die Verschlüsselung von ganzen VM's über nen KMS wäre meiner Ansicht nach übertrieben, und ohne redundante Internet-Anbindung vermutlich auch keine gute Idee. Welche Möglichkeiten gibt es da? Macht es Sinn die Laufwerke innerhalb der VM mit Bitlocker zu verschlüsseln? Bin für alle Kommentare dankbar

Ich war auch skeptisch bezüglich der VCSA, aber ich bin auch positiv überrascht worden. Wie haben aber auch ne sehr überschaubare Umgebung (2 Hosts ohne vmotion etc). Und mit Veeam geht auch die Sicherung schnell von der Hand.

Der SQL ist bereits ein 2014er, soviel ich weiß das Maximum für SP2013. Aber um mal Licht in die Sache zu bringen, ich habe hier folgende Konstellation: Server Windows 2016 mit 1x MSSQL 2014 und 1x MSSQL2016 (auf der gleichen Maschine) installiert; auf dem 2014 läuft die SharePoint-Instanz und auf dem 2016 die Default-Instanz. Klingt jetzt zwar "etwas" exotisch, läuft aber bisher fehlerfrei und ausreichend performant. Habe auch bisher nichts gefunden dass das nicht supportet wäre. Die jetzige SharePoint Foundation 2013 läuft noch auf einem Windows 2008R2, die möchte ich auf einen Windows 2012R2 bringen. Und das teste ich gerade, die oben genannten Probleme tauchten bei der Installation der SPF 2013 auf dem neuen Win2012R2 auf.

Nein, Testumgebung ist ne 1:1 Kopie (bzw. Restore) der Echtumgebung. Daher sind die Ports schon offen, läuft ja bereits die alte SP-DB auf der Instanz. Habe aber die Lösung gefunden, mit nem SQL Alias findet er dann auch den richtigen Server mit Instanz. https://veronicageek.com/sharepoint/sharepoint-2013/configure-sql-aliases-for-sharepoint-server/2018/04/

Hallo Forengemeinde, ich muss demnächst meine SharePoint Foundation 2013 von einem W2008R2 auf einen W2012R2 verschieben. Daher bin ich in meinem Testlab gerade am testen und versuche auf dem neuen Server SP2013 zu installieren. Der SQL Server hat zwei Instanzen, die Default Instanz (MSSQLSERVER) und die Instanz SHAREPOINTSQL auf Port XY (wo ja auch bereits die DB's des alten SharePoint laufen). Das Problem ist jetzt folgendes: Wenn ich beim Konfigurationsassistenten die SHAREPOINTSQL Instanz mitgebe (sqlserver\sharepointsql), kommt der Fehler dass auf die Master DB nicht zugriffen werden kann weil der Server nicht gefunden werden kann oder die Zugriffsrechte nicht ausreichen. Die Rechte des SP-Setup-Accounts habe ich schon gecheckt, der entsprechende User hat dbcreator und securityadmin. Gehe ich mit der Installation auf die Default-Instanz gibt es kein Problem - er scheint also aus irgendeinem Grund nicht auf die SHAREPOINTSQL Instanz zugreifen zu können. Jemand ne Idee wo der Fehler liegen könnte? Wie gesagt, die Instanz fungiert bereits für den alten SP-Server als DB-Instanz. Und da gibt es auch keine Probleme.

Ok ?

Reden wir hier eigentlich von privater Spielerei oder etwas was produktiv in einer Firma, Verein oder ähnliches genutzt werden soll?

@Norbert: Kannst du das bei dir mal testen wenn du Zeit hast? Wäre schon interessant ob das ein generelles Problem ist oder mit den "Altlasten" zusammen hängt.

Weil auch dieses Forum ein gewisses Maß am Fachwissen voraussetzt. Ein Auto repariert man auch nicht mal so nebenbei wenn man nicht weiß was man tut...

Was erhoffst du dir von der Anzeige der "Größe"? Hier wird nur angezeigt was auf dem physikalischen Laufwerk des Servers insgesamt frei ist. Wenn du z.B. drei Netzlaufwerke auf einem physischen Server-Laufwerk freigibst, wird dir bei allen das gleiche als "frei" angezeigt.

Der VMware-Support hat das als "Known Issue" bestätigt, ohne SMBv1 funktioniert das derzeit nicht. Es soll in einer zukünftigen Version gefixt werden sagt der KB aus dem Januar 2019

Hattest du eventuell vergessen die FSMO-Rollen auf den neuen DC zu übertragen?

So, mal eine Rückmeldung zum eigentlichen Thema. Ich habe heute morgen die Kennwortlänge von 14 auf 20 Zeichen umgestellt. Und schon werden wieder die SceCli Fehler 1202 geloggt, net accounts /Domain zeigt weiterhin 14 Zeichen an. Ziemlich blöde...

Für mich ein typischer Fall von "Ich säge an dem Ast auf dem ich sitze"... Die Verwaltbarkeit der Clients über GPO ist eines DER Argumente für Windows Clients in der Domäne, zumal ja auch nicht erkennbar ist wie MS das sich ohne GPOs vorstellen würde. Und bis auch alle Clients in einer wie auch immer gearteten Cloud gehosted werden läuft noch sehr viel Wasser den Rhein runter. Wobei ich mir sowas nicht in meinen schlimmsten Albträumen ausmalen möchte.

Die GPO Geschichte finde ich schon nen großen Wurf, die Idee zumindest. Da möchte ich gar nicht dran denken ohne auskommen zu müssen ?

Damals waren es ja zumindest noch Features, das was heute als "Feature" verkauft wird braucht man eigentlich nicht.

Ich werde das Mitte nächster Woche testen können, ich gebe dann mal Rückmeldung. Kannst ja auch mal Rückmeldung geben wenn du das in deiner Umgebung testen konntest.