Andre.Heisig

Hallo Daniel, klingt gut, scheint aber keine Änderung zu bringen. Zum Verständnis: Auf dem SBS existiert der Reg-Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EapHost\Configuration" nicht (auch testweises Anlegen da ändert nichts); auf dem betroffenen Client hab ich gemäß Beschreibung das DWORD angelegt, den Wert "0x1" per Copy&Paste eingetragen (direktes Schreiben von "x" geht nicht. Kann da noch ein Fehler liegen?). Fehlermeldung bleibt die gleiche.

Moin zusammen, gibt es bekannte Probleme mit Umlauten im Usernamen, bei Nutzung der SBS 2011 internen VPN-Einwahl? Ich kann unter sonst gleichen Bedingungen mit allen VPN-freigeschalteten Usern eine Verbindung herstellen, nur bei 2 bestimmten nicht: "Es konnte keine Verbindung unter Verwendung des angegebenen Namens und Kennworts hergestellt werden." Ich hab alles mir sinnvoll erscheinende zwischen den "geht"- und "geht-nicht"-Usern abgeglichen, einzig auffälliger Unterschied: Umlaute im Nachnamen. Gruß und Danke. Andre.

Lexware? Dann ist das doch kein Thema: Datensicherung aus der alten Installation, auf dem neuen Rechner eine saubere Neuinstallation und die Daten per Lexware-Rücksicherung wieder reinholen. Alles andere ist doch m.E. ein Riesenaufwand mit ungewissem Ausgang.

Moin. Das Thema Recovery-Test kann man unendlich diskutieren. Mal abseits meiner Entscheidung bzgl. meines eigenen Servers: Ich bin im KMU-Umfeld unterwegs, in der Mehrheit eher K als M. Ich möchte gern den oder die Kollegen kennenlernen, deren Kunden auf folgende Frage mit "Ja" antworten würden: "Ihr habt hier einen (und manchmal wirklich nur DEN einen) Server. Er läuft, das (reine) Backup ist durch Rücksichern von einzelnen Dateien soweit verifiziert. Ich würde jetzt gern das aktuell fehlerfrei laufende System einmal zu Testzwecken komplett recovern. Einen zweiten Server gibts nicht, also muss ich DEN produktiven Server nehmen. Ich ziehe ein Image für alle Fälle, und dann spielen wir den Fall X mit den Bordmitteln des SBS einmal durch. Das kostet einiges an Zeit und Geld, und birgt auch die Gefahr gewisser Ausfallzeiten, falls dabei Unvorhergesehenes passiert. Und sei es "nur" eine falsche Erwartung hinsichtlich der Recovery-Dauer. Seid ihr damit einverstanden?" Du hast recht, Günther hatte es auch schon angesprochen, und hatte auch recht. Keine Diskussion. Ich weise auf die Problematik eines nicht durchgespielten Recovery-Plans tatsächlich bei passender Gelegenheit hin, bekomme aber ausschließlich ein "Nein", und kann das ein Stück weit sogar nachvollziehen. Manchmal ist die Welt halt komplizierter als "recht haben". Back 2 topic: Ich hab den SBS soweit wieder am Rennen, mit ein paar Schönheitsfehlern im Sharepoint. Das Nicht-Wiederherstellen-Können von Exchange und Sharepoint lag an Out-of-Sync der spfarm- und spwebapp-Konten, falls das für andere interessant sein könnte, nach der Korrektur dieses Problems (das vermutlich schon vor dem Crash bestand, da nur noch keine Auswirkungen gezeigt hat; das ist an der Stelle aber reine Vermutung) konnten Exchange und Sharepoint fehlerfrei zurückgespielt werden. Der Sharepoint zickt noch (Http-Fehler 503 beim Öffnen des companyweb), daran setze ich mich heute nachmittag, ggf. mach ich einen neuen Thread dazu auf. Gruß, und einen sonnigen Start in die Woche! Andre Heisig.

