Dunkelmann

In kleineren Umgebungen kann eventuell auch ein Controller mit 4 oder 8 GB Cache den Einsatz von SSD sparen.

Es es sehr schwer zu dem Thema pauschale Aussagen zu treffen. Ein zusätzlicher Faktor bei der Auswahl des RAID Levels sollte auch die Gesamtzahl der Platten im Verbund sein. Je mehr Platten, um so höher ist die Wars***einlichkeit, dass eine oder mehrere ausfallen (können). Oftmals gibt es die Empfehlung bei mehr als 10 oder 12 Platten in einem Verbund, RAID 6 einzusetzen um 2 Paritätsplatten zu haben. Durch RAID 6 gibt es auf der anderen Seite aber wieder Performanceeinbußen durch das doppelte Anlegen der Parität. Die Anbindung kann auch zum Flaschenhals werden. Nehme ich iSCSI 1GBE, 10GBE, gehe ich auf FC oder reicht mir SAS? Das schnellste System im Backend nützt nichts, wenn die Daten im Netz nicht durchkommen. Zur eigentlichen Ermittlung des IOPS Bedarfs, kann man im besten Fall auf eigene historische Daten zuzugreifen. Viele Storage Hersteller bieten Monitoring Tools an oder man hat einen Operations Manager am laufen und zieht sich die notwendigen Berichte. Hat man keine eigenen Daten, muss man ein wenig recherchieren und den IOPS Bedarf seiner Systeme anhand von Richtwerten und Empfehlungen schätzen. Dabei ist es im Prinzip egal ob die Empfehlung eines Softwareleferanten sich auf physische oder virtuelle Systeme bezieht. Der IOPS Bedarf ist in beiden Szenarien annähernd gleich. Hat man sich dann für ein System entschieden, sollte man vor dem Produktivsetzen noch ein paar eigene Tests durchführen. Dazu bietet sich zB IO Meter an. Damit kann man sich schöne Jobs anlegen, die individuell auf den zu erwartenden Workload abgestimmt sind. Hat man vorher sauber seine Anforderungen definiert, sich vom Lieferanten schriftlich bestätigen lassen, dass das Storage diese Anforderungen erfüllt, hat man gute Chancen das System notfalls noch auszutauschen, wenn die Performance doch nicht ausreichen sollte.

Mit dem Elektroschrott wirst du nicht weit kommen, falls du vor hast, dich ernsthaft mit Windows Serversystemen zu beschäftigen. Selbst für einen Mediaserver ist so eine Kiste zu schlapp und wird dir kaum mehr liefern als ruckelnde Bilder und krächsendes Audio. Ich hoffe, die Antwort ist nicht zu hart, aber 12-15 Jahre alte Hardware verwenden zu wollen hat schon etwas von Masochismus.

Ich habe mir zum Spielen zwei günstige 2600'er, zwei 1700'er Router und eine handvoll verschiedener WIC, NM und Kabel gekauft. Dazu noch zwei 12 Port Catalyst 2950 Switches. Mir persönlich macht es einfach mehr Spass mit echtem Blech zu arbeiten.

Hallo, jeder von uns hat einmal so oder so ähnlich angefangen. ;) Den 2003'er Server würde ich ganz schnell vergessen und mir zum Üben einen Server 2008R2 und/oder 2008 als 180 Tage Trial von Microsoft herunterladen. Die ersten Installtionen werden ohnehin kaum länger als ein paar Tage oder Wochen überleben. Je nach Hardwareausstattung dann eine einfache kostenlose Virtualisierungslösung für deinen Win7 Desktop (zB Sun VirtualBox oder VMWare Player) Damit kannst du ohne viel Aufwand eine isolierte virtuelle Testumgebung aufbauen und dich mit einigen Grundlagen (Active Directory, DNS, DHCP) vertraut machen. Wenn du noch ein paar Euros über hast, investiere sie in die grünen MS Press Bücher zum Selbststudium. (MCITP SA / MCITP EA) Bei einem großen Online Buchhandel gibt es oftmals Bücher mit kleinen Schönheitsfehlern zu 50% oder weniger des Listenpreises.

