136248
Jul 03, 2018
3078
23
0
WSUS Installation auf DC wird nicht erfolgreich abgeschlossen
Hallo,
Ausgangslage: 1 DC (Windows Server 2016), 1 Client (Win10), synchronisieren, alles gut, läuft auf VMware.
Problem: Ich habe versucht den WSUS auf dem DC zu installieren, was auch funktionierte, jedoch wurde die erforderliche Nachinstallation nicht erfolgreich beendet, im Log fand sich dann eine Fehlermeldung, es konnte sich nicht zum SQL-Server verbunden werden (siehe Auszug unten). Die Installation erfolgte allerdings ohne explizite Auswahl eines SQL-Servers, ich folgte der üblichen Standardinstallation.
Deinstallation/Neuinstallation, gleiches Resultat, zudem dauerte die erfolglose Nachinstallation fast 2 Stunden.
Mein Eindruck: Es hat mit dem DC zu tun.
Frage 1: Kann es möglich sein dass es tatsächlich am DC lag?
Frage 2: Sollte ich a) sowas prinzipiell auf/über einen Client installieren (in dem Fall Win10), b) gibt es bekannte Stolperfallen bei der Installation von WSUS auf dem Win Server 2016 bzw. seinem Client, und c) wenn ich WSUS auf/über den Client installiere, muss/sollte der DC dann verbunden sein?
Plan: WSUS erneut installieren, diesmal aber auf dem Win10-Client.
Vorschläge, Hinweise, Warnungen?
Danke wie immer im voraus für jeden Hinweis.
Gruß Max.
Ausgangslage: 1 DC (Windows Server 2016), 1 Client (Win10), synchronisieren, alles gut, läuft auf VMware.
Problem: Ich habe versucht den WSUS auf dem DC zu installieren, was auch funktionierte, jedoch wurde die erforderliche Nachinstallation nicht erfolgreich beendet, im Log fand sich dann eine Fehlermeldung, es konnte sich nicht zum SQL-Server verbunden werden (siehe Auszug unten). Die Installation erfolgte allerdings ohne explizite Auswahl eines SQL-Servers, ich folgte der üblichen Standardinstallation.
Deinstallation/Neuinstallation, gleiches Resultat, zudem dauerte die erfolglose Nachinstallation fast 2 Stunden.
Mein Eindruck: Es hat mit dem DC zu tun.
Frage 1: Kann es möglich sein dass es tatsächlich am DC lag?
Frage 2: Sollte ich a) sowas prinzipiell auf/über einen Client installieren (in dem Fall Win10), b) gibt es bekannte Stolperfallen bei der Installation von WSUS auf dem Win Server 2016 bzw. seinem Client, und c) wenn ich WSUS auf/über den Client installiere, muss/sollte der DC dann verbunden sein?
Plan: WSUS erneut installieren, diesmal aber auf dem Win10-Client.
Vorschläge, Hinweise, Warnungen?
Danke wie immer im voraus für jeden Hinweis.
Gruß Max.
Fehlernummer (Error Number):233,Status (State):0,Klasse (Class):20
Schwerwiegender Fehler: Fehler auf šbertragungsebene beim Empfang von Ergebnissen vom Server. (provider: Named Pipes Provider, error: 0 - Kein Prozess ist am anderen Ende der Pipe.)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 378965
Url: https://administrator.de/contentid/378965
Printed on: April 19, 2024 at 19:04 o'clock
23 Comments
Latest comment
Hallo,
wie oft denn noch: Ein DC ist ein DC und sonst nichts!!!!!!! Maximal noch DNS und DHCP.
Sonst hat auf einem Domänencontroller kein weiterer Dienst etwas zu suchen!
Warum ist das so schwer zu begreifen??
Ein Client-Betriebssystem (Win10) ist nicht dazu da, einen Serverdienst (WSUS) im Netzwerk bereitzustellen!!
Jürgen
wie oft denn noch: Ein DC ist ein DC und sonst nichts!!!!!!! Maximal noch DNS und DHCP.
Sonst hat auf einem Domänencontroller kein weiterer Dienst etwas zu suchen!
Warum ist das so schwer zu begreifen??
Ein Client-Betriebssystem (Win10) ist nicht dazu da, einen Serverdienst (WSUS) im Netzwerk bereitzustellen!!
Jürgen
Also einen weiteren Server aufsetzen und WSUS dort installieren?
Zitat von @136248:
Also einen weiteren Server aufsetzen und WSUS dort installieren?
Also einen weiteren Server aufsetzen und WSUS dort installieren?
Hallo.
Ja, definitiv.
Selbst, wenn Deine Vorgehensweise - irgendwie - funktioniert hätte, Du wärst hinterher nicht glücklich geworden, der WSUS frisst Plattenplatz, schneller als Du schauen kannst, selbst dann, wenn nur maßgeschneidert genau die Produkte und Klassifizierungen ausgewählt sind, die Du wirklich brauchst, und auch Treiber und Service Packs dabei weggelassen wurden. Außerdem verbrät er auch nicht wenig Rechenleistung und RAM.
Den eigentlich wichtig(er)en Diensten (AD, DNS, DHCP) auf der Maschine hättest Du jedenfalls keinen Gefallen damit getan, und irgendwann hättest Du nur noch geflucht.
Mir ist klar, daß Dir das eine weitere Serverlizenz aufbraucht, aber so ist das in dem Fall nunmal.
Viele Grüße
von
departure69
Ok dann werde ich das so machen, danke für Eure schnellen Rückmeldungen, ist sehr geschätzt :--)
Moin,
ein WSUS lässt sich auch auf einem DC installieren. Auch bei einem 2016er.
Meines Wissens ist das auch Seitens MS supported, falls sic hdas nicht mittlerweile geändert hat.
Als Best Practice empfiehlt sich natürlich ein eigenener Memberserver.
ein WSUS lässt sich auch auf einem DC installieren. Auch bei einem 2016er.
Meines Wissens ist das auch Seitens MS supported, falls sic hdas nicht mittlerweile geändert hat.
Als Best Practice empfiehlt sich natürlich ein eigenener Memberserver.
Natürlich läuft WSUS auf einem DC. Hat Microsoft mit der SBS Version auch gemacht.
Ist bei mir auch jahrelang auf nem 2008 R2 DC gelaufen. Auf einem 2016 übrigens auch etwa 6 Monate lang.
Warum immer dieses ein DC ist ein DC.....
Nicht jeder hat die Hardware und das Geld für umfangreiche Virtualisierung.
Gruß Looser
Ist bei mir auch jahrelang auf nem 2008 R2 DC gelaufen. Auf einem 2016 übrigens auch etwa 6 Monate lang.
Warum immer dieses ein DC ist ein DC.....
Nicht jeder hat die Hardware und das Geld für umfangreiche Virtualisierung.
Gruß Looser
Moin
Es gibt nicht nur Umgebungen mit hunderten oder gar tausenden Userkonten.
Die große Mehrzahl an Windows-Domänen wird zwischen 5 und 30 Benutzern haben.
Da langweilt sich der DC zu Tode. Dort den WSUS laufen zu lassen ist absolut kein Problem. Ich betreue viele solcher Umgebungen, in manchen ist sogar noch der Exchange auf dem DC (SBS halt).
Zitat von @chiefteddy:
wie oft denn noch: Ein DC ist ein DC und sonst nichts!!!!!!! Maximal noch DNS und DHCP.
Sonst hat auf einem Domänencontroller kein weiterer Dienst etwas zu suchen!
Diese Aussage ist totaler Unsinn und kann nur von Leuten kommen, die nicht selbst für Hardware und Serverlizenzen zahlen müssen.wie oft denn noch: Ein DC ist ein DC und sonst nichts!!!!!!! Maximal noch DNS und DHCP.
Sonst hat auf einem Domänencontroller kein weiterer Dienst etwas zu suchen!
Es gibt nicht nur Umgebungen mit hunderten oder gar tausenden Userkonten.
Die große Mehrzahl an Windows-Domänen wird zwischen 5 und 30 Benutzern haben.
Da langweilt sich der DC zu Tode. Dort den WSUS laufen zu lassen ist absolut kein Problem. Ich betreue viele solcher Umgebungen, in manchen ist sogar noch der Exchange auf dem DC (SBS halt).
@goscho
Stimme Dir zu.
Andererseits: Ist es nicht mehr so, dass man mit einer Standard-Lizenz zwei VM unter Hype-V betreiben darf? Falls doch, dann müsste man nur die Installation ändern. Hardware --> Hype-V --> 2 VM drauf, 1x DC und 1x WSUS.
Oder?
E.
Stimme Dir zu.
Andererseits: Ist es nicht mehr so, dass man mit einer Standard-Lizenz zwei VM unter Hype-V betreiben darf? Falls doch, dann müsste man nur die Installation ändern. Hardware --> Hype-V --> 2 VM drauf, 1x DC und 1x WSUS.
Oder?
E.
Zitat von @emeriks:
@goscho
Stimme Dir zu.
Andererseits: Ist es nicht mehr so, dass man mit einer Standard-Lizenz zwei VM unter Hype-V betreiben darf? Falls doch, dann müsste man nur die Installation ändern. Hardware --> Hype-V --> 2 VM drauf, 1x DC und 1x WSUS.
Oder?
E.
@goscho
Stimme Dir zu.
Andererseits: Ist es nicht mehr so, dass man mit einer Standard-Lizenz zwei VM unter Hype-V betreiben darf? Falls doch, dann müsste man nur die Installation ändern. Hardware --> Hype-V --> 2 VM drauf, 1x DC und 1x WSUS.
Oder?
E.
Das ist korrekt, sofern man auf der VM nicht schon andere Dienste laufen hat, auf die man nun wirklich keinen WSUS mit draufhaben möchte.
Zitat von @emeriks:
@goscho
Stimme Dir zu.
Andererseits: Ist es nicht mehr so, dass man mit einer Standard-Lizenz zwei VM unter Hype-V betreiben darf? Falls doch, dann müsste man nur die Installation ändern. Hardware --> Hype-V --> 2 VM drauf, 1x DC und 1x WSUS.
Oder?
E.
@goscho
Stimme Dir zu.
Andererseits: Ist es nicht mehr so, dass man mit einer Standard-Lizenz zwei VM unter Hype-V betreiben darf? Falls doch, dann müsste man nur die Installation ändern. Hardware --> Hype-V --> 2 VM drauf, 1x DC und 1x WSUS.
Oder?
E.
Klar....kann man so machen. Und wohin dann mit dem Rest? Fileserver, Mailserver und was sonst noch benötigt wird?
In kleinen Umgebung reicht ein ausreichend dimensioniertes Blech ohne Virtualisierung für all das zusammen.
Hallo,
wenn ein Server zum DC hochgestuft wird, werden nicht nur die entsprechenden Dienste installiert bzw. aktiviert. Der Server wird für seine Aufgabe als DC entsprechend konfiguriert. UA. wird der Schreib-Cache der HDDs aus Sicherheitsgründen dektiviert. Das verlangsamt natürlich alle Festplattenzugriffe.
Best Practice und von M$ empfohlen sind nun mal etwas anderes als ausdrücklich verboten.
Ein AD-Netzwerk mit meheren Servern für die unterschiedlichsten Dienste ist etwas völlig anderes als ein SBS-Server, den M$ für diese spezielle Situation der KMUs angepaßt hat. Und wenn ich mich richtig erinnere, war der MS-SQL-Server der einzige Dienst, den man nicht auf dem SBS installieren sollte.
Jürgen
wenn ein Server zum DC hochgestuft wird, werden nicht nur die entsprechenden Dienste installiert bzw. aktiviert. Der Server wird für seine Aufgabe als DC entsprechend konfiguriert. UA. wird der Schreib-Cache der HDDs aus Sicherheitsgründen dektiviert. Das verlangsamt natürlich alle Festplattenzugriffe.
Best Practice und von M$ empfohlen sind nun mal etwas anderes als ausdrücklich verboten.
Ein AD-Netzwerk mit meheren Servern für die unterschiedlichsten Dienste ist etwas völlig anderes als ein SBS-Server, den M$ für diese spezielle Situation der KMUs angepaßt hat. Und wenn ich mich richtig erinnere, war der MS-SQL-Server der einzige Dienst, den man nicht auf dem SBS installieren sollte.
Jürgen
Zitat von @chiefteddy:
Hallo,
Best Practice und von M$ empfohlen sind nun mal etwas anderes als ausdrücklich verboten.
Hallo,
Best Practice und von M$ empfohlen sind nun mal etwas anderes als ausdrücklich verboten.
Wenn es supported ist, sollte es funktionieren.
Aussagen, dass man sowas nicht macht oder gar, dass das gar nicht gehen kann, sind halt einfach falsch.
Hallo @ArnoNymous,
wenn M$ in seinen Best Practice und seinen Schulungsunterlagen ausdrücklich empfiehlt, den DC nicht für andere Dienste zu nutzen, heißt das eben doch, "dass man soetwas nicht macht"! Und das ist dann "halt einfach NICHT falsch".
Und wie sooft im Leben: Nicht alles, was technisch machbar ist, ist sinnvoll.
Jürgen
Aussagen, dass man sowas nicht macht oder gar, dass das gar nicht gehen kann, sind halt einfach falsch.
wenn M$ in seinen Best Practice und seinen Schulungsunterlagen ausdrücklich empfiehlt, den DC nicht für andere Dienste zu nutzen, heißt das eben doch, "dass man soetwas nicht macht"! Und das ist dann "halt einfach NICHT falsch".
Und wie sooft im Leben: Nicht alles, was technisch machbar ist, ist sinnvoll.
Jürgen
Nur das solche Aussagen einen Kunden schnell ein paar Tausend Euro extra kosten für Lizenzen, die definitiv nicht erforderlich sind.
Ausserdem: Wer verkauft denn die Lizenzen? Etwa derselbe von dem die Schulungsunterlagen sind? Ein Schelm, wer böses....
Zum Thema SQL und DC: Eine installierte Version von BackupExec bringt einen SQL Express mit. Das läuft ebenfalls problemlos.
Ausserdem: Wer verkauft denn die Lizenzen? Etwa derselbe von dem die Schulungsunterlagen sind? Ein Schelm, wer böses....
Zum Thema SQL und DC: Eine installierte Version von BackupExec bringt einen SQL Express mit. Das läuft ebenfalls problemlos.
Zitat von @chiefteddy:
Hallo @ArnoNymous,
wenn M$ in seinen Best Practice und seinen Schulungsunterlagen ausdrücklich empfiehlt, den DC nicht für andere Dienste zu nutzen, heißt das eben doch, "dass man soetwas nicht macht"! Und das ist dann "halt einfach NICHT falsch".
Und wie sooft im Leben: Nicht alles, was technisch machbar ist, ist sinnvoll.
Jürgen
Hallo @ArnoNymous,
Aussagen, dass man sowas nicht macht oder gar, dass das gar nicht gehen kann, sind halt einfach falsch.
wenn M$ in seinen Best Practice und seinen Schulungsunterlagen ausdrücklich empfiehlt, den DC nicht für andere Dienste zu nutzen, heißt das eben doch, "dass man soetwas nicht macht"! Und das ist dann "halt einfach NICHT falsch".
Und wie sooft im Leben: Nicht alles, was technisch machbar ist, ist sinnvoll.
Jürgen
Ich kann mich nur wiederholen: es ist von MS supported. Damit erübrigt sich die Diskussion doch eigentlich schon.
Best Practice heißt nicht, dass man es nicht anders machen kann. Denn sonst bräuchten wir für jede gammlige Software nen eigenen Server.
Es beschreibt die beste Lösung, aber nicht die Einzige.
Nunja, die Diskussion wird es wohl immer wieder geben. Jeder wie er möchte oder er es dem Kunden verkaufen kann.
Ich klink mich aus.
1Zum Thema SQL und DC: Eine installierte Version von BackupExec bringt einen SQL Express mit. Das läuft ebenfalls problemlos.
Naja, das als ernsthafte DB-Anwendung zu betiteln ist schon interessant.
Der SQL-Server dient in diesem Fall IMHO nur als bessere CSV, verursacht aber 0.0 Ballet auf der VM.
Wenn wir über DBs reden, die nicht nur zu Backupzeiten gefragt werden, sieht die Sache schon anders aus.
1
Der Schreibcache kann aber wieder aktiviert werden, so bspw. eine USV die Server vor Stromausfällen sichert.
Der SBS hat schon diverse SQL-Instanzen installiert (Sharepoint, WSUS, SBSMonitoring).
Auch kann man weitere dazubringen (ob sinnvoll oder nicht, sei dahingestellt). Die BE-SQL-Instanz ist so ein Beispiel.
MS bot damals jedoch ein Premium-Addon an, was eine W2K8R2 und eine SQL-Server 2008R2 Standard-Lizenz beinhaltete. Das sollte logischerweise auf einem Extra-Server (oder VM) installiert werden.
Zitat von @chiefteddy:
Ein AD-Netzwerk mit meheren Servern für die unterschiedlichsten Dienste ist etwas völlig anderes als ein SBS-Server, den M$ für diese spezielle Situation der KMUs angepaßt hat. Und wenn ich mich richtig erinnere, war der MS-SQL-Server der einzige Dienst, den man nicht auf dem SBS installieren sollte.
Du weißt sehr wenig von KMU-Umgebungen. Ein AD-Netzwerk mit meheren Servern für die unterschiedlichsten Dienste ist etwas völlig anderes als ein SBS-Server, den M$ für diese spezielle Situation der KMUs angepaßt hat. Und wenn ich mich richtig erinnere, war der MS-SQL-Server der einzige Dienst, den man nicht auf dem SBS installieren sollte.
Der SBS hat schon diverse SQL-Instanzen installiert (Sharepoint, WSUS, SBSMonitoring).
Auch kann man weitere dazubringen (ob sinnvoll oder nicht, sei dahingestellt). Die BE-SQL-Instanz ist so ein Beispiel.
MS bot damals jedoch ein Premium-Addon an, was eine W2K8R2 und eine SQL-Server 2008R2 Standard-Lizenz beinhaltete. Das sollte logischerweise auf einem Extra-Server (oder VM) installiert werden.
Hier besteht doch nicht das - durchaus zu diskutierende - Problem, daß ein DC idealerweise ein DC und nichts anderes sein sollte, wenn man an Lics und HW nicht sparen muß, sondern, daß es speziell um einen WSUS geht. Und daß der ein übler Ressourcenfresser ist oder spätestens nach wenigen Jahren sein wird, selbst dann, wenn man ihn sparsamst konfiguriert hat (Produkte und Klassifizierungen), ich denke darüber herrscht einigermaßen Einigkeit. Das Systemhaus, daß die hiesige Umgebung allein betreut hat, bevor ich hier eingestellt wurde, hatte auch einen SBS installiert. das erste, was die damals vom SBS ausgelagert hatten, war: WSUS. Danach lief der SBS wieder einwandfrei, wie mir die Techniker erzählt haben.
Ich bleibe - nur speziell bei dem geschildertem Problem bzw. der Fragestellung des TO - dabei, daß ich einen WSUS nicht auf den DC mit draufhocken würde. Über Dateideinste, Druckdienste oder anderes wenig rechen- und RAM-Ressourcen-Intensives auf einem DC würde ich durchaus mit mir reden lassen, aber nicht beim WSUS.
VG,
departure69
Ich bleibe - nur speziell bei dem geschildertem Problem bzw. der Fragestellung des TO - dabei, daß ich einen WSUS nicht auf den DC mit draufhocken würde. Über Dateideinste, Druckdienste oder anderes wenig rechen- und RAM-Ressourcen-Intensives auf einem DC würde ich durchaus mit mir reden lassen, aber nicht beim WSUS.
VG,
departure69
Zitat von @departure69:
Hier besteht doch nicht das - durchaus zu diskutierende - Problem, daß ein DC idealerweise ein DC und nichts anderes sein sollte, wenn man an Lics und HW nicht sparen muß, sondern darum, daß es speziell um einen WSUS geht. Und daß der ein übler Ressourcenfresser ist oder spätestens nach wenigen Jahren sein wird, selbst dann, wenn man ihn sparsamst konfiguriert hat (Produkte und Klassifizierungen), ich denke darüber herrscht einigermaßen Einigkeit.
Was heißt denn Ressourcenfresser?Hier besteht doch nicht das - durchaus zu diskutierende - Problem, daß ein DC idealerweise ein DC und nichts anderes sein sollte, wenn man an Lics und HW nicht sparen muß, sondern darum, daß es speziell um einen WSUS geht. Und daß der ein übler Ressourcenfresser ist oder spätestens nach wenigen Jahren sein wird, selbst dann, wenn man ihn sparsamst konfiguriert hat (Produkte und Klassifizierungen), ich denke darüber herrscht einigermaßen Einigkeit.
Mein WSUS ist der Hyper-V-Host. Die Datenbank ist auf der VM mit dem SQL-Server 2014 Standard und der WSUS-Ordner auf einem per ISCSI angeschlossenen Pfad.
Ich sehe auch keine WSUS-Installationen bei meinen Kunden, die viel RAM oder CPU brauchen. Einzig der Festplattenspeicher kann schnell knapp werden.
Edit:
Mal was zum TO:
Den WSUS kannst du nicht auf einem Windows 10-PC installieren. Das geht nur auf einem Server.
Mit WSUS auf W2K16 habe ich keine Erfahrung, jedoch hatte ich selbiges Problem mal bei der Installation auf einem W2K12R2.
Es gibt ein Installationslog, welches den Fehler auswirft. Diesem bin ich gefolgt und habe dann die entsprechenden Ratschläge ergooglet.
Es ging dabei AFAIR um Updates von .NET 3/4/5.
Zitat von @departure69:
Das Systemhaus, daß die hiesige Umgebung allein betreut hat, bevor ich hier eingestellt wurde, hatte auch einen SBS installiert. das erste, was die damals vom SBS ausgelagert hatten, war: WSUS. Danach lief der SBS wieder einwandfrei, wie mir die Techniker erzählt haben.
Wenn es die Möglichkeit gibt, dann ist es sinnvoll, den WSUS auf einen Memberserver zu bringen. Zumeist ist der SBS durch Exchange, Sharepoint, SBSReporting etc. schon am Rand des Möglichen und die Memberserver eben noch nicht.Das Systemhaus, daß die hiesige Umgebung allein betreut hat, bevor ich hier eingestellt wurde, hatte auch einen SBS installiert. das erste, was die damals vom SBS ausgelagert hatten, war: WSUS. Danach lief der SBS wieder einwandfrei, wie mir die Techniker erzählt haben.
Ich sehe auch keine WSUS-Installationen bei meinen Kunden, die viel RAM oder CPU brauchen. Einzig der Festplattenspeicher kann schnell knapp werden.
Bei kleinen Umgebungen mit nur einen WSUS Server sicherlich richtig.Bei großen Umgebungen mit vielen WSUS-Clients und replizierten WSUS-Servern können die WSUS-Server auch richtige CPU- und RAM-Fresser sein.
Hallo.
Woher hast du diese Weisheit? Ich arbeite seit Jahren für KMUs. Die Frage ist doch, sieht das Unternehmen die IT als lästiges und eigendlich völlig überflüssiges Übel an oder ist sie der Meinung, dass man mit einer "guten" IT auch Geld verdienen kann im "eigentlichen" Geschäft. Wenn letzteres der Fall ist, gibt es auch entsprechende Resourcen, die eine "gute" IT ermöglichen.
Leider ist meistens ersteres der Fall und die Folgen davon kann man zB. in den Analysen zur IT-Sicherheit bei KMUs nachlesen.
Firewall?? Ich habe doch eine Fritzbox!
Und noch einmal: Ein "normaler" Win-Server hat sehr wenig mit einem SBS zu tun. M$ hat den SBS speziell für das Zusammenspielen der unterschiedlichen Dienste auf einem System optimiert. Diese Optimierung hat aber Grenzen: nämlich die Leistungsanforderungen in Abhängigkeit von der Userzahl. Deshalb "Small Business Server".
Jürgen
Du weißt sehr wenig von KMU-Umgebungen.
Woher hast du diese Weisheit? Ich arbeite seit Jahren für KMUs. Die Frage ist doch, sieht das Unternehmen die IT als lästiges und eigendlich völlig überflüssiges Übel an oder ist sie der Meinung, dass man mit einer "guten" IT auch Geld verdienen kann im "eigentlichen" Geschäft. Wenn letzteres der Fall ist, gibt es auch entsprechende Resourcen, die eine "gute" IT ermöglichen.
Leider ist meistens ersteres der Fall und die Folgen davon kann man zB. in den Analysen zur IT-Sicherheit bei KMUs nachlesen.
Firewall?? Ich habe doch eine Fritzbox!
Und noch einmal: Ein "normaler" Win-Server hat sehr wenig mit einem SBS zu tun. M$ hat den SBS speziell für das Zusammenspielen der unterschiedlichen Dienste auf einem System optimiert. Diese Optimierung hat aber Grenzen: nämlich die Leistungsanforderungen in Abhängigkeit von der Userzahl. Deshalb "Small Business Server".
Jürgen
Deshalb "Small Business Server".
Sorry, aber deshalb definitiv nicht. Das hat nur was mit Lizenzen zu tun, nichts weiter. Die ganzen aufgeflanschten Konsolen und "Funktionen" sind nur als Verkaufsargument eingebaut worden, damit eben "jeder Handwerker" ganz leicht sein eigenes Windows-Netzwerk aufbauen kann.
