DocData

Grundsätzlich halte ich es für sehr sinnvoll, wenn Zertifizierungen ein Ablaufdatum haben. Danach kann die jeder weiterhin gerne in den Lebenslauf schreiben, aber sie sind dann halt nicht mehr gültig, keine einfachen Upgradepfade mehr etc. Wo liegt das Problem nach drei Jahren das Upgrade zu machen? Man lernt nie aus, schon gar nicht in unserer Branche. Und mal ehrlich: Wer heute noch meint seinen NT4 MCSE In den Lebenslauf schreiben zu müssen, dem ist eh nicht mehr zu helfen - vor allem, wenn danach nichts mehr kam. Man kann ihn sicherlich informativ aufführen, aber wenn ich keine Folgezertifizierung habe, dann lasse ich ihn weg. Viel wichtiger sind Referenzprojekte.

Glückwunsch zu den bestandenen Prüfungen! Kannst du Projekte vorweisen, die zu den Zertifizierungen passen? Wenn ja, dann würde ich die Zertifizierungen zwar im Lebenslauf auflisten, aber sie in der Bewerbung nicht erwähnen. Wichtiger sind Projektreferenzen, also Projekte in denen du das zertifizierte Knowhow einbringen konntest. Die eigentlichen Zertifikate kannst du der Bewerbung beilegen. Teilnahmeurkunden der Trainingscenter würde ich weglassen, ebenso Sales- oder Dummyzertifikate. Klasse statt Masse... Werdegang, Skills, Zertifikate und Projektreferenzen gehören in den Lebenslau/ CV. Wenn du nur die Zertifikate hast, aber keine Projekte, dann wird es in meinen Augen schwer. Ich will nicht anzweifeln, dass die Zertifkate die Attraktivität erhöhen, aber sehr hart formuliert bist du ein Papiertiger. Schulungsteilnahme und bestandene Prüfung "beurkundet", aber in der Praxis nie angewendet. Da dürfte dir jeder ohne Scheine, aber mit Projekterfahrung die Butter vom Brot ziehen.

Hyper-V Hosts werden gesichert. Je nach Kunde unterschiedlich. Aufwand ist aber um deutlich höher als bei VMware ESXi. Aber auch bei denen wird die Config gesichert.

Grundsätzlich ist es genau so, wie Daniel es beschrieben hat. Du wirst um Downtime nicht herumkommen. Wenn du die Daten per Robocopy o.ä. auf die Volumes des neuen Clusters kopierst, dann brauchst du die LUNs nicht an das neue Cluster hängen. Du wirst aber für einen Übergangszeitraum die doppelte Datenmenge vorhalten und auch sichern müssen (die Backuplösung will mit dem neuen Cluster ja getestet sein...). Am Tag des Changes bennenst du erst den alten Cluster um und gibst ihm eine andere IP. Das sind zwei Ressourcen der Fileserver-Clustergruppe. Anschließend bekommen die Ressourcen in der neuen Fileserver-Clustergruppe den alten Namen (die haben zur Installation einen temporären Namen und eine andere IP als das alte Cluster bekommen). Habe ich x-Mal gemacht, auch mit über 25 TB (mehrere Gruppen in einem Cluster). Noch einfacher wird es, wenn deine Freigaben nicht auf das Cluster direkt zeigen würden, sondern auf ein DFS.

Das ist schon krass... CIDR gibt es sei 1992/93. Solch Equipment gehört schnellstens entsorgt.

Veeam kennt keine Agenten und ist auch nicht dafür gedacht, physikalische Maschinen zu sichern. Veeam ist aber in der Lage SQL oder z.B. Exchange per VSS zu sichern. Schau dir HP Data Protector an. In der Basislizenz sind eine unbegrenzte Anzahl Agenten enthalten. Lizensiert werden Applikationen und Datenbanken, und diese nur pro Server. Wenn du also 20 Server hast und auf zweien davon ein MS SQL und ein Exchange läuft, dann brauchst du nur die Basislizenz plus zwei sog. On-Line Extensions. Wegen dieser Lizenzierung ist es oft günstiger, als vergleichbare Produkte - vor allem bei vielen Backup Clients. Data Protector ist in der Liga EMC Networker, Symantec NetBackup, CommVault Simpana. Also eher über CA ArcServe und BackupExec angesiedelt.

