NilsK

Moin, Wenn du Anforderungen dieser Art hast, solltest du dir eine echte Softwareverteilung anschaffen. GPOs sind damit zu schnell überfordert. Gruß, Nils

Moin, Ist supported. Eine Quelle kann ich dir aber nicht nennen. Gruß, Nils

Moin, ich erwähne noch mal robocopy und dessen Auswahl-Syntax ... Gruß, Nils

Moin, aber nur wenn man Äpfel mit Birnen vergleicht. Office 365 ist ja eine ganze Menge mehr als ein Office-Paket und eine Exchange-Mailbox. Rein technisch betrachtet sollte es so gehen. Gruß, Nils

Moin, also ... wenn man ein Zertifikat mit Private Key verteilt, ist das schon mal ausgesprochen seltsam. Ein Private Key ist per definitionem privat, d.h. er hat einen (einen einzigen!) Rechner niemals zu verlassen. Verteilen eines Private Keys geht gar nicht. Wenn man dann aber auch noch das Kennwort dazu im Klartext in ein Skript packt, dann hebelt man jedes Fitzelchen Sicherheit aus, das sich mit dem Zertifikat vielleicht erzeugen ließe. Entweder liegt hier also ein gravierendes Missverständnis vor, wie man die Installation dieser Software durchführt. Oder der ganze Sicherheits-Ansatz ist so kaputt, dass man diese Software nicht einsetzen sollte. Gruß, Nils

Moin, ach der. Ja, auch der liefert nicht in jedem Fall Gold-Qualität. Gruß, Nils

Moin, dann hat der Autor des Buches das entweder in einem uralten Buch abgeschrieben oder seit der Windows-2000-Ausgabe nicht mehr aktualisiert. (Sind die Initialen des Autors zufällig T. J.?) Ja, Zuweisung per GPO ist der heute übliche Weg. Die Freigaben als AD-Objekte anzulegen, war eher ein Beispiel von Microsoft aus den Neunzigern, wozu man so einen Verzeichnisdienst so alles nutzen könnte. Da aber niemand seine Freigaben per LDAP suchen wird, war das schon damals eine nutzlose Idee. Gruß, Nils

Moin, kein Mensch packt Freigaben ins AD. Das war mal eine Idee, die Microsoft Ende der Neunzigerjahre hatte, die sie aber nicht weiterverfolgt haben. Ist faktisch nutzlos. Ich würde diese Objekte wieder löschen. Was möchtest du denn damit erreichen? Gruß, Nils

Moin, ich empfehle eine Abfrage wie "upgrade sql server edition" in der Suchmaschine deines geringsten Misstrauens. Dann findet man z.B. dies: https://docs.microsoft.com/en-us/sql/database-engine/install-windows/supported-version-and-edition-upgrades?view=sql-server-ver15 Im "laufenden Betrieb" wird das natürlich nicht gehen. Gruß, Nils

Moin, man kann auch robocopy für sowas einspannen, das recht gute Möglichkeiten zur Auswahl und für den Ausschluss bietet. http://www.codesingh.com/2009/08/using-robocopy-to-delete-old-files-from.html Gruß, Nils

Moin, ich stimme Jan zu. Die Frage ist die nach dem Ziel. Wenn ihr dringend die Zertifizierungen braucht und die Praxis nicht relevant ist, kann man das machen. MS-Partner stehen manchmal vor so einer Situation, wenn sie schnell bestimmte Zertifikate nachweisen müssen für den Partnerstatus. In der Situation nützen einem Praxiskenntnisse (die man schon hat!) nichts, dann muss es das Papier sein. Sonst wüsste ich aber auch schon kein Szenario dafür. Sobald es eigentlich auf das Wissen ankommt, sind solche Kurse falsch. In dem Fall würde ich aber auch gar keinen "offiziellen" Kurs machen sondern mir selbst einen zusammenstellen lassen. Ist meist schon ab 3-4 Teilnehmern günstiger. Gruß, Nils

Moin, zumindest früher war der SQL Server Agent eben doch in der Express Edition dabei, nur deaktiviert. Aktivieren - ging. Ob das immer noch so ist, kann ich grad nicht nachsehen. Gruß, Nils

Moin, du hast den Domain Level angehoben. Das ist notwendig, aber reicht nicht. Den Forest Level musst du separat anheben. Das tust du in "AD-Domänen und -Vertrauensstellungen" per Rechtsklick ganz oben. Gruß, Nils

Moin, da gibt es schon diverse Threads, die sich eignen ... etwa diesen hier: Gruß, Nils

Moin, wobei man sich da nie zu sicher sein sollte ... ich habe schon Serverräume mit Sprinkleranlagen gesehen. Gruß, Nils PS. und leider war ich nicht dabei, aber der Kunde hat es hinbekommen, die auch ohne Feuer auszulösen.