Der SBS 2011 verschiebt neue Computer - egal ob Client oder Server - automatisch in die OU für Clients. Das führt bei Servern gerne zu unerwarteten oder auch unerwünschten Nebenwirkungen, da der Server mit den Client Gruppenrichtlinien zwangsbeglückt wird. Einen Mitgliedsserver in einer SBS Domäne würde ich manuell - nach den Domain Join und vor dem Neustart - in die Server OU unter MyBusiness schieben. Alternativ ein Prestaging Konto vor dem Domainjoin in der Server OU anlegen.

Letztlich träget der Kunde die Verantwortung für die Auswahl des neuen Dienstleisters. Du hast keine Geschäftsbeziehung mit dem neuen Dienstleister, sondern nur mit deinem Kunden und bist nur ihm verpflichtet. Die Übergabe würde ich daher einzig mit dem Kunden durchführen und nur ihm die Zugangsdaten aushändigen. Wenn der neue Dienstleister irgentwelche Tools installieren möchte bevor er überhaupt die Umgebung gesehen hat, dreht sich mir schon der Magen um und ich würde mich da komplett raushalten.

Bei uns habe ich dafür einen schutzigen Trick eingesetzt. Es wird 2 Minuten vor dem Job mit eigentlichen Workload ein dummes Skript mit einem Ping an die Gegenstelle ausgeführt. Durch den Ping wird der Dialout Adapter aktiviert und der Rest läuft - meistens - ohne Probleme. Ist nicht wirklich elegant aber manchmal zählt nur das Resultat :cool:

So eine Kompatibilitätsmatrix suche ich schon seit Jahren und habe sie noch nicht gefunden. Es gibt lediglich Hinweise unter den einzelnen Produkten oder in der Knowledge Base. Gerade bei einer hohen Dienstdichte, wie sie bei dir vorgesehen ist, wird es schwierig mit pauschalen Aussagen. Da helfen nur Einzelfallrecherchen und im Idealfall eine Testumgebung.

Ein SBS 2011 kann ohne größere Probleme mit einem Reverse Proxy (TMG) und einem Exchange Edge Transport umgehen. Bei der Unternehmensgröße - Wachstum hin oder her - würde ich dennoch auf einen SBS verzichten und Einzelsysteme als Basis nehmen. Die Konfigurationmöglichkeiten des SBS sind mir persönlich für "größere" Umgebungen etwas zu eingeschränkt.

Bei einem 2008(R2) Lizenzserver kannst du in der Lizenzverwaltung die Zuweisung für den problemmatischen Client einfach löschen. Dann sollte er bei der nächsten Verbindung automatisch eine neue Lizenz bekommen.

WOW :eek: Die Datenträgerwarteschlange zeigt die Anzahl von wartenden Datenträger I/O Operationen auf. Grundsätzlich sollte die Länge der Disk Queue unter 1 liegen. Bei unwichtigen Systemen können ggf. höhere Werte toleriert werden.

Die Performance macht beim RDS wenig Sorgen. Problematisch bei der Kombination mit anderen Diensten sind eher Kompatibilitätsaspekte. SQL Server wird auf Windows Server 2003 oder Windows Server 2008 Terminal Server Application Server nicht unterstützt. Wie's bei Exchange aussieht, kann ich nicht sagen. Es würde mich aber wundern, falls es als unterstützte Konfiguration durchgeht.

Das wäre doch die perfekte Gelegenheit für einen Funktionstest der Backup / Restore Prozedur gewesen. :p

