NilsK

Moin, hm - jetzt verstehe ich nicht. ;) Nach meinem Verständnis schrobst du, du würdest auf Freigabe-Ebene nicht "Jeder: Vollzugriff setzen, sondern Nicht-Admins nur "Ändern". Darauf bezog ich mich und meinte, dass ich die Regel, auf Freigabe-Ebene "Null-ACLs" zu setzen, nur dann einschränken würde, wenn es konkreten Bedarf dafür gibt. Sonst wundert man sich - ähnlich dem TO hier - später drüber, warum die NTFS-Berechtigungen nicht so greifen, wie sie da stehen. Gruß, Nils

Moin, das würde ich nur dann tun, wenn es Bedarf dafür gibt. Wenn man es nicht braucht, fällt es einem sonst auf die Füße. "Jeder" ist seit Windows XP SP2 identisch mit "Authentifizierte Benutzer". Vorher galt die Empfehlung, auf die du dich beziehst (Ausnahme: Freigabeberechtigungen, siehe oben), seither nicht mehr. Und "Benutzer" sind in Wirklichkeit auch "alle" ... wenn man also etwas einschränken will, entfernt man "Jeder", "Authentifizierte Benutzer" und alle anderen Pauschalgruppen und trägt nur noch die (selbst erzeugten) Gruppen ein, die für die gezielte Berechtigung notwendig sind. Und ganz bestimmt: Für die Verhaltensänderung im hier diskutierten Fall kann ein Ersatz von "Jeder" durch "Benutzer" nicht sorgen. Gruß, Nils

Moin, äh - nö. "Jeder" enthält auch die Domänen-Benutzer, diese Änderung kann es also nicht gewesen sein. Schauen wir uns deine Zugriffsberechtigungen mal an, dann wird aber klar, woran es liegt. Du hast dir mit den Freigabeberechtigungen selbst ein Bein gestellt. Wenn man sowohl auf Freigabe-Ebene als auch auf NTFS-Ebene Berechtigungen setzt, dann gilt immer die daraus entstehende stärkste Einschränkung. Auf Freigabeebene hat "Jeder" nur Leserechte, also kann kein höherer Zugriff als "Lesen" erfolgen - egal, wieviel auf NTFS-Ebene gewährt ist. Aus diesem Grund rät man dazu, dass auf Freigabe-Ebene immer "Jeder: Vollzugriff" gelten sollte (auch bekannt als "Null-ACL", weil es effektiv keine Einschränkung gibt) und alle Berechtigungen nur auf NTFS-Ebene gesetzt werden. Nur so hat man die Gewähr, dass die NTFS-Berechtigungen 1:1 und in jeder Situation gelten. Gruß, Nils

Moin, klar, gern :) Für ein "ausführliches" Training kannst du dich gern an meinen Arbeitgeber wenden (oder mir eine PM senden). Für Kurztrainings gibt es im Herbst neue Termine, die Zeitschrift IT-Administrator (www.it-administrator.de) setzt eine neue Folge der Eintagestrainings auf. Da werden wir allerdings natürlich nicht so tief ins Detail gehen können. Gruß, Nils

Moin, naja ... hier wäre es irgendwie hilfreich zu wissen, wie die Berechtigungen aussehen und mit welchen Konto der Zugriff erfolgt - meinst du nicht? Gruß, Nils

Moin, das wird dann wohl ein Missverständnis gewesen sein. Hyper-V erlaubt kein Memory Overcommit, daher kann man gar nicht mehr Speicher verteilen, als der Host wirklich hat - im Unterschied zu (fast) allen anderen Virtualisierern. Gruß, Nils

Moin, mit der Menge an RAM im Host hat das nichts zu tun. Es geht hier um die NUMA-Anbindung der RAM-Bänke an bestimmte Prozessoren. Lässt man hier den RAM-Zugriff über "NUMA-Grenzen" hinweg zu, dann lassen sich tendenziell mehr VMs auf dem Host betreiben. Es kann aber eben sein, dass einzelne Speicherzugriffe nicht mit maximaler Geschwindigkeit laufen - so wie bei dir. Wenn dir die Performance ausreicht (was meist der Fall ist), dann kannst du das in der Tat so lassen. Wenn nicht, dann kannst du die NUMA-Konfiguration auf der Host-Ebene (nicht auf der VM-Ebene) so anpassen, dass keine NUMA-Knoten-übergreifenden Zugriffe erlaubt sind. Nebenbei: Du weißt, dass du mit einer Standard-Lizenz nur zwei Windows-Server-VMs betreiben darfst? Gruß, Nils

Moin, ich meine damit die Adressen aus dem DHCP-Scope, die der DHCP-Server aus irgendeinem Grund überspringt, statt sie zu vergeben. Vielleicht werden die ja in Wirklichkeit benutzt und sind nicht frei. Gruß, Nils

