Andre.Heisig

Dann hab ich mich im Eingangspost dämlich formuliert, DAS hier ist die Info, die ich brauchte. Danke euch & schönes Wochenende!

Moin zusammen, danke für die Rückmeldungen. @Norbert: Die Frage nach der Quelle ging nicht gegen Dich; ich muss die Entscheidung gegen einen SBS2011 und die damit verbundenen Mehrkosten bei Standard-Server- und Standard-SQL-Lizenzen beim Kunden zumindest begründen, zumal der vom SBS2003 kommt. Daher meine Frage nach etwas "belegbarem". Bitte nicht falsch verstehen. @all: Vielleicht hab ich mich b***d ausgedrückt: Mir gehts nicht darum, nicht ausreichend Lizenzen kaufen zu wollen, sondern um das Limit des SBS, Benutzer anlegen zu können. Ich habe gedanklich einfach mal "Anzahl CALs lt tech. Spezifikation des SBS" = "maximale Anzahl anlegbarer User" gleichgesetzt, wenn ich von User CALs ausgehe. Oder ist das ein Denkfehler? Ich muss bereits jetzt (Planungsphase!) ca. 70 User berücksichtigen, die zumindest angelegt werden müssten (tatsächlich ist nichtmal die Hälfte jeweils angemeldet). Wenn die CALs "named" sind, müsste der SBS doch dann das Anlegen weiterer Benutzer verhindern, oder nicht? Oder werden die CALs nur für die aktiven Anmeldungen runtergezählt, und ich kann deutlich mehr User anlegen; und nur der 76ste, der sich anzumelden versucht, würde nicht mehr können? Ich bin in einer SBS-Umgebung noch nie auch nur in die Nähe der 75-User-Grenze gekommen, mir fehlt hier der Hintergrund.

Das würde die SBS-Tauglichkeit definitiv beenden. Hast Du eine Quelle für die Info? Die Idee, den Einwahl-Server als Gerät zählen zu lassen, anstelle der sich darauf anmeldenden User, ist vermutlich zu einfach, als dass sie funktionieren könnte, richtig?

Hi zusammen, 1. Frage) wie werden die 75 maximalen User, die der SBS 2011 laut Spezifikation verwalten kann, gezählt: konkurrierend oder namentlich? 2. Frage) die CALs für den SQL des Premium Addons müssen separat gekauft werden, richtig? Auch hier, named oder concurrend? Eine SQL-CAL gilt dann aber für den SQL-Server, für alle vorhandenen Instanzen / Datenbanken, richtig? Hintergrund: Ich muss die (weitere) SBS-Tauglichkeit eines SBS 2003-Ablöseplans abklären; der Kunde hat ca. 20 "echte" Nutzer und derzeit ca. 50, die sich über eine Remote-Lösung (kein RDP, die Nutzer müssen aber im AD angelegt werden) in eine SQL-Datenbank einwählen. Selten mehr als 5 dieser Benutzer gleichzeitig aktiv. Im Netz liest man leider sowhol als auch hinsichtlich der SBS-CALs. Hat jemand eine verlässliche, offizielle Quelle? Gruß und wartungsfreies Wochenende allen! :-)

Ich würde zudem vorher die Aufgabenplanung und das EventLog durchgehen, und kontrollieren, welche geplanten Tasks im angerissenen Abschalt-Szenarion NICHT ausgeführt werden würden. Zumindest das interne Reporting fällt in den Standard-Settings in einen Zeitraum, wo der Server dann nicht laufen würde. Zudem sollte man die tatsächliche Stromersparnis mal grob überschlagen; vielleicht erübrigt sich das Ganze dann.

Geh das hier: http://www.wbadmin.info/articles/how-does-windows-server-2008-backup-work.html mal durch. Windows Backup erzeugt immer ein Vollback, und die Sicherungen davor werden zu Delta's. Eine Vollsicherung erzwingen kann man m.W. nur indem du die Ziel-HDD vorher putzt.

das hier http://www.pcadvisor.co.uk/how-to/windows/3495216/how-fix-corrupt-user-profile-in-windows-7/ schon probiert? Das reine Löschen des Profil-Ordners hilft ab Win7 nicht mehr (oder nicht immer).

