Tło: Przesyłam przychodzący ruch 80/443 do \SERVER2; TFS działa \SERVER3. Chcę kierować wszystkie żądania związane z TFS do \SERVER3. Muszę to zrobić w ten sposób, gdy uruchamiam Server Essentials \SERVER2, co jest wystarczająco wybredne, aby nie działało dobrze przy przepisywaniu adresów URL (prawie tak źle, jak SharePoint, ale nie całkiem).
Oto jedyna reguła w domyślnej witrynie:
<rule name="TFS Rewrite" stopProcessing="true">
<match url="^tfs(.*)" />
<action type="Rewrite" url="http://server3:8080/{R:0}" />
</rule>
... a oto dziennik nieudanych żądań: https://1drv.ms/f/s!AodXF_j3BiWkhPAZwjnwC-rAecVgtw
Zanotuj żądany adres URL w linii 87 pliku PDF: http://server3:8080/tfs. Mogę przejrzeć to wewnętrznie w porządku. Zewnętrzny adres URL to https://tfs.domain.com/tfs.
Następnym wpisem dotyczącym wszystkich plików jest sam numer 404 w wierszu # 165.
Po prostu tego nie rozumiem. To prosta zasada. Dlaczego IIS miałby wyświetlać kod 404 dla wyraźnie poprawnego i działającego adresu URL?
EDYTOWAĆ
Jako test dodałem ten warunek:
<conditions>
<add input="{HTTP_HOST}" pattern="tfs.domain.com" />
</conditions>
Teraz, jeśli przeglądam https://tfs.domain.com/, ładuje się domyślna strona internetowa.
To - wraz z dziennikami - wydaje się wskazywać, że podczas gdy IIS przepisuje adres URL, ruch nie jest faktycznie kierowany do \SERVER3.
Co tu się dzieje? To tajemnica.
Odpowiedzi:
0 dla odpowiedzi № 1OK, mam to działa.
Zainstalowałem moduły URL Rewrite i ARR, ale jeszcze nie włączyłem przetwarzania proxy.
Utworzyłem obojętną regułę odwrotnego proxy i zostałem poproszony o włączenie jej w IIS. Zrobiłem to, usunąłem fikcyjną regułę i teraz wszystko działa zgodnie z oczekiwaniami.