Everyday Digital » windows

HowTo: ODBC 32-Bit / 64-Bit

WWW-KR — Tue, 07 Sep 2010 19:30:27 +0000

Seit Windows 2003 findet die 64-Bit Version der Betriebssysteme immer größere Verbreitung. Den aktuellen Windows 2008 R2 Server gibt es nur noch als 64-Bit Version. Die Gründe sind bekannt und sprechen für 64-Bit.
Jetzt müssen wir mit Anwendungen, die über die ODBC Schnittstelle auf Datenbanken zugreifen aufpassen, sonst gibt es prompt, die Fehlermeldung:
Folgende(r) Fehler trat(en) auf: [Microsoft][ODBC Driver Manager] Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf
Diese Meldung erscheint, wenn eine 32-Bit Anwendung über einen 64-Bit ODBC-Treiber versucht auf die Datenbank zuzugreifen, oder umgekehrt.
Jetzt hat leider Microsoft unter Systemsteuerung -> Verwaltung lediglich zugriff auf die 64-Bit Version von ODBC vorgesehen. Wenn ich aber einen 32-Bit Konnektor installiere, taucht er dort nicht auf und kann dort auch nicht eingerichtet werden.

Folgende Schritte helfen hier weiter:

Taucht im Taskmanager hinter dem Namen der Anwendung ein *32 auf, handelt es sich um eine 32-Bit Anwendung, die auch einen 32-Bit ODBC-Konnektor verlangt. Also werden zunächst die 32Bit ODBC-Treiber installiert. Danach geht es über C:\Windows\SysWOW64\odbcad32.exe (nicht durch SysWOW64 verwirren, es ist der 32-Bit System32 Ordner) zum 32-Bit ODBC-Schnittstelle. Hier den Konnektor sauber einrichten und schon läuft die 32-Bit Anwendung mit Datenbank-Anbindung sauber.

Befindet sich im Taskmanager hinter dem Namen der Anwendung kein *32, handelt es sich um eine 64-Bit Anwendung. Hier kann die Konfiguration der ODBC Konnektoren unter Systemsterung -> Verwaltung oder direkt durch Aufruf von C:\Windows\System32\odbcad32.exe (nicht durch die 32 irritiren lassen, es ist der 64-Bit Teil des OS) erfolgen.

w32/wecorl.a False Positive – Danke McAffen

WWW-KR — Thu, 22 Apr 2010 08:00:32 +0000

Gestern Abend, plötzlich bei diversen Kunden und wenigen Rechnern in unserem Unternehmen: Reboot auf Reboot, Taskleiste funktioniert nicht, keine Netzwerkdienste und nur wenige Dienste gestartet. Was ist passiert? Der erste Gedanke eine neue Malware geht um und wird noch nicht von den Scanneren erkannt, aber in den Newstickern ist nicht zu finden. Also ging es selber auf die Fehlersuche und nach etwas umschauen ist der Fehler erkannt. McAfee hat die svchost.exe Datei in Windows XP Rechnern als schädliche Software erkannt und in die Quarantäne verschoben, deswegen funktioniert fast nichts auf den Rechnern.

Die Manuelle Lösung kam per Mail, kurz nachdem ich den Fehler schon selber eingegrenzt und am ersten Rechner behoben habe:

Emergency DAT 5959 has been posted and is available at http://www.mcafee.com/apps/downloads/security_updates/dat.asp. This file is available in English and is replicating in other languages. For MORE information, go to the 5958 DAT Report on http://vil.nai.com/vil/5958_false.htm.

================================
UPDATE (12:47pm US/CDT)

McAfee is aware that a number of corporate customers have incurred a false positive error due to incorrect malware alerts. Our initial investigation indicates that the error can result in moderate to significant performance issues on systems running Windows XP Service Pack 3.

The 5958 DAT has been removed from McAfee download servers, preventing any further impact to corporate customers. McAfee teams are working with the highest priority to support impacted customers and plan to provide an update virus definition file shortly. You can view information at https://kc.mcafee.com/corporate/index?elq_mid=2363&elq_cid=1499606&page=content&id=KB68780 (NOTE: system is currently slow) or the McAfee Community at http://community.mcafee.com/docs/DOC-1374/

We will notify you of an emergency update when available, or in 90 minutes.