Ich hab damals beim Querlesen hier mal einen Blick geworfen, habe auch als Admin keinen Zugriff auf die Red. Folders. Kann allerdings insofern Entwarnung geben: Ich hab kürzlich erst meinen SBS auf eine andere Maschine recovert (per wbadmin, also mit Bordmitteln und VSS), und u.a. dies her im Anschluss explizit überprüft: Ich konnte für meine 2 User keine fehlenden Daten feststellen. Gesichert wird der Kram in jedem Fall und ist auch resore-bar (schönes Wort!).

Im zweiten Screen oben steht, dass mit der Windows Edition kein Domain-Beitritt möglich ist - neu aufsetzen mit einer Pro-Version, oder mit Net use / run as -Scripten so gut wie eben möglich "rundherum basteln". Edit: war natürlich Blödsinn mit dem Neuaufsetzen, ich hatte nicht auf dem Schirm, dass sich Win8 ja upgraden lässt - sorry.

>> Hmm, ich kann mir das nicht vorstellen dass der WSUS auf dem SBS, bzw. der SBS mit einer manuellen Korrektur Probleme haben sollte. Führt bzw. kann dazu führen, dass die SBS -Konsole den Update-Status nicht mehr anzeigt; meldet dann sinngemäß eine "nicht unterstützte Konfiguration". Das hier ist die Anleitung zum Wiederherstellen des SBS-konformen Standards, siehe konkret "manually recover, Punkt 4d: http://technet.microsoft.com/en-us/library/gg680316.aspx (Bitte nicht falsch verstehen: Soll keine Klusc***erei sein; ich kenn die Empfehlung nicht anders und habe beim SBS 2008 selber schon eine abweichende Konfiguration wieder zurückstellen müssen. Ich werd die Tage aber zum Verifizieren meinen SBS 2011 mal bewusst in der Produktliste "verbiegen" und nochmal schauen. Vielleicht kann sich ja einer der SBS-Gurus hier kurz dazu melden ;) ).

