Dunkelmann

Moin, ich würde diesen Punkt nicht nur dem Verhältnis PC:User festmachen, sondern zunächst eine Aufstellung aller aktuellen (und künftigen) Geräte machen. Smartphones, Tabelts, Multifunktiongeräte (Scan2Mail, Scan2SMB), die Stechuhr (SMB Zugriff), private Geräte usw. - für das ganze Zeugs brauchst ggf. einen CAL. Ein weitere Aspekt könnte die Umlage der Kosten für die CALs sein: Device-CAL=Sachkosten(meistens = IT), User-CAL=Personalkosten (=Fachabteilung) Wenn man einen User-CAL (oder die SA) ins Verhältnis zum Jahresbruttogehalt setzt, sieht es im Vergleich zu einem Device CAL für ein € 150,- Multifunktionsgerät sehr preiswert aus ;)

Bist zufällig als Domain Admin etc. unterwegs? Da wird in der Standardeinstellung das Kennwort nicht auf einem RODC gespeichert. Daher ist der Anmeldeserver dann ein 'echter' DC Schau dir mal die Kennwortreplikationsrichtlinie für den RODC an. Falls jemand in einer 'verweigern' Gruppe ist wird sein Kennwort nicht repliziert, auch wenn es durch eine andere Gruppe erlaubt wird. Ein RODC ist kein autorisierender Nameserver für die Zone

Moin, grundsätzlich sollte der Hersteller der Anwendung immer der erste Ansprechpartner für solche Themen sein. Falls dieser nicht verfügbar ist, wäre es hilfreich, wenn Du uns mitteilst um welche Anwendung es genau geht.

Moin, die Konfiguration von Host-OS und VM-OS haben fast nichts gemeinsam - außer dass es sich vielleicht zufällig um das gleiche Betriebssystem handelt. Würdest Du bei einem Linux fragen, ob der Swap deaktiviert werden soll? Die Konfiguration vom Host OS wird auf den Betrieb als Virtualisierungshost abgestimmt; die Konfiguration des VM-OS wird auf die Bereitstellung der Services, die in der VM laufen, abgestimmt - das gilt nicht nur für die Auslagerungsdatei. Wenn es für Hyper-V die Empfehlung gibt, die Auslagerungsdatei so und so zu konfigurieren, wird es getan Wenn es für Service xyz, der in einer VM läuft, die Empfehlung gibt die Auslagerungsdatei so und so zu konfigurieren wird es getan Werden Abweichungen gewünscht oder ersonnen, sind sie mit belastbaren Argumenten zu begründen

Glückwunsch! Jetzt musst Du nur noch jemanden mit 8.1 zum supporten finden :p :jau:

Ein inplace upgrade vom OS mache ich höchstens in meiner Testumgebung, wenn ich mal zu faul zum Migrieren bin. :cool: Für fast alle MS Services finden sich im Technet Migrationsanleitungen. Selbst bei LOB Anwendungen ist Migrationsfähigkeit mittlerweile ein Auswahlkriteium bei der Beschaffung.

Moin, gute Systemhäuser zu finden kann, je nach Region, ein Problem sein. Wir hatten schon genügend Pappnasen zu Gast, bei denen relativ schnell die heiße Luft raus war. Ich habe darauf direkt bei den einschlägigen Herstellern angefragt, das Projekt skizziert und nach einem Partner in der Region gefragt. Mit diesem arbeiten wir jetzt schon seit mehreren Jahren zusammen.

Eine PKI ist eine definierte Infrastruktur aus technischen und organisatorischen Bestandteilen. Zugrunde liegt eine konkret formulierte Zielsetzung: Identitätsverifizierung durch eine zentrale Instanz in einer hierachischen Infrastruktur (Das Gegenteil davon ist z.Bsp. ein Web Of Trust, wie es bei GPG zum Einsatz kommt. Hier muss jeweils eine Identitsprüfung zwischen den Individuellen Entitäten erfolgen) Zur Identitätsverifizierung gehört das Vertrauen, dass die zentrale Instanz von der die Identität bestätigt wird, interger ist. Eine Zertifizierungsstelle stellt nur Zertifikate aus. In einer PKI ist das nur ein Bruchteil der Gesamtheit - daher die Bezeichnung Infrastruktur ;)

