LukasB

Der Lizenzserver muss nicht auf einem DC installiert werden. Unter Umständen muss dann der Lizenzserver jedoch manuell auf allen TS eingetragen werden. Da in deinem Fall nur ein TS existiert ist das weniger ein Problem.

Windows Server 2008 kann Seamless Application Publishing. Inklusive Icons - diese musst du aber manuell verteilen. Windows Server 2008 R2 und Windows 7 werden eine PNAg ääh XenApp Hosted Funktionalität haben.

Die Lösung für das Performanceproblem hast du dir ja schon selber gegeben: Zuwenig Disks: Du brauchst: Mehr Disks (die üblichen 2U Maschinen kannst 2x OS, 2x LOG, 4x RAID10 DB machen - das reicht für die meisten Kleinunternehmens-Datenbanken), 64bit OS damit du mehr RAM ansteuern kannst (kostet nix mehr: Nicht kleckern sondern klotzen - 10GB kosten keine 500 CHF), und natürlich ein Setup das von Microsoft offiziell supported ist (alles andere ist als Dienstleister sehr heikel). – Ja was von beiden? 64bit SQL Server und 32bit TS wäre doch eine gangbare Variante: Evtl. brauchst du dann halt ein paar TS für 30 User (wenn die Applikation viel RAM braucht), aber hier kann Virtualisierung helfen nicht zuviele Physikalische Server kaufen zu müssen.

Dieser KB Artikel beantwortet alle deine Fragen: SQL Server is not supported on Windows Server 2003 Terminal Server application server Ernsthaft: 4GB RAM, 30 TS&SQL User, SQL Server und nur zwei Disks in einem RAID1 - alles auf derselben Hardware. Du brauchst mindestens zwei Kisten: Ein ordentliches Disk-Layout für den SQL Server (Mehr Disks - mehr Performance) und einen seperaten Terminal Server. Beide mit einem richtigen RAID-Controller. Beide in 64bit (wenn möglich).

Das ändert nichts daran das die anderen Mailserver nur ein qmail erreichen. Woran das genau liegt kann ich dir nicht sagen: Mögliche Gründe sind: * Falscher öffentlicher DNS * Falsches Portforwarding * Falsche Firewall-Konfiguration Welcher dieser Punkte es genau ist kannst nur du herausfinden.

Dann kanns auch nicht funktionieren. Beschäftige dich erstmal mit DNS, im speziellen MX Records. Guter Startpunkt findest du hier: MSXFAQ.DE - SMTP und MX

Ja, wie schon gesagt: Ein klarer Indikator dafür dass das Mail garnicht bis zum Exchange kommt - entweder bleibt es bei dem ISP schon hängen weil du keine Relayberechtigung hast, oder aber DNS für die xxx-informatik.de zeigt nicht auf deinen Exchange sondern auf einen qmail-Server der nicht für die Domain die du verwenden willst konfiguriert wurde. Erhältst du, wenn du versuchst das Mail von einem anderen ISP als Chello her zu versenden eine identische Fehlermeldung? Und nochmal die Frage: Was hast du denn für Schritte unternommen damit die Mails an deinen Exchange geroutet werden? DNS-Einträge? Port Forwardings?

Diese Meldung stammt nicht von einem Exchange, sondern von qmail ( qmail mirror selection ). qmail läuft unter Linux (und anderen unixoiden Betriebssystemen). Was hast du denn für Schritte unternommen damit die Mails an deinen Exchange geroutet werden? DNS-Einträge? Port Forwardings?

Also die von dir genannte Lösung kann ja (der Website nach zu Urteilen) nichtmal die Bedingung erfüllen die Mails auf Laptop + PC synchron zu halten...

