Joerg´s IT-Tech Blog

Microsoft Technologien und über den Tellerrand hinaus, Aber vorher das TESTEN nicht vergessen!

Posts Tagged ‘Problemlösungen’

AD CS Certificate Authority Web Enrollment certsrv nicht verfügbar

Posted by JoergS - 21. August 2013

Hi,

 

nach dem In-Place Upgrade unserer Enterprise CA von Windows Server 2008 R2 auf Windows Server 2012 war das AD CS Certificate Authority Web Enrollment (http://caservername/certsrv) nicht mehr verfügbar. Also auch im IIS war kein Web oder Verzeichnis zu sehen.

ad-cs-certsrv-missing

ad-cs-certsrv-missing

Lösung war die Reinstallation des Rollendienstes AD CS Certificate Authority Web Enrollment

server-manger-remove-roles-features  server-manger-remove-roles-feature-ad-cs

Dann konnte man auch wieder im IIS das Web sehen

ad-cs-certsrv

ad-cs-certsrv

und per Browser auf die CA zugreifen

ad-cs-http-certsrv

ad-cs-http-certsrv

Na dann, Viel Spass beim selber Testen!
CU

Posted in Active Directory, Fehler | Verschlagwortet mit: , , , , , | 1 Comment »

Exchange secure TLS connection could not be established

Posted by JoergS - 2. Juli 2013

Hi,

unser SCOM meldete ein Problem auf unserem Exchange Server, ein Send-Connector hatte Problem beim Empfang von Emails mit der TLS Verbindung. Der Exchange Server (2010 SP3 UR1) hatte dann auch diverse Eventlog Einträge:

A secure connection to domain-secured domain ‚kundendomain.de‘ on connector ‚Internet Mail SMTP (EX2010-1)‘ could not be established because the validation of the Transport Layer Security (TLS) certificate for kundendomain.de failed with status ‚UntrustedRoot. Contact the administrator of kundedomain.de to resolve the problem, or remove the domain from the domain-secured list.

Der Fehler lies sich auf im SMTP-Recieve Log genauer nachvollziehen:

2013-07-02T00:00:13.216Z,ex2010-1\SMTP,08D03639B8BBE13F,15,10.1.2.3:25,123.456.789.10:13322,>,220 2.0.0 SMTP server ready,
2013-07-02T00:00:13.216Z,ex2010-1\SMTP,08D03639B8BBE13F,16,10.1.2.3:25,123.456.789.10:13322,*,,Sending certificate
2013-07-02T00:00:13.216Z,ex2010-1\SMTP,08D03639B8BBE13F,17,10.1.2.3:25,123.456.789.10:13322,*,“CN=mail.WIRdomain.de, OU=IT, O=WIR GmbH, L=Stadt, S=““““, C=DE, SERIALNUMBER=9jdU6QQyv3BEg/AadaIO/pbD2ZT4gtdw“,Certificate subject
2013-07-02T00:00:13.216Z,ex2010-1\SMTP,08D03639B8BBE13F,18,10.1.2.3:25,123.456.789.10:13322,*,“CN=GeoTrust SSL CA, O=““GeoTrust, Inc.““, C=US“,Certificate issuer name
2013-07-02T00:00:13.216Z,ex2010-1\SMTP,08D03639B8BBE13F,19,10.1.2.3:25,123.456.789.10:13322,*,01332C,Certificate serial number
2013-07-02T00:00:13.216Z,ex2010-1\SMTP,08D03639B8BBE13F,20,10.1.2.3:25,123.456.789.10:13322,*,306306CD1B566DF1663165FCE9C3897B9BCEB89D7AA,Certificate thumbprint
2013-07-02T00:00:13.216Z,ex2010-1\SMTP,08D03639B8BBE13F,21,10.1.2.3:25,123.456.789.10:13322,*,mail.WIRdomain.de;autodiscover.WIRdomain.de;smtp.WIRdomain.de,Certificate alternate names
2013-07-02T00:00:13.310Z,ex2010-1\SMTP,08D03639B8BBE13F,22,10.1.2.3:25,123.456.789.10:13322,*,,Received certificate
2013-07-02T00:00:13.310Z,ex2010-1\SMTP,08D03639B8BBE13F,23,10.1.2.3:25,123.456.789.10:13322,*,C025E0C35B3B93DEE21CC2E9477AF4E56047BD0C,Certificate thumbprint
2013-07-02T00:00:13.310Z,ex2010-1\SMTP,08D03639B8BBE13F,24,10.1.2.3:25,123.456.789.10:13322,*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,25,10.1.2.3:25,123.456.789.10:13322,<,EHLO smtp.kundendomain.de,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,26,10.1.2.3:25,123.456.789.10:13322,*,,TlsDomainCapabilities=’None‘; Status=’Success‘; Domain=“
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,27,10.1.2.3:25,123.456.789.10:13322,>,250-smtp.WIRdomain.de Hello [123.456.789.10],
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,28,10.1.2.3:25,123.456.789.10:13322,>,250-SIZE 51445760,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,29,10.1.2.3:25,123.456.789.10:13322,>,250-PIPELINING,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,30,10.1.2.3:25,123.456.789.10:13322,>,250-DSN,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,31,10.1.2.3:25,123.456.789.10:13322,>,250-ENHANCEDSTATUSCODES,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,32,10.1.2.3:25,123.456.789.10:13322,>,250-AUTH,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,33,10.1.2.3:25,123.456.789.10:13322,>,250-8BITMIME,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,34,10.1.2.3:25,123.456.789.10:13322,>,250-BINARYMIME,
2013-07-02T00:00:13.326Z,ex2010-1\SMTP,08D03639B8BBE13F,35,10.1.2.3:25,123.456.789.10:13322,>,250 CHUNKING,
2013-07-02T00:00:13.357Z,ex2010-1\SMTP,08D03639B8BBE13F,36,10.1.2.3:25,123.456.789.10:13322,<,MAIL FROM:<vorname.nachname@kundendomain.de> SIZE=16517,
2013-07-02T00:00:13.357Z,ex2010-1\SMTP,08D03639B8BBE13F,37,10.1.2.3:25,123.456.789.10:13322,*,,Client certificate chain validation status: ‚UntrustedRoot‘
2013-07-02T00:00:13.357Z,ex2010-1\SMTP,08D03639B8BBE13F,38,10.1.2.3:25,123.456.789.10:13322,*,Tarpit for ‚0.00:00:05‘,
2013-07-02T00:00:18.371Z,ex2010-1\SMTP,08D03639B8BBE13F,39,10.1.2.3:25,123.456.789.10:13322,>,454 4.7.5 Certificate validation failure,
2013-07-02T00:00:18.371Z,ex2010-1\SMTP,08D03639B8BBE13F,40,10.1.2.3:25,123.456.789.10:13322,<,RCPT TO:<vnachname@WIRdomain.de>,
2013-07-02T00:00:18.371Z,ex2010-1\SMTP,08D03639B8BBE13F,41,10.1.2.3:25,123.456.789.10:13322,*,Tarpit for ‚0.00:00:05‘,
2013-07-02T00:00:23.385Z,ex2010-1\SMTP,08D03639B8BBE13F,42,10.1.2.3:25,123.456.789.10:13322,>,503 5.5.2 Need mail command,
2013-07-02T00:00:23.385Z,ex2010-1\SMTP,08D03639B8BBE13F,43,10.1.2.3:25,123.456.789.10:13322,<,QUIT,
2013-07-02T00:00:23.385Z,ex2010-1\SMTP,08D03639B8BBE13F,44,10.1.2.3:25,123.456.789.10:13322,>,221 2.0.0 Service closing transmission channel,

Das Problem war, dass der Kunde sein Internes SAN-Zertifikat zusätzlich auch am SMTP Service zugewiesen hatte. Dadurch wurde dieses interne Zertifikat von seiner internen ROOT CA als Authentifizierung, per TLS gegenüber unserem Exchange benutzt.

exchange-certs

exchange-certs

LÖSUNG: Da wir aber dem internen ROOT CA Cert seiner CA nicht vertrauen funktionierte der Mailversand bei Ihm und Empfang über unseren Recieve-Connector nicht mehr. Da aber ein öffentliches SAN-Zertifikat vorhanden ist und auch an dem SMTP-Service hängt wurde das interne SAN-Zertifikat vom SMTP-Service entfernt.

Somit funktionierte auch der E-Mail Versand zwischen dem Kunden und uns wieder mit TLS Verschlüsselung zwischen den Exchange Servern.

Na dann, Viel Spass beim selber Testen!
CU

Posted in Exchange, Fehler | Verschlagwortet mit: , , , , , , | Leave a Comment »

Outlook Social Connector – XING

Posted by JoergS - 1. Juli 2013

Hi,

wir verteilen bei uns gerade die neue Version vom Outlook Social Connector  und dem XING Connector. Bei dem Xing-Connector gabe es jedoch ein Problem.
Ist der Rechner im internen Netzwerk, kann keine Verbindung mit dem Xing-Server hergestellt werden:

outlook-social-xing-connector

outlook-social-xing-connector

Da wir als Proxy TMG einsetzen, sind die Aufrufe nicht authentifiziert:

tmg-xing-blocked

tmg-xing-blocked

LÖSUNG:

Eine Ausnahme Regel für die IP 2.18.249.135 (Akmai Server) erstellen.

tmg-rule-wihout-proxy

tmg-rule-wihout-proxy

tmg-akmai-server

tmg-akmai-server

Dann funktioniert auch der Zugriff auf die XING Konatke:

tmg-xing-allowed

tmg-xing-allowed

Na dann, Viel Spass beim selber Testen!
CU

Posted in Edge, Fehler, Forefront | Verschlagwortet mit: , , , , , , | 1 Comment »

Windows 8 WWAN Fehler Telekom UMTS – Benutzername Kennwort falsch

Posted by JoergS - 22. Mai 2013

Hi,

heute berichtet mir ein Kollege, dass sein WWAN, also die Telekom UMTS Verbindung mitten in der Verbindung abgebrochen ist und sich die Verbindung auch nicht wieder aufbauen ließ.

Ein Test bei meinem Notebook brauchte den gleichen Fehler:

Der Benutzername oder das Kennwort ist falsch, Versuchen sie es noch mal. Zur Aktivierung des Dienstes an Telekom wenden.

telekom-umts-fehler

telekom-umts-fehler

 

Der Fehler lag tatsächlich an der der Telekom, denn heute morgen funktionierte meine UMTS Verbindung wieder und auch die des Kollegen. War wohl ein temporäres UMTS Problem bei der Telekom.

Na dann, Viel Spass beim selber Testen!
CU

Posted in Fehler, UC | Verschlagwortet mit: , , , , , | Leave a Comment »

Ferrari Officemaster Gate und Exchange 2010 Fax Voicemail Problem UnAuthenticatedPilotNumber

Posted by JoergS - 1. März 2013

Hi,

wir hatten in den letzten Tagen ein Problem mit unserem Ferrari Officemaster Gate. Ich konnte meine Voicemailbox auf unserem Exchange Server 2010 (SP2 + RU5v2) nicht mehr erreichen und auch kein Fax mehr erhalten.

Im UM-Log des Exchange 2010 Server war diese Meldung zu sehen:

03/07/2013 14:53:39,UnAuthenticatedPilotNumber,sip_isdn-92-1362668017,,EX2010Server,028f34d8-ce6a-4f26-b29d-97440bf53de7,Dialplan-Standort,3,omg.domain.local,59c2b0fff5df4103b5a3fee3fe85128a,125@10.10.10.102,+491721234567,Answer,None,DivertNoAnswer,,,mmustermann,,,

Grund war, dass das OMG eine andere EUM Adresse auf dem Exchange anwählt: 125@10.10.10.102 statt 125@ex2010server.domain.local

Darum habe ich jetzt bei jedem Benutzer, der eine UM-Mailbox aktiv hat auch die 1XX@10.10.10.102 als EUM Adresse eingetragen.

OMG-EUM-Adresse-EX2010

OMG-EUM-Adresse-EX2010

Na dann, Viel Spass beim selber Testen!
CU

Posted in Exchange, UC | Verschlagwortet mit: , , , , , , , | Leave a Comment »

TMG 0x80070008 ERROR_NOT_ENOUGH_MEMORY

Posted by JoergS - 21. Januar 2013

Hi,

ein Kunde von uns mailte mich heute heute an, dass er im TMG Log den Fehler „TMG 0x80070008 ERROR_NOT_ENOUGH_MEMORY“ erhält.

tmg-error0x80070008

tmg-error0x80070008

Eine Suche nach dem Fehler im Internet führte uns nur zu Artikeln über ISA 2006 und auch nicht zu dem Problem, was hier vorlag.

Nach einer weiteren Suche in der Konfig, fand sich dan der Fehler:

Es wird eine SIP Kommunikation per Port 5060 aufgebaut. In der TMG Konfig war das SIP Protokol mit dem Port 5060 aber 2x als Protokol angelegt, einmal als SIP und CustomWebkonferenz.

Nach dem Löschen des doppelten Protokolls und der nicht mehr benötigten Firewall Regeln, trat der Fehler dann auch nicht mehr auf.

Na dann, Viel Spass beim selber Testen!
CU

Posted in Edge, Fehler, Forefront | Verschlagwortet mit: , , , , , , | Leave a Comment »

Sharepoint 2010 Rapid SSL Root Zertifikat und Event 8311 The root of the certificate chain is not a trusted root authority

Posted by JoergS - 8. Januar 2013

Hi,

wir hatten gleich zu Beginn des Jahres einen merkwürdigen Fehler. Ein SSL Zertifikat musste erneuert werden, weil es demnächst ausgelaufen wäre.
Das SSL Zertifikat war von RapidSSL ausgestellt und sollte dort auch verlängert werden. Also wurde ein neuer CSR erstellt, eingereicht und das Zertifikat auch verlängert. Sowohl das Zertifikat als auch die Root und Intermediate CA (Geotrust Global CA und Rapid SSL) wurden auch in die richtigen Stores des Zertifikatsspeichers importiert.
Somit wurde das Zertifikat auch als vertrauenswürdig in Windows angezeigt.

zertifikat-rapidssl-geotrust

zertifikat-rapidssl-geotrust

Die Root und Intermediate CA waren also auch vertrauenswürdig.

Somit konnte das Zertifikat auch im IIS auf die SharePoint Portal Seite des SSL Listeners gebunden werden. Soweit alles ok. Das Intranetportal lief auch und präsentierte das neue Zertifikat.
Jedoch wurde ein Fehler in einer Anwendung im SharePoint Portal angezeigt:

sharepoint-fehler

sharepoint-fehler

Wir fragten uns was der Fehler soll, schließlich hatten wir doch vorher Berechtigungen die Anwendung zu nutzen.

Ein Blick ins Eventlog zeigt jedoch, dass der Fehler nichts mit Berechtigungen, sondern mit dem Zertifikat und der Root CA zu tun hatte:

Event ID 8311
Fehler eines Vorgangs, weil das folgende Zertifikat Überprüfungsfehler aufweist:\n\nAntragstellername: CN=sharepoint.domain.de, OU=Domain Control Validated – RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)13, OU=GT41352274, SERIALNUMBER=P-gD9zahFo-ThnVTNSrJxW/RQeVZSOhc\nHerausgebername: CN=RapidSSL CA, O=“GeoTrust, Inc.“, C=US\nFingerabdruck: EF7595B2510659D06B0BB477AC53B3A75106CCFE\n\nFehler:\n\n The root of the certificate chain is not a trusted root authority.