Moin, naja, solange es geht, spricht schon einiges dafür. Sehr simples Backup, sehr simples Recovery. Ich würde daher auch schauen, ob ich daran festhalten kann. Kann nur eben sein, dass es nicht mehr passt. Abgesehen davon, dass ich dem Snapshot-Fanatismus von NetApp-Anhängernwendern nichts (mehr) abgewinnen kann, könnte es in diesem Fall durchaus sein, dass genau dieses Szenario platzeffizienter ist. Denn tatsächlich liegen die BLOB-Daten hier ja als einzelne Streams (also Dateien) im Dateisystem. Das könnte die NetApp-Vorteile anwendbar machen. (Ist aber nur spekuliert.) Ob sich daraus dann ein brauchbares Verfahren für Tests usw. ergibt, steht aber auf einem anderen Blatt. Aber lass dir aus Erfahrung gesagt sein: Auch Kunden ohne NetApp und deren Snapshots können sehr effizient mit Testsystemen arbeiten. Die Zeit- und Platzvorteile bei NetApp sind meist eher theoretisch und wirken nicht als Nachteile für Systeme, die das anders machen. Wie gesagt: Kann man nicht, ergibt aber auch bei einem Verweis-System (wie bei dem anderen DMS) in Wirklichkeit nur sehr eingeschränkt Sinn. Ich würde mich einfach darauf einlassen und schauen, wie ich damit umgehe, statt die Energie in Widerstand zu legen. Nur meine 0,02 EUR. Gruß, Nils

Moin, in der c't mutmaßte man neulich, dass es eine neue Zweiteilung gibt. Die Frühjahr-Version wäre dann ein Upgrade mit Neuinstallation, die Herbst-Version käme als Updatepaket. Allerdings - selbst wenn Microsoft das so beschlossen hätte, wäre damit nicht gesagt, dass der Vorsatz auch hält. Gruß, Nils

Moin, auch hier kommt es darauf an, welches Ziel man denn damit verfolgt. Mir scheint es, als hättet ihr falsche Vorstellungen davon gehabt. Was wäre denn das Ziel gewesen? Und wie sind die Anforderungen insgesamt? Das ist zwar nur begrenzt ein Forenthema, aber vielleiecht lässt sich ja ein wenig Licht reinbringen. Gruß, Nils

Moin, wie immer muss man dazu die Rahmendaten und die Anforderungen kennen. Nur dann kann man ein passendes Recovery-Konzept entwerfen. Jedenfalls ist es rein technisch betrachtet beim Backup kein Unterschied zu einer normalen Datenbank. Die BLOB-Daten liegen logisch in Feldern der Datenbank, nur bei Filestream eben physisch nicht in der Datenbankdatei. Das ist für die Datenbanklogik aber transparent. Gruß, Nils

Moin, Naja, kommt drauf an. Ihr sichert den SQL Server so, wie man eben einen SQL Server sichert. Gruß, Nils

Moin, Dazu kann ich öffentlich leider nicht mehr sagen. Und ja, wir arbeiten überregional. Gruß, Nils

Moin, Ich stimme den anderen zu. Es ergäbe keinen Sinn. Die Filestreams sind Teil der Datenbank, nur physisch anders gespeichert. Gruß, Nils

Moin, bei den verschiedenen Upgrade-Vorgängen von Windows 10 hat Microsoft leider schon häufiger Qualitätsprobleme gehabt, die teilweise auch zu Datenverlusten geführt haben. Es ist daher durchaus ratsam, bei einem neuen Upgrade nicht unbedingt der erste in der Welt zu sein, der es ausführt, sondern eine Weile zu warten, ob Berichte über solche Probleme bekannt werden. Meist dauert es dann eine Weile, bis Microsoft Korrekturen dafür hat. Gruß, Nils

Moin, so ein verzögertes Verhalten ist heute typisch für Malware. Es kann auch durchaus sein, dass ihr hier nur die Spitze des Eisbergs seht und in Wirklichkeit eine "richtig große" Malware in eurem System ist. Aus Sicht der reinen Lehre muss jetzt alles neu gemacht werden. Ob das angeraten ist, steht auf einem anderen Blatt - wobei ich damit auch nicht davon abrate. Es wäre vielleicht sinnvoll, einen guten Dienstleister hinzuzuziehen, und zwar schnell. Hier ein bisschen dazu, was wir in solchen Situationen schon gemacht haben: [Hackerangriff, Trojanerausbruch, Lösegeldforderung - und jetzt? - michael wessel Blog] https://www.michael-wessel.de/blog/2019/11/20/hackerangriff-trojanerausbruch-loesegeldforderung-und-jetzt/ Gruß, Nils

Moin, ich habe selbst nie damit gearbeitet, aber es ist nicht so schwer, Informationen dazu zu finden. Kurz: Die normale Backup-Prozedur reicht aus, und auch das Recovery geschieht wie bei einer "normalen" Datenbank. https://www.mssqltips.com/sqlservertip/1854/how-to-backup-and-restore-a-sql-server-filestream-enabled-database/ Gruß, Nils