locked
Setup Woes! RRS feed

  • Question

  • Hello,

       My name is Damien. I have just completed setting up a deployment of OCS 2007 Beta on our internal office network.

    I have managed to get the installation working quite well on the network local to our office, but one of the requirements for this system was to allow a remote office to connect over the web from time to time.

    I have managed to get them to connect and enabled most of the OCS functionality but we are still having some significant issues.

    I have spent a LOT of time running through the Validation system for OCS and still have not managed to resolve ALL of the issues it is reporting.

     

    Specifically, I need to allow connection for Live Meetings using a browser instead of a custom client (application).

    We have to be able to connect to Live Meeting or conference with remote users who are behind nightmare firewall systems that there is no hope in hell of getting modified.

     

    Unfortunately I have not been able to connect to the Web components of the OCS at all.

     

    The validation says that the Web Components Server is working with no errors.

     

    However, the A/V and Web Conferencing have validation errors:

     

    We are using a single OCS server with a seperate Edge server.

    For the moment the Edge server has its firewall completely disabled.

     

    The A/V Server reports this error:

    Connecting to A/V Authentication Edge Server to get credentials    Exception: The requested operation failed.
      Failure
    [0xC3FC200D] One or more errors were detected

     

    The web Conferencing server reports this error (no firewall enabled):

    Web Conferencing Edge Server myserver.domain.com   DNS Resolution succeeded: 192.168.1.33 192.168.1.34
    TLS connect succeeded: 192.168.1.33:8057
    TLS connect failed: 192.168.1.34:8057 Error Code: 0x0 No connection could be made because the target machine actively refused it
    Suggested Resolution: Make sure that the server is listening on the specified IP address/Port/Transport. If you have a firewall make sure that this port is open. Make sure that the server is running. This can be ignored if you have not enabled the transport on the target server.
    Suggested Resolution: Ensure that the DNS records have been setup correctly. If this server is an Access Edge Server, make sure outside user access is enabled.
      Failure
    [0xC3FC200D] One or more errors were detected

     

    I have spent a significant amount of time and resource trying to resolve these issues and have so far had no luck at all.

    Most forums where I have found some information posted have been abandoned with no resolution to be had.

    Any help would be most greatly appreciated.

     

    Kind Regards,

        D

    Monday, May 21, 2007 12:49 AM

Answers

  • Hello Damien,

     

    yes you are right there is a DMZ implemented in the Edge Server Deployment Guide. Please have a look on page 8 which describes your consolidated topology.

     

    The Edge Server Deployment guide states the following:

    Here is an excerpt on page 11 and 13

     

    Step 1.3. Establish Your Deployment Process

    • Deploy the edge server between two firewalls (an internal firewall and an external firewall) to ensure strict routing from one network edge to the other.

     

    --> In case you have only 1 firewall you must configure a DMZ and the policies  ( from external network to internal network ) on the firewall accordingly.

     

    Step 1.4. Verify Prerequisites

    • A perimeter network that supports the assignment of a publicly routable IP address to A/V Edge Servers.

     

    You must ensure that the external interface can be accessed from the internet. This means no matter which firewall you use the traffic should be directed without any NAT to the Edgeservers external interface.

     

    In order to acheive this you should talk to your Internet Service Provider first on how to implement this only for the Edgeserver and without exposing the rest of your network to the outside. Ususally this should be done on your firewall.  

     

     

    Regards

     

    Athanasios

     

     

     

     

     


     

     

     

     

    Friday, June 1, 2007 11:20 AM