Moin, Du könntest Dir mal opsi oder ocs inventory anschauen: http://www.opsi.org/en http://www.ocsinventory-ng.org/en/

... und welchen Zugewinn bringt Dir der Overhead von separatem Subnetz, Firewall, 'gehärtetes OS' etc. gegenüber einem Server der einfach nur 'Aus' ist? Da kannst Du auch gleich eine Enterprise Root CA auf einem x-beliebigen Server installieren - das ist dann aber keine PKI, sondern nur eine Zertifizierungsstelle. btw. Das I in PKI steht für Infrastructure

Moin, anstelle der Scripts könntest Du es mal mit den GPP (Group Policy Preferences) 'Windows Einstellungen - Dateien' versuchen. Ich verteile Kleinkram wie config-files etc. nur noch damit.

Es gäbe zwei alternative Wege, die Anforderung umzusetzen: Einen eleganten und einen 'nicht so schönen' Der saubere Weg: die CA auf einen Server 2008R2 Enterprise oder 2012(R2) Standard migrieren und die angepasste Vorlage nutzen.Eventuell wird hierfür eine neue Lizenz fällig, aber eine PKI macht man richtig oder gar nicht Der andere Weg: Das Zertifikat über einen Dummy-User mit dem gewünschten Namen anfordern.

Das ist schade, Server 2008(R2) Standard hat als CA einige Einschränkungen: http://technet.microsoft.com/en-us/library/cc730826%28v=ws.10%29.aspx

Moin, Du benötigst dafür eine angepasste Zertifikatsvorlage. Die Standardvorlage 'Codesignatur' verwendet den AD-Benutzer, der das Zertifikat angefordert hat. Dazu gehtst Du in die mmc 'Zertifikatsvorlagen' und dublizierst die Vorlage 'Codesignatur', gibst ihr einen neuen Namen. Im Register 'Antragsteller' aktivierts Du die Option 'Informationen werden in der Anforderung angegeben' In der CA fügst Du die neue Vorlage hinzu. Dann forderst Du ein neues Zertifikat auf Basis der neuen Vorlage an. Hier sollte dann auch der Hinweis erscheinen, dass weitere Informationen benötigt werden. Dann kannst Du unter 'Antagsteller' / 'Allgemeiner Name' angeben was Du möchtest.

Moin, Du möchtest eine Benutzereinstellung auf ein Computerobjekt anwenden? http://www.gruppenrichtlinien.de/artikel/loopbackverarbeitungsmodus-loopback-processing-mode/

Moin, da bleibt Dir wohl nur die telefonische Aktivierung: Eingabeaufforderung -> 'slui.exe 4'

Moin, hast Du eventuell dieses Problem? http://support.microsoft.com/kb/937251/en-us

Moin, schau Dir mal den TLG für RDS an. http://technet.microsoft.com/en-us/library/hh831610.aspx Da wird die Bereitstellung Schritt für Schritt durchgegangen.

Moin, iSCSI sollte soweit geklärt sein, ein VLAN je Subnetz/Pfad. Bei den Cluster und VM Netzwerken habe ich mich an diesem Artikeln orientiert: http://blogs.technet.com/b/keithmayer/archive/2013/04/04/build-a-private-cloud-foundation-networking.aspx http://technet.microsoft.com/en-us/library/hh831738.aspx Da ich iSCSI über dedizierte NICs verwende, habe ich kein Sub- /Teaminterface für's Storage konfiguriert. Als Team Modus verwende ich LACP. Auf dem DataCenter-Team habe ich 3 VLANs; jedes VLAN entspricht dabei einem Subnetz - ein native VLAN für das Host OS (Domänen-Netz, routed) - ein taged VLAN für Cluster (isoliertes Subnetz) - ein taged VLAN für Live Migration (isoliertes Subnetz) Zur Steuerung der Bandbreiten nutze ich QoS Für das VM-/Tenant-Team nutze ich einen Trunk ohne native VLAN Bevor jemand fragt, warum kein native VLAN für VMs? -> 'VLAN hopping' und 'tagging the native VLAN' sind die Suchbegriffe ;)

