Wisi

Hallo,

habe heute über das LiveUpdate unser Symantec BackupExec aktualisiert. Soweit hat das funktioniert. Allerdings hat das Update scheinbar einen Fehler in der SQL Datenbank erzeugt. Seit dem Update bekomme ich folgende Meldung:

SQL Server hat einen logischen, konsistenzbasierten E/A-Fehler gefunden: incorrect pageid (expected 1:152; actual 60415:642179558). Der Fehler ist beim read von Seite (1:152) in der Datenbank mit der ID 2 bei Offset 0x00000000130000 in der Datei 'C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\tempdb.mdf' aufgetreten. Weitere Informationen finden Sie möglicherweise in anderen Fehlermeldungen im SQL Server-Fehlerprotokoll oder im Systemereignisprotokoll. Dies ist ein schwerer Fehler, der die Datenbankintegrität bedroht und sofort behoben werden muss. Führen Sie eine vollständige Überprüfung der Datenbankkonsistenz aus (DBCC CHECKDB). Dieser Fehler kann durch viele Faktoren verursacht werden. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation.

seitdem funktioniert auch backup exec letztlich nicht mehr, da die datenbank korrupt zu sein scheint.

genau das gleiche ist mir an dem server schon mal passiert mit backup exec, da hab ichs noch auf zufall geschoben und hab das backup exec neu installiert und erst mal ne weile ohne update laufen lassen - alles wunderbar. dann update und wieder das.

hat jemand eine idee wie ich das gelöst bekomme?

backup exec nutzt übrigens einen sql server 2005 express als db.

so

problem gelöst. server noch mal neu installiert und gleich danach die aktuellsten treiber eingespielt, seitdem gehts. scheint also problematisch zu sein, wenn man vorher schon ältere versionen mit dem fehler drauf hatte...

kleine ergänzung: NIC Teaming Server 2008 R2, NIC Team...

das ja ne tolle sache :( funktioniert aber bei uns leider nicht die lösung.

Hallo,

also auch mit den neuen Treibern und der Erstellung des Teams über das Proset Tool kein Unterschied. Macht auch kein Unterschied ob der Switch managed ist oder nicht (natürlich dann nur mit der Lastenverteilung ohne SLA oder LACP).

Hi,

ich glaub in dieser Version haben wirs noch nicht installiert.

Gebildet wurde das Team über die Treiber im Gerätemanager direkt. Proset war nicht installiert.

Ip wurde über die Team Nic gesetzt, bei den anderen sind ja auch die protokolle gar nicht mehr gebunden.

aufgrund der unterschiedlichen versionen hatten wir dann auch mal nur die dual port karte genommen fürs teaming, selbes ergebnis.

probieren jetzt noch mal die version, die ist ja jetzt relativ neu. evtl. steuert das proset die karten auch anders als der treiber selbst beim teaming.

werde dann berichten

Hi,

folgende Karten und Versionen:

Intel 82574L - Treiber 11.7.32.0

Intel 82578DM - Treiber 11.6.92.0

Intel Pro/1000 PT Dual Port Server Adapter - Treiber 9.13.41.0

Hallo zusammen,

wir haben einen neuen Server aufgesetzt mit Windows Server 2008 R2.

In diesem sind zwei Intel Netzwerkschnittstellen on board und eine gesteckte Karte mit Dual Port.

Soweit funktionieren auch alle 4 Ports, sowohl mit statischer IP Adresse, als auch mit DHCP.

Probleme gibts allerdings beim Teaming der NICs über die Intel Treiber im Gerätemanager.

Sobald man zwei (oder mehr) Ports bündelt (bspw. als Load Balance) funktioniert der Datentransfer nur noch mit aktiviertem DHCP.

Bei statischer IP Adresse funktioniert nichts mehr. Selbst wenn man nur pingen möchte kommt immer: "Fehler bei der Datenübertragung".

Löst man das Team wieder auf und gibt einer einzelnen NIC diese IP Adresse funktioniert alles bestens.

Wir haben sowohl reines Load Balance (das ohne Konfiguration auf jedem Switch funktioniert), als auch Static Link Aggregation, als auch Dynamic Link Aggregation mit LACP probiert. Die Diagnose mit "Switch testen" ergab, dass auch die Port Konfiguration korrekt war. Trotzdem flossen mit statischer IP keinerlei Daten, mit DHCP immer ohne Probleme.

Hatte schon wer das Problem?

So,

hatte das ganze in der Zwischenzeit mit Wlan verifizieren können. Der gleiche Fehler, nur die Meldungen in Windows sehen anders aus.

Hab dann das Stammstellen Zertifikat auf dem Client noch mal gelöscht und mir neu geholt über die certsrv Seite und nu gehts.

Ist also gelöst. Beruhigend, dass der Fehler nicht in der Konfiguration lag, sondern der Client sich wohl nur in irgendeiner Art und Weise an dem Stammstellen Zertifikat verschluckt hat.

hi

schön, dass jemand antwortet.

Genutzt wird derzeit das Standardzertifikat, welches eingerichtet wird bei Installation der Zertifikatsstelle (so schauen auch die Basic Howtos aus). Auf dem Client ist kein Zertifikat installiert, dort ist nur die entsprechende Stammzertifizierungsstelle installiert (passiert ja automatisch durch die Domäne).

Ich nutze PEAP ohne Zertifikat am Client. Das ganze funktioniert wie gesagt schon mit Benutzerauthentifizierung und Zertifikatsprüfung. Nur Computerauthentifizierung und Zertifikatsprüfung schlägt fehl mit dem Fehlercode 801.

Hallo zusammen,

habe heute mal ein bisschen "rumgespielt" um mal zu testen, wie in der vorhandenen Infrastruktur die Implementation von 802.1x geht.

Eingerichtet:

- Zertifikatsstelle auf dem 2003 DC

- Internetauthentifzierungsdienst

- HP ProCurve mit dem Connect zum Radius

Es funktioniert auch alles schon wunderbar, solange ich mich via Benutzer authentifziere.

Stelle ich nun bei meinem Testclient (Windows XP SP3) ein, dass er sich nicht via User, sondern via Computer authentifzieren soll (siehe How to enable computer-only authentication for an 802.1X-based network in Windows Vista, in Windows Server 2008, and in Windows XP Service Pack 3), dann habe ich ein Problem.

Ich sehe am IAS, dass die Anfrage über das Computerkonto geschieht und nicht mehr über das Benutzerkonto. Soweit so schön. Die Voraussetzung in der Ras Richtlinie (Zugehörigkeit zu einer Gruppe) ist auch erfüllt.

Jetzt prüft der Client aber das Zertifikat des Servers und läuft auf den Fehler 801 (Diese Verbindung ist für die Bestätigung der Identität des Zugriffservers konfiguriert. Es können jedoch keine vom Server gesendeten digitalen Zertifikate verifiziert werden.).

Jedoch kann das ja nicht sein, da es bei Authentifzierung über das Benutzerkonto perfekt läuft. Sonst müsste er da ja bei der Prüfung des Zertifikats auch schon meckern. Oder habe ich da was übersehen?

Wenn ich in der Authentifzierung "Serverzertifikat überprüfen" abschalte, funktioniert es auch wunderbar mit dem Computerkonto.

Aber ich will ja eigentlich zwingend die Gegenstelle prüfen um sicher zu gehen mit wem ich kommuniziere?

Hat wer das gleiche Problem schon gehabt oder eine Lösung? Logfiles etc. kann ich gerne liefern.

nur als kleine info und zur vollständigkeit, falls noch mal wer danach sucht (ja ich hatte den fehler erneut ;) )

