LukasB

Die Sizing-Angaben in Technet sind meistens sehr praxistauglich. Speziell bei den Exchange 2007-Angaben kann ich dir bestätigen das diese so ziemlich hinkommen, um eine gute Konfig abzuliefern. In deinem Fall käme der Technet-Sizing-Guide auf ca. 10GB RAM. Ich. Immer wenn ich vor einem Problem stehe das weder ich mir noch die Kollegen in der Firma sich erklären können. Oder die Nachforschungen ergeben das es sich effektiv um einen Bug handelt. Aber ich wünsche dir viel Erfolg mit deiner Bastelinfrastruktur.

Dir ist schon klar das der Mainstream-Support von Exchange 2003 bereits abgelaufen ist? Wieso migrierst du nicht auf Exchange 2007?

Das ist bei allen Servern die ich kenne möglich. Bei nur 55 Usern? Die Annahme dahinter ist natürlich das im Cached-Exchange Modus gearbeitet wird (d.h. Outlook 2003 oder neuer). Dann reichen die Disks. Falls alle Clients im Online-Modus arbeiten (Terminal-Server), dann sieht die Dimensionierung schnell anders aus. Falls du allerdings auf 100 User wachsen willst würde ich 4 Disks für die DB in einem RAID10 nehmen. Damit hast du genau 8 Disks, was das Maximum der Standard-Konfiguration der meisten 2U Maschinen ist. Die HP DL380 schaffen mit Erweiterung bis zu 16 Disks, IBM's x3650 M2 bis 12. 12GB in 3x4GB dürfte bei einem 1 CPU Nehalem-System die sinnvollste Variante sein. Erzähl.

Erstmal muss ich mich BrainStorm anschliessen - Server kauft man als fertiges Paket bei einem renommierten Hersteller. Grundsätzlich sind die Komponenten die du ausgewählt hast das was man üblicherweise in den 2U-Mainstream-Servern findet - z.B. x3650 M2 bei IBM oder DL380 G6 bei HP. Das ganze gibts natürlich auch immer noch in Towerform. Zwei CPUs halte ich bei 50 Usern für überdimensioniert - die Wahl des E5520 ist allerdings nicht schlecht, da dies die günstigste, voll funktionsfähige 1366-Xeons CPU ist. Diese Entscheidung musst du ja auch bei richtigen Servern treffern. Zwei RAID-Controller sind völlig überdimensioniert. Meist macht es Sinn auf das "Performance"-Modell des Serverherstellers zu upgraden (bei IBM ist z.B. der BR10i das Basismodell ohne Cache und ohne RAID5, und der MR10i das Performancemodell mit optionalem Cache und RAID5). 9 Festplatten sind überdimensioniert - ich denke, bei 50 Usern dürfte die Lösung mit 6 Platten reichen - 2x OS, 2x Log, 2x DB. Dies bringst du auch ohne das es teuer wird in eine 2U-Maschine. Netzteile natürlich redundant auslegen (Bei der kleinen CPU dürften bei HP die 480W-Netzteile reichen - bei IBM kannst du nicht wählen, da sind immer 8xx Watt) - idealerweise an zwei unterschiedliche UPS anschliessen, oder an eine UPS und eine Überspannungs-Geschützte Steckerleiste.

Günstig ist nicht billig - aus meiner Sicht kannst du nicht auf Unterstützung von Leuten mit Erfahrung auf dem Gebiet verzichten - wenn du das tust wird es langfristig teuerer. Wie gesagt, den technischen Teil kannst du sicher problemlos übernehmen. Aber alles Geschäftsspezifische muss von Spezialisten gemacht werden - früher oder später. Und Später wird teuer.