Und der Kunde muss das auch schnell genug zum Dienstleister streamen können. Davon ausgehend das Backup gern mal trotz Gigabit-Ethernet das am Anschlag ist längert dauert als gewünscht sollte eigentlich klar zeigen dass das ganze übers Internet abzuwickeln eher illusorisch ist. Ein Autoloader/Library kümmert sich um den täglichen Wechsel, exportieren kann man dann auch gerne nach Wunsch - das ist dann dem Kunden sein Bier. Reinigen tun die Geräte im übrigen auch automatisch ;)

Wie wärs z.B. mit Exchange? Microsoft Exchange Server 2007 Kann natürlich ein bisschen mehr als das was du hier beschrieben hast, wie z.B. Kalender und einen Zugriff via Webmail oder auch Push-Mail auf Mobiltelefone. Hervorragende Integration in Active Directory und einwandfreie Zusammenarbeit mit Outlook.

Wieso sollte man das tun wollen? Dämliche Idee - du sparst damit nichtmal Geld. Du kannst auch einfach das selbstsignierte Zertifikat benutzen, welches im internen Netz auch prima funktioniert.

Okay, ihr setzt also eine Konfiguration ein die in jeder Hinsicht schlechter ist als das was euch der Software-Hersteller empfiehlt, und wundert euch dann über miese Performance? Das Interface ist physikalisch dasselbe, der Befehlssatz jedoch nicht. Bei Datenbanken geht es nicht um Sequential Write/Read (wofür die grossen SATA-Platten optimal sind), sondern um eine möglichst hohe Anzahl IO-Operationen pro Sekunde (IOPS) - je geringer die Rotational Latency ist (d.h. desto schneller die Umdrehungszahl der Platte) desto mehr IOPS sind möglich. SAS Platten sind für den Hochgeschwindigkeitsbetrieb in Servern ausgelegt. Im Firmenumfeld eigenen SATA-Platten für Fat-Clients und z.B. als Speicher auf den primär Sequentiell von nur sehr wenigen Quellen zugegriffen wird, z.B. Backups. Software-RAID ist Gebastel. Gut vielleicht für ein Datengrab zuhause oder einen Testserver im Keller, aber nicht für den produktiven Betrieb einer Datenbank in der Firma. Memory hilft in einem SQL-Server im übrigen nichts wenn geschrieben werden muss - synchrone Writes können vom OS nicht gecacht werden (HW-RAID Controller mit BBU können dies aber). Verwende Qualitätshardware von einem renommierten Hersteller (IBM, HP, Dell) und size diese gemäss den Spezifikationen des jeweiligen Softwareherstellers (und eigenen Erfahrungswerten). Dann wirst du in Zukunft nicht mehr in solche Probleme hineinlaufen.

SQL Trigger sind die "Eigenbau"-Lösung - die Replikation wird dann Quasi auf Anwendungsebene realisiert. Das ist ideal wenn nicht alles repliziert werden soll, sondern nur ganz bestimmte Änderungen bzw. Daten. Programmiertechnisch ist das ganze natürlich eine relativ komplexe Sache die grosses Fachwissen erfordert. Die Variante ist keinesfalls besser oder schlechter als die integrierte SQL Server Replikation - die beiden Varianten haben völlig unterschiedliche Anforderungen und völlig unterschiedliches verhalten. Wie Nils schon sagte: Welche der Varianten in eurem Umfeld die richtige ist kann nur jemand beurteilen der die Applikation/Datenbank kennt. Vielleicht einfach noch ein weiterer Vorschlag: Man könnte das ERP-System zentralisieren, und den Zugriff von den anderen Standorten via Published Applications (Citrix, TS08) realisieren. Denn ein ERP-System auf SQL Server Express laufen zu lassen dünkt mich doch eher bastlerisch.

Doch, das ging bereits dem SBS 2003. Unter 2008 gehts immer noch - die Einschränkung ist einfach das alle FSMO Rollen auf dem SBS selber liegen müssen. Ja. Definiere "Nicht so schnell", wieviele User, etc. Im Cached Exchange Modus geht das sehr gut. Wir haben kümmerliche 2mbit Upstream und 10 Leute in einer Aussenstelle. Outlook-Performance ist super, da Cached Exchange. Allerdings ein neues OST anlegen dauert einen guten Tag ;)

