deubi

Ach schade, ich habe schon gefrühstückt , sonst hätt ich mich gleich eingeklinkt... ;)

Als gemeinsamen Nenner sehe ich erst mal den bereits genannten Ansatz "Netzwerk"; ich würde mal Routerseitig den Traffic überwachen. --> Lässt sich das Phänomen provozieren? Wenn ja, geht's wesentlich einfacher, das zu verfolgen. Evt. auch mit einem Sniffer arbeiten, und gegebenenfalls mal den Leitungsprovider (DSL,Standleitung, was auch immer) mit einbeziehen. Die Jungs haben oft gutes KnowHow bei solchen Problemen (Zumindest hier in der Schweiz). Ich habe gelesen, dass es mit Webinterface geht, währenddessen der RDP-Client nicht mehr connectet. Wie ist der RDP-Client denn konfiguriert (Übertragen der lokalen Ressourcen)?

sieh mal hier: http://www.microsoft.com/learning/mcp/mcsa/windows2003/new.asp für Einsteiger http://www.microsoft.com/learning/mcp/mcsa/windows2003/experienced.asp für Erfahrene Die 282 ist hier nicht aufgeführt

Ich weiss nicht, wie das bei Euch läuft, aber ich muss meine Arbeiten auch in der internen IT rapportieren. Aber mal ganz ehrlich: kann es wirklich sein, dass Du nicht sicher aufzählen kannst, was Du den lieben langen Tag lang tust? Oder siehst Du den Wald vor lauter Bäumen nicht mehr? :suspect:

Ich empfehle "SQL für Dummies" für's Grundlegende; ist nicht vom DB-Derivat abhängig und bezieht sich auf die ANSI-Standards; den Titel darfst Du halt nicht ZU ernst nehmen. Ich persönlich greife sehr gern auf die OnlineReferenz/-Help (die kannst Du in mehreren Sprachen direkt von MS runterladen) von MS selber zu, die ist MS-unüblich wirklich sehr gut. Spezifisch zum MS-SQL schaden die dicken grünen von MS-Press zu den Prüfungen 70-228 und 70-229 sicher auch nicht; die haben im Trainingsstil für die "Alltagsvorbereitung" auch gute Übungen drin. Und wenn's technischer/anspruchsvoller werden soll, dürfte das Ressourcekit zu SQL interessant sein.

Sorry, aber C# und C++ sind m.E. KEINE Einsteigersprachen, dazu ist die C++-Syntax viel zu komplex. Und seine Frage hat sich in einem Windows-lastigen Thread auf Scripting bezogen. C würde nur gerade Sinn machen, wenn wir von Linux/Unix und Shellscripting sprechen würden - was nicht der Fall ist. Mit C/C++/C# hat er wirklich erst mal gar nichts für WIndows-Scripting gewonnen...

@ Marodeur: Du findest oben Postings mit vielen handfesten Hinweisen. Ich kenne den Switch nicht, den Ihr benutzt. Ist er manageable? Wenn ja, schau mal im Management nach, ob Du auf einem oder auch mehreren Ports Errors oder Kollisionen entdeckst. GGF. resetten, warten, bis das Problem wieder auftritt, festestellen, welche® Port betroffen ist --> Auslöser/Maschine eruieren. Wenn Du den Störenfried hast, check mal die Settings (gb/10/100MB/ Duplex etc) beidseitig, Switch UND Client.

Für Scripting auf Windows? Definitiv NICHT für VB- oder WSH-Scripts. Da liegst Du damit ziemlich daneben.

Also für DIESEN spezifischen Fall würde ich, falls keine Testinstallation vorhanden ist, den Eingriff für's Wochenende planen. Das Allererste wird dann sein, ein Image zu ziehen (Ghost, Driveimage oder was immer), und dieses Image zu prüfen, ob's auch funktioniert. Dann erst würde ich so einen Fall angehen, wo ich einen eher komplexeren Eingriff wage, ohne das je ausgetestet zu haben:immer mit Netz und doppeltem Boden... ;) Also wenn der Server wegen dieses Problems nicht gleich in die Knie geht, d.h. das Problem nicht gleich in den nächsten 5 Minuten gelöst sein muss würde ich sowas eben trotzdem zumindest auf einer virtuellen Installation (VMWare oder VPC) simulieren.