Hallo Steven, So wie es sich anhört sind deine Kenntnisse eher im Bereich Basisinfrastruktur (Windows, Exchange, Office, etc. pp.) angesiedelt denn im Line-of-Business-Bereich. Ich würde dir also vorschlagen das du deinen Bekannten dabei unterstützt einen guten Dienstleister für die ganze LOB-Software auszusuchen, der auch über ein Produkt verfügt das technisch solide ist - also kein Access-Gefriemel, oder Software die SQL Server im 2000er Compatibility-Modus benötigt, und nur bei aktivierter Mixed-Mode Auth funktioniert wenn der "sa" User ein leeres Passwort hat (Alles schon gesehen...). Und dich natürlich um die Basisinfrastruktur kümmerst - für die meisten Startups ist ein SBS 2008 Standard Ideal - falls die LOB-Software auf SQL Server aufsetzt könnte der SBS 2008 Premium auch eine Überlegung wert sein. Gruss, Lukas

Jap, habe bei der 70-685 auch ein Passed.

Nimm doch einfach leise Server - ich habe einen IBM System x3200 M2 unter meinem Arbeitsplatz stehen, den hört man nicht. Rackserver fallen da allerdings flach - die hört man immer.

Das ist ein SBS - Benutze die SBS-Wizards für die Zertifikate, und fummele nicht manuell an Exchange- oder IIS-Einstellungen herum.

DHCP! Mehr habe ich dem Thema nicht mehr hinzuzufügen ;)

Jap :)

Wenn du das sagst gibts wohl keine elegantere Lösung :) Private Key exportieren openssl pkcs12 -in mykey.pfx > out.txt In out.txt den Private-Key heraussuchen (z.B. mittels Notepad++, der Unix LF versteht), den Private Key in key.pem speichern) Das neue CA-Zertifikat in cert.crt speichern. openssl pkcs12 -export -in cert.crt -inkey key.pem -out newcert.p12 Das ganze wieder in Exchange importieren. $secureString = ConvertTo-SecureString "blubb" -AsPlainText -Force Import-ExchangeCertificate -path C:\cert\newcert.p12 -pass $secureString

Hallo Miteinander, Ich steh mal wieder etwas auf dem Schlauch und finde nicht heraus wie ich etwas machen muss. Ich bin gerade dabei unsere Testumgebung für Exchange 2010 vorzubereiten - dafür brauche ich einen neuen SAN-Namen im Zertifikat. Bei unserem Zertifikatsprovider konnte ich das neue Zertifikat auch problemlos beantragen und habe nun eine neue .crt Datei für denselben Private Key aber mit neuem SAN-Namen. Also hab ich mal naiv probiert dieses .crt File mit Import-ExchangeCertificate zu importieren, was auch geklappt hat. Aber das anschliessende aktivieren mit Enable-ExchangeCertificate klappt nicht. Okay, also flugs im certmgr.msc angeschaut. Das alte Zertifikat ist drinnen und hat auch einen kleinen Schlüssel der anzeigt das ein Private Key vorhanden ist. Beim neuen Zertifikat wird aber nicht angezeigt das ein Private Key vorhanden ist - anscheinend muss ich Windows noch irgendwie mitteilen das die Zertifikate zusammengehören. Was ich gefunden habe ist die Option "Renew this certificate with the same key", aber dort wird gemeckert das "The request contains no certificate template information", eine Fehlermeldung die darauf hindeuted das die Funktionalität für Windows-Online CAs gedacht ist und nicht für Third-Party CAs. Nun, ich hab jetzt zwei Lösungsansätze aber die find ich beide nicht so elegant - das Zertifikat Rekeyen, und dann das neue Zertifikat benutzen. Oder mittels OpenSSL in einem exportieren PFX das Zertifikat ersetzen und das PFX-File wieder importieren. Kurzfassung: Wie ersetze ich ein Zertifikat, sodass der alte Private Key weiterverwendet werden kann?

CPU-Affinity wird im Taskmanager auf Prozess- und nicht auf Thread-Ebene vergeben. Wenn du also einem blah.exe eine Affinity auf Core 1 gibst, und blah.exe aus 5 Threads besteht, laufen nachher alle 5 Threads auf Core 1.

Ein Produkt namens "Forefront Server Security" gibt es nicht - meinst du evtl. Forefront Client Security?

Windows 7: Microsoft Listens To Intel, Finally - Review Tom's Hardware : Intel Core i5 And Core i7: Intel?s Mainstream Magnum Opus Die Anzeigen des Taskmanagers solltest du nicht überbewerten. Diese sind lediglich eine graphische Annäherung an das was effektiv passiert.