Status: Das Recovery der Datenplatte ist irgendwann in der Nacht von gestern auf heute ohne erkennbaren Grund und / oder Meldung abgebrochen. Der SBS stand heute morgen in der Anmeldemaske, die neu hinzugefügte Datenplatte war im System vorhanden, aber nicht mal formatiert ... was immer das Recovery da von Dienstag nachmittag bis Freitag nacht betrieben hat, es war erfolglos. Ich konnte aus der Sicherung das ursprüngliche Volume (mit Verweis auf einige fehlerhafte Dateien) wieder herstellen, allerdings streiken seither Exchange und Sharepoint (und ggf. mehr, das muss sich noch zeigen). Rücksicherung der Anwendungen per Windows-Backup schlägt fehl mit "Fehler beim Vorbereiten der angegebenen Komponenten für die Wiederherstellung: Der Anwendungs-Generator wird nicht ausgeführt." Ich hab bisher nichts brauchbares hierzu ergoogeln können, kann mir jemand hierzu weiterhelfen?

Update: Ich habs mal wirklich "vermessen", nach gut 48h sind jetzt knapp 20% zurückgeschrieben ... rein rechnerisch also eine Restlaufzeit von noch ca. 8 Tagen. Ich seh im Moment auch keine sinnvolle Alternative zum "Aussitzen" ...

Soll mich das jetzt verleiten, einen G8 anzuschaffen, und das Bare-Metal-Recoery auf eine andere Maschine gleich auch noch auszutesten ... :D Nein, im Ernst: Der G8 ist hardwareseitig auch schon wieder eine gute Ecke weiter als der NL40. Hätte ich den nicht da stehen, würde ich sofort zuschlagen, aber - wenn nicht grad die Platte abraucht - reicht mir der NL40 gut aus. Ich überdenke allerdings die künftige Datenablage-Struktur: Vielleicht ist es im Desaster-Fall doch keine gute Idee, die SBS-Datenordner (Exchange, Sharepoint, WSUS, ...) von der System-HDD zu verschieben. Das Gesamtvolumen OS inklusive dieser (bei mir nun ausgelagerten) Daten wäre deutlich geringer, als die nun vollständige Wiederherstellung, und das Restore der Systemplatte vermutlich langsam durch. Den großen Wust an "passiven" Daten (Dokumente, Setups, VM-Images, Acronis-Images, etc.) hätte ich vermutlich sehr viel besser und schneller mit einem schon wieder laufenden SBS zurücksichern können; und selbst wenn das vergleichweise lange dauern würde: Wenn der SBS selber inzwischen wieder im Dienst wäre, wäre das halb so wild. Denkbar. Ich sehe einfach den Acronis-Vergleich, wenn ich das System komplett image: Das ist auch nicht in 2h durch, aber eben auch lange keine 2+ Tage. Eventuell haben die tatsächlich schlicht einen besseren Treiber dabei als die MS Recovery Konsole ...

Moin zusammen, danke fürs "dranbleiben" ... Was willst Du jetzt hören? Dass ich glaube, mit meinem SBS2011 für meine One-Man-Show grundsätzlich ganz gut aufgestellt zu sein, der Luxus aber dann doch nicht soweit geht, dass ich den Server psysisch doppelt vorhalte. Dann würde ein Test aber bedeuten, ein problemlos laufendes System zu restoren, mit den Unabwägbarkeiten, dem Aufwand und der Ausfallzeit, der/die daran hängen ... Ich hab meine Tests darauf beschränkt, mal ein paar sehr große Image- oder VM-Dateien zurückzuholen, das waren auch gut und gerne mal 50GB, und die Laufzeit hierbei im Rahmen des Erwarteten (sicher stemmt ein großer DELL- oder HP-Server solche Mengen in anderen Zeiten zurück, aber wir reden hier über TAGE ... ). Allerdings eben auch mit dem laufenden System drunter und da eventuell mit besserem Treiber-Support. Ungeachtet dessen hast Du mit der Spitze natürlich recht ... ;-) Die Platten sind alle drei in den normalen HDD-Bays, aber es sind (zu dem langsamen AMD-Core) eben auch WD Greens, und damit eher kühle und ruhige als schnelle Modelle. Die Info mit dem Einschub ist aber hilfreich, das war mir bisher nicht bewusst. Das der NL40 nur eine Budget-Lösung ist, ist mir schon bewusst. Aber ein Acronis Image des gesamten Datenpools dauert etwa 8h, inklusive Verifizierung; wenn ich die bisherige Laufzeit und die Statusanzeige grob überschlage, ist das Restore nicht vor Sonntag Mittag fertig ... das ist irgendwie immer noch eine ganz andere Hausnummer. Naja ... we'll see ... ich melde mich nochmal, wenn's was zu melden gibt, und sitze den Spass jetzt notgedrungen eben aus. Bis dahin nochmal Dank an euch beide!