Moin, kann man schon so machen. Ich rate allerdings grundsätzlich davon ab, Testumgebungen per Cloning zu erzeugen. Dadurch erzeugst du ein hohes Sicherheitsrisiko, wenn z.B. die Testumgebung nicht genauso geschützt wird wie das produktive Netzwerk. Zudem musst du absolut sicherstellen, dass das Testlab vom Echtnetz getrennt ist und bleibt. Sofern du im Testlab andere IP-Adressen verwenden willst, entsteht ein sehr hoher Aufwand bei der Anpassung. Und schließlich wärest du nicht der erste, der was in der Testumgebung ändert - um dann hinterher festzustellen, dass es doch das echte Netz war, denn der Klon sieht ja genauso aus wie das Original. Da es dir ja um das Verfahren als solches geht, würde ich dazu raten, die Testumgebung neu aufzubauen und da, wo es wichtig ist, Elemente aus der Produktion nachzubilden. Das Vorgehen selbst ist hier sehr schön beschrieben: [Whitepaper: Migration von Exchange 2003 zu Exchange 2010 | faq-o-matic.net] http://www.faq-o-matic.net/2011/05/30/whitepaper-migration-von-exchange-2003-zu-exchange-2010/ Gruß, Nils

Moin Xanathos, deine Ausführungen verstehe ich an dieser Stelle auch nicht recht. Was haben OUs mit der Frage des TO zu tun? Und an welcher Stelle ist der Ersteller/Besitzer hier relevant? Gruß, Nils

Moin, naja, bei seinem Anforderungsprofil schon nachvollziehbar. Mit einem Löscheinsatz scheiden einfach fast alle normalen Geräte aus - hat er ja oben eindrucksvoll beschrieben. Gruß, Nils

Moin, zum Anlegen von Freigaben muss man lokaler Administrator auf dem Zielsystem sein. (Mit OUs hat das nichts zu tun.) Gruß, Nils

Moin, um dazu noch kurz was zu sagen: In den meisten Umgebungen ist von derart kurzen Lease-Dauern abzuraten. Insbesondere, wenn ihr sowieso ein Lastproblem habt. Ein DHCP-Client wird im laufenden Betrieb nach 50% der Lease-Dauer seine Lease erneuern. Das ist dann Unicast, aber eben Traffic. Bedeutet bei euch: alle sechs Stunden, also mindestens einmal pro Arbeitstag für die meisten Rechner (in vierstelliger Zahl). Nun hat der Client allerdings auch schon beim Hochfahren seine Lease erneuert ... Sollte der DHCP-Server nicht geantwortet haben, dann versucht der Client nach 87,5% der Lease-Dauer erneut eine Verlängerung per Unicast. Nur wenn das nicht erfolgreich ist, verwirft er seine Lease am Ende von deren Dauer und führt ein neues Broadcast-Discover durch. Wenn ihr ohnehin Last im Netz habt, würde ich nicht ausschließen, dass das bei euch häufiger passiert. Und das alles für vermutlich zum größten Teil stationäre Clients, die ohnehin dauerhaft eine IP-Adresse brauchen und in der Regel auch immer dieselbe vom Server erhalten. Kurze Lease-Dauern haben neben der Netzwerklast noch einen weiteren Nachteil: Die automatische DNS-Registrierung kann dadurch aus dem Tritt geraten, insbesondere wenn auf den (Windows-) DNS-Servern das Scavenging (Entfernen veralteter Einträge) aktiv ist. Hier muss man die Scavenging-Intervalle und die Lease-Dauern aufeinander abstimmen, was mit Lease-Dauern unterhalb von 24 Stunden eigentlich gar nicht geht und mit Dauern unter drei Tagen nicht sinnvoll konfigurierbar ist. Wenn es also nicht wirklich einen zwingenden Grund für kurze Lease-Dauern gibt, solltet ihr die deutlich verlängern. EDIT: Eine mögliche Ursache für euer Phänomen fällt mir noch ein. Könnt ihr sicher ausschließen, dass die Adressen, die der DHCP-Server nicht dynamisch vergibt, in Benutzung sind? Ein Windows-DHCP-Server wird nämlich, bevor er eine Adresse rausgibt, zunächst per Ping prüfen, ob diese schon jemand nutzt ... Gruß, Nils

