Micodat

Noch zur Erklärung: 192.168.100.114 ist der Windows DNS Server 192.168.100.204 ist die Adresse, die ich bei Stammhinweise eingetragen habe und beim PING bekommen möchten 'ipconfig /flushdns' habe ich gemacht, ebenso wie Neustart des Servers, des PCs, Funktion "Cache löschen" auf dem DNS-Server, ...

System: Windows 2008 Server R2 64Bit Ich möchte einen Internet-Namen auf eine lokale IP umleiten. Ich könnte zwar an jedem PC in der lokalen 'hosts' Datei einen entsprechenden Eintrag machen, eine Server-gestützte Lösung ist mir aber lieber. Die PCs haben in der IP Konfiguration als DNS nur den Windows Server drin. Auf dem Windows-DNS-Server habe ich den entsprechenden Eintrag unter 'Stammhinweise' angelegt. Unter 'Weiterleitungen' ist nichts eingetragen, so dass er die Anfragen auch nicht weiterleiten sollte. Wenn ich vom PC aber jetzt ein PING fahre, kommt immer noch die Internet-IP des Namens und nicht die lokale IP aus dem 192.168er Netz: ping owa.axx.de Ping wird ausgeführt für owa.axx.de [217.86.139.137] mit 32 Bytes Daten: Wenn ich jetzt ein NSLOOKUP auf dem PC mache, kommt: nslookup owa.axx.de Server: axxlocal-dc2.axx.local Address: 192.168.100.114 Name: owa.axx.de Address: 217.86.139.137 D.h. der DNS Server schickt schon die richtige lokale IP, aber bei der Namensauflösung wird die falsche genommen. Was muss ich am DNS Server noch ändern, damit das PING von den Workstations die 192.168.er IP bekommt? Ciao Frank

System: Windows 2008 Server R2 (64 Bit) Exchange Server 2010 IIS 7 Bisher war auf dem Server ein selbst-signiertes Zertifikat im Einsatz. Outlook hat das so akzeptiert, beim Zugriff von extern über OWA https://firma/owa gab es natürlich eine entsprechende Meldung, dass das kein gültiges Zertifikat ist. Jetzt haben wir uns bei Thawte ein gültiges Zertifikat gekauft, installiert und dem Service "IIS" zugewiesen (die Services IMAP, POP und SMTP sind weiter an das alte Zertifikat gebunden) Der Zugriff von extern über OWA funktioniert jetzt ohne Probleme, das Zertifikak wird als gültig anerkann. Jetzt macht aber Outlook Probleme: Obwohl das Zertifikat an den PC's (WinXP und Win7) als Administrator (vertrauenwürdige Stammzertifikate) und als User installiert wurden, kommt beim Start von Outlook zweimal die Fehlermeldung, dass das Zertifikat ungültig ist. Hintergrund ist, dass das Zertifikat auf unseren externen Firmennamen (z.B. "firma.de") ausgestellt ist, der interne Server-Name des Exchange-Servers, den Outlook verwendet, aber natürlich ein anderer ist. Daher passt für Outlook der Server-Name im Zertifikat nicht mit dem Server-Namen des Exchange-Servers zusammen. Wie bekomme ich es hin, dass OWA das Zertifikat benutzt, Outlook aber nicht? Oder wie kann ich es wenigstens schaffen, die lästigen Fehlermeldungen zu vermeiden, wo das Zertifikat doch auf dem PC installiert ist? Ciao Frank

XAMPP von ApacheFriends 1.7.1 Modul

Leider nicht: Der Eine bekommt eine saubere Fehlermeldung beim Starten des Apache, die fehlt bei mir. Bei mir kann also scheinbar php_oci8.dll erfolgreich geladen werden. Der Andere hat die falsche PHP.INI erwicht. Das ist bei meinem Fall auszuschliessen, da das Ein- und Ausschalten von extension=php_oracle.dll erfolgreich ist. Ciao Frank

System: Office 2010 / Echange Server 2010 / Windows 2008 R2 Der Benutzer hat eine Mail im Eingang, auf die er bereits geantwortet hat. Outlook: Der Benutzer klickt auf die Mail, sie wird in der Vorschau angezeigt und als Info steht oben in grau: "Sie haben am .... auf diese Nachricht geantwortet" Soweit alles richtig. OWA: Der Benutzer klickt auf die Mail. Aber anstatt dieser Mail wird in der Vorschau die Antwort-Mail angezeigt (da vom Datum her neuer). Will man die Mail sehen, auf die man geklickt hat, muss man in der Vorschau nach unten scrollen, die Nachricht suchen und dort öffnen. Wie/wo kann dieses gänzlich unpraktische Verhalten korrigiert werden? (OWA -> Optionen -> Mail -> "Neuste Nachricht unten" bringt nichts, dann steht zwar die alte oben, ist aber trotzdem nicht geöffnet. Noch schlimmer ist es, wenn es paar Mal hin und her geantwortet wurde, dann findet man die Mail, auf die man geklickt hat, gar nicht mehr) Ciao Frank