All replies

  • Hi Damien,

     

    could you please rund the Validation wizard again on OCS and Edgeproxy and share out the entire logs.

    Based upon the log above "DNS Resolution succeeded: 192.168.1.33 192.168.1.34
    " it seems that both interfaces of your edgeserver ( external and internal ) are registered in DNS.

     

     

    Regards

     

    Athanasios

    Monday, May 21, 2007 11:00 AM
  • Hi Athanasios,

       What is the best way to post the logs?

       I have tried a couple of times to post the data into this reply area and it is VERY large and does not render properly when I do a preview?

       Is there a better way to publish the data?

     

    Cheers

     

    D

    Tuesday, May 22, 2007 12:06 AM
  • Hello Damien,

     

    please provide me your contact information (email address) so we can share the data.

     

    Regards

     

    Athanasios

     

    Tuesday, May 22, 2007 7:26 AM
  •  

    I have generated a PDF for each validation log, and I can publish them to a download area for your review on our company website if that will help.

     

    If you contact me on the above email address I will provide the link to download the ZIPped PDF files.

     

    Cheers

     

    D

    Thursday, May 24, 2007 12:40 AM
  • Hello Damien,

     

    thanks for providing the logs. I had a look and what I assume is the following:

     

    Error 1 :

    Concerning Error 1 : Exception: The requested operation failed

     

    --> The A/V Edge and also the A/V Authentication services are not running on the Edge Proxy

     

    Error 2:

    TLS connect failed: 192.168.1.34:8057 Error Code: 0x0 No connection could be made
    because the target machine actively refused it

     

    While the connection to your internal interface succeeds

     

    TLS connect succeeded: 192.168.1.33:8057

     

    Both interfaces of your Edgeserver are in the same subnet and this does not make any sence.

    I suppose both addresses are also registered in DNS for one FQDN ?

     

    I suppose that after the DNS resolution succeeds the validation wizard tries to connect to both interfaces to the same port and fails because the external interface listens for webconferencing on 444 by default ( except you changed it ).

     

    I would recommend the following steps:

     

    - Please verify that all services on the edgeproxy are up and running so error 1 will be eliminated. Does it start ?

    - Please verify your TCP/IP settgins for both interfaces on the Edgeproxy and remove any duplicate records in DNS

     

    The external interface should not register its IP Address and should also not point to your internal DNS Server.

    Please run the validation wizard again afterwards and check if the same errors reappear.

     

    Regards

     

    Athanasios

     

     

     

     

    Friday, May 25, 2007 4:03 PM
  • Hi Athanasios,

        As far as I can tell all the services are started and running correctly on both servers. I have reviewed the event logs and the status information on the OCS Communications Server console and all seems to be ok.

     

    I have re-run the validation after making the changes you recommended and re-sent the files to your email address.

     

    With regards to both interfaces on the Edge server being on the same subnet "not making any sense" ....

    Why is that.

     

    I have a virtual machine hosting the edge server and it requires 2 interfaces to run as far as I can tell, one designated for Internal communication and one Designated for external communication.

    I can see why the DNS would be an issue the way I had both adapters addressable, but otherwise, I would have thought that as long as I have the router (Internet) forwarding the traffic correctly to the designated "external" adapter, then all should be ok.

     

    Anyway, the logs have been emailed and here is where I am up to:

     

    I have managed to connect successfully to the Web conferencing site now, after re-running the installation for the web scheduler component.

    Now I can log onto the Web Conferencing site and start/schedule a meeting no problem from the internal network.

     

    HOWEVER,

     

    When I try and connect from outside the network, i.e. using a remote (or external) client, I cannot connect the meeting client to our server.

     

    All of the settings are correct in the Live Meeting client configuration (as far as I can tell) and Communicator connects no problem.

     

    When I try and connect using the Live Meeting, using the Meet Now button, I get the following error message:

    Join Error

    Live Meeting cannot connect to the meeting.

    Wait a few moments and then try to join the meeting again.

     

    If you still cannot connect, contact your administrator or technical support.

     

    It seems that the meeting itself has been created, but the client cannot join it.

     

    When I try and connect using the Web Conferencing site : https://myserver.com.au/conf/ext

     

    I can log in to the site no problem, then I see a list of conferences that have been created (aparantly by me during testing the meeting client)

    and I can click any of the Open or Anonymous meetings and click Join Meeting.

    This starts the Live Meeting client ok, then I get the same error message as before (as above) Join Error.

     

    When I go into options and Test the User account details and Meeting Server details I get the following:

     

    Your Live Meeting logon information was successfully verified

    Followed by

     

    A connection to the Live Meeting service could not be established. Please check the live meeting or Portal URL and try again.

     

    The URL I am using is: https://myserver.com.au

     

    I have also tried: https://myserver.com.au/ext/conf

     

    It doesn't work either.

     

    I look forward to any assistance (as usual Smile )

     

    Cheers

    D

    Tuesday, May 29, 2007 1:55 AM
  • Hello Damien,

     

    thanks for providing the logs. As far as I can see the error with the TLS connection to the external interface disappeared after the reconfiguration.

    I assume there is only one A Record in DNS pointing to the FQDN of your internal interface.

     

    There are specific requirements for the external interface of an Edgeproxy, because we need a publicly routable IP address assigned to this interface for direct connection and without  NAT. Your external interface has an IP adress in the range of 192.168.x.x which is not a public one. This is the reason why I wrote that both interfaces in the same subnet do not make any sense.

     

    The requirements for an Edge Proxy can be found in the corresponding whitepaper

     

    Documentation for Microsoft Office Communications Server 2007 (Public Beta)
    http://www.microsoft.com/downloads/details.aspx?familyid=0A3E2593-5812-4BF5-A554-3215CBBA587A&displaylang=en

     

    Microsoft Office Communications Server 2007 (Public Beta) Edge Server Deployment Guide

     

    ( I copied the relevant part and highlighted the necessary information )

     

    On page 5

     

    Office Communications Server 2007 supports a variety of topologies for edge server deployment. This section describes the supported topologies and explains the considerations for choosing the edge server topology that best addresses the needs of your organization, as well as for deploying components in the internal topology to support edge servers.

    The size, geographical distribution, and needs of your organization are the primary determinants of which edge server topology is most appropriate for your organization. This section describes technical considerations for locating edge servers and the various edge server topologies and considerations for choosing the topology that is best suited for your organization.

    Although your business requirements should drive your topology decisions, your decisions should also take into account the following technical considerations:

    ·         A single server can provide multiple edge server roles.

    ·         A load balancer is required to support multiple Access Edge Servers, multiple Web Conferencing Edge Servers, and multiple A/V Edge Servers.

    ·         Each edge server role requires a single external interface to which users can connect by using the fully qualified domain name (FQDN).

    ·         The external IP address of the A/V Edge Server must be a external IP address that is directly contactable by external parties

    Note

    To conform to the requirement of a publicly routable IP address of the A/V Edge Server, the external firewall of the perimeter network must not act as a NAT (Network Address Translator) for this IP address.


     

    ·         To prevent port conflicts, if multiple edge servers (such as an A/V Edge Server and a Web Conferencing Edge Server) are collocated on a single computer, each edge server should have its own external IP address.

    ·         Each collocated edge server must use a unique port and IP address combination.

    ·         If you configure the Access Edge Server, A/V Edge Server, or Web Conferencing Edge Server to use a port other than 443, an attempt by a remote user to sign in by using Office Communicator 2007 or to join a conference from within another organization’s intranet may fail. This situation can occur because many organizations prevent traffic traveling through their firewall over non-default ports.

     

     

    and on page 13:

    Before you deploy your edge servers, ensure that your IT infrastructure, network, and systems meet the following requirements:

    ...

    ...

    ·         All hardware for your edge server meets the recommended system requirements as documented in the Office Communications Server 2007 Planning Guide.

    ·         PKI (Public Key Infrastructure) is deployed and configured to use a certification authority (CA) infrastructure that is provided by either Microsoft or another provider.

    ·         A perimeter network that supports the assignment of a publicly routable IP address to A/V Edge Servers.

    ·         Your perimeter firewalls can support opening the ports that are described in the following section.

    ·         A reverse HTTP proxy is deployed in your perimeter network and can be configured as described in “Configuring a Reverse Proxy” later in this document.

    ·         All users that require any of the new functionality that is provided by an Office Communications Server 2007 edge server install the Live Meeting 2007 client and Communicator 2007.

    ...

     

    When you connect as an external user and try to reach the external interface of your server which has an IP 192.168.x.x the router or whatever Device you use ( FW etc. ) must perform a NAT. As you can read in the excerpt above the perimeter Network must not perform a NAT and I suppose this is the reason why your conferencing fails.

     

     Verify that your setup fullfills all the requirements for the external interface ( publicly routable ip adress , A Record in DNS etc. ) first and rerun the validation again.

     

    Regards

     

    Athanasios

     

    Tuesday, May 29, 2007 2:13 PM
  • Hi again Athanasios,

       Thanks for the clarification. I can see that I need to revise my setup here a little.

    As we are on a small company network,  I have spent some considerable time examining the possible configuration solutions for

    the setup as outlined in the documentation for OCS 2007 Beta.

     

    We have deployed the consoloidated topology as we have a limited number of physical machines we can deploy the services

    on, and as I mentioned previously, the Edge server is currently running off a virtual server.

     

    However, if I can resolve the issue of exposing one of the interfaces of the edge server directly to the internet (bypass the firewall)

    I am concerned about the exposure of my internal network as the edge will effectively be bridging the internet with the internal system with no firewall in between.

     

    I am investigating the setup options at the moment for the configuration outlined in the docs to make sure I have understood it correctly.

     

    Is this the only problem to be resolved with my setup?

    The validation logs for the AV, Web and Front end were giving errors that had no information.

     

    Can you clarify what they mean please.

     

    Thanks again for all your assistance so far.

     

    Cheers.

    D

    Thursday, May 31, 2007 1:22 AM
  • Hello Damien,

     

    of course there are some errors but we cant`t fix every error.

    Web Components Validation Log: no errors
      Web Conferencing Log : no errors

     

    FrontEnd Validation:

     

    Warning: One or more phone usages are not assigned to any route or VOIP policy

    --> As long as you do not configure any voice options you will see this error.

    checkd public beta forum first for possible already answered posts

    Please see post :
    http://forums.microsoft.com/Ocs2007publicbeta/ShowPost.aspx?PostID=1553096&SiteID=57

     

    Check Pool Hosted User Setting

    Error: One or more pool hosted users are enabled for federation, remote access or public
    IM connectivity, but global federation is disabled.

    --> this error is displayed because users are configured for federation and PIC but federation is disabled globally.
    basically it can be ignored in this case but if you want it to disappear you have 2 options

    - reconfigure your users not to be enabled for fedration and PIC
    - enable federation in the global properties

    Howto enable federation globally:
    http://forums.microsoft.com/Ocs2007publicbeta/ShowPost.aspx?PostID=1630567&SiteID=57

     

    There are also some registrytion errors which I will have a look tomorrow. 

     

    Regards

     

    Athanasios  

     

     

     

    Thursday, May 31, 2007 4:31 PM
  • Thanks Athanasios,

       I have reviewed the links you provided and I have made those changes already (to federation).

    Our users do not really require the link between the two (at the moment) the external conferencing is a MUCH higher priority for us.

     

    Again, I have had a look at our setup and based on the requirement for the Edge to have one interface on the internet and one on the internal network, I am still unclear as to how I should implement this.

    I have had a reasonable amount of network experience, including various firewall, routing and port forwarding configurations for home and small office environments.

    I have reviewed the documentation again for the setup of the consolidated deployment of the edge server and it looks like the diagram has implemented some kind of DMZ arrangement but there is only one firewall marked on the diagram.

    As the machine will be exposed directly to the web on one interface I would expect that the correct solution does indeed invlove a DMZ, but I cannot find a mention of this configuration in the doco anywhere.

     

    Obviously I don't want to expose my work network to any significant risks/threats so I really want to be clear on how to implement the edge correctly.

     

    Could you explain the best way to implement the edge server using a single DSL line and firewall configuration please.

     

    Again, I appreciate all of the assistance.

     

    Cheers

     

    D

    Thursday, May 31, 2007 10:59 PM
  • Hello Damien,

     

    yes you are right there is a DMZ implemented in the Edge Server Deployment Guide. Please have a look on page 8 which describes your consolidated topology.

     

    The Edge Server Deployment guide states the following:

    Here is an excerpt on page 11 and 13

     

    Step 1.3. Establish Your Deployment Process

    • Deploy the edge server between two firewalls (an internal firewall and an external firewall) to ensure strict routing from one network edge to the other.

     

    --> In case you have only 1 firewall you must configure a DMZ and the policies  ( from external network to internal network ) on the firewall accordingly.

     

    Step 1.4. Verify Prerequisites

    • A perimeter network that supports the assignment of a publicly routable IP address to A/V Edge Servers.

     

    You must ensure that the external interface can be accessed from the internet. This means no matter which firewall you use the traffic should be directed without any NAT to the Edgeservers external interface.

     

    In order to acheive this you should talk to your Internet Service Provider first on how to implement this only for the Edgeserver and without exposing the rest of your network to the outside. Ususally this should be done on your firewall.  

     

     

    Regards

     

    Athanasios

     

     

     

     

     


     

     

     

     

    Friday, June 1, 2007 11:20 AM
  • I just wanted to weigh in here as well.  I've got an edge server and SE server that are communicating (no errors in validation logs for ANY component) and I have the edge server dual homed (two external NICs, one for Webconferencing and one for OCS access).  These both have publically routable IPS and are directly connected to the internet.  The only firewall running is the Windows Server SP2 firewall.  The internal NIC is the onlt NIC on the edge server that is registered in internal DNS, but it is on the LAN subnet, not a DMZ (though I can't think of any concievable reason this would matter).

     

    I've got an Apache reverse proxy running pointing the external pool FQDN at the internal SE server.

     

    I can connect internally to any service without trouble.  Externally, I can connect to Communicator from Domain member computers (logged in with cached creds) or from non domain computers.  Live Meeting doesn't work externally at all, which sounds similar to Damien's problem.  Logins in the Live Meeting console seem to work, but when I try to create or join meetings, it fails.

     

    Hopefully figuring out one or the other of our problems can help the other person.

    Friday, June 1, 2007 8:13 PM
  • Hello John,

     

    it may sound similar, but Damien does not have publicly routable ip adresses assigned to his Edgeserver.

    John, Please open a new thread for your issue so someone can follow up with you.

     

    @Damien:

    Please consider to setup the Edgeproxy as it is required and get back to this forum in case it still does not work.

     

     

    Regards

     

    Athanasios.

    Monday, June 4, 2007 7:22 AM
  • John, Damien,

     

    Did you manage to get Live meeting working? I'm also experiencing some challenges configuring external access.

     

    So far I have been able to configure the following:

     

    •  I can make calls and start video conferences between internal users (connected to OCS) and external users(connected via Edge). So the basic functionality of communnicator is working fine but we are experiencing some problems with connecting the address book server. You can read more about this in the following post: http://forums.microsoft.com/Ocs2007publicbeta/ShowPost.aspx?PostID=1593644&SiteID=57
    • Connecting with Live Meeting via Edge is a more difficult story. When I test the connection it seems to work but when I plan a meeting I can never join.

    I think this also has something to do with implementing an reverse proxy (see the post above) so that meetings can be planned via Edge. I 'm investigating this at the moment. Would you like to share information with me on your implementation? Did you get Live Meeting working via Edge?

     

    /Thomas

    Sunday, July 29, 2007 4:27 PM