Moin, als Windows-Phone-Freund kann ich dich da zwar grundsätzlich unterstützen. So eine richtig große Geräteauswahl findest du dort aber leider nicht. Die breiteste Modellreihe hat natürlich Nokia. Deren Geräte sind auch wegen der zahlreichen Softwarebeigaben (kostenlos - ich habe keine einzige Bezahl-App auf meinem Gerät) aus meiner Sicht am interessantesten (die Navigation etwa ist hervorragend, die kostenlos nutzbare Fassung der Musik-Streaming-App ist auch ziemlich gut, dann gibt es dazu noch eine ganze Reihe von Kleinigkeiten). Nachdem ich ursprünglich der Meinung war, ein Telefon sei kein Fotoapparat, bin ich mittlerweile auch von den sehr guten Kameras der "höheren" Modellreihen sehr angetan. Sinnvoll ist, entweder ein richtig aktuelles Modell zu nehmen (kann im Zweifel auch heißen, ein paar Wochen abzuwarten, weil die aktuelle Generation gerade in der Markteinführung ist) oder von den bestehenden Modellen eher ein höherwertiges. Auf die Weise ist es am wahrscheinlichsten, dass das Gerät noch lange und jeweils zügig mit OS- und Firmware-Updates versorgt wird. Da sich gerade auf dem Sektor einiges tut, ist das durchaus interessant. Dein Robustheits-Wunsch wird aber, soweit ich sehe, von keinem aktuellen Windows Phone wirklich erfüllt. Also entweder Zusatzlösung per Hülle/Cover, um das zumindest zu lindern. Oder eben doch ein grüner Überraschungseiroboter. Gruß, Nils

Moin, prima, danke für die Rückmeldung! :) Gruß, Nils

Moin, ich kann es gerade nicht testen, aber ich bin der Meinung, dass du nicht nur die Tabellen und Objekte des SQL Server skripten lassen kannst, sondern auch die Daten. Das könnte dann doch für dein Vorhaben ausreichen. [script Data in MS SQL Server 2008 Database Tables using Generate SQL Server Script Wizard] http://www.kodyaz.com/articles/sql-server-script-data-with-generate-script-wizard.aspx Gruß, Nils

Moin, ja, aber es befriedigt eben die Anforderung. Gruß, Nils

Moin, hast du denn die Standardinstanz in deiner Quellverbindung angegeben? Gruß, Nils

Moin, dein Problem ist der Browserdienst ("Computerbrowser", hat nichts mit Webbrowsern zu tun), der nun einmal nicht zuverlässig läuft. Dass sich Rechner im Netzwerk "nicht sehen", hat i.d.R. nichts damit zu tun, dass sie einander nicht erreichen würden. Sie werden nur in der Netzwerkliste nicht angezeigt, weil diese eben auf dem Browserdienst beruht. Das ist Technik aus den Achtzigern, weswegen Microsoft auch seit einigen Jahren einiges tut, um diese Funktion zu verstecken. Ein WINS-Server könnte das Problem lindern. Noch besser wäre allerdings, wie die Kollegen schon richtig sagen, ein vernünftiges Netzwerkdesign. Gruß, Nils

Moin, Hilfe ist hier einfach: Das geht nicht. Weder auf Foundation noch auf einer anderen Version. Ein Domänencontroller kann immer nur eine AD-Domäne verwalten. Will man mehrere AD-Domänen, braucht man auch mehrere Domäencontroller. Allerdings rät man heute allgemein davon ab, überhaupt ein AD mit mehr als einer Domäne zu planen. [Welches Domänenmodell ist das Beste für Active Directory? | faq-o-matic.net] http://www.faq-o-matic.net/2007/06/09/welches-domaenenmodell-ist-das-beste-fuer-active-directory/ Und zuletzt darf die Foundation nicht in einer Umgebung mit mehr als einer Domäne genutzt werden. Gruß, Nils

Moin, nein, das kann man nicht beantworten. Ist wirklich so. Die einzige Möglichkeit ist Messen. Gruß, Nils

Moin, dass das mit dem Dualboot so funktioniert, würde ich ebenfalls bezweifeln. Gut möglich, dass das der Grund für Bitlocker ist, in den Recovery Mode zu wechseln. Für solche Einsatzfälle wäre Windows to Go eine adäquate Lösung. Gruß, Nils

Moin, [bitLocker mit USB-Key entsperren auf Notebook ohne TPM | WindowsPro] http://www.windowspro.de/andreas-kroschel/bitlocker-recovery-auf-notebook-ohne-tpm Die GPO-Einstellung, die die Verwendung eines USB-Sticks für den Key zulässt, ist gesetzt? [Windows 7 BitLocker Review - 4sysops] http://4sysops.com/archives/review-windows-7-bitlocker/ Gruß, Nils

Moin, naja, kommt darauf an, was man als "selten" bezeichnet. Ich habe schon mehrere Kunden bei sowas unterstützen dürfen, und das waren beileibe keine Großunternehmen. Bei den Stückzahlen, die du nennst, würde der Aufwand aber wohl selbst in dem Fall noch handhabbar sein. Gruß, Nils

Moin, im Wesentlichen ja. Sollte Microsoft sich wegen einer Überprüfung melden, ist das allerdings trotzdem ein großer bürokratischer Aufwand. Gruß, Nils