Mach doch Nägel mit Kopfen und installiert die Umgebung neu, sichere die Daten zurück und dann hast du es sauber. Das wird besser sein, als an der krummen Installation zu schrauben.

PPTP kann seit spätestens 2012 problemlos geknackt werden. Es ist grob fahrlässig heute noch auf PPTP zu setzen.

Also grundsätzlich möchte ich dir dringend empfehlen dein Konzept zu überdenken. Eine Idee wäre es, die Server mit privaten IPs hinter einer Firewall zu erreichen, zu denen die Clients dann eine Verbindung aufbauen. Alles andere ist ein ziemlich gebastel und wirkt auf mich sehr naiv gedacht. Hast du die Themen Datenschutz und Datensicherheit mal genauer beleuchtet? Immerhin geht es da u.a. um Buchhaltungsdaten.

Oh, ich bitte untertänigst um Verzeihung euch mit meiner Frage beleidigt zu haben. Leider ist es so, dass Class C Adressen aus dem privaten Adressbereich (RFC1918) auf WAN Interfaces, vorsichtig ausgedrückt, merkwürdig sind. Es ging mir einzig und allein darum, mehr über die Hintergründe deines Konstruktes zu erfahren. Aber um deine Frage zu beantworten hätte es gereicht, sich die Funktion eines Routers vor Augen zu führen. Geroutet wird was bekannt ist. Insofern ist es nur logisch, dass man ungewollte Wege per ACLs schließen muss. Aber ich bitte noch einmal um Verzeihung, deinen Intellekt mit meiner Nachfrage beleidigt zu haben.

Ist das WAN wirklich WAN oder hat es einen bestimmten Grund, dass du private IP Class C Adressbereiche im "WAN" nutzt?

Auch wenn es OT ist: Irgendwas an deiner Rolle als Dienstleister hast du nicht verstanden. Du bist Dienstleister, nicht Mutter Teresa. Deine Aufopferung in allen Ehren, aber wenn der Kunde eine passende Lösung nicht bezahlen will, dann bekommt er halt die, die er bezahlen kann. Und wenn die Murks ist, dann muss er sich einen anderen Dienstleister suchen, der diese verkauft und implementiert. Es mag Kunden geben die so viel Einsatz honorieren, aber der größte Teil der SMB Kunden nutzt sowas eiskalt aus.

Du hast Recht. Den Rest brauchen wir hier tatsächlich nicht zu diskutieren. Ich will dir aber trotzdem auf die zitierte Fragen antworten. Ja, ich bin Dienstleister. Ich bin Freiberufler und ich habe mich schon vor Jahren bewusst gegen das tränenreiche Handelsgeschäft entschieden. Ich verkaufe Knowhow, keine Waren. Wenn man natürlich keine große Kundenbasis hat, dann muss man die Kunden, die man hat, entsprechend gut melken. Ich kann dir nur den gut gemeinten Rat geben, dein Geschäftsmodell und dein Lösungsportfolio zu überarbeiten, statt anderen Leuten oder Herstellern die Schuld zu geben, dass dein Geschäftsmodell/ Lösungsportfolio wegbricht. Genug OT, den Rest gerne per PN.

Hallo, sehr lobenswerter Ansatz! Höre ich ständig von "Dienstleistern". Ahh, da fällt die Maske und das wahre Gesicht zeigt sich. Es geht dir nicht um die beste Lösung für den Kunden, sondern du willst die Lösung verkaufen, die dir dein Überleben sichert. Das ist schon ein kleiner, aber sehr feiner Unterschied. Und ja, ich kann dich verstehen, weil ich genau dieses Verhalten von extrem vielen kleinen IT-Dienstleistern kenne. Du solltest deine Kundenbasis verbreitern und über andere Lösungen nachdenken. Lösungen die deinen Kunden Mehrwerte bieten, statt an einem Konzept zu kleben und es über die Jahre zu konservieren, weil es für dich am bequemsten ist.