nach dienst stopp den in der meldung genannten ordner catalog.wci löschen. dieser wird nach dienst neu start neu angelegt und dann sollten die fehler weg sein. bei mir ist seitdem in der hinsicht absolute ruhe.

hi,

danke für die bestätigung, ging auch um das drumherum, aber scheint ja soweit zu passen. :)

zwei dinge, warum nicht:

- offiziell keine treiber unterstützung seitens dell (power edge sc1425)

- keine lizenz für diesen server angedacht für 2008 (vorhanden sind welche)

ließe sich wahrscheinlich beides lösen schätze ich...

vielleicht installiere ich auch mal kurz einen 2008 r2 zum test drauf und sehe mal wie die hardwareunterstützung ist (unabhängig von der offiz. unterstützung). auf die "paar" minuten kommts im verhältnis zum ergebnis dann auch nimmer an. danach kann ich dann die lizenz beantragen, wir kriegen die sowieso über einen rahmenvertrag mit vlk.

Hallo zusammen,

ich habe eine untergeordnete Domäne mit einem einzigen DC (Windows 2003 R2 x32 Server).

Jetzt würde ich das Ding aufgrund des erhöhten Arbeitsspeicherbedarfes gerne auf x64 upgraden.

Meine Idee war grob die folgende:

- Daten sichern auf dem DC, inkl. aller DBs etc (evtl. noch ein Image zusätzlich)

- Virtuellen zweiten Server erstellen, diesen zum zusätzlichen DC in der untergeordneten Domäne machen

- Rollen übertragen auf den virtuellen Server

- ursprünglichen DC herabstufen und löschen

- Server mit x64 Version installieren und wieder als DC einfügen

- Rollen zurück transferieren

Oder habt ihr einen ganz anderen Vorschlag?

seitdem keine klagen mehr, scheint zu passen

danke.

Hi,

problem gefunden, wie so immer, wenn man dann mal dachte man findets nimmer...

How to configure SQL Mail to use an Internet mail server by using Outlook 2003

In Microsoft Outlook 2002 and in later versions, the MAPI spooler runs in process. Therefore, you must start Outlook 2003 so that SQL Mail can send and receive e-mail messages through an Internet mail server. If Outlook 2003 is not running, SQL Mail can only send and receive e-mail messages through a mail server that is running a version of Microsoft Exchange. When Outlook 2003 is not running, outgoing messages remain in the Outbox folder until you start Outlook 2003.