System: WinXP sp3 Apache 2.2 / PHP 5.2.9 (von apachefriends.org) Oracle 10g Win32 Client Der Oracle Client funktioniert, ODBC Zugriff auf Oracle geht, PATH verweist auf das Client-Verzeichnis und TNS_ADMIN auf das Verzeichnis mit TNSNAMES.ORA. phpinfo() zeigt mit folgendes Configure Command an: cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--with-snapshot-template=d:\php-sdk\snap_5_2\vc6\x86\template" "--with-php-build=d:\php-sdk\snap_5_2\vc6\x86\php_build" "--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared" Die Oracle Treiber sind also dazugebunden. In der PHP.INI ist das Extension-Verzeichnis richtig gesetzt: extension_dir = "C:\Programme\xampp\php\ext\" dieses Verzeichnis enthält auch die php_oci8.dll Wenn ich in der PHP.INI Oracle freigebe: extension=php_oracle.dll ;extension=php_oci8.dll erscheint in phpinfo() der Oracle-Eintrag. Wenn ich aber OCI8 freigeben möchte: ;extension=php_oracle.dll extension=php_oci8.dll erscheint nicht der "OCI8" Eintrag bei phpinfo(). Es kommt aber beim Starten von Apache auch keine Fehlermeldung und auch im EventLog steht kein Eintrag. Die dll wird aber tatsächlich nicht geladen, die Benutzung von "oci_connect()" bringt einen "Call to undefined function" Ich habe jetzt auch schon versucht, die Oracle Client dlls zusätzlich ins %systemroot%\system32 zu kopieren, hat aber auch nichts gebracht. Hat noch jemand eine Idee, warum die php_oci8.dll nicht lädt, aber es auch keine Fehlermelldung gibt? Ciao Frank

Hi, Server: Windows 2008 R2 64Bit mit IIS 7.5 Ich habe auf dem IIS zwei Zertifikate installiert: 1.) Ein selbst-zertifiziertes, dass auf den internen Servernamen läuft (z.B. 'MySvr08'), und das auch von Exchange verwendet wird 2.) ein gekauftes, das auf den Namen den externen Servernamen läuft (z.B. 'myserver.de') Wenn ich jetzt intern (z.B. den PC's des Firmen-Netzwerkes) auf den Server zugreife (z.B. 'https://MySvr08/owa) soll das 1. Zertifikat verwendet werden. Wenn ich von extern (z.B. INet-Cafe) auf den Server zugreife (z.B. 'https://myserver.de/owa), soll das 2. Zertifikat verwendet werden. Von alleine erkennt es scheinbar der IIS nicht, welches Zertifikat er verwenden soll. Wo kann ich ihm das sagen? Ciao Frank

Ich denke, es lag an folgendem Registry Eintrag: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update] "NetworkPath"="\\\\linuxsrv14\\netlogon\\ntconfig.POL" "UpdateMode"=dword:00000002

Hier noch ein paar zusätzliche Infos: - das Benutzerprofil ist vom Typ 'Lokal' - Es hängt wohl mit MS-Office 2010 zusammen: wenn ich den Eintrag korrigiere und dann Outlook starte, ist er nach dem Start wieder falsch - ich kann das Problem umgehen, indem ich dem Benutzer und System die Schreibrechte auf diesen Key der Registry wegnehme. (Ich bekomme aber keine Meldung, wer vergeblich versucht hat, zu schreiben) - die GPO habe ich mit RSOP.MSC geprüft: da habe ich nichts gefunden, das damit zu tun haben könnte. - legen ich einen neuen lokalen User an, passiert das bei dem nicht.

Hi, System ist ein Sony Vaio Notebook mit WinXP sp3. In der Firma war er bisher an eine Domäne angeschlossen, die unter Linux/Samba lief. Seit ein paar Wochen wurde die Domäne auf Windows Server 2008 R2 (mit Exchange 2010) geändert. Seit dieser Zeit macht der lokale User Probleme (also der Account, unter dem ich mich anmelde, wenn ich den Laptop ausserhalb der Firma verwende): In der Registry unter HKCU -> Software -> Microsoft -> Windows -> Current Version -> Explorer -> Shell Folders stehen alle Einträge auf C:\Dokumente und Einstellungen\username, nur der Eintrag Personal steht auf "\\linuxsrv14\u34" "linuxsrv14" ist der alte Linux-Server. Dadurch habe ich, wenn ich als lokaler User angemeldet bin, lauter System-Hänger, weil viele Programme auf das Verzeichnis zugreifen wollen und dann das System die Time-outs abwartet. Ich kann zwar in der Registry den Wert korrigieren, aber nach dem nächsten Login ist wieder der falsche drin. (nach dem Logout ist noch der korrigierte Wert drin, habe ich über den lokalen Administrator überprüft). Jetzt muss ich herausfinden, welches Programm mir diesen Wert beim Login wieder kaputt macht. Ich habe alle Programme aus dem Autostart Ordnern (User und AllUsers) entfernt. Ausserdem habe ich alle Einträge in der Registry aus dem 'Run' und 'RunOnce' Pfaden entfernt (auch sowohl unter HKCU als auch HKLM) und danach neu gestartet. Trotzdem ist nach dem Login der 'Personal' Pfad wieder geändert von C: auf den Server. Da das ganze beim Login-Vorgang geschieht, kann ich auch RegMon nicht einsetzen, da das ja während des Logins nicht läuft. Hat noch jemand eine Idee, wie ich herausfinden kann, welches Programm mir den Eintrag zerschiesst? Ciao Frank