Moin, Live Migration und Cluster/CSV werden nur von den Cluster Nodes benötigt. Andere Systeme sollen keinen Zugriff auf die Netze bekommen. Da Du auf's Teaming verzichtet hast, wird der Switch zum Single Point of Failure. Im iSCSI hast Du zwar Redundanz durch MPIO, das nützt jedoch nichts, wenn die LAN Konnektivität getrennt wird. Ob der Cluster überhaupt noch lebensfähig ist, hängt davon welche Node gerade welche Ressourcen hält. Wenn Du Pech hast, geht der komplette Cluster beim Ausfall eines Switches down.

Moin, vielleicht gibt es in eurem Unternehmen tatsächlich besondere Bedingungen, die gegen den Einsatz von RD-Gateway und SSL sprechen. Bitte doch den Externen, seine Argumente und Quellen offenzulegen. Wenn er etwas einzuwenden hat, sollte er auch in der Lage sein, es stichhaltig begründen zu können. Den Einsatz eines Wildcard-Zertifikats würde ich als ein mögliches Argument gelten lassen. Es gibt SSL Implementierungen, die als 'unsicher' gelten und nicht mehr vewendet werden sollten.

Moin, zunächst sollte die Firewallablteilung sich mal mit RPC Inspection befassen. Es gibt Firewalls, die RPC können und bei denen nicht pauschal alle Ports geöffnet werden müssen. Dabei sollte möglichst darauf geachtet werden, dass die Firewall neben strict RPC auch benutzerdefiniertes RPC unterstützt. Den AD Standort des Clients kannst Du z.bsp. mit 'nltest /dsgetsite' abfragen Stellt der Unix DNS auch die für's AD notwendigen Service Records bereit? http://technet.microsoft.com/en-us/library/bb727055.aspx

Jedes Konzept macht Sinn, wenn es den Bedarf erfüllt. Ohne einen definierten Bedarf, ist alles nur Kaffeesatzlesen :cool: Hier gibt's ein paar Infos zum Exchange Sizing: http://www.msxfaq.de/konzepte/sizing.htm

Moin, Genau! Ich erfasse alle aktuellen und geplanten Systeme samt deren Spezifikationen bzw. Herstellerempfehlungen in einer Excel Tabelle und schaue was unterm Strich herauskommt. Bei laufenden Systemen greife ich - sofern vorhanden - zusätzlich auf historische Performancedaten zurück. Bei der Planung versuche ich ein Verhältnis von 1 Host Thread zu 4 vCPU für heterogenen Workload umzusetzen. MS gibt zwar bis 1:8 für Server und 1:12 für VDI an, aber ein System sollte man immer mit ausreichend Reserven planen. Dann kommt meistens das Budget ins Spiel und es wird geprüft, wo Komprisse gemacht werden können oder müssen. In den meisten Fällen gibt es Abstriche beim Takt. RAM und Kerne werden eher aufgestockt. Mehr Threads und mehr RAM bedeuten eine höhere VM-Dichte und weniger Datacenter-Lizenzen bei gleicher VM Anzahl - den Faktor sollte man nicht vernachlässigen; besnders wenn man clustern möchte und dazu auch noch SA benötigt.

Moin, Partionierung von virtuellen Datenträgern ist imho kontraproduktiv. Du verlierst dadurch die Flexibilität, die Volumes einer VM nach Bedarf zu vergrößern oder auch zu verkleinern. Mit 3rd Party Tools kannst Du das zwar wieder ausgleichen, aber es verlängert und verkompliziert den Vorgang nur unnötig.