================================
ORIGINAL EMAIL (11:06am US/CDT)

McAfee is aware of a w32/wecorl.a false positive with the 5958 DAT file April 21 at 2:00pm (GMT +1). McAfee advises NOT to download this DAT. Please disable pull tasks and update tasks.

Information updates will be sent every 90 minutes to keep you advised.

Die Mail mit einer Automatisierung hat McAfee heute morgen nachgereicht:

McAfee has developed a SuperDAT remediation Tool to restore the svchost.exe file on affected systems.

Q: What does the SuperDAT Remediation Tool Do?
A: The tool suppresses the driver causing the false positive by applying an Extra.dat file in c:\program files\commonfiles\mcafee\engine folder. It then restores the svchost.exe by looking first in %SYSTEM_DIR%\dllcache\svchost.exe, if not present it will attempt a restore from %WINDOWS%\servicepackfiles\i386\svchost.exe, if not present it will attempt a restore from quarantine. After the tool is run, the machine needs to be rebooted.

Recommended Recovery SuperDAT Procedure
1. From a machine that has Internet access, locate and download the Recovery SuperDAT at http://download.nai.com/products/mcafee-avert/tools/SDAT5958_EM.exe and save it to portable media.
2. Take the portable media to each affected machine and run the tool. If you are not able to run the tool on the affected machine, boot in safe mode
3. Execute the Recovery SuperDAT tool
4. Reboot in normal mode
5. Use the product update to update to 5959

For additional FAQs and information, go to https://kc.mcafee.com/corporate/index?elq_mid=2373&elq_cid=1499606&page=content&id=KB68780 which will remain up to date.

================================
UPDATE #4 (7:38pm US/CDT)
McAfee has published recovery procedures for the following two scenarios:
• Recommended Manual Recovery Procedure using the Extra DAT where DAT 5958 is currently installed
• Alternate Manual Recovery Procedure using DAT 5959 where DAT 5958 is currently installed
This information has been posted on http://vil.nai.com/vil/5958_false.htm and will be continuously updated as more information and procedures become available.

================================
UPDATE #3 (2:55pm US/CDT)
Emergency DAT 5959 has been posted and is available at http://www.mcafee.com/apps/downloads/security_updates/dat.asp. This file is available in English and is replicating in other languages. For MORE information, go to the 5958 DAT Report on http://vil.nai.com/vil/5958_false.htm.

================================
UPDATE #2 (12:47pm US/CDT)
McAfee is aware that a number of corporate customers have incurred a false positive error due to incorrect malware alerts. Our initial investigation indicates that the error can result in moderate to significant performance issues on systems running Windows XP Service Pack 3.
The 5958 DAT has been removed from McAfee download servers, preventing any further impact to corporate customers. McAfee teams are working with the highest priority to support impacted customers and plan to provide an update virus definition file shortly. You can view information at https://kc.mcafee.com/corporate/index?elq_mid=2373&elq_cid=1499606&page=content&id=KB68780 (NOTE: system is currently slow) or the McAfee Community at http://community.mcafee.com/docs/DOC-1374/
We will notify you of an emergency update when available, or in 90 minutes.

================================
ORIGINAL EMAIL (11:06am US/CDT)
McAfee is aware of a w32/wecorl.a false positive with the 5958 DAT file April 21 at 2:00pm (GMT +1). McAfee advises NOT to download this DAT. Please disable pull tasks and update tasks.

Information updates will be sent every 90 minutes to keep you advised.

UPDATE
Spät aber immerhin:

Heise: Signatur-Update von McAfee macht Windows-PCs unbenutzbar
Golem: McAfees Virenscanner legt Windows-Systeme lahm

Mail mit Anhang über Kommandozeile versenden

WWW-KR — Wed, 07 Apr 2010 21:39:23 +0000

Im Zeitalter der grafischen Oberflächen mag sich der eine oder andere Fragen, wozu man noch über die Kommandozeile Mails versenden soll und dann auch noch mit Anhang.

Genau vor dieser Aufgabe stand ich heute aber selber. Es sollte eine automatisch generierte PDF-Datei an Kunden und Mitarbeiter versendet werden. Das ganze war als Batch-Datei geschrieben und sollte nun einfach noch versendet werden. Da es mit einfachen Telnet nicht funktioniert einen Anhang mit zur versenden, machte ich mich auf die Suche nach der Lösung.

