frr

Hallo, ich finde es nicht besonders toll, wenn die Benutzer den Servernamen an der Freigabe sehen. Das hilft denen bei der Arbeit überhaupt nicht. Noch sinnfreier wird das, wenn ich mit versteckten Freigaben arbeite. Dadurch sehen die dann auch nich schön den Freigabenamen. Dadurch kann ich mir auch gleich die versteckte Freigabe sparen. Besser finde ich, wenn die Netzlaufwerke treffende Bezeichnungen haben. Probiere mal folgendes Skript aus: sDrive = "Z:\" Set oShell = CreateObject("Shell.Application") oShell.NameSpace(sDrive).Self.Name = "Datenlaufwerk" Viele Grüße Frank Röder

Hallo Markus, deaktiviere mal den Virenscanner. Wichtig ist auch, dass der Virenscanner nicht dateibasiert das Datenbankverzeichnis des Exchange scannt. Welchen AV setzt ihr denn ein? Was für ein Backupprogramm habt ihr? viele Grüße Frank Röder

Hallo, hast Du eventuell die bks Datei mit dem Notepad nacheditiert? Diese Datei ist glaube ich im Unicode Format. Das wird beim Abspeichern mit dem Notepad zerstört. Dadurch verdirbt sich dann ntbackup den Magen:D.

Hallo, das scheint soweit alles normal zu sein. Wurde denn in der letzen Zeit ein größerer Patchday oder auch eine Veränderung an den Netzwerkkarten vorgenommen. Ich könnte mir auch noch vorstellen, dass eventuell SNP dafür verantwortlich sein könnte. faq-o-matic.net » Gut gedacht, schlecht gemacht, hin & her: Scalable Networking Pack Viele Grüße Frank Röder

Hallo, wir reden hier über längere Bootzeiten die sich im Sekundenbereich bewegen. Wenn der Benutzer bei aktivierter Richtlinie etwa 10 - 20 Sekunden länger warten muss, dann ist das für mich kein Beinbruch, wenn ich dafür sicherstellen kann das meine Richtlinien ziehen. Viele Grüße Frank Röder

Hallo, warum willst Du denn genau diese Einstellung vermeiden? Das würde genau dein Problem beseitigen. Die Meldung, die Du bekommst hängt damit zusammen, dass der Client die Software installieren will aber es sind noch keine Netzwerktreiber geladen. Dadurch kann der Client das MSi Paket nicht aus der DFS Freigabe installieren. Deshalb kommt es zu der von Dir genannten Fehlermeldung. Du solltest also zwingend diese Richtlinie aktivieren. Es gibt auch nichts, was dagegen spricht. Übrigens ist die Installation von Software über GPOs ohne den Einsatz von DFS eine gefährliche Sache. Warum das so ist steht hier: Änderung Pfad MSI (Softwareverteilung) - microsoft.public.de.german.windows.gruppenrichtlinien | Google Groups Viele Grüße Frank Röder

Hallo, die Regkeys sind soweit in Ordnung. Bei den RPC Endpunkten fehlt mir noch eine Info. Welche Dienste sind denn auf der Kiste installiert? Wieviele DCs hast Du denn in der Domäne und auf welchen DCs hast Du diese Meldung? Ziehe bitte mal von den DCs ein dcdiag und poste die Ergebnisse hier. Viele Grüße Frank Röder

Hallo, jetzt solltest Du aber mal die Platte ordentlich checken. Solche korrupten Ordner lassen sehr eine beschädigte Platte vermuten. Ich würde dort nochmal genau nachhaken. Viele Grüße Frank Röder

Hallo, das sagt Dir doch aber schon die Fehlermeldung. Dein Bereich ist erschöpft. Dadurch kann der DHCP Server keine weiteren IP Adressen verteilen. Viele Grüße Frank Röder

Hallo, das scheint so zu passen. Kannst du mal posten, was auf den Servern sonst noch so unter "Clientprotocols" steht. Lade Dir mal von MS das Tool portqry herunter. Damit kannst Du prüfen, ob alle RPC Endpunkte vorhanden sind. portqry -n NameDesServers -e 135 Poste mal die Ausgaben hier oder hänge die als TXT File mit an. Viele Grüße Frank Röder

Hallo, das lässt sich leider beim Standard SMTP Server nicht so einfach über die GUI Umbiegen. Dafür benötigst Du das Tool Metaedit. Damit kannst Du die Metabase editieren und den Warteschlangenpfad ändern. Du solltest Dir aber lieber Gedanken machen, warum der Ordner beschädigt ist. Vielleicht droht Dir ein größerer Festplattenausfall. Viele Grüße Frank Röder

Hallo, schau mal hier: Using Microsoft’s log parser to analyse web server traffic | 90kts Dort wird Dir das was Du vorhast mit Logparser gezeigt. Viele Grüße Frank Röder

