deubi

ich nominiere dieses Posting für den Tim-Taylor-Award

Hallo "MCSE_Killer". Es bringt nicht viel, auf diese Art einen Streit vom Zaun zu brechen. Ich denke, Dr. Melzer ist sicher bereit, Differenzen zwischen Euch per PN auszudiskutieren. Peace!

Nein, in der Hinsicht ist der Tipp von ITHome wohl passender. Versuch's erst in einem Testaufbau, bevor Du das im produktiven Netz machst

Na ja, Der hält mir die Offerte vor inklusive der SLA's mit den Lieferanten, und wir gehen von einer Redundanz in Form von 2 RZ's aus mit je einem SAN, die synchronisiert werden. Damit ist für die GL wiederum die Grundlage geschaffen, dass wir selber unsere SLA's unsern Kunden gegenüber erfüllen können. Eben gerade wenn ein Hersteller wie HDS SATA-SAN anbietet, mache ich mich lächerlich wenn ich behaupte, dass der nicht kompetent ist oder nicht fähig ist, eine SLA mit kurzen Reaktionszeiten zu erfüllen. Zumal ich nicht behaupten kann, damit jahrelang Erfahrung zu haben und die von uns evaluierten potentiellen Lieferanten ein professionelles Auftreten an den Tag gelegt haben

Danke *geschmeicheltfühl* Im Ernst: das ist eine Betriebskrankheit. Ich habe mir den MCDBA hart erarbeitet. ;) Ich empfehle DIr jedenfalls, einen Spezialisten vor Ort aufzubieten (vorzugsweise von Deinem Softwareanbeiter), der sich das Ganze nochmals anschaut. Wenn die Installation betriebskritisch ist, musst Du sie kontrollieren lassen. Oder wurde die Installation sogar von diesem Anbieter ausgeführt?

Lips: Deine Angaben sind etwas mager. Ich gehe davon aus, dass die Konfigurationsdaten, die Deine Benutzer ändern können sollen, sich nicht lokal auf deren Workstation befinden, sondern >vermutlich< in Form von Parametern in einer Konfigurationstabelle in der Applikationsdatenbank auf Deinem Server enthalten sind. Bloss: Über Datei- oder Netzwerkzugriff kannst und DARFST Du Deinen Benutzern so keinen Zugriff geben. Die Parameter würden, falls notwendig, über eine entsprechende Applikation geändert. Notfalls auch mittels Query Analyzer oder Entreprise Manager. Grundsätzlich: SQL-Clients connecten z.B. über ADODB, ODBC, OLEDB oder NamedPipes. Nichts davon hat etwas zu tun mit Shares oder NTFS. Das gilt auch für lokale SQL-Installationen: Zugriff auf den Inhalt der DB geht nur über diese Schnittstellen. Du kommst nicht über's FIlesystem an die darin enthaltenen Daten ran. WARNUNG nochmals: Keinen Filezugriff an die Benutzer geben geben auf den Programmordner auf dem Server, der SQL enthält! Wie weit bist Du mit SQL vertraut, hat's in Deinem Betrieb jemanden, der da sattelfest ist? Ist diese Applikations betriebswichtig? Falls Du gar keinen "zentralen" SQL-Server hast: Du schreibst ja, die Applikation liegt auf den Clients. Hat JEDER EINZELNE Client eine MSDE? Wenn ja, würde ich mich dringendst mit dem Hersteller in Verbindung setzen und abklären, ob Du das nicht zentralisieren kannst.

NACK Das ist eben der Unterschied zwischen Hacking und Cracking. Hacker haben an sich eine andere Intention als Unordnung zu stiften. Ich sehe KEINEN Widerspruch zwischen Hacking und Ethik. Aber zwischen "666" und Ethik...

Ohne jemanden angreifen zu wollen, frage ich hier mal bewusst provokativ: ist es glaubhaft, wenn sich jemand, der sich ...666 nennt, sich über ETHISCHES Hacking informiert :suspect: Ich persönlich habe da riesige Zweifel. Nehmt's mir bitte nicht übel, aber die Bedeutung von "666" und der Begriff "Ethik" widersprechen sich diametral. :wink2: OK, war OT. Zurück zum Thema

In Ergänzung meines vorhergehenden Postings: ich habe noch keine seriöse Applikation erlebt, die ich so sharen musste. Deshalb meine Skepsis. Ich gehe davon aus, dass in der Aufgabenstellung selber / dem Design eine grundlegende Fehlüberlegung drin steckt. Ich werde es TUNLICHST vermeiden, Benutzern Zugriff zu geben auf Applikationsverzeichnisse auf dem Server.

Vielleicht klärst Du uns auch über die ganzen Umstände detailliert auf, und wir kommen auf einen völlig anderen Lösungsansatz? Da Du Dich in Deinem Beispiel ausgerechnet auf einen Pfad namens "Datenbank" beziehst: Datenbankzugriff wird üblicherweise applikatorisch bewerstelligt und nicht durch Datei- oder Netzwerkdirektzugriff... Daher meine Nachfrage :shock:

Mit den Shadowcopy-Files ist es, wie mit anderen Files auch: die NTFS-Berechtigungen auf dem entsprechenden Volume/share anschauen. Übrigens: nichts gegen meine Kristallkugel - die war teuer!

Da fehlen halt bloss die speziellen übersinnlichen Wahrnehmungen. Wir sind leider OT --> bitte zurück zum Thema. Ähm.. was war denn das noch?