Update: Restore läuft immer noch, inzwischen knapp 20h. Die Datenplatte lt. Statusbalken immer noch bei vielleicht 10% ... es tut sich was, ohne Frage, aber das ist wirklich grottenlahm. Kann ich noch auf einen erfolgreichen Abschluss hoffen, oder wirds Zeit für einen Plan B (den ich aktuell noch nicht wirklich hätte)? Nebenschauplatz: Woran liegts? SATA auf SATA sollte doch an sich einigermaßen fix vonstatten gehen. Das Zeitfenster hier geht aktuell zu Lasten meiner Nerven, das ist dann eben so. Wenn ich mir das Szenario aber im Ernstfall beim Kunden vorstelle (und dort hätte ich mehrheitlich tatsächlich eher USB-Backupmedien, was nach Günthers Aussage ja eher noch langsamer geht) dann kann ich das Windows Backup in der Form nicht als Desaster-Recovery-Strategie empfehlen.

Moin Daniel. Das (tägliche) Backup läuft auf eine (dritte) SATA-HDD, intern, genau wie die OS- und Daten-HDD. Ich sichere monatlich noch auf eine externe HDD, aber diese Sicherung ist nicht aktuell genug. Keine Spiegelung: Bei dem Rechner handelt es sich um einen HP Microserver NL40, ursprünglich war das mal eine "Laborplattform" für SBS2011-Installationen in Komibination mit irgendwelchen Drittprodukten, irgendwann später hab ich die Kiste samt eigener SBS-Lizenz für mich selber produktiv genommen. Der Rechner hat nur ein "Mainboard-RAID", und zu den Dingern habe ich nicht wirklich großes Vertrauen, auch hinsichtlich der Performance. Der SBS läuft auf dem NL40, aber auch ohne Software-Raid schon nicht wirklich flott. Habe mich seinerzeit dafür entschieden, mit einer täglichen Vollsicherung in der Hinterhand das Risiko einzugehen, und bade nun gerade die Konsequenzen aus ... :-) ... Mir waren aber auch die Restore-Zeiten so nicht klar: Ein Acronis-Image o.ä. in der Größenordnung hat man normalerweise nach ein paar Stunden zurückgespielt ... Status: Er sichert noch immer zurück. OS-Platte abgeschlossen, steht jetzt ziemlich zu Anfang der Daten-Platte. Für SATA- zu SATA-Restore kommt mir das unheimlich langsam vor ... ich konnte gestern allerdings noch die beiden "alten" Platten (OS + WindowsBackup) vor dem SystemRestore noch per Acronis weg-Imagen, insofern geh ich (noch) davon aus, dass das einfach so ist, und die beiden Platten nicht auch defekt sind.

Ah. ok. Naja. Wenn das System morgen früh wieder konsistent und stabil drauf ist, kann ich drüber wegsehen.

Moin Günther, danke für die Info. Rücksichern per SBS Konsole geht bisher nicht. Weder die Datenträgerverwaltung noch die Konsole der Windows Server Sicherung lassen sich öffnen (bzw. kommen bis zu einer Anzeige - habs nach 30 Minuten Warten auf beide Snap-Ins abgebrochen). Ich versuche gerade die Wiederherstellung per Boot-DVD. Sicherungssatz wurde erkannt, ich konnte die neue Platte auch als Restore-Ziel angeben, Restore läuft ... allerdings quälend langsam. Seit 2h dran, und bisher keine 10% zurückgesichert. Datenvolumen ca. 300GB OS und 1,5TB DATEN. Ich warte mal ab, wie der Status morgen früh ist.

Moin zusammen, würde gern mal rumhören, wie ein "Desaster-Recovery" am sinnvollsten abzulaufen hätte, ich hatte das Vergnügen bisher nicht. Folgendes Szenario: SBS2011 Standard, Systemplatte OK, Datenplatte abgeraucht. Inhalt der Platte: Alle per Assistent verschobenen SBS-"Inhalte" (Exchange, Sharepoint, WSUS, alles eben), dazu die üblichen Freigabe-Verzeichnisse für Dokumente, etc. Server wurde nach Abtritt der Platte noch einmal neu gestartet, naturgemäß mit reichlich Fehlermeldungen. Problemdiagnose, Server runtergefahren. Neue Platte ist eingebaut, Server noch nicht wieder gestartet. Backup vorliegend von gestern abend 23:00 Uhr. Wie vorgehen? Wiederherstellungskonsole vom Boot-Medium? Ganz normal booten, die neue HDD formatieren und per Assistent alles aus der Sicherung zurückspielen? Oder gibts inbesondere bzgl. der Exchange- und Sharepoint-Datenbanken da besonderes zu beachten? Gruß und Danke vorab! Andre Heisig.