Hallo, die Frage ist, was Du damit erreichen willst. Willst Du es Kunden zur Anzeige bringen oder brauchst Du es nur für den Heimgebrauch. Diese Logfiles kann man beispielsweise mit "logparser" auswerten. Das ist als Kostenloser Download bei MS erhältlich. Wenn Du es etwas komfortabler willst und es auch etwas kosten darf, dann kann ich Smarterstats empfehlen. Das haben wir beim Webhosting im Einsatz. Viele Grüße Frank Röder

Hallo, prüfe mal in der Registry welche Einträge unter "HKEY_Local_Machine\Software\Microsoft\Rpc" vorhanden sind. Eventuell ist ja der Eintrag "RPC-Protokollsequenz: ncacn_ip_tcp" doppelt vorhanden. Normalerweise sollte dort "ncacn_ip_tcp REG_SZ rpcrt4.dll" stehen. Viele Grüße Frank Röder

Hallo, das ist zumindest standardmäßig nicht so. Da hat jemand an den Berechtigungen gefummelt. Du solltest mal in den Eigenschaften des Postfachspeichers prüfen, ob der Administrator die Rechte "Send as" und "Receive as" besitzt. Dadurch kann er nämlich alle darin enthaltenen Postfächer öffnen und auch für diese versenden. Viele Grüße Frank Röder

Hallo, ich kann mich da nur "cybquest" anschließen. Durch die neuen GPPs ist das Skripting nun fast überflüssig geworden. Damit lässt sich auch sehr elegant das Druckerproblem mit ein paar Mausklicks lösen. Alles was Du dafür brauchst ist ein Windows Vista SP1 und auf allen anderen Clients Windows XP mit den installierten GPPs. Download details: Group Policy Preference Client Side Extensions for Windows XP (KB943729) Die Powershell kannst Du für Login Skripts vergessen. Damit man die Powershell für Loginskripts verwenden kann, müsste vorher auf jedem Client die Powershell installiert werden. Das macht eher wenig Sinn. Für Loginskripts ist meine erste Wahl "VBScript". Das ist auf jedem System vorhanden und bietet ausreichend Funktionalität. Außerdem kannst Du Deine Kenntnisse gleich wiederverwenden wenn Du mal auf der Serverseite etwas skripten musst. Viele Grüße Frank Röder

Hallo, konfiguriere zusätzlich noch eine ordentlich Reverse Lookup Zone, die du natürlich auch AD integrierst. Dadurch bekommst Du auch nicht diesen Hinweis von nslookup, dass er zu der IP den Servernamen nicht finden kann. Grüße Frank Röder

Hallo, da gibt es zumindest keine Lösung mit ntbackup. Das ntbackup unter NT 4.0 erwartet immer ein Bandlaufwerk:-(. Was Du z.B nehmen könntest wäre Drive Snapshot - Disk Image Backup for Windows NT/2000/XP/2003/X64 Viele Grüße Frank Röder

Hallo Axel, Du musst den SMTP Namespace sharen: Für E2k7: Exchange 2007 SMTP Namespace Sharing and Different Relay Domain Types Für E2k3: Exchange 2003 SMTP Namespace Sharing Grüße Frank Röder

ich würde als Nächstes mal versuchen, den Treiber auf dem alten Printserver zu aktualisieren. Du kannst auch mal unter HKLM\SYSTEM\CCS\Control\Print\Environments für die entsprechende Architektur prüfen ob für diesen Drucker auch die ganzen notwendigen Dateien auf dem Dateisystem vorhanden sind. In der Registry findest Du die ganzen involvierten Dateien. grüße Frank Röder

Hallo, prüfe mal auf der Workstation ob dort eine ATI Grafikkarte installiert ist. Diese Karten bringen meist ein Controlcenter mit, was auch mit ALTGR Shortcuts bedient werden kann. Deaktiviere mal diese Shortcuts und versuche es erneut. Viele Grüße Frank Röder

Das bekommst Du so nicht hin. Die einzige Idee die ich hätte, wäre es einen Dienst zu schreiben. Im .net gibt es eine Klasse "FileSystemWatcher". Damit könntest Du das Verzeichnis auf neu erstellte Dateien überwachen und dann diese Dateien in ein Verzeichnis verschieben, was der FTP Nutzer nicht sieht. Viele Grüße Frank Röder

Hallo, prüfe bitte einmal ob die Treiber sogenannte Kernelmodustreiber sind. Dann sollte eigentlich auch beim Restore der Drucker eine entsprechende Fehlermeldung kommen. Wenn das so sein sollte, dann prüfe mal mit einem RSOP ob der Printserver die Rcihtlinie: Computerkonfiguration\Administrative Vorlagen\Drucker "Installation von Druckern, die Kernelmodustreiber verwenden.........." Viele Grüße Frank Röder