Schnell kam ich auf das kleine und freie Programm Blat. Es übergibt schnell und einfach eine Mail an einen SMTP-Server (z.B. Exchange in meinem Fall). Mit einer recht einfachen Zeile Code ist es möglich die Mail inc. Anhang zu versenden, z.B.:
blat.exe -to empfänger@domain.tld -f absender@domain.tld -u absender@domain.tld -pw AbsenderKennwort -server smtpsrv.domain.tld -s Betreff -body "Nachricht selber" -attacht "C:\ordner\Anhang.xxx"

So kann mit Authentifizierung beim Server versendet werden. Ist eine Authentifizierung nicht erforderlich, entfallen die Optionen -u und -pw.
Über die Syntax von Blat kann man noch diverse andere Möglichkeiten nutzen, fast wie bei einem grafischen Mail-Client.

V2V – schnell und einfach

WWW-KR — Sun, 21 Feb 2010 22:03:52 +0000

Wenn man die Virtualisierungswelt wechseln möchte kann es schwierig werden. In meinem Fall beim Wechsel vom Hyper-V ins VMware vSphere 4 Lager wollte es nicht ganz so schön und schnell klappen, wie ich es mir vorgestellt habe. Beim Versuch mit dem VMware vCenter Converter dauerte es und die Belastung auf dem Hyper-V war auch nicht ohne. Theoretisch kann man es so machen, aber praktisch nicht bei mehr als einer oder zwei Maschinen, es sei den man hat Geduld und Zeit.

Bei der Suche nach einer schnellen und akzeptablen Lösung bin ich über etliche verschiedene und Aufwendige Wege zur diesem Thema gestoßen. Aber auch meine Lösung war tief unter vergraben. Der StarWind V2V Converter von StarWind Software Inc. ist frei erhältlich, klein und sehr schnell. Es wurde in meinem Fall lediglich aus der VHD Platte eine VMDK gemacht und fertig. Die neue Hardware ist schnell zusammengeklickt und mit dem Einspiele der VMware-Tools vorab umgeht man Bluescreens oder andere Störungen nach dem konvertieren.

Eine einfache und schnelle virtual to virtual Lösung

Immer wieder MSExchangeTransport 12014

WWW-KR — Sat, 09 Jan 2010 15:16:10 +0000

Wenn Exchange 2007 Probleme mit dem SMTP Zertifikat feststellt, wird das Anwendungsprotokoll mit dem Ereignis 12014 vom MSExchangeTransport überschwemmt.
In der Meldung heisst es:

Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen “mail.domain.tld” im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für den Connector “Internet” mit einem FQDN-Parameter von “mail.domain.tld” nicht unterstützt werden. Überprüfen Sie die Connectorkonfiguration sowie die installierten Zertifikate, damit sichergestellt wird, dass ein Zertifikat mit einem Domänennamen für jeden Connector-FQDN vorhanden ist. Wenn das Zertifikat vorhanden ist, führen Sie “Enable-ExchangeCertificate -Services SMTP” aus, damit sichergestellt ist, dass der Microsoft Exchange-Transportdienst auf den Zertifikatschlüssel zugreifen kann.

Was die Meldung eigentlich sagen möchte ist, es braucht nur das Zertifikat dem SMTP Dienst zugewiesen werden. Dazu werden in der Exchange-Verwaltungsshell zunächst die vorhandenen Zertifikate ausgelesen mit, Get-ExchangeCertificate | FL *.
In meinem Fall waren drei Zertifikate vorhanden und ich musste zunächst das richtige raussuchen, dazu einfach den Eintrag in der Zeile CertificateDomains überprüfen. In der Zeile Services kann man überprüfen welchem Dienst das Zertifikat zugewiesen ist.

Jetzt muss noch der 40-stellige Thumbprint vom richtigen Zertifikat kopiert werden, dieser wird jetzt benötigt.
Mit dem Befehl: Enable-ExchangeCertificate -Thumbprint (40-stelliger Thumbprint ohne die Klammern) -Services "SMTP" wird nun das Zertifikat dem SMTP Dienst zugewiesen und es folgen keine weiteren Fehler mehr im Systemprotokoll.