NilsK

Moin, in solchen Fällen ist es meist am besten, den Importprozess vorzubereiten: Erst Datei lokal kopieren, dann die lokale Kopie importieren. Damit umgehst du auch Netzwerkprobleme während des Imports. Gruß, Nils

Moin, von welcher Anzahl Empfänger reden wir denn? Gruß, Nils

Moin, das liegt vermutlich daran, dass der Dienstaccount des SQL Server keine Zugriffsrechte auf den Share hat. In dem Moment, wo du das lokal am Server machst, existiert eine Session zwischen SQL Server und File Server im Kontext deines Admin-Kontos. Machst du das remote, besteht keine solche Session, und dann geht es nur über den Dienstaccount des SQL Server. Gruß, Nils

Moin, indem du die Reihenfolge in deinem Batch änderst und erst die abhängigen Dienste beendest. Gruß, Nils

Moin, nein. Der übliche Weg geht über einen separaten Backupserver, an dem das Band hängt und wo die zentrale Instanz der Backupsoftware läuft. Die VMs nutzen dann Agenten, wenn sie auf Applikationsebene gesichert werden sollen. Typisches Missverständnis. Mit der Standard-Edition darfst du genau eine Lizenz produktiv verwenden - entweder auf dem physischen Server (wenn dort produktive Dienste laufen) oder in einer VM (wenn auf dem Host nur Hyper-V und keinerlei produktive Dienste laufen). Sobald dein Host noch andere Dienste ausführt (wie etwa den zentralen Backupserver), belegt er die Lizenz, und du musst jede VM einzeln lizenzieren. Windows-Lizenzen in VM-Umgebungen Gruß, Nils

Moin, das ist eine nicht empfohlene Konfiguration: faq-o-matic.net » Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte Abgesehen davon, dürfte die Konfiguration eine zusätzliche Lizenz für den Host erfordern. Die Sicherung auf Applikationsebene erfolg in deiner Konstruktion über Agenten der Backup-Software für die jeweilige Applikation. Gruß, Nils

Moin, die Antwort hängt natürlich entscheidend von der Monitoring-Software ab, die du einsetzt ... Gruß, Nils

Moin, ach nee, plötzlich doch? Und warum sagst du das nicht gleich und auch auf Nachfrage nicht? Jetzt mal Butter bei die Fische: Was genau hast du am Ende vor? Es bringt doch nichts, wenn wir dir hier -zig Lösungen vorschlagen und am Ende kommt immer noch was. Sag gleich, was du vorhast, dann können wir dir einen geeigneten Weg vorschlagen, das eigentliche Ziel zu erreichen. Welche Daten brauchst du genau? Welche Applikation soll das verarbeiten? Was soll die Applikation mit den Daten machen? usw. usf. http://support.microsoft.com/kb/555375/en-us Gruß, Nils

Moin, "seit den letzten Snapshots" ... du weißt, dass Snapshots für Produktion nicht gedacht, nicht empfohlen und je nach Applikation auch nicht supported sind? Du kennst darüber hinaus die Auswirkungen von Snapshots auf Speichervolumen und Performance? faq-o-matic.net » Hyper-V: Vorsicht mit Snapshots! In dem Zusammenhang würde ich nicht ausschließen, dass das Dateisystem stark fragmentiert ist und der Fehler daher rührt. Gerade beim Hantieren mit vielen Snapshots passiert sowas leicht. Gruß, Nils

Moin, aha. Dann ist "net user /domain > meineDatei.txt" im CMD-Fenster die einfachste Variante. Dafür braucht man nun wirklich kein VBS. Du willst doch was anderes? Dann wäre jetzt eine gute Gelegenheit, dich zu erklären. Gruß, Nils

Moin, was soll denn am Ende dabei herauskommen? Oder anders gefragt: Welche Aufgabe bzw. welches Problem möchtest du am Ende mit deinem Skript lösen? Gruß, Nils

Moin, das FSMT macht ganz was anderes, was du durch Lesen der Beschreibung und etwas Googeln sicher auch schon herausgefunden hast. Anderswo wurde gerade dies hier empfohlen, ich habs mir noch nicht selbst angesehen: Free NTFS Permissions Analyzer Tool for Active Directory Gruß, Nils PS. Bitte nutze die Shift-Taste, deine Tastatur hat extra zwei davon.

Moin, da ich den Code eurer Vorlage nicht kenne und darüber hinaus auch kein Office-Entwickler bin, kann ich dir das leider nicht sagen. Allgemein wirst du hier aber auch keine fertigen Lösungen serviert bekommen, sondern Hinweise bei konkreten Fehler- oder Problemsituationen. Hinweise zum Auslesen von Werten aus dem AD findest du im Internet einige, z.B. hier: faq-o-matic.net » Ein AD-Attribut zu einem Logon-Namen herausfinden Gruß, Nils Gruß, Nils

Moin, ja, natürlich, das geht. Ihr müsstet also die Formeln in eurer Vorlage so ändern, dass sie die lokal gespeicherte Datei auswerten, statt eine Verbindung ins AD aufzubauen. Die Daten selbst kann man, wie du vorschlägst, z.B. mit einem VBS-Skript beim Logon aus dem AD lesen und in eine Datei schreiben. Falls kein Connect zum AD besteht, bleibt die Datei unangetastet. Gruß, Nils

Moin, wenn überhaupt, einen A-Record, und natürlich keinen Wildcard, sondern den Eintrag für www. Gruß, Nils

Moin, das scheint (leider) Standard bei lokalen Konten zu sein. Ist aber wirkungslos, solange es eine Kennwortrichtlinie gibt, die keine leeren Kennwörter zulässt. Noch eine Möglichkeit, warum es scheitern kann: Im Kennwort darf nicht der Anmeldename und auch kein "Token" daraus auftauchen (wenn der User etwa "Admin-Horst" heißt, darf weder der ganze Name noch "Admin" noch "Horst" im Kennwort enthalten sein). Gruß, Nils

Moin, erzeuge dir eine Benutzerdefinierte Ansicht nach deinen Anforderungen und speichere die Events von dort. Du kannst dabei das EVTX-Format auswählen, das man mit Vista/7/2008/R2 lesen können sollte. Vom Kürzen des Eventlogs rate ich grundsätzlich ab. Gruß, Nils

Moin, nein. Das Grundverhalten kommt vom Server. Alles Spezielle muss man in der Applikation regeln. Der Treiber stellt i.W. nur die Verbindung her. Gruß, Nils

Moin, nein, das Verhalten ist Standard. Wenn du nichts anderes anforderst, isoliert SQL Server Transaktionen automatisch voneinander - das ist gewissermaßen eine seiner Hauptaufgaben. Sprich: Wenn eine Transaktion eine Ressource (z.B. Tabelle) nutzt, dann sperrt SQL Server die Ressource, bis die Transaktion beendet ist (Commit oder Rollback). Einzelne Aktionen bilden in sich eine Transaktion (Implicit Transaction). Das Kapseln mit BEGIN..END TRANSACTION brauchst du nur, wenn du mehrere Kommandos zu einer Transaktion zusammenfassen willst. In dem Fall bleiben die Sperren für alle Ressourcen, die in der Transaktion angesprochen werden, so lange erhalten, bis die Transaktion endet. Sobald eine Ressource gesperrt ist, warten andere Transaktionen, bis die Sperre aufgehoben wird. Ein Limit gibt es da, soweit ich mich erinnere, nicht, daher ist bei komplexen Applikationen einiges an Sorgfalt nötig, um Performanceprobleme durch Sperrkonflikte zu vermeiden. Gruß, Nils

Moin, versuch mal, wenn du das Programm gestartet hast, es per Rechsklick auf das "laufende" Icon an die Taskleiste zu pinnen. Gruß, Nils

Moin, ... ähh ... nee, gerade nicht: und: Daraus lese ich: Nutzung auf bis zu 2 CPUs direkt auf der Hardware ODER (exklusives oder) Installation in einer VM oder Emulation Dass das gleichzeitig möglich sei, wie der TO fragt, lese ich draus eben nicht. "Statt" deutet für mich darauf hin, dass man ein anderes OS oder eine andere Lizenz auf der Hardware braucht, wenn man die fragliche Lizenz in einer VM einsetzt. Gruß, Nils

Moin, bitte gib einmal die Ausgabe folgender Kommandos in einem CMD-Fenster hier an: net accounts und net user <Name des lokalen Users> Was genau heißt "Der früher verwendete Domänenbenutzer hatte ein lokales Konto."? Lokales und Domänenkonto schließen sich gegenseitig aus. Es kann auch durchaus sein, dass das Fehlverhalten auf das HP-Tool zurückzuführen ist. Falls du das deaktivieren kannst, versuch das mal und ändere dann erneut das Kennwort. Klappt es dann? Gruß, Nils

Moin, wenn Outlook nicht an einen Exchange-Server angebunden ist, erzeugt es immer eine PST-Datei. Und die sollte nicht im Netzwerk liegen, weil sie dann Gefahr läuft, kaputtzugehen. Gruß, Nils

Moin, nein, die Aussage ist nicht richtig. iSCSI ist blockbasierend, natürlich auch über Microsofts iSCSI-Target. Die meisten Speichergeräte erzeugen für die LUNs (also die Volumes, die per iSCSI auf dem Server eingebunden werden), intern eine Container-Datei (bei Microsoft natürlich eine VHD-Datei). Das hat nichts mit einem dateibasierten Zugriff zu tun, könnte aber der Grund für das Missverständnis sein. Gruß, Nils

Moin, interessantes Phänomen. Ich könnte mir vorstellen, dass dein Logonskript, da es ja asynchron ausgeführt wird, zu unterschiedlichen Zeitpunkten des Anmeldevorgangs die Werte ausliest und das Verhalten eigentlich normal ist. Ist aber nur geraten. Gibt es denn bei dir ein Problem, das aus diesem Phänomen folgt? Gruß, Nils