Ein schönes Zitat zur PKI: "Eine PKI besteht zu 95% aus Organisation und nur zu 5% aus Technik" Bevor du über die Platzierung der Server nachdenkst, solltest du zunächst festlegen wie Interne und Externe an ein Zertifikat kommen sollen. Eine CA - insbesondere wenn AD integriert - würde ich nicht in eine DMZ stellen und/oder von außen erreichbar machen. Wenn es sein muss, können Externe auch ihre Zertifikate von einer Stand Alone Issuing CA bekommen. Wichtig sind dabei nur die gemeinsame Root CA und der Verwendungszweck im Zertifikat. Bei einer PKI, die über die Unternehmensgrenzen hinweg eingesetzt wird, sollten unbedingt CP und CPS (Certificate Policies / Certificate Practice Statements) ausgearbeitet und veröffentlicht werden. Im Idealfall stehen dabei Hausjuristen, Datenschutz, Betriebsrat und Audit zur Verfügung. Nutzungverträge mit den externen Teilnehmern sind dabei auch nicht schädlich. Insbesondere Haftungs- und Schadensersatzfragen sollten unbedingt geregelt werden. Erst im Anschluss - nach der Definitionsphase - kann über geeignete technische Mittel zur Umsetzung und ggf. zur Erzwingung der definierten Prozesse nachgedacht werden.

Einen Reverse Proxy einsetzen.

Etwas älter, aber im Prinzip auf deine Situation anwendbar: Configure ISA 2004 as a Network Services Segment Perimeter Firewall - Part 1: Perimeter Network Design Principles and Considerations

Mit angepassten Zertifikatsvorlagen kannst du für fast alles ein Zertifikat anfordern und ausstellen. Ein paar Stichworte dazu wären: Zertifizierungsstellen-Webregistrierung, SCEP, benutzerdefinierte Zertifikatsanforderung über die MMC ... und nicht zu vergessen: die individuelle Handhabung von Zertifikaten und mögliche Einschränkungen bezüglich Hash, Schlüssellänge etc. bei den verschiedenen Gerätetypen. Das Thema alleine kann schon etliche Seite füllen ;) Meine Empfehlung: Brian Komar - PKI and Certificate Security

Die Beibehaltungsdauer wird in der Schutzgruppe definiert und die verwendeten Bänder - mit der zum Sicherungszeitpunkt definierten Aufbewahrungsfrist - werden dieser Schutzgruppe zugeordnet. Die Verbindung lässt sich nur durch Löschen der Schutzgruppe und "Verfallen lassen" der erstellten Bandsicherungen lösen. Im Anschluss muss/kann die Schutzgruppe mit neuen Parametern erstellt werden.

Welches Ergebnis liefert diese Abfrage auf dem PDC Emulator? Welches Ergebnis liefert "w32tm /query /peers" auf dem PDC Emulator Prüfen, warum der Dienst überhaupt beendet war! Sind es eventuell virtuelle Maschinen, die ihre Zeit über den Host synchronosieren?

Zu 1-3: Ein VPN wird idR über eine Firewall bzw. einen VPN Gateway aufgebaut. Hier gibt es einige brauchbare Open Source Lösungen. Als Beispiele: DDWRT, IP Cop, Monowall oder IPFire. Das Freigeben der entsprechenden Applikationsports am Server stellt nur ein Sicherheitsrisiko da, wenn dieser direkt (also ohne Firewall) mit dem Internet verbunden ist. Zu 4: Je nach DB Backend, eignet sich eventuell der SQL Browser von PortableApps. Zu 4.1: Das hängt vom verwendeten DB Backend und der Applikation ab. Für gewöhnlich werden neue/aktualisierte Werte erst verfügbar, sobald die Transaktion auf Datenbankebene vollständig abgeschlossen ist. Für die Rückmeldung an die Applikation könnte man eventuell einen Trigger auf der Tabelle nutzen. Die SQL Experten haben aber bestimmt noch elegantere Lösungen parat. ;)

