Marco31

Es gibt für alles einen "Würgaround" ;) Ok, nochmal nachgeschaut. Es hier tatsächlich nur um QoS, also Priorisierung innerhalb des Anschlusses. https://geschaeftskunden.telekom.de/startseite/festnetz-internet/tarife/internet-telefonie/289950/deutschlandlan-connect-ip-internetanschluss-fuer-firmenkunden.html

Also mit der Traffic-Priorisierung werben manche Anbieter sogar, z.B. Telekom, Vodafone... Die Verfügbarkeit muss schon entsprechend hoch sein wegen der Rechenzentrum-Anbindung. Es geht niemand pleite wenn die Leitung mal ein paar Stunden oder gar nen Tag nicht läuft, aber macht natürlich nen miesen Eindruck gegenüber Bürgern/Kunden. Und die Mitarbeiter drehen Däumchen. Tja, die benötigte Bandbreite. Für das "Tagesgeschäft" würden ca. 4-6 Mbit durchaus genügen. Wenn dann aber der monatliche Patchday oder ein anderer Download im Bereich von mehreren GB ansteht reicht das dann halt nicht mehr wirklich... @Testperson: Hört sich nicht schlecht an mit der Leitungs-Teilung. WSUS haben wir schon im Einsatz, ist aber trotzdem jedes mal der ganze Vormittag Download-Zeit

Bei der bisherigen Leitung sind größere Downloads (ISO's, Patchday, etc.) das Problem. Die Kollegen mit den Rechenzentrums-Anwendungen beschweren sich eh schon dass es teilweise recht langsam läuft, bei großen Downloads meinerseits wird's dann noch schlimmer. Und bei 4-6 GB jeden Patchday ist jedes mal die Leitung für den ganzen Vormittag "dicht". Ja, bis vor einiger Zeit hat es gereicht. Es wurde aber seitens des Rechenzentrums vor zwei Jahren eine neue Anwendung eingeführt, die braucht mehr Bandbreite als die alte. Und die Downloads für den Patchday sind seit Windows 10 auf das doppelte bis dreifache angestiegen. Die 2Mbit-Leitung ist natürlich auch ne symmetrische Standleitung.

Hallo liebes Forum, bei uns steht die Erweiterung der Internet-Leitung an von derzeit 2 MBit auf 10-20 Mbit. Die derzeitige Standleitung wird für die Verbindung mit einem Rechenzentrum (Email-Frontend, Anwendungen über Citrix) sowie für den Internet-Zugang genutzt. Da derzeit bei uns Glasfaser (sozusagen direkt vor der Haustür) ausgebaut wird, bietet sich die Aufrüstung der Leitung an. Jetzt ist aber das Problem, dass Business-Leitungen ("Standleitungen") ja nunmal preislich in einer anderen Liga spielen als der heimische DSL-Anschluss... Darum habe ich jetzt die dankbare Aufgabe, dem Entscheidungsgremium (Gemeindegremium von denen niemand auch nur im Ansatz was mit der Materie zu tun hat) klar zu machen, warum der 40 € Heim-DSL für den Business-Einsatz NICHT reicht. Als Argumente habe ich bis jetzt folgendes: - Symmetrische Leitung mit vollen 10 bzw 20 Mbit im Up- UND Download - Garantierte Bandbreite - Traffic-Priorisierung gegenüber anderen Anschlüssen/Tarifen - Feste IP-Adresse(n) und keine Zwangstrennung - Höhere Verfügbarkeit Wenn ich hier falsch liege oder es noch andere Argumente gibt wäre ich dankbar für jede Antwort :-)

Schau mal auf der veeam Homepage, da gibt's entsprechende Infos was welche Version kann.

Bitte auch bei Veeam beachten was du ggf zurücksichern musst. Beim SQL (und exchange) ist die essentials eingeschränkt.

Wir sichern unsere VM's unter VMWare auch mit veeam. Ist einfach Top!

Ich würde auch nicht unbedingt meinen USB-Stick beim Kunden einstöpseln und dann wieder an Rechnern im eigenen Netz anschließen...

Unser WSUS ist ein 2012 (ohne R2) und verteilt problemlos alle Updates auf die Win10 Clients, durchgängig von 1511 bis 1703. Sollte also nicht am 2012er liegen...

Was ich hier nicht ganz verstehe; warum installiert man ein Update, welches voraussichtlich einen Neustart erfordert, OHNE den Server danach neu zu starten? Klingt für mich ehrlich gesagt nicht so wirklich sinnvoll. Wartungszeit einplanen, Patch installieren, Neustart, fertig.

Gelöscht, war Mist, sorry.

Ich kann auch bestätigen dass Netzlaufwerke unter Windows 10 problemlos funktionieren. Wird bei uns per GPO verbunden. Sollte also eher an eurer Konfiguration liegen...

Gehen tun die schon, nur die Schrift ist halt teilweise "anders" :D

Ich bin kein Dienstleister, aber ich hoffe einfach mal dass nicht du das dem Kunden verkauft hast...