Moin! Ja und Nein. Ich will es noch nicht ganz verstehen: Ich hatte 2 baugleiche, externe USB-Festplatten, eine davon ist wochenlang als Medium fürs SBS-Backup gelaufen, die zweite hab ich in der gleichen Zeitspanne regelmäßiger für Images benutzt, ebenfalls fehlerfrei. Seit dem 28.10. will / kann der SBS ohne für mich nachvollziehbaren Grund plötzlich keine Sicherung mehr auf eine der beiden Platten erzeugen. Witzig ist: Ich kann von der SBS-Backup-Platte problemlos Dateien zurücksichern, die Images der anderen Platte hab ich per Acronis stichpunktartig verifizieren können ... Alles, ausser per Windows-Backup drauf sichern, funktioniert mit den Platten problemlos. Langer Rede kurzer Sinn: Die zu Anfang der Wochen neu gekaufte USB-Platte Nr. 3 wird fehlerfrei "besichert", Problem nicht erklärt, aber gelöst. Danke fürs Mitdenken!

Moin nochmal! Checkdisk führ ich aus, mal schauen. VSS lassen sich erstellen, zumindest konnte ich, als ich den Eingangspost erstellt habe, von beiden Partitionen eine erstellen. Ich hab jetzt noch Controller-Fehler im Eventlog gefunden, könnten zeitlich zum Problem passen. Muss ich mir ansehen, und vor allem klären, welcher Controller gemeint ist (interne oder USB-HDDs).

Hi zusammen! Datensicherungsvolumen: Eine 150er, eine 500er HDD + SystemState, etc. (sofern der separaten Platz belegt, wenn man C:\ ohnehin mitsichert; eingerichtet ist jedenfalls eine Vollsicherung des Systems inkl. der OS- und Daten-Platte.) Die Sicherungs-HDD hat 1 TB, ist wochenlang problemlos gelaufen. Nach Feststellen der Störung habe ich sie gegen eine baugleiche, zweite ersetzt (genaugenommen diese dem Pool hinzugefügt), um einen Hardwarefehler zu prüfen. Diese zweite Platte ist vorher zu Image-Zwecken mehrfach und problemlos im Einsatz gewesen. Edit: Besagte Festplatte gerade nochmal an einem anderen PC formatiert, dann per Windows Backup (nicht SBS Konsole!) als Ziel für eine Einmalsicherung angegeben. Sicherung startet, SystemState ist durch, nun steht das Backup aber bei 22,5 MB von knapp 50 GB Laufwerk C, und seit gut 30 Minuten keinerlei Fortschritt. Passt zu der eingangs beschriebenen "Diagnose": Das Backup steckt offenbar irgendwo fest, daher gibts auch keine Meldungen im Eventlog; es bricht nicht ab, sondern steht einfach "auf der Stelle".