Der SBS ist in meinen Augen keine optimale Lösung wenn man über mehrere Standorte verfügt, vorallem in Hinblick auf Server 2008 der einige Zusatzfunktionalitäten für Branch Offices bringt, wie z.B. den RODC. Auch andere Funktionalität die schon länger für Branch Offices praktisch ist wie DFS-R fehlen dem SBS. Grundsätzlich: Wenn du mehrere Standorte hast und eher eine geringe Anzahl Mitarbeiter bedienen musst, dann reicht ein Exchange-Server am Hauptstandort, solange die Clients den Exchange Cached Mode einsetzen. Was für eure Firma die optimale Lösung ist, ist schwierig zu sagen - dazu fehlen auch Details über die beiden Standorte, was diese für Anbindungen haben, welche Dienste du zur Verfügung stellen willst, etc. Wenn du das ganze mit Internal Use Lizenzen lösen willst und ihr sowieso ein IT Dienstleistungsbetrieb (o.ä.) seid, dann würde ich versuchen auf Certified Partner zu upgraden. Dann hast du mehr Lizenzen zur Verfügung.

Erstmal: Mit SQL Server 2000 ist langsam essig: Mainstream Support ist nämlich im 2008 abgelaufen. (Extended Support bis 2013). Please Verify your Location Zwei langsame SATA Festplatten für 30 User? Wer hat denn da das Sizing gemacht? Der Server braucht wohl mehr Platten und mehr RAM. Am besten klärst du da mit dem Hersteller der Software ab was sie für Sizing-Regeln für deren Software hat - das ist nämlich nicht wirklich von der Datenbank-Server-Software selber abhängig, sondern von der Anwendung bzw. dem Datenbank Design. Für 30 User könnte ich mir etwas in der Grössenordnung von 2x 10kRPM OS, 2x 15kRPM Daten (RAID1) und 2x 15kRPM Log (RAID1) vorstellen, das in den meisten Fällen genügen dürfte. Mit perfmon kannst du das herausfinden. Aber du hast zuwenig Disks und zuwenig RAM. Herzig. Dann einfach 8GB RAM in die Maschine und das Problem ist gelöst - die Disks brauchst du das die synchrone Write-Performance auch stimmt. Logischerweise brauchst du dafür ein 64bit OS.

Ich brenne jeweils einfach das Floppy Image auf CD. Div. Brennprogramme bieten das an, das Floppy-Image richtig auf die CD zu schreiben so dass es bootet. Imgburn z.B.

Business InkJet 2800DTN Hat zwei Fächer - eins für 150 und eins für 250 Blätter, jeweils A3 oder A4 möglich.

Wir verwenden Symantec Backup Exec zusammen mit dem Agent für Hyper-V. Läuft problemlos, sogar das GRT-Zeugs. Bei einem TS dürfte dies auch kein Problem sein, allerdings würde ich Datenbank-Server und andere "komplizierte" Systeme über den Gast sichern.

DFS-R ist keine Billiglösung für redundante Fileserver.

Ich würde mal XP SP3 installieren. Auch ne Möglichkeit: Mittels CrashOnCtrlScroll einen Bluescreen forcieren, und den dann mal in WinDbg anschauen.

Schuss ins blaue: Du betreibst die Festplatte nim IDE-Emulation Mode. Nur wenn der Controller auf AHCI-Modus gestellt ist hast du optimale Performance. Einfach mal ins BIOS gucken. Achtung: Umstellen des Controller-Modus erfordert das Windows die passenden Treiber im verein aktiv hat. Dafür gibts auf Google aber auch zahlreiche Anleitungen.

Guck ob mit bcdedit evtl. numproc auf 2 gesetzt wurde.

Smokeping finde ich dafür ganz toll. Ist allerdings primär Linux-orientiert, läuft aber auch unter Windows.