zahni

Dann solltest Du da ansetzen. Ein WINS schadet nicht, DNS sollte der Windows-Server machen. Das Leben mit einem AD wird auch viel angenehmer (dann muss der Server DNS bereitstellen). Denkbar ist übrigens, dass beim UNC-Zugriff immer wieder eine Authentifizierung durchgeführt wird, die u.U. Zeit kostet. Der User ist ja kein Domain-User. Da wird solche Umgebungen i.d.R. nicht installieren, sind unsere Erfahrungen hier begrenzt.

Was hast Du außerhalb der Default-Installation der Server und Clients "optimiert"? Z.B. In der Registry?

Welche Windows-Version verwenden die "Clients"? Dieses Verhalten solle bei SMB 2.0 oder 3.0 nicht mehr auftreten.

Also allgemein zu einem SQL-Server (nicht nur von MS) Wichtig ist: - Reorg der Tabellen durchführen - Reorg der Indizes (oder Neuaufbau) durchführen - Datenbank-Statistiken über alle Tabellen inkl. der Indizes aktuell halten (die werden unbedingt zur Berechnung optimaler Zugriffpfade benötigt). Nun das leidige Thema "Indizes": Ich erlebe es immer wieder, dass man Anwendungen entweder ganz ohne Indizes (außer bei PK's), sinnfreien Indizes (hier gab es tatsächlich mal einen fall, im dem alle Spalten einer Tabelle im Index vertreten waren) oder veralteten Indizes bekommt. Hier kann ein Admin nur die Tools vom SQL-Server verwenden um einen Workload (der möglichst alle häufig auftretenden Abfragen umfasst) analysiert und die resultierenden Indizes der Softwareentwicklung übergibt zu Validierung und Freigabe. Indizes müssen zu den verwendeten Abfragen passen. Die kennt der Admin üblicherweise nicht. Des Weiteren sollten sog. Residual Predicates vermieden werden (kann auch nur die Entwicklung). PS: Die VM sollte keine Snapshots besitzen.

Lustig: Der Mod da hat meine Beiträge "abgelehnt". So kann man Bugs auch "unter der Decke" halten.

Ja, steht im Link ganz oben ;) Wobei 7u72 nur ein "PSU" ist und den gleichen Fehler hat.

Hi, wer Applets im Browser braucht (z.B bei Creditreform) und eine Proxy.pac benutzt kann mit den aktuellen Java-Versionen in eine Falle laufen. Ich kriege es jedenfalls gerade nicht hin. Eine manuelle Proxy-Konfig in den Deployment.properties wird leider auch ignoriert. Siehe https://community.oracle.com/thread/3621761 Unsere Proxy.pac kann ich hier nicht selbst ändern und habe ehrlich auch keinen Bock dazu :( Fehler soll erst mit dem nächsten Release behoben werden.

Das sage ich mal spontan, dass wenn Du den Task mit einem anderen Konto ausführst (k.A. ob man einen Task auch bei der Abmeldung planen kann), sieht das Script der User mit dem das Script ausgeführt wird. Hilft Dir also auch nicht. Mal davon abgesehen sind neue Gruppenmitgliedschaften erst "gültig", wenn sich der User erneut anmeldet. Der User muss vor der Anmeldung Member der Gruppe sein. Due Musst Di für Dein Problem was Anderes einfallen lassen. Eventuell kann man hier über GPO's was machen. Siehe http://support.microsoft.com/kb/260370/en-us . Hier kenn ich mich leider zu wenig aus.

Unter der Voraussetzung dass der User kein Domain- oder Lokaler Administrator ist und das Script im User-Kontext ausgeführt wird, ist Dein Ansinnen zum Scheitern verurteilt. Wenn Du uns Deine Aufgabenstellung mal schilderst, kann der Eine oder Anderer User vielleicht eine alternative Lösung vorschlagen.

Ein User soll sich also in seinem Logon-Script eine Gruppenmitgliedschaft erteilen.. Vielleicht fällt Dir jetzt was auf ;)

Im Eventlog dürfte auch so Einiges stehen.