We do not recommend that you use Outlook 2002 or Outlook 2003 together with SQL Mail and with Internet mail servers that use SMTP or POP3.

Hallo zusammen,

wir wollten unserem SQL 2000 jetzt mail Email beibringen um uns informieren zu lassen, wenn Wartungsaufträge durchgelaufen sind.

Gesagt, getan.

Ausgangssituation:

- Windows Server 2003 SP2

- Office 2003 mit Outlook SP3

- SQL Server 2000 SP3

Getane Schritte:

- Outlook Profil eingerichtet -> getestet, funktioniert

- SQL Server -> SQL Mail eingestellt -> Test ok

- SQL Server Agent -> Mailprofil eingestellt -> Test ok

- Operator erstellt, Emailadresse eingetragen -> test nicht ok

- Wartungsaufträge geändert -> Operator eingetragen

- Reboot Server

- Er sagt, dass er Mails versendet und alles erfolgreich wäre, aber dem ist nicht der Fall.

Eigentlich alles korrekt eingestellt nach dem Guide bei MS, aber das ****e Ding sendet keine Mails. Habe schon umgestellt auf SMTP ohne Auth um sicherzugehen, dass nicht das SMTP Auth das Problem ist, aber auch das wars nicht.

Jemand eine Idee? Gibt es irgendwo ein detailliertes Log zur SQL Mail Funktion? Ich konnte keinerlei Log finden, wo etwas dazu steht, was genau er gemacht hat beim Testversand.

gute idee, ließe sich auch als transparenter proxy über die vorhande zugangslösung einbinden (technisch alles vorhanden).

aber das geht leider nicht, siehe weiter oben.

wegen bits müsste ich ja zugriff auf die clients haben, den hab ich ja nicht, daher denke ich das in dem fall auch

da mach ich mir bei unserem maschinenpark keine größeren gedanken

darauf kommts auch nicht mehr an, wenn du verstehst was ich meine ;)

so

um das mal zu ergänzen: habe den davor sitzenden lancom umkonfiguriert, dieser macht nun qos, entsprechend haben wir damit nicht mehr so viele probleme :)

das war mir soweit klar ;)

negative nebeneffekte waren eher gemeint.

aber danke für die positive bestätigung, dann werd ich morgen mal die umsetzung wagen :)

hallo

danke für den tipp, werd ich mal versuchen

welche nachteile hat die richtlinie denn oder aktiviert ihr die standardmäßig?

Hallo zusammen,

ich habe ein Problem mit einigen Benutzern in Zusammenhang mit deren Basisordner.

Der Witz ist, dass der Fehler nur sporadisch auftritt und eigentlich alles richtig ist.

Wir verbinden in unseren Domänen das Netzlaufwerk U: als Basisordner mit einem share in der Form: \\server\user$\username

Funktioniert auch soweit eigentlich wunderbar. Nur bei zwei Benutzern tritt in letzter Zeit häuft das Problem auf, dass der Client das Laufwerk U: mit folgendem Pfad mountet "\\server\user$\"

Er hört praktisch im Root auf mit der Pfadverfolgung, wenn man so will.

Man kann dann U: trennen und neu mit dem korrekten Pfad verbinden, funktioniert problemlos. Zudem ist das Problem meist bei einer neuen Anmeldung (kein Reboot) nicht mehr zu beobachten und alles stimmt wieder.

Jemand eine Idee oder das gleiche Problem?

Gerne kann ich das für dich tun ;)

In Foren erachte ich das allerdings nicht als so schlimm, der Inhalt und die Sprache (vor allem der "Tonfall") erscheint mir wichtiger :)

Du hast natürlich Recht bezüglich der vielen Live Update Funktionen. Jedoch war zumindest zum Zeitpunkt der Analyse das Hauptproblem beim Windows Update zu suchen.

Ich werde das Problem der fehlenden Bandbreite so nicht zu 100% lösen können, ich denke das ist allen in diesem Thread klar. Wie gesagt hoffe ich auch, dass dieses Thema mit der Einführung von "RAM" bei der Telekom auch endlich von meinem Tisch kommt. So lange muss ich allerdings sehen, dass meine Gäste bzw. die Gäste meines Unternehmens zufrieden sind und auch kleine Ansätze helfen hier.

Diverse Ansätze sind auch beim Hersteller unserer Zugangslösung im Test und ich hoffe da kommt was bei raus.

die liegen eben nicht in meiner hand (wie oben geschrieben). nicht immer ist man herr aller dinge :(

aber ich habe eben auch noch mal mit dem hersteller gesprochen, da tut sich was für das problem. evtl. lösen wir das in zukunft auch über ein qos feature, womit wir die priorität für die adressen deutlich senken. das wäre mir auch lieber als zu blocken.