gelöst: Ich habe im Exchange eine neue Zertifikats-Anforderung angelegt, dann bei Thawte neue ssl Zertifikate gekauft, diese (incl. Thawte root und Zwischenz.) neu installiert und die Services neu zugeordnet. jetzt läuft alles wieder.

openssl s_client -debug -connect (server):443 Loading 'screen' into random state - done CONNECTED(00000768) write to 0xa905c8 [0xa90610] (142 bytes => 142 (0x8E)) 0000 - 80 8c 01 03 01 00 63 00-00 00 20 00 00 39 00 00 ......c... ..9.. 0010 - 38 00 00 35 00 00 88 00-00 87 00 00 84 00 00 16 8..5............ 0020 - 00 00 13 00 00 0a 07 00-c0 00 00 33 00 00 32 00 ...........3..2. 0030 - 00 2f 00 00 45 00 00 44-00 00 41 00 00 07 05 00 ./..E..D..A..... 0040 - 80 03 00 80 00 00 05 00-00 04 01 00 80 00 00 15 ................ 0050 - 00 00 12 00 00 09 06 00-40 00 00 14 00 00 11 00 ........@....... 0060 - 00 08 00 00 06 04 00 80-00 00 03 02 00 80 f6 97 ................ 0070 - d5 55 c4 d3 0a fe 4f 1e-a7 f8 77 01 13 07 f9 33 .U....O...w....3 0080 - 48 a3 be de 24 66 89 a5-6e 51 d7 20 c5 56 H...$f..nQ. .V read from 0xa905c8 [0xa95b70] (7 bytes => -1 (0xFFFFFFFF)) write:errno=10054

Ja, über http:// kann ich alle Seiten ansprechen netstat -ano | find "443" TCP 0.0.0.0:443 0.0.0.0:0 ABHÖREN 4 TCP [::]:443 [::]:0 ABHÖREN 4 Prozess 4 ist system An der Firewall kann es nicht liegen, bis zum Zertifikatswechsel haben alle https:// Zugriffe problemlos funktioniert Ciao Frank

Wenn ich den IE8 lokal starte und auf ein https://localhost, https:/127.0.0.1 oder https://servername/... Verzeichnis zugreifen möchte, kommt nur die lapidate Meldung: Die Webseite kann nicht angezeigt werden. und auch der Button "Diagnose bei Verbindungsproblemen" kann das Problem nicht lösen. Ciao Frank

Das gleiche: Der Server hat die Verbindung zurückgesetzt openssl s_client -connect (server):443 Loading 'screen' into random state - done CONNECTED(00000768) write:errno=10054

Hi, System: Win2008 Server R2 64 Bit mit IIS 7.5 bisher habe ich mit einem selbstsignierten Zertifikat gearbeitet, was auch funktioniert hat, aber immer in den Browsern entsprechende Fehlermeldungen provoziert hat. Jetzt habe ich mir bei Thawte ein gültiges ssl Zertifikat gekauft und installiert (incl. das Thawte Root Zertifikat und das Zwischenzertifikat). Sieht alles soweit OK aus, Hierarche wird sauber abgezeigt. Dann bin ich in die IIS MMC und habe das Zertifikat installiert. Dann kam mein Fehler: (nehme ich jedenfalls an) Die zwei vorhandenen (selbstausgestellten) Zertifikate habe ich gelöscht. Jetzt habe ich nur noch das Thawte-Zertifikat drin. Ergebnis: http Seiten werden weiterhin angezeigt, aber bei https Seiten kommt im Browser nur noch die lapidare Meldung, dass der Server die Verbindung zurückgesetzt hat. Ich finde aber im Ereignisprotokoll auch keinen Hinweis. Ich habe dann in der IIS MMC wieder ein neues Zselbstausgestelltes Zertifikat gemacht, und den Server neu gestartet, hat aber auch nichts gebracht. Hat jemand ne Idee, wie ich https/ssl wieder hinbekomme? Ciao Frank