Moin zusammen! Folgene Problemstellung: Seit gut 2 Wochen "klemmt" das Backup eines SBS2011. Äußert sich darin, dass weder per Konsole noch per Windows Backup GUI der Status des letzten Backups ausgelesen werden kann, beide Programme hängen in "Informationen werden aktualisiert", wenn ich's laufen lasse, über Tage hinweg. Ein hartes Trennen des USB-Mediums, auf das gesichert wird, oder ein Server-Neustart lässt mich wieder in die Konsole / GUI, und ich sehe, dass die Backups nicht erfolgt sind. Zugleich scheint das Problem auch das Erstellen und Versenden des SBS-Statusberichts zu verhindern. Inzwischen getan: - neue Festplatte in den Pool aufgenommen und auf die vorhandene abgestöpselt (nicht aus dem Pool entfernt). Keine Veränderung. - Updates geprüft. Zeitnah zum Auftreten des Fehlers habe ich lediglich ein Exchange-Antispamupdate installiert, ansonsten war und ist der Rechner auf aktuellem Patchlevel. - die Sharepoint SP-Nachbearbeitung geprüft. Tatsächlich und wider Erwarten wollte der Sharepoint die Datenbanken angepasst haben. Installation des Sharepoint-SP2 ist schon was her, habe das Prozedere seinerzeit durchgearbeitet, danach liefen die Backups auch; die erneute Notwendigkeit kann ich nicht nachvollziehen, das erneute Beheben brachte im Hinblick auf die aktuelle Backup-Problematik aber nichts. - VSS kontrolliert: Werden auf der OS-Partition wie geplant 2x täglich erstellt. Auf der Datenpartition setzen sie offenbar sporadisch aus, und die Zeitstempel der VSS-Kopien passen nicht immer zum Plan, ich kann sie auf Knopfdruck aber ohne Fehlerhinweis erzeugen. - Windows Eventlogs: ca. 7 Tage lange keine Fehlerhinweise, hier hat das Backup vermutlich etwas länger am Stück gehangen. Seither (ich stoppe eine nachmittags noch laufende Sicherung des Vorabends manuell) Fehler "2155348315", die eher spärlichen Infos im Netz dazu haben bisher aber nicht geholfen. Hat jemand ein paar Ideen, was man noch prüfen oder tun kann? Gruß und Danke! Andre Heisig.

Kann man? Wenn ich die Statusanzeige der SBS-Konsole aktualisiere, blitzt bei anderen Servern als dem SBS selbst (hier ein 2008 R2) kurz "Überprüfung" auf, dann wird aber nichts angezeigt. Kann man die SBS-Konsole dazu bewegen? Gruß und Danke! Andre Heisig.

Ok, verstanden. Dann werd ich's so tun. Danke für die Infos.

für das anstehende DB-Upgrade? Oder um was zu tun? Nein, mein Fehler. Mit Admin Rechten gibts auf die Abfrage das erwartete "True" auf der Shell, d.h. ich würde die Sharepoint-DB mit "PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures" updaten, und dann sollte den Artikeln zufolge das Backup wieder laufen. Werde wohl erst am Freitag abend dazu kommen, das Vorher-Image zu ziehen, melde den Status dann hier zurück.

Hier z.B: http://blog.sbspraxis.de/small-business-server-2011-hardware-anforderungen-p170/

Moin zusammen, nachdem ich schon Monate hier eher nur mitlese, muss ich heute mal selber einen Thread aufmachen. Szenario: Ein knapp 2 Wochen alter SBS 2011, im Laufe der vorletzten Woche alle kleineren Updates geholt, am vergangenen Montag dann Windows 2008 SP1 und Sharepoint 2010 SP2 installiert, seither setzt das (vorher einwandfrei laufende) Backup aus. "Beim Erstellen einer Schattenkopie der zu sichernden Volumes durch den Volumeschattenkopie-Diensts ist der folgende Fehler aufgetreten: "2155348129". Google bringt mich dahin, dass offenbar nach dem Sharepoint-SP die Datenbank noch manuell angehoben werden muss (in meinen SBS-Installationen wird der Sharepoint nirgendwo aktiv benutzt, hier fehlt mir jegliche Fronterfahrung.) Wenn "(get-spserver $env:computername).NeedsUpgrade" auf der Sharepoint-Shell True ergibt, gibts ein auszuführendes Kommando. Ich bekomme allerdings nicht True oder False, sondern die Meldung "Auf die lokale Farm kann nicht zugegriffen werden", und Google gibt hier z.B. fehlende Datenbank-Rechte auf der Sharepoint-DB aus. Edit meint: Hier wird ab und an davon gesprochen, dass dann die Companyweb-Seite nicht gehen würde, was bei mir nicht der Fall ist: Abgesehen vom Backup hab ich keinerlei ungewöhnliches Verhalten auf dem Server bemerkt, wobei auch nur Datei-Shares und der Exchange wirklich in Benutzung sind. Da sich meine Sharepoint-Kenne in engen Grenzen hält, und ich auch weiss, wie "sensibel" der SBS schonmal sein kann: Kennt jemand das Problem? Abgesehen davon, ein Image zu ziehen, bevor das Gebastel losgeht: gibts zum Sharepoint weitere Do's und Don'ts? Muss ich irgendwas besonderes beachten, weil ich von Sharepoint "nackt" direkt auf "Sharepoint SP2" gehe? Gruß und Danke! Andre Heisig.