Ob du das Zertifikat im AD veröffentlichst oder per GPO verteilst ist Geschmackssache. Wichtig ist nur, dass alle Teilnehmer das Zertifikat als "Vertrauenswürdige Stammzertifizierungsstelle" bekommen und das die Sperrlisten überprüft werden können. Ich habe mal kurz meinen Spieker für eine Laborumgebung ausgegraben. Dabei verzichte ich auf eine Veröffentlichung im LDAP und nutze nur interne und externe CDP/AIA per Webserver. Die Scripte und HowTos kommen übrigens aus dem oben genannten Buch. ;) Vor der Installation der Root CA eine Datei "capolicy.inf" ins Windows Verzeichnis packen: [Version] Signature= "$Windows NT$" [certsrv_server] renewalkeylength=2048 RenewalValidityPeriodUnits=20 RenewalValidityPeriod=years CRLPeriod=weeks CRLPeriodUnits=26 CRLOverlapPeriod=weeks CRLOverlapUnits=2 CRLDeltaPeriod=days CRLDeltaPeriodUnits=0 DiscreteSignatureAlgorithm=1 Nach der Installation der Root CA folgendes Skript auf der Root CA laufen lassen. Ob die externen CDP und AIA "xxxx.xxxxx.biz" benötigt werden, sollte vorher unbedingt evaluiert werden. Eine PKI entwirft man für eine Zeit von 5, 10 oder mehr Jahren und da sollte man sich genau überlegen was künftig benötigt werden könnte. :: :: Direkt nach der Installation der Root CA auf der Root CA ausführen! :: :: Define CRL Publication Intervals certutil -setreg CA\CRLPeriodUnits 26 certutil -setreg CA\CRLPeriod "Weeks" certutil -setreg CA\CRLDeltaPeriodUnits 0 certutil -setreg CA\CRLDeltaPeriod "Days" certutil -setreg CA\CRLOverlapPeriod "Weeks" certutil -setreg CA\CRLOverlapUnits 2 :: Apply the required CDP Extension URLs certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3.crl\n2:http://xxxx.xxxxx.biz/CDP/%%3.crl\n2:http://lab-root-ca.labor.test/CDP/%%3.crl" :: Apply the required AIA Extension URLs certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3.crt\n2:http://xxxx.xxxxx.biz/AIA/%%3.crt\n2:http://lab-root-ca.labor.test/AIA/%%3.crt" :: Enable all auditing events for the Root CA certutil -setreg CA\AuditFilter 127 :: Set Validity Period for Issued Certificates certutil -setreg CA\ValidityPeriodUnits 10 certutil -setreg CA\ValidityPeriod "Years" :: Enable discrete signatures in subordinate CA certificates Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1 :: Restart Certificate Services net stop certsvc & net start certsvc :: Publish CRL certutil –crl pause Nach dem Skript können Zertifikat und Sperrliste in die Produktivumgebung transferiert werden. Ich verteile das Stammzertifikat im Anschluss per GPO in meiner jeweiligen Testdomäne.

Den SCCM finde ich etwas überdimensioniert. Für ein einfaches Clientrollout sollte es das MDT (Microsoft Deployment Toolkit) auch tun. Kennst du Stifter-Helfen? Herzlich willkommen bei Stifter-helfen.de! | Stifter-helfen.de - IT for Nonprofits

Ich gehe mal davon aus, dass die passenden Treiber für die Netzwerkkarte installiert sind ;) Zur Wiederherstellung aus einem Share muss der Ordner oberhalb des Ordners "WindowsImageBackup" freigegeben werden. Alternativ kann auch der Ordner "WindowsImageBackup" auf eine USB Platte kopiert und lokal als Quelle für die Wiederherstellung genutzt werden. Funktioniert im Prinzip wie beim DPM: Performing a Bare Metal Restore with DPM 2010 - System Center: Data Protection Manager Engineering Team Blog - Site Home - TechNet Blogs

Die 647 befasst sich mehr mit Strategie und Design. Natürlich liegt der Focus dabei auf der Frage "Mit welcher Microsoft Lösung kann ich die Anforderung am besten umsetzen?" Bei mir waren es viele Fragen zu - Netzwerk, Firewall und VPN - System Center - Identitätsmanagement Dabei ging es nicht so sehr um das "Wie" sondern um das "Was" Du brauchst im Prinzip einen recht guten Überblick über das MS Produktportfolio.