Was für Dich "gut" ist, hängt von Deinen Vorkenntnissen und Deinem Verständnis für Programmlogik etc. ab. Ich empfehle "Scripting für Administratoren",Tobias Weltner, MS-Press, ISBN 3-86063-633- 2 sowie "Inside Windows Scripting Host" von Günter Born, ebenfalls MS-Press, ISBN 3-86063-616-2. Beides sind ausgezeichnete Hilfen.

Jein - Falscher Ansatz; korrekt ist: unternehmenskritische Server MÜSSEN in einer Testumgebung abgebildet sein, wo Updates, Releases und Patches getestet werden MÜSSEN, bevor sie in ein produktives System eingespielt werden.

ok, ich bin fälschlicherweise von einem Installationsproblem ausgegangen, sorry. Du brauchst ja noch nicht mal eine physische Testmaschine; eine virtuelle würde ja bereits reichen (Dampf sollte der aber schon genügend haben). Sowas kannst Du, wenn Du keine Hardware zum Testen zur Verfügung hast mit VMWare oder VirtualPC lösen.

Ich würde erstmal die ja laut Deiner Aussage noch vorhandenen DB-Files mal in einer SQL-Testumgebung zu attachen versuchen. Wenn DAS klappt, dann hast Du bereits eine grosse Hürde überwunden; dann kannst Du Dir m.E. die Geschichte mit dem Band ersparen, soweit es SQL betrifft. Sofern Du eben die Security in SQL hinbiegen kannst.

Also, falls Du mit SQL nicht so sattelfest bist - so mein Eindruck, entschuldige, wenn ich falsch liege- und nicht direkt auf jemanden zurückgreifen kannst, der Dich da tatkräftig unterstützen kann, würde ich Dir DRINGENDST empfehlen, das Ganze in einer Testinstallation zu machen; d.h. dort die Daten zu restoren und auszuprobieren, ob und wie Du alles rekonstruieren kannst, und ERST DANN, wenn das klappt, das dann auch beim Kunden machst. Pauschalkunden? Wenn Euer Verkauf sowas offeriert, müsst Ihr eigentlich zumindest einen SQL-Spezi haben. Wie sieht's damit aus? :suspect: Entnehme ich das Deinem Posting vorhin richtig: der Server war nicht bloss SQL-Server, sondern auch gleich noch DC? :shock: Oder habe ich falsch verstanden, was Du meinst? Bei der gemischten Authentifizierung (nicht Modus) haben die lokalen Admins des Servers auch sa-Rechte in SQL, das ist nicht abhängig von der Zugehörigkeit zu einer Domäne.

Sowas würde ich nicht gleich an einem produktiven System austesten, das sieht für mich etwas abenteuerlich aus! Also erstmal: Testmaschine- ausprobieren Aber zuvor eine etwas doofe Frage: in welchem Modus läuft der Terminalserver? Hast Du in den Installationsmodus gewechselt? (Falls Du nicht weisst, wie: cmd-Line --> "change user /query" --> sollte auf Installation stehen)

ach so, keine Eigeninstallation. --> Arbeitszeit --> verrechenbar. Kein Problem Mit der Security meine ich die ganzen Logons, Passwörter etc innerhalb SQL mit den Settings der StandardDB's der Logins usw. Diese Daten sind im EntrepriseManager unter "Security" zu finden. Wenn Du die mdb- und ldf-Dateien hast, und die Security sonst rekonstruieren kannst, brauchst Du die Backups nicht. Ich habe die ganzen Tapegeschichten nicht mehr im Kopf; ich sichere SQL NIE auf Tape direkt, sondern habe maintenancePlans, die Files generieren (Bak & TRN), die werden wiederum mittels Tapebackup (Veritas) auf einer Jukebox "getaped". Ich meine mich aber zu erinnern, dass die Kataloge sich in einer der SystemDB's befinden; da Du die ja nicht wiederhergestellt hast, kriegst Du diese Fehlermeldung. Aber die Tapegeschichten waren noch nie meine Stärken, da kann ich leider nicht weiterhelfen :rolleyes: (die OnlineReferenz vom SQL-Server ist allerdings sehr stark!) Hast Du mal versucht, die alten User-Datenbanken mittels "attach" anzuhängen?

