none
Falsche URL verweise werden external im hintergrund aufgerufen https://mandant.contoso.com (OK) | https://contoso.com/mandant (BAD)

    Frage

  • Hallo,

    es wird normal im CRM gearbeitet und es kommen soweit keine Fehler beim user an, jedoch sehen wir im hintergrund das falche URL verweise aufgerufen werden, entweder beim mailtrack oder aufrufen einer entität etc.

    Eingestellt lauten die aufrufe so    https://mandant.contoso.com

    Im Hintergrund wird jedoch versucht https://contoso.com/mandant aufzurufen.

    Dies wird dann für den user nicht ersichtlich denn er landet mit etwas verspätung dann doch auf der aufgerufenen seite bzw. seine mail wird nach etwas leerlauf für ihn dann als getrackt angezeigt.

    Dies betrifft sporadisch alle user oder mandanten.

    DNS haben wir gecheckt, da ist alles gut.

    Was wir festellen ist das wir internal also mit http so aufrufen: http://IP/mandant

    und extern eben mit https so:https://mandant.contoso.com

    Das widerum auch so in der TMG regel steht, also rein theoretisch würde ich sogar sagen das er external überhaupt nicht durchgeroutet wird, da die  publicnames überhaupt nicht exisitieren und irgendetwas merkt das dann und routet auf die korerkte URL; oder auch nicht=planlos

    Ich danke im vorraus allen Vorschlägen.

    --|RU13 CRM 2011 unter windows server 2008 r2 sp1 +TMG+ADFS+IFD|--


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Dienstag, 16. April 2013 11:54

Antworten

  • Hallo Daniel,

    Zusammenfassend: Der oben genannte Fehler ("...file doesn't exist...") tritt auch bei https://internalcrm.domain.com/D00001/Activities/Attachment/download.aspx auf?

    Die Fehlermeldung deutet mir irgendwie darauf hin, dass am IIS etwas im Argen ist - die Fehlermeldung hat meiner Meinung nach nicht direkt etwas mit dem CRM zu tun. Vielleicht sollte die Konfiguration der CRM-Website mal durchgesehen werden!?

    Liebe Grüße,

    Andreas


    Andreas Buchinger
    Microsoft Dynamics Certified Technology Specialist
    MCPD: SharePoint Developer 2010

    Donnerstag, 2. Mai 2013 11:11