Schau mal bei Rittal. Die bauen auch für HP, Dell usw. Im Prinzip tut es da jedes Rack. Von Sexton (http://www.sexton-gmbh.de/Standverteiler.html) habe ich 12U und 21U Racks im Umlauf (für Demos, Labs und Trainings). Günstig, stabil, auf Rollen.

Na ja, bei ITIL würde ich eher von einem Common Practice sprechen. Best ist es schon lange nicht mehr. ;) Jeder Laden meint sich nach ITIL aufstellen zu müssen. Teilweise komplett, teilweise nur in in bestimmten Bereichen. Teilweise werden Prozesse angepasst und eingeführt, teilweise sklavisch aus den Unterlagen übernommen, ob es passt oder nicht. Angesichts der Verbreitung würde ich daher von einem Common Practice sprechen, nicht mehr von Best Practice. Aber das sind nur meine 0,02 €. ;)

Glückwunsch. Was für Modelle sind es konkret geworden?

Hinsichtlich der CPUs wäre es interessant zu wissen, ob die Terminalserverapplikationen eher von mehreren Threads oder von einem hohen Takt profitieren. Wenn der hohe Takt (single thread performance) entscheidend ist, dann solltest du zu den CPUs mit dem höheren Takt greifen. Ich habe leider, gerade im Terminalserverbetrieb, immer wieder Anwendungen gefunden, die von einem hohen Takt profitieren. Das führt zu so kuriosen Konstellationen, dass Terminalserver VMs auf eine bestimmte Gruppe von Hosts im Cluster genagelt werden, da diese CPUs mit einem höheren Takt haben. Die Entscheidung, welche CPU nun zu wählen ist, wird also maßgeblich von den Applikationen diktiert. Hinsichtlich der Platten kann ich meinen Vorrednern nur anschließen: Das wird nix...

Feel free... ;) Ich sehe aber das Problem, dass so eine Sache möglicherweise zu spezifisch bei vielen Kunden gehandhabt wird. Evtl. wird es was, wenn man sich an ITIL Change Management orientiert.

Full Backups mit COPY_ONLY und Log Backups sind auf der Secondary Replica supported. Log Truncating auf der Secondary führt automatisch zu Log Truncating auf der Primary.

Das ist OT. Wir können das gerne per PN weiterführen.

Klar kann man das machen aber zu welchem Preis?! Fasse doch mal den Kostenaspekt ins Auge oder das grundsätzliche Designparadigma KISS. Aber das ist nun wirklich OT.

Falscher Ansatz. Nicht die Features definieren wie etwas gemacht wird, sondern die formulierten Anforderungen. Wenn man sich das Featureset anschaut und dann überlegt was man wie macht, dann kommt sowas raus - irgendwie Murks.

Eine offline CA ist eine VM. Gehärtet, ohne NIC, exportiert und einem entsprechenden Datenträger im Safe lagernd. Sie wird im Prinzip nur benötigt um die Sub CAs ins Leben zu bringen. Allein aus diesem einfachen Grund gibt es kein durchdachtes Requirement, was eine online Root CA rechtfertigt. Wenn ein Kunde als Requirement formuliert, dass die Root CA online sein muss, dann muss man da auch die Risiken gegenüberstellen. Spätestens dann ist die Sache erledigt. Davon ab ist mir in der Praxis keine online Root CA bei einem Kunden bekannt, der das ersthaft so betreibt. Bei allen anderen werden, also die Root CAs online betreiben, werden mit hoher Wahrscheinlichkeit auch die Prozesse und andere Dinge nicht passen. Klassischer Designfehler.

Routing über Server ist keine gute Idee. Das wird nie so schnell wie ein Layer-3 Switch sein. Das solltest du dringend ändern. Optimierungsversuche sind da quasi sinnlos.