Ja, der Preis pro MB auf der InstallationsCD ist unschlagbar. Das ISO-Image auf MSDN ist grade mal etwa 22MB gross --> Preis hier in CH: sFr 42'000.-- Genial mag's ja sein, wenn Du jemanden hast, der Dich da drin instruieren kann, ich hab's als Autodidakt versucht- ich lasse die Finger davon

Stimmt. Vielleicht wäre für ihn das "Do-It-Yourself Script Center Kit" passender. Auf dem selben Link.

Hier wirst Du (oder Dein Kollege) geholfen: http://www.microsoft.com/technet/scriptcenter/createit.mspx

P.S: wenn die Originalen FIles des "gestorbenen Servers" noch verfügbar sind, und Du die Logins am SQL-Server sowie die Security händisch einrichten kannst, kannst Du die MDB- und LDF-Files auf den neuen Server rüberkopieren und dort attachen, mit minimalstem Zeitaufwand. Auch DAS gehört in ein DesasterRecovery-Szenario...

Mir ist da nun eins nicht klar: Du schreibst einerseits von BAK-FIles, die Du restoren willst, andererseits von MTF. Ja was denn nun? Die BAK-Files kommen ja sicher nicht vom Tape; die Bak-Files sind aber nur die Backups der DB-Files; wie siehts mit den TRN's (Backup der TLog's) aus? Übrigens: ein Desaster-Recovery-Szenario ist etwas, das man eben zumindest sporadisch mal durchziehen MUSS :rolleyes:

Wie sieht's aus mit Usern zwischen der Unix/Linux- und der MS-Welt abgleichen? Dort landest Du in der interessanten (und komplizierten) Welt der identity Integration.... MS hat da Tools wie den IIFP (Identity Integration Feature Pack), das kostenlos ist, oder das wesentlich funktionsstärkere, aber ebenso extrem teure MIIS (Microsoft Indentitiy Integration Service)

Dann konfrontier ihn doch einfach mal mit dem Scriptomat....

Ich will nochmals ganz zurück zum 1. Posting; dem gemeldeten Mangel an Fachkräften für IT-Netzwerke. Ich sehe's so, dass wir zwar im Applikations- und Serverbereich viele kompetente Fachkräfte haben, das aber im NETZWERKBEREICH eben tatsächlich ungleich dünner gessät ist. Ich selber suche und evaluiere beispielsweise einen neuen Mitarbeiter für mein Team. Das Profil ist so klar wie nur möglich beschrieben, mit Schwerpunkt auf Checkpoint-FW. Was sich da teilweise gemeldet hat, fand ich schon auch abenteuerlich. Die Anzahl der tauglichen Bewerber auf so eine Stelle ist x-Fach kleiner als wenn ich einen Systemengineer suche. @MCSE-Killer: es gibt viele Situationen, wo es Sinn macht, externe Partner beizuziehen. Gerade im (Re)Design und Engineering einer Infrastruktur ist ein "normaler" Admin (oft unbewusst) klar überfordert. Und in einer anfänglichen Betriebsphase macht es oft Sinn, solche externen Partner auf Kontingentbasis weiterhin beizuziehen. Oder auch, wenn die "Size" eines Aufgabenbereichs für einen Spezialisten zu klein ist und zu speziell, um dafür eine Teilzeitkraft zu finden.

Ich würde mir über solche Details nicht ZU viel Gedanken machen. 1000 Punkte "schiesst" sowieso niemand. Das Ziel ist ja, die Prüfungen zu bestehen. Das heisst, einen ausgewogenen Kenntnisstand zu erreichen. Eine Prüfung zu bestehen wird nicht abhängen von 1 oder 2 Fragen über Scripting.