Alle Antworten

  • Hallo Daniel,

    habt ihr im CRM (im Bereitstellungsmanager) denn genau diese URL konfiguriert? Und habt ihr eine IFD-Konfiguration vorgenommen? Also in Verbindung mit ADFS2.0 oder läuft das über Windows Authentifizierung?

    Schöne Grüße,

    Nils Frohloff

    http://www.strategic-it.de

    Dienstag, 16. April 2013 12:37
  • Hallo Nils,

    nein, im deploymentm steht nur eine gloable adresse die extern aufrufbar ist und die staht korrekt dadrin, TMG macht hier die translation und routet an die internen mandantennamen.

    IFD ist konfiguriert in verbindung mit ADFS2.0 ja.


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Dienstag, 16. April 2013 12:46
  • Hallo Daniel,

    Bei korrekter IFD-Konfiguration muss die TMG keinerlei Translation übernehmen. Bei IFD konfigurierst du eine allgemeine URL für den CRM-Server und zusätzlich die DNS Namen und Weiterleitungsregeln je Organisation (allg.: crm.domain.com || spezifisch: org1.domain.com, org2.domain.com). Die Translation bzw. Weiterleitung von der auth-URL auf die korrekte org-URL übernimmt dann ADFS.

    Wenn IFD konfiguriert ist sollten alle Links mit "IFD-Format" aufgerufen werden, d.h. erstens mit https und zweitens mit org1.domain.com von extern und internalcrm.domain.com/org1 oder internalcrm.domain.com/org2 von intern.

    Liebe Grüße,

    Andreas


    Andreas Buchinger
    Microsoft Dynamics Certified Technology Specialist
    MCPD: SharePoint Developer 2010

    Dienstag, 16. April 2013 12:58
  • Hallo Andreas,

    ganz so einfach ist es bei uns nicht. Wir haben mehr als einen Mandanten.. Und nutzen für extern ein wildcard cert für die verschiedenen mandanten.

    Grundsätzlich werden von extern nur anfragen an https://mandant1-100.contoso.com akzeptiert. TMG routet diese Aufrufe an die crm frontends, diese leiten an die federation adresse, dann prüft ADFS den user und sein passwort, spendiert ggf. den token und leitet wieder an die frontends zurück, die dann voller freude die anfrage beantworten.

    Intern werden nur aufrufe in der form (ohne ssl) http://IP_des_frontendservers/mandant akzeptiert da sonst das cert nicht mit den servernamen übereinstimmt.

    Möglicherweise könnten es auch sessionkonflikte seitens TMG sein?


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS


    Mittwoch, 17. April 2013 08:03
  • Hallo Daniel,

    Wenn IFD auf einem CRM-Server konfiguriert ist _muss_ (lt. Microsoft) die gesamte Kommunikation über https laufen um eine fehlerfrei Funktion gewährleisten zu können. Darum wird auch von MS vorgeschlagen ein Wildcard-Zertifikat zu verwenden.

    Bei der Konfiguration von IFD hast du eine interene CRM-URL angegeben - kommt es beim Aufruf dieser auch zu den oben beschriebenen Fehlern? Ich denke, dass manche CRM-Funktion mit der URL arbeiten, von der diese aufgerufen werden und das dies dein Problem sein könnte.

    Liebe Grüße,

    Andreas


    Andreas Buchinger
    Microsoft Dynamics Certified Technology Specialist
    MCPD: SharePoint Developer 2010

    Mittwoch, 17. April 2013 08:18
  • Hallo Andreas,

    thx, das ist ein guter ansatz, ich teste das und gebe später bescheid, könnte etwas dauern da wir mehrere frontends und backends haben und ich doch von jedem server aus den zugriff testen müsste der sorgfalt wegen...


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Mittwoch, 17. April 2013 08:58
  • Hallo Andreas,

    leider hat es überall problemlos funktioniert. Hier mal die exception die wir im hintergrund abfangen:

    Organisation: D000001 Message: The file '/D00001/Activities/Attachment/download.aspx' does not exist. Description:

    Exception-Message:

    The file '/D000001/Activities/Attachment/download.aspx' does not exist.

    User: 000001-2 Browser: IE 7.0

    Method: LogItem Stack-Trace: at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean throwIfNotFound) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp) at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig) at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Mittwoch, 17. April 2013 11:01
  • Hallo Daniel,

    Kommt der Fehler beim Aufruf über https://internalcrm.domain.com oder bei http://crmserver ? Das Problem ist, dass D00001 ein virtuelles Verzeichnis ist das beim IFD Aufruf von extern aber nicht eingefügt wird (korrekt wäre: https://d00001.domain.com/Activities/Attachment/download.aspx)!

    Ist die Konfiguration des Token-basierten Zugriffs und des IFD-Zugriffs sicher korrekt? Sind die korrekten URL's am ADFS-Server hinterlegt? Mir kommt vor als wenn hier ein Redirect nicht korrekt arbeitet und zwischen internem und externem Zugriff fälschlicherweise wechselt...

    Mein Favorit für IFD-Beschreibungen: http://www.interactivewebs.com/blog/index.php/server-tips/microsoft-crm-2011-how-to-configure-ifd-hosted-setup/

    Liebe Grüße,

    Andreas


    Andreas Buchinger
    Microsoft Dynamics Certified Technology Specialist
    MCPD: SharePoint Developer 2010

    Mittwoch, 17. April 2013 12:05
  • Hallo Andreas,

    habe etwas Zeit gebraucht um das durchzuchecken, unsere config matcht die im dokument..

    Der Fehler kommt beim Aufruf über https://internalcrm.domain.com

    Ist nicht kriegsentscheidend, wäre aber trotzdem schöner wenn wir das nciht mehr ständig loggen müssten...


    gruss Daniel Ovadia MBSS - Microsoft Dynamics CRM MCNPS

    Donnerstag, 2. Mai 2013 08:25
  • Hallo Daniel,

    Zusammenfassend: Der oben genannte Fehler ("...file doesn't exist...") tritt auch bei https://internalcrm.domain.com/D00001/Activities/Attachment/download.aspx auf?

    Die Fehlermeldung deutet mir irgendwie darauf hin, dass am IIS etwas im Argen ist - die Fehlermeldung hat meiner Meinung nach nicht direkt etwas mit dem CRM zu tun. Vielleicht sollte die Konfiguration der CRM-Website mal durchgesehen werden!?

    Liebe Grüße,

    Andreas


    Andreas Buchinger
    Microsoft Dynamics Certified Technology Specialist
    MCPD: SharePoint Developer 2010

    Donnerstag, 2. Mai 2013 11:11