Original : https://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=19#EntryTabs
OCS Reverse Proxy with ISA 2006
Using ISA Server 2006 we need to create a publish a web site rule to allow external clients access to address book and meeting information which is hosted on the internal Standard or Enterprise server via the IIS Default Web Site. Following the instructions under section 2.1 of the Edge deployment guide can be a little tricky at first, but makes much more sense once a few specifics are more clearly understood.
The paragraph below is very confusing as it's actually referring to two different certificates but reads like they are talking about just one:
Request and Configure a Certificate for Your Reverse HTTP Proxy
The root certification authority (CA) certificate for the CA that issued the server certificate on the Web server (the IIS server running your Office Communications Server Web components) needs to be installed on the server running ISA Server 2006. This certificate should match the published FQDN of the external Web farm where you are hosting meeting content and Address Book files.
The first statement basically says that you need to export the root CA certificate from your internal CA and import it into the Trusted Root Certification Authorities store on the ISA computer; simple enough. But the second sentence is now talking about a second certificate that should be requested from a third-party CA and will be used by external clients to connect to ISA via the published External Web Farm FQDN. What this 'Web Farm" FQDN actually refers to is the external name that clients will use to connect to the IIS web site which is running on the internal OCS front-end server. This is NOT the FQDN used by clients to connect to the Access Edge, A/V service, or Web Conferencing service. In this example I will use abs.domain.com as the external FQDN, which will be configured in the OCS Edge deployment wizard and is part of the in-band configuration information to is passed to the external client once it makes a connection to the Access Edge service.
So to summarize that, the internally issued certificate which is assigned to the Front-End server's default web site will be trusted by the ISA Server, and a second third-party certificate needs to be installed on the ISA Server in order to assign to the web listener for the external client to accept. ISA will terminate the connection from the requesting external client using one certificate and then create a second connection (using the other certificate) to the internal web site, essentially bridging the entire connection.
And if it's not completely clear by looking at the first diagram in this article, then let me restate the obvious: the Reverse Proxy is not configured on the Edge Server itself, it's simply a way to allow external users access to a web site running on the internal OCS server. Installing ISA on the Edge Server for this rule is not advisable (and probably not even possible; I can't imagine even attempting to host both ISA and OCS on the same physical server!)
Once these important points are understood then working through the rest of the deployment guide should be pretty straight-forward. The resulting ISA publishing rule and web listener configuration would look something like this:
설정 테스트를 확인해 보시고 테스트 성공을 할 수 없으면,
.gif)
중요: 
.gif)
참고: 
사전 요구 사항 .gif)
참고: 
invalid-file