Eigentlich konnte das ja nicht sein, denn das Zertifikat wurde von Windows als vertrauenswürdig anerkannt.

Ein suchte brachte uns dann aber die Lösung. In der SharePoint Central Administration unter Sicherheit mussten die Root/Intermediate CA noch als Vertrauensstellung eingetragen werden:

sharepoint-manage-trust01

sharepoint-manage-trust01

sharepoint-manage-trust02

sharepoint-manage-trust02

Dann funktionierte sowohl das Portal als auch die Anwendung in dem SharePoint Portal.

Na dann, Viel Spass beim selber Testen!
CU

Posted in Fehler, Probleme | Verschlagwortet mit: , , , | Leave a Comment »

Windows NPS Server und Root Certificate Update KB931125 (Dez2012)

Posted by JoergS - 13. Dezember 2012

Hi,

heute hatten wir durch das Root Certificate Update KB931125 (Dez2012) auch ein Problem mit Windows NPS (Radius) Server.

Hier war der Fehler im Eventlog durch das zu sehen:

Log Name:      System
Source:        Schannel
Date:          13.12.2012 09:20:28
Event ID:      36887
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Computer:      NPS1.domain.local
Description:
The following fatal alert was received: 47.

Event Xml:
<Event xmlns=“http://schemas.microsoft.com/win/2004/08/events/event„>
<System>
<Provider Name=“Schannel“ Guid=“{1F678132-5938-4686-9FDC-C8FF68F15C85}“ />
<EventID>36887</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime=“2012-12-13T08:20:28.224687400Z“ />
<EventRecordID>565797</EventRecordID>
<Correlation />
<Execution ProcessID=“616″ ThreadID=“5788″ />
<Channel>System</Channel>
<Computer> NPS1.domain.local</Computer>
<Security UserID=“S-1-5-18″ />
</System>
<EventData>
<Data Name=“AlertDesc“>47</Data>
</EventData>
</Event>