Das .274er Update fehlt noch. Ich hols nach, von der Beschreibung her fixt das aber andere Löcher. >> Weshalb brauchst Du bei 8 Clients 8000 genehmigte Updates? Die 8.000 Updates kommen, weil der SBS (konkret: die Update-Statusprüfung in der SBS-Konsole) nicht mehr rund laufen, wenn der WSUS ausserhalb der Standard-Parameter betrieben wird. Dazu gehört auch "alle, auch zukünftige Produkte", sprich ich kann hier nicht wie sonst sinnvoll tatsächlich explizit die Produktlinien wählen, die im Einsatz sind. (Wenn mich einer der SBS-Guru's hier korrigieren mag, gerne! Die Vorgehensweise ist aber meines Wissens die im SBS 2008/2011-Kontext empfohlene). >> Gibt es irgendwelche alten OS-Updates und/oder Office-Updates die abgelehnt werden können? Die 8.000 stehen ja nach (!) dem massigen Ablehnen, bisher per grober Produkt- (Itanium, Internet Explorer <8, Windows < XP, etc.: alles abgelehnt) und Update-Status- Suche (alle ersetzten Updates: abgelehnt). An der Stelle steht aber meine Kernfrage von oben: Was bewirkt Ablehnen hinsichtlich der SUSDB? Abgelehnte Updates werden ja mit dem Status "abgelehnt" weiter in der DB geführt; das dürfte die Datenbank-Größe insofern kaum beeinflussen. Der dadurch frei werdende Platz im Repository ist (hier) nicht das Problem.

Alles richtig, aber das Ausgangsproblem (Timeout-Abbruch beim Bereinigungsassi, und insgesamt spürbar trägere WSUS-MMC) bestand ja eben nicht im Platzbedarf der Updates im Dateisystem, sondern in der DB-Größe! Wie gesagt, in der betrachteten Umgebung verwalte ich die Updates nur per WSUS, die Clients laden aber direkt bei MS (Optionen => Dateien und Sprache => Updatedateien; Randnotiz: diese Abweichung vom Standard-Setting schluckt der SBS 2011 sogar ohne zu Maulen). Die Timeout-Probleme einer ca. 15GB großen WSUS-Datenbank sind gegen Null gegangen, seit die DB nach Bereinigung nur noch <4GB hat. Mein Repository hat sich durch die ganzen Klimmzüge nicht verändert: <15 MB. Wenn ich aber trotz nicht-vorhandenem Update-Repository irgendwann aufgrund der WSUS-Datenbankgröße Performance-Probleme bekomme, muss ich an der Datenbank ansetzen (können). Jetzt stecke ich nicht tief genug in den WSUS-DB-Interna, um beurteilen zu können, ob ein abgelehntes Update dort weniger Datensätze erzeugt/benötigt wird als ein genehmigtes; denn nur dann würde Ablehnen von Updates zu einer Verkleinerung der DB führen. Oder hab ich hier einen grundsätzlichen Denkfehler? Hast Du zum Vergleich mal Eckdaten von einem SBS 2011 WSUS, der ohne explizite Datenbank-Bereinigungen schon eine Weile läuft, und wo der Bereinigungs-Assi noch sauber durchgeht? Anzahl Comuter, Anzahl Updates, Größe Datenbank? Rechner-Eckdaten? Mein SBS: Aufgesetzt Mitte 2012 | 8 verwaltete Computer; 8.000 genehmigte, 3.500 abgelehnte Updates | DB-Größe 3,5 GB. (Vor der Bereinigung ca. 29.000 Updates) Hardware: HP ML-310 v2; XEON@3,1GHz, 32 GB RAM.

Tja ... ich würde sagen: Ausgleich in der zweiten Halbzeit durch den WSUS: Aus den mühselig bereinigten knapp 7.500 Updates in der WSUS-DB sind ohne aktives Zutun schon wieder gute 11.500 geworden. Denkfehler? Wenn man nach obigen Vorschlägen nicht benötigte Updates ablehnt, und dann per SQL-Bereinigung diese Updates aus der DB löscht ... dann müsste der WSUS bei der nächsten Synchronisation doch genau diese Updates alle als noch nicht geladen wiederfinden ... und wieder ziehen? Ich lass das Ganze jetzt mal noch 2, 3 Tage einfach laufen, mir schwant aber dass ich wieder auf den alten Pool der 30.000 Updates kommen werde. Reines Ablehnen (und in der DB belassen) verkleinert die WSUS-DB nicht, ein Ausfiltern der zu (re)syncronisierenden Produkte im Anschluss ans Löschen bringt die SBS-Konsole ja bekanntlich aus dem Tritt. Und nu?

So, Lösung offenbar in Sicht, und sogar recht simpel: Aufräumen! Ich hab gemäß dem dritten Link oben alle abgelaufenen bzw. ersetzten Updates im WSUS gesucht und abgelehnt, definitiv nicht benötigten Updates per manueller Suche (Itanium, ia64, Internet Explorer < Version 8, etc.) im WSUS gesucht und abgelehnt, per Script alle Updates der Kategorie "Treiber" gesucht (gabs bei mir nicht, könnte aber ggf. vorliegen) und ggf. aus der WSUS-DB gelöscht, per Script alle abgelehnten Updates aus der WSUS-DB gelöscht. Das Löschen der Updates per Script lief 5 Tage permanent durch, auch mit regelmäßigen TimeOut-Fehlern. Wiederholung des Laufs nach der ersten "Wäsche" steht noch aus. Update-Pool von knapp 30.000 auf jetzt knapp 9000 Updates reduziert, und die Server-Bereinigung ist jetzt zumindest einmalig wieder durchgelaufen. Beim Ablehnen wäre bei genauerer Analyse der noch vorhandenen Updates sicherlich auch noch Luft, bspw. alte Office-Versionen, etc. Da ich (auch beim "SBS-WSUS" möglich) die Updates nicht im Repository speichere, sondern direkt bei MS ziehe (mein privates Setup; in Standard-Umgebungen handhabe ich das selbstredend anders), ist der Festplatten-Platzgewinn zwar (wie erwartet) überschaubar, aber die WSUS-Datenbank selber läuft nun aber um einiges flüssiger. Lästig ist das Prozedere aber allemal, und der WSUS-Assi bzw. das automatische Bereinigungs-Script von Bent's Blog erledigen das Entscheidende, das Ablehnen nicht (länger) erforderlicher Updates offenbar nicht. @Sunny: Offenbar ist dein Script etwas anders als das von Bent's Blog. Ich sichte beide nochmal auf Unterschiede; eine Mail bekomme ich von meinem aber nicht. Beim Öffnen alter Logfiles hab ich aber inzwischen gesehen, dass das Script zwar durchläuft, aber dort auch schon TimeOut-Fehler geloggt wurden - das hatte ich eingangs nicht bemerkt.

Jepp, das ist ja Bestandteil der "Komplettlösung" von Bent. Habe das Script aber eben auch immer nur in der Gesamtlösung ausgeführt. Bringt mich bisher noch nicht recht weiter; die Timeout-Fehler bleiben. Wie bei BumBum auch: WSUS an sich läuft, nur die Bereinigung nicht. Bisher probiert / überprüft: - Aufräum-Script von Bents Blog - Löschen der Sync-Historie per SQL-Manager (manuell) - Ablehnen aller ersetzen Updates (handisch im WSUS) - Defragmentieren der HDD drunter (geschieht wöchentlich per Task) - Einzelnes Ausführen der Aufgaben des Bereinigungs-Assis (alles ausser Punkt 1 lässt sich in beliebiger Reihe und Kombination ausführen). Ich bleib dran, wenn noch jemand Ideen hat, gerne hier melden.

Später Nachtrag, falls es wen interessiert: Ich hab das gleiche Szenario vor ein paar Tagen nochmal, diesmal allerdings geplant und vorbereitet, abgefrühstückt: Umzug vom HP Proliant N40L auf einen ML310 G8 v2: Ein "recovery-vorbereitetes" Fullbackup vom N40L erstellt (Gesamtvolumen ca. 1,3 TB) mittels der SBS-Setup-DVD auf den ML-310 wieder aufgezogen. Für mich persönlich das erste wirklich echte Bare-Metal-Recovery, und ich bin schwer angetan: Nach ein paar wenigen Stolperfallen, die im Nachhinein aber erklärbar waren, ein echt runder Ablauf. Eine handvoll Treiber nachgeschoben, und der SBS steht mit allem Zipp und Zapp auf völlig anderer Hardware wieder bereit. Laufzeit des Gesamt-Recoverys ca. 10 Stunden, d.h. an der quälend langen Dauer meines damaligen Recoverys war tatsächlich primär die Hardware des N40L "schuld". USB 3.0 und der XEON des ML-310 arbeiten das deutlich schneller ab.

Gerne - Status: Sehr informative Seite => https://thwack.solarwinds.com/community/application-and-server_tht/patchzone/blog/2013/01/21/wsus-timeout-errors--removing-unneeded-update-approvals. Ich arbeite gerade den Part "Ablehnen abgelaufener Updates" ab, damit wäre ich ca. 2.500 von insgesamt ca. 30.000 Updates im WSUS los, der Blick aufs Mengengerüst lässt erahnen: das allein wirds vermutlich noch nicht lösen. Hier: http://wsus.codeplex.com/releases/view/17612 wird ein Weg beschrieben mit unmittelbarem Löschen nicht benötigter Updates im SQL-Manager. Ist mir im Moment noch 1) zu aufwendig (müsste 12.500+ Zeilen/Updates einzeln löschen), und 2) zu wenig transparent.

Dem Screen hier folgend: http://www.a-m-i.de/tips/sqlserver/sqlserver.php Obs was bringt, muss ich noch testen ... Edit: Kommentar war dieser: http://bent-blog.de/automatische-wsus-serverbereinigung-mit-tasks-und-skripten/#comment-20218

Ich hab noch einen Hinweis auf ein Timeout-Setting im SQL-Server gefunden: http://bent-blog.de/windows-server-update-services-wsus-auf-windows-server-2012-mit-automatischer-bereinigung/, einfach mal die Kommentare durchscrollen. Auf dem SBS 2011 / SQL 2008 stehen da im Default in der Tat 30 Sekunden; ich hab das gerade mal deutlich hochgesetzt und teste weiter.

Wie ist denn der Status? Plage mich mit dem gleichen Problem: Das Bereinigungsscript von WSUS.de läuft fehlerfrei durch, der Bereinigungs-Assistent des WSUS streikt beim ersten Punkt der Auswahl (und nur da).

Hi, danke für die Rückmeldung. Es gibt eben keine Meldung in dem Sinne, weder eine Fehlermeldung noch sonstiges; der SBS und auch WBADMIN wähnen alles im grünen Bereich. Wenn ich in der SBS-Konsole die Sicherung anklicke, steht doch im "Fussbereich" der Infoblock; Links Datensicherungs-Elemente und -Zeitplan, rechts Zielmedien. Dort lese ich "Laufwerk C ausgeschlossen", was der Assistent gar nicht zulässt, die Sicherung selber aber bestätigt. Öffne ich den Job per WBADMIN, steht dort auch nur Laufwerk D. Besonderheiten bei der Installation nur eine: Das Volume ist eine dynamische HDD. Ansonsten: Standard-Installation, keine Installationen außer dem SBS und die Konfiguration soweit möglich ganz brav per Konsole. Edit: Ja, auf D: liegen inzwischen User-Dokumente, etc, und eine Handvoll Datenverzeichnisse. Edit 2: Ich hab inzwischen ein WBADMIN-Script per Aufgabenplanung, das sichert wie gewollt alle Laufwerke, inklusive SystemState; benötigt allerdings auch ein weiteres Laufwerk, da das für die eigentliche Sicherung eingerichtete nicht aktzeptiert wird. Das gröbste Problem ist gelöst, die Sicherung steht. Dennoch würde ich dem gern auf die Spur kommen, falls es noch Ideen gibt, was zu tun wäre, immer gerne ...

Moin. Ich pushe nochmal. Status unverändert; niemand eine Idee?

Moin zusammen, vielleicht weiss jemand Rat: Ich hab einen frisch installierten SBS 2011 vor mir, aktueller Patchstand, Netzwerkdienste, Druckserver etc. grundeingerichtet, System noch nicht in Betrieb. Das Backup will nicht, was ich will: Eingerichtet über den Assistenten, Partionen C und D (mehr gibts nicht) dort ausgewählt, (C liesse sich ja auch nicht abwählen), die Konsole spricht aber nach Einrichtung des Jobs schon "C ausgeschlossen" und sichert C tatsächlich nicht. Fatal: Backup wird im Anschluss als "erfolgreich" quittiert, mir kam nur die Laufzeit von 45 Sek. extrem performant vor. Aufruf des "geplanten Jobs" per WBAdmin zeigt auch nur D:\ als zu sichernd an. Ich kann per WBAdmin aber eine komplette Sicherung durchführen, incl. C, SystemState, etc., die läuft auch ohne Fehlermeldung durch, und passt auch vom Volumen und Laufzeit. Denn SBS-Assistent hab ich mehrfach erneut angestossen, dort wird C:\ jedesmal als inkludiert angezeigt, ändert am Ergebnis aber nichts. Edit: Eventlog spricht gar nichts, nur "Backup wurde gestartet", und "Backup erfolgreich abgeschlossen". Edit 2: Die manuelle Sicherung hat zwar C:\ und D:\ gesichert, offenbar aber nicht das BareMetal-Recovery oder den SystemState. Weiterhin keine zielführenden Meldungen im Eventlog. Hat irgendjemand eine Idee? Gruß und Danke! Andre.

Alles Standard nach Assistent-Setup; "VPN-Typ: Automatisch", "Datenverschlüsselung: Erforderlich, Trennen falls Server ablehnt", "Protokolle: CHAP, MS-CAHP v2"

Wäre Windows 7 Pro gewesen. Ich habs jetzt aus Zeitgründen darüber gelöst, den Benutzer umzubenennen... Hätte es lieber "richtig" gelöst, aber der Kunde steht letztlich (berechtigterweise) mit der Frage daneben, wie es am kostengünstigsten zu lösen wäre, und das Umbenennen hat's gelöst.