Moment, kurze Frage noch. Auf dem "alten" SQL ist SharePoint in einer separaten Instanz. Muss ich dann beim Alias setzen für den Namen des "alten" Servers auch die Instanz angeben à la vmsql\SharePoint? Das würde erklären warum der Alias nicht funktioniert. Scheint die Angabe der Instanz beim Alias für den "alten" Server gewesen zu sein, jetzt läuft's. Eigentlich ziemlich logisch wenn ich so drüber nachdenke... :shock: Es sind halt manchmal die einfachsten Dinge.

So, kleine Rückmeldung. Die Sache mit dem Konfigurationsassistenten war eigene Dummheit... Der Account mit dem ich mich eingeloggt hatte war nicht entsprechend berechtigt, mit dem SharePoint Setup-Account funktioniert der Assi. Maxdop=1 war für die neue SP-Instanz nicht gesetzt, habe das jetzt nachgeholt und werde testen ob der Umzug nach Änderung der Einstellung funktioniert. Leider hatte der Umzug auch mit aktiviertem maxdop=1 keinen Erfolg. Ich bekomme nach starten der SharePoint-Dienste statt der SharePoint-Seite nur folgenden Fehler angezeigt (Bild1) Auf Bild2 und Bild3 habe ich mal die Einstellungen am SQL für die Instanz und am SharePoint für den Alias angehängt... Sollte eigentlich richtig sein. Fällt noch jemandem was dazu ein?

Ok, das ist ein guter Anhaltspunkt. Werde ich probieren, vielen dank schonmal!

Ja, hatte ich eben mal gegoogelt. Wenn ich's richtig verstanden habe verursacht Maxdop ungleich 1, dass die DB's nicht richtig angelegt werden. In meinem Fall wurden die Datenbanken aber aus einer Sicherung wiederhergestellt.

Die Sharepoint Farm wurde erst vor ca. zwei Wochen auf den aktuellsten Patch-Stand gebracht. Maxdop dürfte NICHT auf 1 stehen (kann ich erst morgen nachschauen), aber die DB's sind ja eigentlich schon vorhanden da wiederhergestellt...? Oder verstehe ich da was falsch?

Leider habe ich keine entsprechende Testumgebung da, daher die "Operation am offenen Herzen"... Auf den Konfigurationsassistenten bin ich nur gekommen da ja nach der DB-Umstellung SP nicht lief... Auch wenn ich den jetzt nicht brauche, irgendwann brauche ich den und laufen tut er momentan nicht.

Hallo liebes Forum, ich habe Freitag versucht, die Datenbanken unserer Sharepoint Foundation 2013 von einem DB-Server A (SQL 2008 R2) auf einen SQL-Server B (SQL Server 2014) umzuziehen. Ich bin dabei wie folgt vorgegangen: - Alle Sharepoint Dienste am Sharepoint-Server beendet - Datenbanken auf DB-Server A gesichert - Benutzer der Sharepoint-Instanz auf DB-Server A per Script exportiert - Datenbanken auf DB-Server B wiederhergestellt - Benutzer per Script importiert - Am Sharepoint Server per clicgf einen Alias für den SQL-Server angelegt - Sharepoint-Dienste wieder gestartet. Leider war danach die Sharepoint Seite und die Zentraladministration nicht erreichbar - der Konfigurationsassistent meldet, dass er nicht feststellen kann ob eine Farm verbunden ist. Ich habe nur die Möglichkeit, die Farm zu trenne oder den Assi abzubrechen. Habe erstmal abgebrochen. Danach Sharepoint-Dienste beendet, SQL Alias entfernt, Sharepoint Dienste wieder gestartet. Die SharePoint-Seite und die Zentraladministration sind jetzt wieder erreichbar, verbunden mit DB-Server A. Der Konfigurationsassistent liefert immer noch den Fehler, dass er die Farm nicht findet. Habe das ganze dann erstmal so gelassen, da ja SharePoint zumindest wieder läuft und die Zentraladministration auch keine Fehler auswirft. Jetzt ist für mich die Frage: Was passiert wenn ich die Farm trenne? Kann ich diese dann wieder ohne Datenverlust verbinden? Wie kann ich den Umzug der Datenbanken bewerkstelligen? Bin für jede Hilfe dankbar :-)

Ich habe nach dem gestrigen Update den Cache-Modus wieder eingeschaltet, bis jetzt scheint die Suche wieder zu funktionieren.

Super, das höre ich gern! Vielen Dank für die Hilfe!

Ok... Was bedeutet das jetzt für meine Idee Instanz SQL Server 2014 und 2016 mit einer Server-Lizenz auf einer Server Maschine...? Vielleicht ist's ja nicht so gut rüber gekommen; ich möchte mit der vorhandenen SQL-Server 2016 Standard Lizenz auf einer Maschine eine Instanz SQL Server 2016 und per Downgrade eine Instanz SQL Server 2014 betreiben. Ist das über die Lizenzbedingungen gedeckt oder eher nicht? Ist gar nicht so einfach... ;)

Die Lizensierung ist Server + CAL, ohne SA. Bei der Frage nach Host oder VM-bezogen muss ich grade passen; ich habe 16 Core-Lizenzen Windows Server 2016 Standard, die habe ich einem VMware-Host zugewiesen (der weniger als 8 Cores hat) und habe damit 2 VM's auf dem Host lizensiert. Auf einer dieser VM's habe ich den SQL Server installiert. Die Lizenzen sind übrigens Volumen-Lizenzen aus einem Select Plus Vertrag.