Es konnten keine Clients mehr per NPS/RADIUS authentifiziert werden!

Hier half auch nur das Löschen der Root Certificates aus dem Store, von 367 sind es jetzt nur noch kanpp 50.

Trusted-Root-CAs

Trusted-Root-CA´s

Na dann, Viel Spass beim selber Testen!
CU

Posted in Fehler, Windows Server, Windows Server 2003, Windows Server 2008 | Verschlagwortet mit: , , , , | Leave a Comment »

FTP Uploads von kleinen Dateien bricht ab Gateway ISA2006

Posted by JoergS - 6. Dezember 2012

Hi,

ein Kunde meldete sich heute bei mir, er hat ein Problem mit dem Upload von vielen kleinen FTP Dateien zu einem Zielsystem. Sein eigenes Netz ist durch einen ISA2006 abgegrenzt.

Beim Transfer (Upload) von einer oder mehreren (10) großen Dateien gab es keine Probleme. Aber wenn er viele kleine Dateien (mehrere Hundert) von seinem Rechner zum Zielsystem transferieren wollte, wurden X Dateien transferiert und danach brach der Client die Verbindung ab.

Im ISA2006 Live Logging waren aber keine Fehler erkennbar, zum Zeitpunkt des Abbruchs.

Nach einigen Tests und Troubleshootings haben wir dann mal, zum Test die Flood Mitigation vom ISA2006 deaktiviert.