Enterprise ist, nach den Medien die Microsoft so verteilt, immer ein seperates Image. D.h. falls da wirklich immer mit der selben CD installiert wurde ist dort evtl. ein Custom-WIM drauf welches Enterprise + Professional enthält. Wie NilsK schon sagte sind die MAK-Keys für Enterprise/Professional diesselben.

Das Problem wurde in Windows 7 bzw. WS08R2 behoben. Ask the Performance Team : Windows 7 / Windows Server 2008 R2: Core Parking / Intelligent Timer Tick / Timer Coalescing virtualboy : Seeing Core Parking in action

Der Himmel fällt dir auf den Kopf. Was du machen könntest wäre eine Verteilergruppe erstellen. Das würde aber nur die eingehenden Mails verteilen. Lies doch nochmal alle Antworten von Norbert im Detail durch. Vorschläge wie man dein Problem lösen kann hast du ja genügend bekommen.

Na komm - das Ding kostet nichtmal n Tag Dienstleistung...

Geht dir eventuell der Speicherplatz aus Kenne das Phänomen von meinem Laptop, wenn kein Platz mehr übrig ist.

Tun wir intern und bei vielen Kunden. Einige Kunden haben mit uns einen monatlichen Wartungsvertrag der die Installation sämtlicher Updates für von uns supportete Software einschliesst. Einige Kunden machen die Updates selber - da gibts es dann alle Ausblüten - solche die am Patchday sofort alle Updates einspielen (was erstaunlich wenig Probleme ergibt), und solche die einfach garnichts einspielen). Wir lassen auf den Windows-Servern hauptsächlich Microsoft-Software laufen, mit Ausnahmen vielleicht von Antivirus- und Backupsoftware, obwohl wir mittlerweile angefangen haben Forefront Client Security an Neukunden zu verkaufen. Dies macht die Patchstrategie relativ einfach - installieren und sehen was passiert. Bei unserer internen Infrastruktur bin ich da relativ agressiv - einige Server werden sofort mit automatischen Reboot gepatcht (unwichtiges, Semi-Testsysteme), andere eine Woche nach dem Release der Patches. Das einzige Problem in den letzten vier Jahren mit dieser Strategie: http://projectdream.org/wordpress/2009/10/13/kb974571-crypto-api-update-may-break-office-communications-server-2007-r2-installations/ Das gibt es sowieso täglich. Gut, vielleicht in grösseren Betrieben nicht machbar. Ja, wenn am nächsten Tag die Mitarbeiter in die Firma kommen :) Sofort in der Testumgebung (inkl. Autoreboot) und auf unwichtigeren Server per Update mit Autoreboot. Eine Woche später auf den kritischen produktiven Systemen. Microsoft-Updates und kritische, Internetexponierte-Anwendungen einmal pro Monat. So all drei Monate update ich alles Hardwaremässige (Treiber, BMC, RSA, etc. pp.), und im gleichen Zyklus auch Switches, Router, Firewalls, etc. pp.

Ja, unter Umständen. Aber so ist auf jeden Fall klar wo das Problem liegt - ohne sichere Authentifizierung via Zertifikat verschwinden die Mails einfach im Nirvana - und das ist nicht gut.

Viele Asiatische Länder haben transparente Firewalls die die Mails evtl. zu einem Mailserver des Providers umleiten damit diese auf diverse, gegen lokale Gesetze verstossende Inhalte überprüft werden können. Eine einfache Lösung um dies zu Umgehen dürfte die Verwendung von SMTP-TLS sein mit erzwungener Zertifikats-Überprüfung auf dem Client. So wird sichergestellt das die Mails an den richtigen Server übergeben werden.

Nachdem du den Domainjoin ausgeführt hast (aber bevor du die Maschine rebootest) kannst du mit lusrmgr.msc den gewünschten Benutzer bereits in die lokale Administratoren-Gruppe hinzufügen. Eine erneute Anmeldung ist nicht notwendig.