SB steht in diesem Fall für System Builder. Den verkauft MS, beziehungsweise die Distributoren ausschliesslich an Hardware-Wiederverkäufer, daher der günstige Preis. Als Endkunde wirst Du das Produkt im Normalfall nicht zu diesen Konditionen erwerben können. Die SBS-Spezi's hier auf dem Board - es hat mehrere davon - mögen mir bitte widersprechen, wenn ich etwas Falsches geschrieben habe.

Wir sprechen nicht von IDE. Dort gebe ich Dir recht. Aber: Es werden SAN-Lösungen von namhaften Herstellern auf Basis von SATA/SATAII angeboten. Das widerspricht ja dann Deiner Behauptung. Was das "sparen" betrifft: ich kann mein Budget nicht aus dem Ärmel zaubern. D.h. ich muss der GL schlüssig erklären können, wenn ich ein wesentlich teureres System haben will. Wenn auch namhafte Hersteller SATA-basierte SAN anbieten (beispielsweise HDS) , habe ich da ein Argumentationsproblem. Übrigens laufen auch unsere PC's (-->IDE) im 24hx365Tage-Dauerbetrieb. Die meisten mehrere Jahre lang ohne Ausfälle.

Für den Einsatz in der IT vorteilhaft ist FLÜSSIGKRISTALL :D

Um sowas vorzubeugen ist es empfohlen, einen SUS-Server einzusetzen, und dort empfangene Updates erst auf einem dedizierten Testsystem abzuchecken, bevor Du die Updates auf dem SUS-Server approvest. So kannst Du solchen Szenarien vorbeugen. Erst durch den Approval werden die Updates für die Netzwerkclients freigegeben. Die Clients müssen durch einen Registrykey, der auf den SUS-Server zeigen muss entsprechend konfiguriert. Nebenbei sparst Du damit Bandbreite auf Deinem Internetlink, weil nur noch der SUS-Server sich gegen aussen synchronisiert. Was Dein Problem betrifft, hast Du aktuelle Images der betreffenden Maschinen (Ghost oder ähnliches)? Da würde ich einfach mal ganz pragmatisch versuchen, die problematischen Updates per Uninstall zu entfernen

Weiters gibts auch Probleme, wenn Du Dateien zu kopieren versuchst, die "locked" sind, beispielsweise geöffnet durch eine Applikation oder sonst irgendwie im Zugriff.

Dann kläre ich das Problem mal auf: ein echter Profi guckt in die KRISTALLkugel, Glas is nix!! :rolleyes:

ergänzend zu lefg/ Ansatz Netzwerk: Habt Ihr mehrere Standorte, beispielsweise so verkabelt, dass ein "Loop" entstehen kann? Das kann hässliche Effekte verursachen. Ansonsten pflichte ich meinem Vorredner äähm -schreiber bei: Netzwerksniffer in Betrieb nehmen, Broad- und Multicasts mal anschauen.

Gibt's dazu Backgroundinfo? SATA ist ja mittlerweilen bei SAN's nichts mehr Ungewöhnliches. Ich möchte da gerne mehr dazu wissen, da bei uns ein Redesign im SAN-Bereich ansteht. Da ist sowas natürlich gut zu wissen. Danke!

Dynamische Datenträger sind ausserdem nochmals zusätzlich ein NO-NO, wenn Du wie wir Acronis8 einsetzt, um Images der Server zu erstellen. Acronis sieht nur Basic Disks.

kurzes Resümee: Du kannst mit keiner Netzwerkkomponente, egal welcher, die Adresse "8" verwenden. Denkansätze: -Das könnte z.B. deshalb sein, weil sie schon verwendet wird... dann müsste Ping antworten. Ausser, das Ding hat eine lokale F/W, die ICMP blockt. Hey, das solls ja auch geben. Allerdings müsstest Du im Fall einer Doppelbelegung eine entsprechende Fehermeldung kriegen - oder ein IDS, das sich einmischt. Wie sieht's in der Hinsicht aus? Wenn Du schreibst, das geschieht auch mit anderen Komponenten mit dieser IP, also beispielsweise PC's oder Servern oder sonstwas, dann sind das Geräte, die jeweils auf unterschiedlichen Ports am Switch connected sind? Wenn NICHT, dann würde ich mal den Switch, bzw Port auf dem betreffenden Switch genau anschauen. Ohnehin: ist es ein "managbarer" Switch? Wenn ja, schau Dir mal an, ob Du dort Fehler findest, Kollisionen oder Ähnliches. Nun: war die "IP 8" früher mal erfolgreich in Betrieb? Könnte es in diesem Fall sein, dass da seitens Switches oder evt. eines IDS geblockt wird, weil nun die "falsche" MacAdresse diese IP verwendet?

Full ack. Sogar die müssen teilweise "nacharbeiten". Ein Neuling kann mit normalen Mitteln NICHT innerhalb dieser Zeit auf seriöse Art die Zertifizierung erlangen.

Diese Relativierung ist aber schon wichtig: die Berufserfahrung, respektive Praxis, denn wenn Du den ersten Satz oben im Zitat auf einen "reinen Einsteiger" beziehst, ist er auf jeden Fall falsch.

Du hast das nicht ganz durchdacht. Wenn ich mit VNC connecte, und - wie zu erwarten- auf dem DC, auf den Du connectest niemand eingeloggt bist, dann verhielte sich das dann wieder identisch. Wäre das Problem eben die "Logon interaktiv"- Geschichte, dann ginge das mit VNC ebensowenig wie sonstwie. Mit VNC bin ich auf der "lokalen" Konsole drauf. Ist dann das selbe Problem. Ich hab's noch nicht getestet, denke aber, dass es auch auf einem DC reicht, die User der RDP-Usergruppe hinzuzufügen, damit das klappt. Ich werde diesen Test mal mit einer VPC-Session nachholen.