NilsK

Moin, also, von anderen Geduld einzufordern, wenn man selbst derart ungeduldig und fordernd auftritt, ist schon ein starkes Stück. Dir wurden von Anfang an die richtigen Vorgehensweisen genannt, innerhalb einer halben Stunde. Also noch mal zusammengefasst: Neue VM als Vorlage installieren und konfigurieren. Wenn die VM fertig ist, dort sysprep ausführen, die VM herunterfahren. Die VHDX-Datei dieser VM ist deine Vorlage. Die kopierst du irgendwohin und stellst sie auf Read-only. Um eine neue VM zu erzeugen, kopierst du deine Vorlage, stellst sie auf Read-write und bindest sie in eine neue VM ein. In der neuen VM läuft dann das Mini-Setup durch, und du hast eine neue, indivudualisierte Installation. So, und jetzt denkst du noch mal über dein Auftreten nach und machst es nächstes mal besser. Danke. Gruß, Nils

Moin, dann vermutest du ja dasselbe wie ich. Wie wäre es, wenn du die Stelle änderst? :rolleyes: Mit deinem CAST-Statement gibst du den Wert ja nur per SELECT aus, aber du weist ihn keiner Variablen zu. Gruß, Nils

Moin, interessanter Ansatz ... Wenn ich nicht ganz falsch liege, müsstest du für den LIKE-Vergleich die Variable in einen String konvertieren. Vielleicht wäre es aber einfacher, den Ergebniswert mit dem Integer des Ergebnisses zu vergleichen. Auch nicht gerade elegant, aber einen Stringvergleich finde ich hier schon sehr krude. Gruß, Nils

Moin, je nachdem, wie komplex die CSV-Dateien sind könntest du dir mit dem oben verlinkten Verfahren ein SQL-Skript generieren, das für jede Datenzeile einen INSERT-Befehl erzeugt. Das ist oft weniger fehlerträchtig als ein Massenimport, weil du vor dem Ausführen das SQL-Skript noch mal kontrollieren kannst. Gruß, Nils

Moin, wenn es eine Vertrauensstellung gibt (noch dazu bidirektional!), dann sind die AD-Forests eben nicht getrennt. Interne Informationen haben in einer DMZ nichts zu suchen. Eine pauschale Weiterleitung hilft dem nicht ab. Fehlerbehebung ist das eine, konzeptionelle Fehler (zumindest potenzielle) sind aber erheblich wichtiger. Nur meine 0,02 EUR, Nils

Moin, ohne nähere Analyse würde ich von einem AD in der DMZ entschieden abraten. Und wenn, dann gehören dort keine Daten aus der internen Domäne hin, auch nicht per Zonentransfer. Gruß, Nils

Moin, ist es jetzt eine neue Erkenntnis, dass alles Vor- und Nachteile hat? Nicht umsonst habe ich mehrfach darauf hingewiesen, dass Differenzierung sinnvoll ist. Wenn eine bestimmte Methode in einer gegebenen Situation sinnvoller ist, nimmt man die. Ist deshalb jede andere Methode grundsätzlich abzulehnen? Um bei plakativen Analogien zu bleiben: Würde jemand argumentieren, Fahrräder seien Blödsinn, weil man damit nicht übers Meer kommt? Abgesehen davon, speichert Windows Hello (um das es ja ursprünglich ging) die biometrischen Daten eben nicht zentral. Es legt abgeleitete Identifikatoren geschützt auf dem lokalen System ab. Es wäre auch ziemlich unsinnig, die Daten zentral zu speichern, weil ein anderer Client ja vielleicht andere Hardware hat. Gruß, Nils

Moin, bei den Mailboxgrößen scheidet ein PST-Export aus meiner Sicht sowieso aus. Also stimme ich zu: Swing-Migration über einen (temporären) Exchange-2010-Server. Gruß, Nils PS. Ganz schön mutig, so große Mailboxen mit einem SBS 2003 zu betreiben ...

Moin, <hust> du weißt, in welcher Preisklasse sich Quest bewegt? Man kann durchaus per PST-Export/-Import migrieren. Es gibt halt ein paar Einschränkungen, aber bei 15 Usern sollte das vertretbar sein. Wie groß sind denn die Mailboxen? Gruß, Nils

Moin, aber-doch-nicht-für-Exchange-das-geht-doch-per-Mailbox-Move-viel-besser ... Gruß, Nils

Moin, die Antwort wirst du dann in eurem konkreten Lizenzvertrag finden. Meiner Kenntnis nach waren Downgrade-Rechte bei OEM-Lizenzen für die Pro-Varianten enthalten, nach der folgenden Einschätzung soll das auch weiter so sein. Alle Details musst du aber euren konkreten Bedingungen entnehmen, denn ihr habt ja anscheinend einen Sondervertrag. [Microsoft releases new license terms for Windows 10: Biggest surprise? No gotchas | ZDNet] http://www.zdnet.com/article/microsoft-releases-new-license-terms-for-windows-10-no-surprises/ Gruß, Nils