isa-flood-mitigation-settings

isa-flood-mitigation-settings-disable

Nach der Deaktivierung funktioniert der komplette Transfer aller Dateien ohne Unterbrechungen. Also war zumindest grob die Ursache der Unterbrechungen ausgemacht.

Nach weiteren Analysen und Tests haben wir die „Maxium Half-open TCP Connections“ als Ursache ausgemacht, da der FTP Client für jede Datei eine Verbindung herstellt.
Da die Werte für die „Maxium Half-open TCP Connections“ aber nicht änderbar sind muss man, die „“Maxium concurrent TCP Connections per IP Address“ vom Standardwert (160) erhöhen, hier z.b. 260.

isa-flood-mitigation-settings-tcp-concurrent

isa-flood-mitigation-settings-tcp-concurrent

Damit ändern sich auch die  „Maxium Half-open TCP Connections“ von 80 auf 130 (immer die Hälfte).

isa-flood-mitigation-settings-tcp-halfopen

isa-flood-mitigation-settings-tcp-halfopen

Somit kann der FTP Client jetzt ohne Unterbrechungen erfolgreich alle Dateien per FTP hochladen.

Na dann, Viel Spass beim selber Testen!
CU

Posted in Edge, Fehler, Forefront | Verschlagwortet mit: , , | Leave a Comment »

Windows 8 WSUS Error 800B0001

Posted by JoergS - 8. November 2012

Hi,

wir rollen nach und nach Windows 8 Enterprise in der Firma aus. Dabei haben wir ein Problem festgestellt, dass die Windows 8 Clients immer Fehler beim Abrufen der Windows Updates vom internen WSUS Server (auf SCCM 2012) erhielten.

Error 800B0001

LÖSUNG: Die Installtion des WSUS Hotfix KB2734608 und auf dem Client

NET Stop wuauserv
RD/s %windir%\softwaredistribution\
Net Start wuauserv

Dann sync der Client auch mit dem WSUS Server!

Na dann Viel Spass, beim selber Testen!
CU

Posted in Probleme, Windows 8, WSUS | Verschlagwortet mit: , , | Leave a Comment »

 
%d Bloggern gefällt das: