Dunkelmann

Moin, Bitlocker ist bei laufenden Systemen, wie z.Bsp. einem Server, relativ unsicher. Bei laufendem System befindet sich der Entschlüsselungsschlüssel im RAM und kann abgegriffen werden. Die Zielgruppe von Bitlocker sind mobile Geräte. http://technet.microsoft.com/en-us/library/dn632180.aspx http://blogs.msdn.com/b/si_team/archive/2008/02/25/protecting-bitlocker-from-cold-attacks-and-other-threats.aspx

Moin, ich würde mir mal 'sqlcmd' und 'grant' anschauen. http://msdn.microsoft.com/de-de/library/ms162773.aspx http://msdn.microsoft.com/de-de/library/ms188371.aspx

Moin, für Änderungen am/im AD (Clients hinzufügen, Benutzer- oder Computer-Kennwörter ändern etc.) wird Zugriff auf einen vollwertigen DC benötigt.

Danke für die Rückmeldung :)

Moin, afair haben Self Service User keinen Zugriff auf die Fabric unterhalb der Cloud und können somit keine Hosts innerhalb der Cloud gezielt auswählen. Die niedrigste Berechtigung, die das könnte, ist der 'Delegierte Administrator'.

Moin, das Problem ist nicht nur die SID des Users. Du brauchst Zugriff auf den DPAPI Key. http://technet.microsoft.com/de-de/library/ee681624%28v=ws.10%29.aspx http://support.microsoft.com/kb/309408/en-us http://msdn.microsoft.com/en-us/library/ms995355.aspx

Job der IT ist es nunmal, die Anforderungen der Organiation umzusetzen. Häufig genug auch unabhängig von einer persönlichen Meinung oder Vorliebe. Ich erstelle in solchen Fällen gerne eine kleine oder auch größere Matrix mit Anforderungen, Lösungsmöglichkeiten und Pro/Contra. Viele Bedenken lassen sich besser anbringen, wenn man gut vorbereitet ist und Alternativen zu "schnell und billig" vorweisen kann. Wenn es kein Budget für vernünftige Ausstattung gibt, muss hin und wieder improvisiert werden. Ein paar preiswerte consumer router mit DDWRT können in einer kleinen Umgebung durchaus ausreichend sein.

Den Vendor Lock In bei Microsoft habe ich an vielen Stellen. Da käme es auf einen weiteren Service nicht mehr an. Off-Topic:Auch wenn es jetzt etwas vom Thema abschweift. Langfristige strategische Entscheidungen sind nicht immer rein technisch oder wirtschaftlich motiviert. Sie haben oftmals auch eine politische Dimension. Bevor Du mir leichtfertige Planung unterstellst oder mit 'Rolling Eyes' antwortest, solltest Du sicher sein, das gesamte Bild zu kennen. over and out

Moin, wie kommst Du auf doppelte AP usw.? Wenn ihr schon eine UTM im Einatz habt, wären die zugehörigen APs vielleicht eine Variante. http://www.sophos.com/de-de/products/secure-wifi.aspx MAC Filter, PSK und hidden SSID gibt es nicht einmal bei mir zuhause. Alles außer 802.1x oder open WLAN + Captive ist mMn für die Tonne.

Beim Handling steht es in meinem Szenario unentschieden. Der SOFS hat bei der Bereitstellung von Storage für die Hyper-V Cluster und bei der System Center Integration die Nase vorn. Beim Handling von Platten (bzw. SSD), RAID Arrays und Volumes gewinnt das klassische Blockstorage. Die Supportfähigkeit ist für mich aktuell ein klares Negativ-Kriterium des SOFS. Inhouse Support ist für uns nur sinnvoll möglich, wenn die Einsparungen bei der Hardware und der Verzicht auf Herstellersupport, zusätzlich notwendige Planstellen gegenfinanzieren. Momentan ist der break even für zusätzliche Planstellen noch nicht erreicht. Auf externen Support eines Systemhauses zu setzen, ist keine Alternative. Endweder gibt es qualifizierten Herstellersupport oder die notwendige Kompetenz inklusive Redundanz beim Personal wird intern vorgehalten. Am Ende des Tages ist es mir egal, woher mein Storage kommt. Es muss den Anforderungen genügen und bezahlbar sein. An vielen Premiumanbietern stört mich der Vendor Lock In und dass ich häufig Features mit kaufen muss, die ich nicht benötige. Wie es der Zufall will, habe ich heute Vormittag meine Anforderungs- / Lösungsmatrix aufgebaut. Das klassische Blockstorage hat in meinem Szenario erstaunlich deutlich gewonnen.