Hallo, was ist eigentlich das Ziel der Fragen? Du arbeitest doch nicht an einem konkreten Problem, oder? Deine Beispiele hören sich wie aus einem Lehrbuch abgeschrieben an. Wenn Du übst und lernst, installiere einen SQL-Server und probiere die Lösungsansätze selbst aus. Dabei können wir nicht helfen. -Zahni

In dem entsprechenden Event steht normalerweise das Gerät bzw. dessen IP-Adresse vom dem der fehlerhafte Logon erfolgte. Ist dies ein anderer Server oder PC schaut man in dessen Security-Eventlog (u.U. mal die XML-Ansicht öffnen) Die entsprechende Protokollierung muss natürlich Domänenweit aktiviert sein (per GPO).

Neulich lief APP-V 5.0 bei mir mal "Amok" und verbrauchte jeden verfügbaren "virtuellen" und physikalischen Speicher. Ursache war nicht ganz klar, wir haben da mal den alle getreamten Apps gelöscht und ein Hotfix installiert. Hier war es auch so, das sogar Netzwerkverbindungen ausfielen. Problem: Ich hatte damals auch keinen geeigneten Counter gefunden, weder im Taskmanager, noch im Process Explorer. Letztendlich fiel APP-V durch Eventlog-Einträge zu passenden Uhrzeit auf. Durch "killen" des Prozesses kamen wir dem Übeltäter auf die Spur. Kleine Anmerkung zu App-V 5.0: Das scheint derzeit stark auf Office 365 (Klick 6 Los, oder wie sich das nennt) zugeschnitten zu sein und ist wegen stark beschnittener Server-Funktionalitäten (von der völlig ****** GUI rede ich mal nicht) kaum noch vernünftig verwendbar. Kurzum: Was ist auf dem PC noch installiert außer Windows?

Warum soll eine LAN-CAPI nicht über VPN gehen? Dir Frage ist, ob es hier Latenz-Probleme gibt. Das musst Du leider ausprobieren.

Kannst Du dieser Version auf einem Server als virtuelle Maschine installieren? Wenn nicht: Schaue Dir die VDA-Lizensierung zu Windows 8 Enterprise an. Ich vermute mal, dass Du in PUR's ein paar Dinge vermischst, die nicht zusammen gehören.

Hast Du mal im Forum gesucht? Da steht wirklich Alles zum Thema.

OEM-Version haben generell keine VDA-Lizenz und dürfen nicht virtualisiert betrieben werden.

Beantworte trotzdem Die Frage von XP-Fan. Bei VDA ist es entscheidend aus welchem Vertriebskanal der Software stammt. Ansonsten gibt es hier ein paar ausführliche Threads zum Thema. Da wurde eigentlich schon alles geschrieben.

Wenn "net time \\srv-pdc /set" hilft, hast Du irgend anders einen Fehler gemacht. Der Befehl stammt auch der Steinzeit und sollte heute nicht mehr verwendet werden.

Wenn die BIOS-Einstellungen korrekt gesichert und alle externen Anschlüsse wie USB und Floppy deaktiviert sind, hilft ein TPM ohne PIN auch was. Denn die BIOS-Einstellungen können nicht geändert werden, ohne dass der TPM-Chip gesperrt wird. Ich würde auch einem Server relativ wenig "verwalten" . Hier sind passende Client-System vorzuziehen. Ansonsten lassen die entsp. Management-Tools natürlich installieren. Warum auch nicht?

Wenn "nichts" konfiguriert ist, kannst Du auch keine Remote-Verbindungen herstellen. Daher die Frage von Sunny.

Oder man schaut sich das mal mit Powershell an und schreibt die persistenten Daten in eine Text- oder XML-Datei.

Darum meine Fraje. Bitlocker macht auf einem Server nur begrenzt Sinn. Die Angriffsszenarien sind bei einem laufenden Server vielfältig. Der Bitlocker hilft dann auch nicht.

Vorsicht: Der Link "Meinhardt" enthält einen komplett überflüssigen Adware-Installer. Wem "Inno-Setup" was sagt.