Moin, nein, du hast es anscheinend immer noch nicht verstanden ... :( Das Gesicht musst du gar nicht ändern. Niemand außer dir hat dein Gesicht. Ändern muss man die Fehleranfälligkeit der Gesichtserkennung, damit man ihr nicht so leicht etwas vorgaukeln kann. Genauso verhält es sich mit Fingerabdrücken und allen weiteren biometrischen Merkmalen. Dass der Stand der Technik nicht für jedes Szenario ausreichend sicher ist, ist ein anderes Thema. Genau deshalb zwingt Windows 10 ja auch niemanden, auf eine bestimmte Technik umzusteigen. Und niemand verlangt, dasselbe Verfahren für alle Zwecke einzusetzen. Und wie genau wolltest du Einmalpasswörter bei Nicht-Enterprise-Systemen umsetzen? (Nein, wir müssen das nicht diskutieren, nimm es als Hinweis, dass es nun mal nicht so einfach ist und dass es kein "One size fits all" gibt.) Gruß, Nils

Moin, du könntest dir ein Skript bauen, das die CSV-Dateien liest, die Tabellen erzeugt und dann die Daten in die Tabellen pumpt. Der größte Teil des Skripts wäre ja immer identisch. Auf die Schnelle würde ich mir wahrscheinlich ein T-SQL-Gerüst für die Tabellen bauen und dann mit Excel die INSERT-Kommandos aus den CSVs erzeugen. Das ist zwar nicht elegant, aber einfach. [Excel: Admins unbekannter Liebling | faq-o-matic.net] http://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Gruß, Nils

Moin, hast du denn den Editor definiert? [sqlcmd (Hilfsprogramm)] https://msdn.microsoft.com/de-de/library/ms162773.aspx Und warum so kompliziert? Nimm doch lieber das SQL Server Management Studio ... oder notfalls sowas wie Ofarim: [Ofarim Free: SQL-Client | faq-o-matic.net] http://www.faq-o-matic.net/2007/02/27/ofarim-free-sql-client/ Gruß, Nils

Moin, man muss aber auch nicht an jedem Essen herummäkeln, nur weil es anders schmeckt, als man es gewohnt ist. Als Vater weiß ich, wovon ich rede. ;) Ich verstehe die grundsätzlichen Vorbehalte durchaus. Sie führen mich aber nicht dazu, einen neuen Ansatz pauschal abzulehnen. Gruß, Nils

Moin, öffentliche Zertifikate sind kein Grund für oder gegen einen Domänennamen. Die Mail-Domain braucht mit dem AD-Domänennamen nichts zu tun zu haben. Intern nutzt man für Exchange i.d.R. ohnehin Selfsigned oder interne Zertifikate, oder man baut eben den Namensraum passend. Alles Weitere siehe in meinem oben verlinkten Artikel. Gruß, Nils

Moin, ich kann deinen Argumenten nicht ganz folgen. Nur dem, dass wir uns hier wohl nicht einigen werden. :D Warum soll es ein Problem sein, wenn die speziellen Kameras weit verbreitet sind? Der Sicherheitsgewinn liegt ja nicht darin, dass niemand diese Kameras hätte. Er liegt darin, dass diese Kameras über Technik verfügen, die sich nicht so einfach austricksen lässt. Einfache Fotos reichen dafür nicht aus. Und nein, natürlich ist diese Technik nicht zu 100 Prozent sicher. Welche Alternative hattest du noch genannt, die dieses Kriterium erfüllt? Das Argument mit den Fingerabdrücken, die bei Behörden liegen, erschließt sich mir ebenfalls nicht. Warum soll dies grundsätzlich die Authentisierung an einem konkreten Gerät unsicher machen? Weil Angreifer grundsätzlich in der Passbehörde arbeiten und sich vorher gezielt den richtigen "Abdruck" raussuchen? (Der dort im übrigen gar nicht gespeichert ist, es liegen ja nur Identifikationsdaten vor, die auf dem Abdruck beruhen, ähnlichen einem Kennworthash.) Ein Sicherheitsgurt im Auto schützt auch nicht vor jedem Schaden. Trotzdem nutze ich ihn selbstverständlich. Gruß, Nils

Moin, das wird ja sicher irgendwo dokumentiert sein. Es handelt sich hier um Gruppen, die wahrscheinlich eingerichtet wurden, um auf bestimmte Ordner oder ähnliches Zugriffsberechtigungen zu erteilen. Was mit dem "Alias" gemeint ist, ist nicht ersichtlich, da wird es sich um eine organisatorische Kategorie in eurem Unternehmen handeln. Windows kennt kein "Alias"-Konstrukt. Wenn das nicht dokumentiert ist, wird es schwierig. Dann kommst du je nach Umgebungsgröße ggf. nicht um kostenpflichtige Zusatztools herum. Gruß, Nils

Moin, also, ich bin weiterhin für Differenzierung. Es geht hier nicht um Hochsicherheitstrakte, sondern um die Absicherung alltäglicher Vorgänge. Nicht mehr, aber eben (und vor allem) nicht weniger. [besser mit Touch | heise Security] http://www.heise.de/security/artikel/Besser-mit-Touch-1965801.html Jürgen Schmidt ist nicht irgendwer, und er steht mit der Einschätzung nicht alleine. Und dass sich die Spezialkameras verbreiten werden, ist beabsichtigt und natürlich kein Problem, sondern prinzipiell ein Gewinn. Das ist ja gerade der Witz daran. Solange es gängige Praxis ist, dass auch IT-Profis für wichtige Systeme Lulli-Kennwörter verwenden, halte ich alternative Methoden für einen grundsätzlichen Gewinn, auch wenn sie (wie jede andere Methode) keinen 100-Prozent-Schutz bieten. Gruß, Nils PS. Microsoft speichert die Biometrie-Daten für Windows Hello eben nicht in der Cloud. [Making Windows 10 More Personal and More Secure with Windows Hello | Blogging Windows] http://blogs.windows.com/bloggingwindows/2015/03/17/making-windows-10-more-personal-and-more-secure-with-windows-hello/

Moin, Technik entwickelt sich weiter, und nicht jeder Angriff ist praktikabel. Die neue Gesichtserkennung mit Windows Hello wird sich eben nicht so einfach austricksen lassen. Sie braucht dafür auch spezielle Hardware (neuartige Kamera). Auch andere Angriffe sollte man durchaus einordnen. So hat es keinen Tag gedauert, bis nach dem Release des iPhone mit Fingerabdruck-Scanner Angriffe gezeigt wurden. Trotzdem waren (und sind) die meisten Sicherheitsexperten der Ansicht, dass das Feature das allgemeine Sicherheitsniveau anhebt und nicht absenkt, weil die Angriffe eben aufwändig sind. Und das sind sie bei "Teleobjektiv und Nachbildung" eben auch. Wie immer, tut auch hier Differenzierung Not. Gruß, Nils

Moin, bei der Diskussion sollte man auch den Einfluss von Smartphones und Tablets auf die faktische Anmeldesicherheit beachten: Weil es mit solchen Geräten so umständlich ist, mit ordentlichen Kennwörtern usw. zu arbeiten, nutzen die meisten User simpelste PINs oder Wischmuster (oder kennt ihr jemanden, der bei Android keine "Z"-Geste verwendet?) für alles. Kennwörter bei Webdiensten usw. werden dann auch nach Bequemlichkeit möglichst touch-simpel gewählt. Da ist eine einfach zu bedienende, "ziemlich sichere" Methode ganz bestimmt ein Fortschritt. Zumal die bekannten Angriffe nun wirklich nicht "mal eben" durchzuführen sind. Gruß, Nils

Moin, ich habe absichtlich von den Worker-Prozessen gesprochen, nicht von PowerShell. Wenn der Management-Dienst ein Problem hat, wird auch die PowerShell die VMs nicht anzeigen, was aber nicht zwingend heißt, dass die VMs nicht laufen, denn dafür sind andere Prozesse zuständig. Natürlich sollte so etwas nicht passieren. Ich habe es auch noch nie gesehen. Was immer da war, es war ein Fehler. Was für einer, würde sich nur mit erheblichem Aufwand feststellen lassen, wenn überhaupt. Gruß, Nils

Moin, bevor man irgendwas an der Konfig ändert, sollte man prüfen, ob die VM-Worker-Prozesse laufen. Das sieht man schnell im Taskmanager. Gruß, Nils

Moin, zumal WINS nie daran Schuld ist, wenn "das Netzwerk langsam" ist. Viel häufiger ist das Gegenteil der Fall: Es ist zäh im Netz, weil WINS fehlt und die NetBIOS-Namensauflösung per Broadcast arbeiten muss. Aber ich wollte mich ja zurückhalten. ;) Gruß, Nils

Moin, mir ist ebenfalls kein Angriff gegen WINS bekannt, der einem DC schaden könnte. WIchtig ist vor allem: Nicht mehr als fünf WINS-Server, sonst ist es nicht supported (oder besser: Bei mehr als fünf muss man den Microsoft-Support einschalten). Und Hub-and-Spoke-Replikation, wenn mehr als drei genutzt werden. In den meisten Umgebungen ist es sinnvoll, die Infrastrukturdienste auf den DCs zu konzentrieren. Wenn man es richtig macht, kann das auch für DHCP gelten. Das ist eine reine Effizienzfrage: Diese Dienste sind im Zweifel leicht wiederherzustellen und erzeugen keine kritischen Abhängigkeiten. (Sollte das im konkreten Fall für DHCP nicht zutreffen, dann kommt DHCP separat.) Und: Ich habe bislang mehr Kunden angetroffen, die nach dem Abschaffen von WINS mehr Probleme im Netzwerk hatten, als solche, deren Probleme geringer geworden wären. (Das spricht sicher nicht für die Netzwerke dieser Kunden, aber eben noch weniger dafür, WINS einfach nur deshalb loszuwerden, weil man es für böse hält.) Gruß, Nils PS. Jehova ... PPS. Ach so, und wo wir dabei sind: Nein, die GlobalNamesZone ist keine Alternative. Die ist nicht mal ein Witz.