Der Eindruck täuscht. Ich habe nicht vor, eine Lösung zu erzwingen. Um das Für und Wieder besser abwägen zu können, muss ich mich argumentativ für eine Seite entscheiden; das war in diesem Fall der SOFS. Warum? Ganz einfach, jeder Anbieter erzählt wie toll seine Premium Storages sind. Somit ist die Position schon besetzt; außerdem spiele ich gerne des Teufels Advokat :cool: Meine Anforderungen an die Storagelösung sind klar - auch in konkreten Zahlen - und definieren sich über Performance, Kapazität und Verfügbarkeit als Primärfaktoren. Rackspace, Handling und Supportfähigkeit (durch den Hersteller und die interne IT) spielen neben den Kosten pro TB natürlich auch eine Rolle.

Danke für die Antworten. Bei Punkt 1+2 ging es mir primär um die Migration. Die Übersichtlichkeit ist egal - ob ein paar hundert VMs auf einem iSCSI oder einem SMB liegen macht für mich ersteinmal keinen Unterschied. Wenn ich die VMs clusterübergreifend live migrieren kann, ohne dass die VHDX kopiert (=dubliziert) werden muss, hilft mir das bei der Kapazitätsplanung schon weiter. Zu Punkt 3 habe ich in der Zwischenzeit auch etwas gefunden. Um den Ausfall eines Enclosures zu tollerieren, muss der SOFS mindestens 3 Enclosures haben. http://social.technet.microsoft.com/wiki/contents/articles/11382.storage-spaces-frequently-asked-questions-faq/rss.aspx#Enclosure_Awareness_Support_Tolerating_an_Entire_Enclosure_Failing

Hast Du das schon einmal getestet? Im Schadensfall hilft der Konjunktiv nicht weiter. Dir fehlt die Konfiguration der VM. Wenn Du manuell eine neue VM Konfiguration erstellst, gibt es neue Hardware GUIDs. Das kann beträchtliche Nacharbeiten notwendig machen und den Wiederanlauf verzögern. Das ist kein Backup.

Moin, ist es vielleicht eine abgelaufene Eval?

Moin, ich finde den Geschäftsprozess als Grundlage fürs Lizenzmanagement 'zu groß'. Lizenzmanagement kann höchstens Bestandteil eines übergeordneten Prozesses ein. Beim Lizenzmanagement orientiere ich mich an den angebotenen IT-Services und den Nutzern der Services. Um einen Service bereitzustellen, benötige ich Hardware, Software, Datenverbindungen und Lizenzen für den Betrieb Um einen Service zu nutzen, benötige ich Hardware, Software, Kommunikation mit dem Service sowie Lizenzen für den Betrieb meines Zugriffsgerätes und Lizenzen für den Zugriff auf den Service. Ein kleines Beispiel: Exchange Es wird für die Bereitstellung benötigt: Hardwareumgebung (physisch oder virtuell mit RAM, CPU, Festplatte und Backup) Betriebssystem Anwendung (Exchange ggf. AntiMalware, AntiSpam) Kommunikationsverbindungen (LAN, DSL, MPLS usw.) Für den Zugriff wird ein Gerät benötigt: Business Client Hardware Betriebssystem Office Den Client inkl. Software und Lizenzen kann ich bspw. als IT-Service 'Dektop-PC' bereistellen. Ein Mobiltelefon oder Multifunktionsgerät würde analog als eigenständiger IT-Service definiert und angeboten werden. Zusätzlich benötige ich Zugriffslizenzen Nutze ich Device-CAL, so werden diese in den IT-Service 'Desktop-PC', 'Mobiltelefon' usw. integriert Bei User-CAL kann die Verwaltung bspw. in den Geschäftsprozess 'Personalzu- und -abgänge' integriert werden Mit diesem Ansatz bin ich deutlich schlanker als im abstrakten Geschäftsprozess. Als Nebeneffekt oder sogar als ein Teilziel bekomme ich die Grundlage für eine differenzierte Betrachtung der IT Kosten. Ich kann genau beziffern, was mich die Plattformbereitstellung, jeder einzelne Client und jeder Nutzer kostet. Das Ganze lässt sich auch schön nach Kostenstelle, Fachabteilung, Lokation usw. kumulieren :D Bei Bedarf lässt sich die Verbindung zum Geschäftsprozess in Form eines Show-Backs aufbauen und aufzeigen, dass IT nicht der Kostentreiber ist, sondern die Anforderungen aus der Organisation bestimmte IT Kosten verursachen :cool:

Moin, ich möchte hier auch noch die Lizenzbedingungen einzelner Windows Updates einwerfen. Die werden am zentralen WSUS akzeptiert und gelten für alle Clients, die ihre Updates über diesen WSUS bzw. die WSUS Hierachie beziehen.

Moin, IPv6 versursacht für gewöhnlich keine Probleme. MS empfielt an mehreren Stellen, IPv6 aktiviert zu lassen selbst wenn es nicht konfiguriert ist. Einige Produkte (z.Bsp. Exchange) haben IPv6 als Voraussetzung. http://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx http://technet.microsoft.com/en-us/network/cc987595.aspx

Moin, vor dem Backup sollte eine Wiederherstellungsstrategie stehen. Wieviel Datenverlust kann tolleriert werden und welche Wiederanlaufzeiten werden angestrebt. Das Backup ist nur ein Vehikel. Bei uns werden alle VMs grundsätzlich einmal täglich über den Host gesichert. Einzelne Applikationen und Fileshares werden bei Bedarf stündlich über den Applikationsagent gesichert. Es gibt bei uns ein onsite Backup auf Disk und ein offsite Backup auf Band

Moin, ich versuche gerade, ein paar Storageszenarien für den nächsten Hardwarezyklus zu bewerten. Eine mögliche Variante ist ein SOFS. Falls Funktionen nur mit VMM oder anderen System Center Produkten möglich sein sollten - kein Problem, SC ist im Einsatz. Performance steht aktuell nicht an erster Stelle. Die Priorität liegt bei Verfügbarkeit und Migrationspfaden. Können sich mehrere Hyper-V Cluster eine Freigabe auf dem SOFS teilen? Ist das empfohlen oder wird davon eventuell abgeraten? Gibt es Best Practice dafür? Können VMs per Live Migration zwischen den Clustern verschoben werden oder auf eine höhere Hyper-V Version migriert werden, ohne dass die VHDX kopiert werden muss? Jetzt zu den physischen Platten in den JBOD: Wenn Mirror oder Triple-Mirror mit zwei bzw. drei Shared SAS Enclosures eingesetzt wird, werden die Mirrorsets automatisch auf die Enclosures verteilt, so dass der Ausfall eines Enclosures tolleriert werden kann? Falls nicht automatisch, ist es manuell möglich? Auch anderen Input zum Thema nehme ich gerne mit :)

Moin, Hyper-V bietet ab 2012R2 Port-ACL für den virtuellen Switch. Nicht ganz so komfortabel, aber dafür umsonst http://technet.microsoft.com/de-de/library/dn375962.aspx

Ich kann Dein Leiden gut nachvollziehen. Nachdem ich das Elend in meiner Testumgebung durch hatte (inclusive Reporting geradebiegen, Konsistenzprüfungen nach jeder Teilmigration usw.), habe ich für die Produktivumgebung eine Neuinstallation gewählt. Die war in 3 Stunden erledigt - die Migration hätte mindestens 3 Tage gedauert :thumb2: .

Vielen IT'lern mangelt es an Bewegung. Hier gibt es Betriebssport inklusive :p

Dann würde ich meine Zeit nicht mit der Diskussion um ein, zwei oder zehn Domain Controller verschwenden. Bei IBM einen Case aufmachen und eskalieren ist angesagt.

Moin, bevor die Technik ins Spiel kommt, sollten die organisatorischen Rahmenbedingungen feststehen. Risiken aufnehmen und bewerten, Klassifizierungen festlegen, Policies und Prozesse definieren ... usw ... Du beziehst Dich auf ein Beispiel (vermutlich - wie so oft - aufgrund eines Vorkommnisses in jüngster Vergangenheit). Für DLP braucht es einen ganzheitlichen Ansatz, Aktionismus ist kein guter Ratgeber. Vielleicht hilft Dir diese Präsentation weiter http://de.slideshare.net/sarfarazchougule/isaca-webinardlpaug82013final-v128451

Wenn die Virtualisierungsinfrastruktur mit den physischen DC versorgt ist, sehe ich keine Notwendigkeit einen physischen DC für die zweite Domäne zu betreiben. Wenn schon ein zweiter physischer DC, dann würde ich ihn mit in die Infrastrukturdomäne nehmen. Damit gäbe es auch während eines OS Upgrades auf dem einen physischen DC immer noch einen physischen DC online. Eventuell könnte man so einen zweiten physischen DC auch an einem anderen Standort betreiben.