• Skip to main content
  • Skip to secondary menu
  • Skip to primary sidebar
  • Skip to footer
  • Home
  • Disclaimer & Policy

Elan Shudnow's Blog

MVP Logo
  • Azure
  • Exchange
  • Lync

Office Communications Server 2007 R2 Enterprise Deployment – Part 5

January 20, 2009 by Elan Shudnow 151 Comments

Welcome to Part 5 of this article series. So far in this article series, we have deployed an Enterprise Pool, configured our Pool, set up DNS, tested connectivity with Communicator 2007 R2, configured our ISA box, and prepared our Edge Servers.

In this Part, I will go through the part of the configuration of our Consolidated OCS Edge Server using a separate NIC for each Edge Role.

Part 1

Part 2

Part 3

Part 4

Part 5

OCS 2007 R2 Edge Server Installation

When installing an OCS 2007 R2 Edge Server, you would perform the following steps:

Note: Edge Server should not be joined to your Corporate Active Directory.

  1. Install Files for Edge Server
  2. Activate Edge Server
  3. Configure Edge Server
  4. Configure Certificates for Edge Server
  5. Start Services
  6. Validate Edge Server

Install Files for Edge Server (Step 1)

To begin the Edge Server installation process, we can insert our OCS CD (Standard can be used for Edge).  There are some prerequisites for installing OCS such as .Net Framework 3.5 SP1, but this is all taken care of during the installation.

Insert the CD and let’s begin the installation process.  You will be asked to install the Microsoft Visual C++ 2008 Redistributable. Click Yes to Continue.

You will then be asked to install the Microsoft .NET Framework 3.5 SP1. Click Yes to Continue.

Once Microsoft .NET Framework 3.5 SP1 is installed, you will be presented with the Deployment Wizard.  We will want to deploy our Edge Server in a Consolidated fashion..  Click Deploy Other Server Roles > Deploy Edge Server to Continue.

We are now on Step 1 which is to Install Files for Edge Server. Click Install for Install Files for Edge Server to Continue after meeting the Prerequisites (being a local Administrator).

On the Welcome Screen, Click Next to Continue. After fully reading the License Agreement, if you agree, Select “I accept the terms in the license agreement .”  Click Next to Continue.

You will be asked for Customer Information such as Product Key, Name, and your Organization Name.  Enter them appropriately. Click Next to Continue.

Enter the location you want your files to be installed.  I chose the default location. Click Next to Continue.

You are now ready to start the Installation.

Once you completed the File Installation, you should see the Installation Interface update the Step 1 Status showing as Completed.

Activate Edge Server (Step 2)

Click Run for Active Edge Server to Continue.

On the Welcome Screen, Click Next to Continue.

In OCS 2007 R1, you’d be prompted for what roles to install.  In OCS 2007 R2, there are only Consolidated Edge Servers.  Because of this, you will not be prompted for roles to install.

You will now be prompted to specify passwords for your Service Accounts.  I recommend to use long secure passwords.  You can view this and this site which assist in choosing strong passwords.  You will have to do this for several Service Account: RTCProxyService

Once you have set a password, Click Next to Continue.

You are now ready to Activate your Edge Server.  Review your Current Settings.  After satisfied, Click Next to Continue.

When the Activation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

Once you completed the Activation, you should see the Installation Interface update the Step 2 Status showing as Completed.

Configure Edge Server (Step 3)

Click Run for Confingure Edge Server to Continue.

On the Welcome Screen, you will be prompted with a warning recommending that you stop all OCS Services.

Go ahead and stop all services (mine were already stopped). Click Next to Continue.

The next screen asks us if we have a Configuration File to use.  This file is great to use if we are deploying multiple Edge Servers that will be load balanced.  For example, it would be useful if I was going to be deploying two Edge Servers behind a Hardware Load Balancer.  I would configure my first Edge Server, and at the end of the configuration, it would ask me to export the configuration so I can import it on my second Edge Server.  Nifty!

Because this is our first and only Edge Server, Click Next to Continue.

We must choose the Internal IP of our Edge Server as well as its’ FQDN.  We are presented with the following options.

You may be wondering which IP to choose.  Remember back in Part 4 we configured four NICs.  One of these NICs was the Internal NIC which we configured as follows. We also configured a dedicated NIC and IP for each Edge Role.  Here is a list of NIC Names, their associated Edge Role, and IPs associated with them

So in our Edge Configuration, we will want to choose 192.168.1.180 for our Internal NIC.  We will also want to set the FQDN as  shud-ocsedge01.shudnow.net (computername.domain.com).  Because our server is not a domain member, we will need to manually add the DNS record in our Active Directory DNS due to the nature of Active Directory Secure DNS Zones only allowing domain members to add records to our zone. Click Next to Continue.

We now must configure the IPs and FQDNs for all three Edge Roles.  You can refer to the Excel List above to determine what IPs are associated with which role.

When a client connects to the Access Edge Server, the Access Server will return the URLs needed for the client to successfully communicate with services in the OCS organization.  For example, we will configure our Web Conferencing Edge Server to use webconf.exchange.shudnow.net.  Exchange.shudnow.net is our Internet DNS Zone.  So when a Live Meeting Client tries to connect to a web conference, our Access Edge will communicate with the client telling it the FQDN for the web conferencing edge.  The same applies for the A/V Edge Server.

Enter in the IP Configuration and FQDN accordingly.  Click Next to Continue.

We will want to use this Edge Server to allow anonymous users to join meetings as well as enable federation.  If you plan on allowing your users to talk with public IM providers such as AOL, MSN, and Yahoo, select those features as you see fit.

Now let me explain why Allow remote users to communicate with federated contacts is greyed out.  It is possible to set up two Edge Servers and use one Access Edge for Remote User Access and another for Federation and Public IM connectivity.  If you decide to do this, one one Access Edge you’ll disable Federation which will light up the currently greyed out option.  On the second Access Edge, you’ll disable Remote User Access and enable Federation.  Now keep in mind this is optional.  Because we will be utilizing one Consolidated Edge Server, we can choose the options as follows which will enable Remote User Access, Federation, and Public IM Connectivity through our Consolidated Edge. Click Next to Continue.

We want our Edge Server to be able to talk to the internal OCS Servers.  We have a few options.  If we are using a Standard Server as our next hop, we would enter the Standard Pool FQDN which would be the server’s FQDN.  If we deployed a Director, we would enter the Director (or FQDN of hardware load balancer). Because we deployed an Enterprise Pool, we will use the FQDN of the Enterprise Pool. Enter the Enterprise Pool FQDN OCSPool.shudnow.net. Click Next to Continue.

Because our SIP Domain will be exchange.shudnow.net, that is what we will choose when specifying what our Authorized Internal SIP Domains are.  Click Next to Continue.

We will then want to enter our internal OCS Pool Name for Authorized Internal Servers.  If you have more than one Pool or Standard Edition Server, enter them here.  Click Next to Continue.

You are now ready to Apply your Edge Server Configuration.  Review your Current Settings.  After satisfied, Click Next to Continue.

You are now ready to apply your configuration.  Review your Current Settings.  After satisfied, Click Next to Continue.

When the Configuration is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.  This is also where you’ll have the change to export your configuration if you’re deploying a second Edge Server for Hardware Load Balancing.

Once you completed the Configuration, you should see the Installation Interface update the Step 3 Status showing as Completed.

Configure Certificates for Edge Server (Step 4)

Click Run for Configure Certificates for the Edge Server to Continue.

On the Welcome Screen, Click Next to Continue.

I’m going to skip through a lot of this section as it consists of how to obtian a Certificate which I already went through in Part 4 when we discussed configuring our ISA Server.

I will be obtaining three certificates.  One is for our Internal NIC that consists of the FQDN of our Server (shud-ocsedge01.shudnow.net).  The second certificate will consist of  the names of our Access/Web external edge roles. The third certificate will be our A/V Authentication certificate.

Now you may be thinking, well, can’t I just use two certificates?  One for internal and A/V edge.  Well in our case, probably.  If you have multiple servers, no.  This is because each certificate for the internal interface will be unique due to the name of every server being different.  The A/V Authentication name will be the same and exported/imported on multiple servers.  Also, Microsoft considers it to be insecure by using the same certificate for both the Internal and A/V Authentication services.

Certificate One (Internal Interface):

CN = shud-ocsedge01.shudnow.net

Certificate Two (Access/Web Server Roles):

CN = sip.exchange.shudnow.net

SAN = sip.exchange.shudnow.net

SAN = webconf.exchange.shudnow.net

Note: Microsoft’s Official Support Policy requires you to have a separate certificate for each interface.  A SAN certificate for both will work though.

Certificate Three (A/V Authentication)

CN = av.exchange.shudnow.net

Now keep in mind the reason the namespaces our different is because the internal NIC is connected to our internal infrastructure and will be utilized internally only.  Because of that, we will be using our internal namespace that is also used as our default SIP routing domain.  Our edge servers will be contacted using the external DNS namespace.  If you are using split-DNS where your internal namespace is hosted on external DNS, you can use either namespace.

For purposes of this lab, I will obtain all certificates from our internal CA.  Because our Edge Server is not a domain member, you have to ensure it contains the Root Certificate from our Internal CA.  You will also have to submit the request, approve it, and submit the .cer file manually and import it manually due to our Edge server not being a domain member.

Note: In a production environment, you will be requesting your Access/Web Conferencing Certificates from a Third Party Vendor.  Both your A/V Authentication and Internal Interface NICs will be provided by your Internal CA.  The A/V Edge role doesn’t need an Internet Facing Certificate.

We will first choose to Create a new Certificate.  One you have done this, you will want to make sure you select only your Edge Server Private Interface.  Click Next to Continue.

You will want to go through the rest of the configuration which includes entering your Organization Name, Company Name, Etc…  As I said, when you are at the screen which consists of what FQDN to use, you will use the CN of shud-ocsedge01.shudnow.net.

Once you are finished preparing the request, you will see the Step being partially finished.  Click Run again to Continue.

You will now want to go through the motions of taking the .Cer file you obtained from your Certificate Authority and binding it to your request.

Follow this procedure with the remaining certificates.  Refer to the certificate CN/SAN names above as to what entries should be on your certificate.

Your Access/Web Conferencing Edge Certificate request will look like:

Your A/V Certificate request will look like:

Once you completed the Certificate Configuration, you should see the Installation Interface update the Step 4 Status showing as Completed.

Remaining Steps

I will not be going through the remaining steps.  It consists of Starting Services and Validating your Configuration.

The only remaining steps are to enable users, configure federation, and enable your Front End Servers to talk with your Edge Servers.  All this information is out of the scope of this article.  If you are interested in doing this (and you will have to connect your Front End Servers to your Edge Servers), visit this site here.

TIP: To adminster the Edge Server, type Start > Run > Compmgmt.msc.

Summary

Well folks, that is all for not just Part 5, but the entire article series. Hopefully these articles have helped you understand more on how the deployment of OCS works.  There is a lot more to the configuration of OCS and especially the deployment when you get into load balancing.  Much more than what I went into.  But hopefully the article gave you enough knowledge to know where to look and how the overall deployment process works.

Share this:

  • Click to share on X (Opens in new window) X
  • Click to share on LinkedIn (Opens in new window) LinkedIn
  • Click to share on Reddit (Opens in new window) Reddit

Filed Under: OCS Tagged With: OCS

Reader Interactions

Comments

  1. luke says

    January 18, 2012 at 4:22 am

    After I corrected the Certificate on the server the following Error pops up when I try to logon.

    TL_ERROR(TF_CONNECTION) [0]0D44.0D30::01/18/2012-10:21:20.668.00000161 (SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(157))$$begin_record
    LogType: connection
    Severity: error
    Text: The client connection is not allowed on the internal edge of the Access Edge Server
    Peer-IP: 172.16.28.56:1524
    Transport: TLS
    Result-Code: 0xc3e93d6b SIPPROXY_E_CONNECTION_INTERNAL_FROM_CLIENT
    $$end_record

    Reply
  2. luke says

    January 18, 2012 at 4:20 am

    Services have been restarted and all seems in order.

    However no matter what I do I cannot logon onto the OC EA server. The error I am getting in OCSLogger is as follows:

    L_ERROR(TF_CONNECTION) [0]0E2C.0E24::01/18/2012-09:04:25.856.00000160 (SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(157))$$begin_record
    LogType: connection
    Severity: error
    Text: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?
    Local-IP: 172.16.28.56:5061
    Peer-IP: 172.16.28.56:1503
    Connection-ID: 0x1000
    Transport: TLS
    $$end_record

    I can succesfully ping the FQDN of the Internal Interface of the OC AE Server. The internal Interface is on the same IP Subnet as our Internal Network.

    Any support in this regard would be much appreciated.

    Reply
  3. Luke says

    January 18, 2012 at 4:19 am

    Guys I know its been a while since anybody has posted here but I am desperately looking for some assistance. We have been running a OCS 2007 R2 (Just one Server running OCS2007 R2 Standard) for some time now. All seems to be working great. Now the time has come to deploy Access Edge Server. I dont need any of the Fancy stuff. All I want is to give users the ability to logon onto OC outsite the network just like they would at the office.

    I have configured a server with two NICs. One for DMZ and the other for Internal. I received a Public CA that I have assigned to the External Interface and then generated a new Local CA using our Enterprise CA server. This I assigned to the Internal Interface. ( I have used the same Private SA to generate the certificate for the OC SE server).

    Reply
  4. Francois says

    May 16, 2011 at 5:27 am

    hello, please i am having this error with my edge server isnt working. it keeps giving me this error.

    Server could not register for notifications for configuration changes for a class from the WMI Provider.

    Class: MSFT_SIPProxySetting
    Cause: This could happen in some instances due to insufficient permissions or because the server is unable to contact the Active Directory (or SQL back-end).
    Resolution:
    Please make sure you have sufficient privileges and this computer can talk to the Active Directory (or SQL back-end).

    please help out

    Reply
  5. Saneesh says

    August 25, 2010 at 1:50 am

    Hi Elan,

    Can you please tell me the features available with this setup.

    Thanks
    Saneesh

    Reply
  6. marc says

    March 22, 2010 at 10:24 pm

    Hi, having a strange issue with webconf part of edge server. Seems I can ping av and sip on the external nic (4 IPs assigned to the nic), but only the ip for webconf does not reply. I believe this is causing live meeting logins to fail as authentication comes up but never finshes. Also, desktop sharing features are working externally, so I'm not exactly sure whats going on since all the other IPs I can ping and get a reply from. Have tried reassigning cert as well as reboot. still same issue.

    Reply
  7. Mike says

    January 25, 2010 at 5:12 pm

    Hello Elan, Scenario: External authenticated users can IM to internal, pic, and federated partners. I can communicate with full AV from internal to federated partners but AV between internal and external OC R2 users always fails with “Remote end ending the audio session” thus terminating the attempted AV call. It seems that possibly a port problem. This leads me to the question about the internal interface open port requirements.

    When opening the ports on the internal interface on the edge server the guidelines say to open 443, 5062, and 3478 to ANY IP address.

    Is this to any internal Pool or FE, or literally to ANY internal client address as well as server on the corp intranet.

    Many thanks in advance………Mike

    Reply
  8. Andrea says

    December 15, 2009 at 8:19 am

    Hi Elan,

    is it possible to use a domain service account when I configure the RTCProxyService?
    I need it because my Edge Server is in a DMZ domain, not the same of the FE.

    Do you now if is it supported by MS?

    Thanks!

    Reply
    • Elan Shudnow says

      December 15, 2009 at 8:42 pm

      Not sure if it's supported and I haven't tried it. I always just create the accounts on the Edge Server itself.

      Reply
  9. Elan Shudnow says

    December 9, 2009 at 5:34 pm

    Keep in mind that PIC vendors require them to communicate with the Common Name of the certificate. It's the same for LCS to OCS federation. OCS to OCS can use a SAN name. So if you still end up owning the old DNS namespace you can just request a new certificate and keep the Common Name the same, just add the necessary new domain information as a SAN. That way you won't lose access to PIC for several weeks until PIC re-federates with your new FQDN/Common Name.

    Reply
    • golfer kuno says

      December 21, 2009 at 9:31 pm

      Thank you for your comment, I will work on getting our certificate re-config.

      On the same note, we started to create the new domain setting within the LAN. In the forest Global Properties, we have added the new SIP domains (newdomain.com). On our DNS server we have created a new Forward Lookup Zone for newdomain.com and within this zone created the SRV record _sipinternaltls (pretty much copied what we did with our olddomain.com DNS records). Now if you go to one of the client PCs and do an nslookup for set type=SRV for _sipnternaltls._tcp.newdomain.com it will return the OCS server's address.

      We picked one of our test accounts and change the SIP address to use the newdomain.com. If the OC client is set to use manual there is no problem to sign-in using the newdomain.com SIP address. However, we get the error "Cannot sign in because the server is temporarily unavailable. Please try again later." if its set to use Automatic configuration.

      Why would it work if set manually and not work when set to automatic? FYI – we have not changed our certificate yet on our OCS R2 Server.

      Thanks again,
      Dario

      Reply
      • Elan Shudnow says

        December 22, 2009 at 1:06 am

        That does seem odd. Have you tried to load up netmon or wireshark to see where the breakdown in the communication lies? And the guidance I wrote above is for the Edge. For the FE you'll still have to add something sip.newdomain.com as a SAN name.

        Reply
        • golfer kuno says

          December 22, 2009 at 3:35 pm

          This is the event log from test PC…

          Communicator was unable to locate the login server. The DNS SRV record that exist for domain newdomain.com point to an invalid server ocs.olddomain.com which is not trusted to provide support for the domain because the server's domain is not an exact match.

          Resolution:
          The network administrator will need to double-check the DNS SRV record configuration to make sure that the SRV record for the domain points to a server name that conforms to the DNS naming convention in the server deployment guide.

          Does it mean that I cannot point the new SIP address newdomain.com to ocs.olddomain.com because the SIP address are different? I thought we can have multiple SIP addresses using a single OCS server?

          Can I just create an alias for the OCS server and use the newdomain.com as its domain name? Your thoughts? Thank you.

          Reply
          • golfer kuno says

            December 22, 2009 at 4:01 pm

            I believe this next info could help to resolve this issue…

            I created a new host/alias for the OCS server under the new zone newdomain.com and pointed the _sipinternaltls for this newdomain to the new host/alias. I can see see (using WireShark) that the client is getting the SRV record from the DNS server, so that is at least good to know. Now it seems (only my guess) that the issue is now pointing to the certificate. The message below came for the Event Log.

            Communicator could not connect securely to server ocs.newdomain.com because the certificate presented by the server did not match the expected hostname (ocs.newdomain.com).

            Resolution:
            If you are using manual configuration with an IP address or a NetBIOS shortened server name, a fully-qualified server name will be required. If you are using automatic configuration, the network administrator will need to make sure that the published server name in DNS is supported by the server certificate.

            Your thoughts please. Thank you.

  10. golfer kuno says

    December 9, 2009 at 3:58 pm

    Hello, we have successfully deployed OCS R2 Server and being used in and outside our LAN. We are also IM'ng with aol, yahoo and hotmail users. Now we have a BIG concern this coming January 2010.

    To everyone out there, kindly let us know what should we do once our company switches its domain address from (example only) domain1.com to domain2.com?

    We appreciate all inputs. Thank you kindly.

    Reply
  11. Josh Lynch says

    October 18, 2009 at 2:50 am

    I have also followed this document, since i did not set my reverse proxy address as the external farm.

    I did the below successfully from my FE server.
    Still getting the message.

    My cmd was: "Lcscmd /web /action:updatepoolurls /externalwebfqdn:ocs.domain.com /poolname:ocspool01"
    http://technet.microsoft.com/en-us/library/bb8036…

    Reply
    • Elan Shudnow says

      October 21, 2009 at 6:40 pm

      Sounds like something else is configured someone in your FE Settings or your Edge Settings for Communicator to go ocs.domain.com that is causing your client to attempt to make a connection to ocs.domain.com over 5061. I don't have an idea off the top of my head as this is something I would have to look around for in the settings to see if I catch something.

      If you Ctrl + Right-Click on your Communicator icon in your notification area, you can choose conifguration information. I'd be curious to see what in-band provisioning is providing you as far as connection URLs for each service.

      Reply
  12. Josh Lynch says

    October 18, 2009 at 1:24 am

    Firewall is open, i can telnet to 443 on ocs.domain.com just fine. Why is it asking for 5061?

    Reply
  13. Josh Lynch says

    October 18, 2009 at 1:22 am

    Got a question:

    I think i have an issue with my setup. Ent. consolidated 2007 r2.
    I'm using all public certificates, for everything.

    ocspool01.domain.com is the pool fqdn SAN cert. also has local machine name on the cert.
    im.domain.com for access edge
    livemeeting.com for webconferencing
    av.com for a/v
    ocs.domain.com for reverse proxy

    1 edge, 1 isa, 1 FE server. Edge and ISA are in perimeter network.
    edge has 3 interfaces. all assigned appropriately.

    Everything works except live meetings don't always work. and logon times are slow.

    I'm not sure why its asking for 5061 since ocs.domain.com is the 443 web listener interface/certificate.

    In the client machine app logs, livemeeting events come up:

    Communicator failed to connect to server ocs.domain.com (xx.xx.xx.xx). on port 5061 due to error 10060. The server is not listening on the port in question, the service is not running on this machine, the service is not responsive, or network connectivity doesn't exist.

    Resolution:
    Please make sure that your workstation has network connectivity. If you are using manual configuration, please double-check the configuration. The network administrator should make sure that the service is running on port 5061 on server ocs.domain.com (xx.xx.xx.xx).

    Reply
    • Josh lynch says

      October 18, 2009 at 1:23 am

      by "av.com" i mean "av.domain.com". Same goes for "livemeeting.com" meaning "livemeeting.domain.com"
      thanks.

      Reply
  14. Tobias says

    September 16, 2009 at 4:02 am

    Hi,
    can a manually configure my Front End Servers to talk with my Edge Server, or do I really have to run the “setupee.exe” again.
    If i have to run setup an configuration wizard again, will this affect my running front end server ?
    thanks

    Reply
  15. Tasos says

    September 14, 2009 at 10:07 pm

    Thank you for answering so fast.

    A last question.. From your experience do you think is possible to have access in uploading files without reverse proxy.
    Have you try another reverse proxy expect ISA?

    Reply
    • Elan Shudnow says

      September 14, 2009 at 11:44 pm

      Isn't that the same question? To be MS supported, you need to have ISA as a reverse proxy for any type of web components access which includes updating OCPE, Web Conferencing Uploads, Address Book Downloads, and Distribution Expansion. There are ways to get it working without using a reverse proxy server, but it's not supported and you may run into other issues.

      Reply
  16. Tasos says

    September 14, 2009 at 9:15 pm

    Hi Elan

    Great Document, very helpfull.

    I want to ask if is possible to access my External Web FQDN (https://extwebdomain.com) for uploading files in Live Meeting without reverse proxy (ISA)?

    Reply
    • Elan Shudnow says

      September 14, 2009 at 10:00 pm

      From a Microsoft supported standpoint, no.

      Reply
  17. superjoe says

    August 31, 2009 at 8:39 am

    Hi,
    Am I required to have at least 3 public IP address to deploy an Edge server with the 3 edge roles?
    Moreover, I will have to put the public IP directly on the Edge server, as ISA 2006 used as firewall does'nt support static NAT… am I correct ?

    Reply
    • Elan Shudnow says

      August 31, 2009 at 1:34 pm

      Yes, you need 3 public IPs. And correct, ISA and I believe TMG as well do not support the level of Static NAT you'd look for for NAT'ding your Edge Servers. You'd need to either use a firewall with the capabilities you need or put the public IPs directly on your server.

      Reply
      • superjoe says

        August 31, 2009 at 3:42 pm

        Thanks.
        This is a shame that you got those constraints when using MS products together ! And this is annoying that 3 public IP's are required instead of 1, since I'm in a single edge server topology.
        I guess I'll need to buy a complete /29 IP subnet as 1 IP is needed for proxy and 1 for ISA dmz interface…

        Reply
        • Elan Shudnow says

          August 31, 2009 at 3:51 pm

          You and me both. There has been a lot of feedback to Microsoft about the need to consolidate services.

          Reply
  18. Sean says

    July 25, 2009 at 1:56 am

    Thanks John,

    But I think the problem is that OCS server can’t get credentials to the A/V server , I did not use firewall for easy setup so i don’t have to worry any port blocking but will setup firewall when I get this working,

    how can i check the ff?

    1. The outbound proxy is reachable.
    2. The outbound proxy and A/V Authentication Edge Server are in trusted server list of each other.
    3. The outbound proxy and A/V Authentication Edge Server have valid certificates.
    4. Conference Server certificate is valid.
    5. A/V Authentication Edge Server Gruu is correct.

    I’m not getting error messages from OCS logs, i only get errors when validating a/v authentication.

    Reply
  19. John Bales says

    July 24, 2009 at 1:34 pm

    For the AV Edge stuff, here is out configuration:

    External Port (TCP): 443
    External Port Range: 50000-59999
    Internal Port (TCP): 443
    AV Authenitcation Port: 5062

    Hope this helps.

    Reply
  20. Sean says

    July 24, 2009 at 1:29 pm

    pls. disregard my question about same ports, (I must be tired) been configuring this for more than 2 weeks…what port will I use in the av.domain.com? the External or internal port or tcp port?

    Reply
  21. Sean says

    July 24, 2009 at 1:24 pm

    Hi Elan,

    I have the same problem with one of the users here, internal to internal and external to external users can make AV call, but internal to external call it always say Call disconnected. I’m using internal certificate only because we don’t need to contact users from ym, msn anyway , only users inside the organization will use OCS with them using their laptops outside the company(internet). Is it ok to use internal ca? Also I know the reason why I can’t make a call because I have errors validating A/V authentication Edge Server but I’m lost fixing this ..error says Could not contact A/V Authentication Edge Server….Check if the Outbound proxy is available……by the way I used ISA 2006 for Web Conf Publishing . Do internal A/V server and A/V Edge server need to be in the same port? From the OCS Server -> Global Properties -> A/V Servers , I used av.domain.com port 663 (I also Changed the port because I can’t start the service using 5062), at the Edge Server I have this ports External Port = 5000, Internal Port = 663 (because I’m having problem using 443) , AV Auth Port = 5062.

    By the way my setup is I have 1 OCS Server joined in a domain (firewall off for testing), 1 Edge Server ,not a domain member with 2 NICs , 1st NIC has 3 public IPs and 2nd NIC has 1 private IP, I used internal certificates.

    Also clients can connect from the internet using sip.domain.com.

    Thanks in advance!

    Reply
  22. Trung T. says

    July 20, 2009 at 10:39 am

    hi elan,

    i’m trying to connect via my edge server from a client that is on the same subnet as my edge nic card. i’ve configured the host file so that sip.domain.com goes to the external ip of the access edge nic. i’m unable to connect and see a lot of tlsv1 errors on wireshark. do you know what might be causing this? certificates?

    -trung

    Reply
    • Elan Shudnow says

      July 22, 2009 at 11:42 am

      I don’t really see a problem with that. Do clients successfully connect otherwise using the internet? Did you try turning on OCS Logging and using snooper to inspect the SIP Log?

      Reply
  23. John Bales says

    June 26, 2009 at 2:17 pm

    Yes I was missing something. I ran the Edge Planning Tool and looked at the report it created. According to the report, it tells me that the AV authentication service should be listening on 5062. I cannot figure out how to change the setting from avedge.petroleumtraders.com:443 to be avedge.petroleumtraders.com:5062.
    This IS for the AV Auth service, not the role. I am going by the Edge Planning Tool Report.

    I am looking at these settings at Front End Server>OCS Admin Tools>ocs.pool.com
    – Right Click and go to Pool Properties

    I need to change this setting.

    Reply
  24. Jürgen says

    June 26, 2009 at 1:08 pm

    yes, you are missing something: The Edge Planning Tool and some time to understand it.
    see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ec4b960c-3fe2-41bd-abdf-ae89cfcb8c6c
    Regards,
    Jürgen

    Reply
  25. John Bales says

    June 26, 2009 at 1:01 pm

    So with that being said, the AV Edge role should be listening on 443, so it does not need changed? And the AV auth. is the only thing that needs to be listening on 5062?

    So if I do not need to change the configuration on either the AV edge role or the AV auth, then what exactly do I need to do with the “Private” cert?

    When you say Private cert, do you just mean creating a cert from our internal CA? Or am I missing something?

    Reply
  26. Jürgen says

    June 26, 2009 at 12:45 pm

    two different things / don’t mix up:
    1. AV edge is a role, that needs to be publically available with public IP and DNS entry.
    2. AV auth. edge is a service that “helps” the av edge. This one needs a private cert to do the auth. This one is not reachable neither from the inside nor from the outside.

    Reply
  27. John Bales says

    June 26, 2009 at 12:42 pm

    ALright. I am looking in the Edge Server Properties and see that the AV Authentication port IS actualy listening on 5062. But when I look on the Edge Server tab on the Front End server, it shows the AV server listening on 443. When I try to remove this entry and add the correct FQDN and 5062, it will not let me. It says it is already associated with the pool. This makes sense, but how can I unassociate the AV role from the pool temporarily so I can change this setting on the Edge Server Properties?

    Or, if I am not on the right track, please let me know.

    Reply
  28. John Bales says

    June 26, 2009 at 12:03 pm

    I originally had the Public cert applied to all interfaces on the edge server.

    I have just created an Internal cert with the FQDN the same as the av name on the AV interface and I still have the Limited external calling warning in Communicator.

    Reply
  29. Jürgen says

    June 26, 2009 at 11:12 am

    Normally this means, that something went wrong with A/V authentication. Check if you have an extra internal cert with private key assigned to av auth.
    Regards,
    Jürgen

    Reply
  30. John Bales says

    June 26, 2009 at 11:01 am

    Did we ever have a resolution to the”Limited External Calling” error inCommunicator 2007? The exact error I am getting is “Some calls to and from people outside of your corporate network may not connect due to server connectivity problems. Try signing out and signing back in. If this problem continues, contact your system administrator with this information.”

    Any ideas?

    Reply
  31. Trung T says

    June 25, 2009 at 10:08 am

    Thanks Elan, i also saw this article about Natting the A/V role (in consoldiated topology only). https://blogs.pointbridge.com/Blogs/mcgillen_matt/Pages/Post.aspx?_ID=61

    Reply
  32. Trung T says

    June 25, 2009 at 9:45 am

    Hi Elan,

    I’m trying to publish my Access Edge service via the ISA 2006 server. My Edge server roles all have internal IPs and I want to NAT them via my ISA 2006 server. My ISA is set up as an edge firewall and I want to allow 443 and 5061 to my edge server. I have a non-web server publishing rule that allows HTTPS and MTLS to my access edge’s internal IP address.

    I know that that ISA 2006 server is typically used for address book proxying but is it possible to NAT as well? I’ve seen an article about setting up the 3-legged perimeter – http://isaserver.org/tutorials/OCS-2007-ISA-2006-Firewall-Design-Architecture.html but I’d like to keep my ISA as an edge firewall. Thanks in advance.

    Reply
    • Elan Shudnow says

      June 25, 2009 at 10:05 am

      Sorry, can’t help you much there. I’ve only set up ISA as a reverse proxy before and not as a real firewall replacement or a 3 legged firewall. I’d ask this in the isaserver.org forums or technet forums or on another ISA blog.

      Reply
  33. Elan Shudnow says

    June 15, 2009 at 4:16 pm

    PIC requires PIC licensing which is a user by user based model. You need to get your Edge Server set up with its proper certificates and the MS licensing website will provide information on how to provision PIC.

    Reply
  34. Akhilesh says

    June 15, 2009 at 7:08 am

    Hi Elan,

    I have just read all the comments and your answer and it is very helpful to me. but I am little bit confuse about PIM license and public IM configuration, Is there require PIM license in OCS 2007 R2, If yes then how can I get it and install it. And I also need step by step configuration of public IM on OCS edge server.
    Thanks in advance. :-)

    Reply
  35. Elan Shudnow says

    June 11, 2009 at 3:35 pm

    They can be the same subnet. You can NAT Public IPs for your public facing Edge Roles (A/V can only be NAt’d with 1 R2 Consolidated Server otherwise you need public IP directly on A/V NIC) and your Internal IP can be directly on your internal subnet or your DMZ Subnet so it’s more secure as it’d be within your DMZ and be protected by the firewall.

    Reply
  36. Ozgur says

    June 11, 2009 at 9:47 am

    Hey,
    Thanks for the information. There is one thing i need to clarify though. The ip addresses dedicated to the internal interface and other server roles are all on the same subnet . Did i miss something ?

    Reply
  37. Andy C says

    May 26, 2009 at 11:54 am

    Elan,

    Thanks, I have resolved the issue. It was a firewall issue on the internal firewall. Only the front end server was allowed to talk to the edge server on the AV allocated ports.

    Allowed all internal ip’s to talk to the edge on the AV ports and now seems ok.

    This guide helped a great deal with setup.

    Thanks

    Andy

    Reply
  38. Elan Shudnow says

    May 26, 2009 at 9:39 am

    Andy, internal clients do not need to connect to the external IP of your Edge. Internal clients will always use the AV Service on the Front End.

    Check out this article, it should help:
    http://blogs.technet.com/rickva/archive/2009/04/03/Configuring-A_2F00_V-Edge-Service-for-NAT.aspx

    One thing to keep into consideration is that the DNS Server that the AV Edge will reference should be able to resolve the AV NIC/IP as the publicly accessible IP. So if you have your DNS next hop set to internet servers, you should be fine. If you have them as internal servers doing your Edge Server’s recursion, that DNS Server must have the public IP in DNS.

    Also, you’ll definitely want to use ISA as your reverse proxy. It’s the only supported solution (not saying others don’t work though.)

    Reply
  39. Andy C says

    May 25, 2009 at 6:39 am

    Elan,

    I have managed to install the edge server into our DMZ. I have also configured it and all is working except one thing. We have not deployed the reverse proxy yet could do with some advice on best product to use for that? SRV records will be registered tomorrow so using manual configuration of live meeting for now.

    I have three separate external nics with three separate ip’s. I have NAT on all roles as I’m running R2. I have ticked the use nat box on the av edge nic properties.

    Live meeting is working with AV, and allows anonymous users to join meetings.

    IM from office communicator works.

    AV from MOC client is where my problems start.

    The scenarios are :

    1. MOC connected from internet to MOC connected on internet works fine for IM and AV.
    2. MOC connected on corp network to MOC connected to corp network work fine for IM and AV.
    3. MOC connected on internet to MOC VPN’d in from home, so king of connected to corp network, IM works but AV fails. It call the other party but when they accept it just drops the call.
    4. I have not had change to try a corp network connected MOC to internet MOC yet.

    Do the above tests mean that OCS pool and edge are correctly configured as scenario 1 proves, and it a routing problem.

    I read somewhere that the internal clients must be able to connect the external ip of the AV edge nic?

    Any help greatly appreciated. If anymore if is needed please let me know.

    Thanks.

    Andy C.

    Reply
  40. Ronald says

    May 13, 2009 at 5:00 am

    Hi Jan,

    Thanks for your concern !

    Yes, everything is split up, we have ForeFront/ISA deployed and so on. We have OABs per customers, GALs per customers, etc. Don’t worry about the Exchange part, this is al covered and we have already various clients without them noticing it =)

    We also run a shared CRM 4 environment, and a hosted IP PBX platform, so now OCS is one of the final challenges to complete the portfolio.

    Any ideas of my previous question ? How do I configure the external DNS for the customers ? Is an SRV record externally required and if yes, can this point to a record outside it’s own zone ?

    BR,

    Ronald

    Reply
  41. Jan Boguslawski says

    May 13, 2009 at 4:47 am

    Hi Ronald,

    sorry I cant answer your questions at the moment. But I like to save you again :)

    Are you aware that you will create a shared Adress Book per default for all of your hosted customers!!! I guess you dont want that all customers will see each other including privacy informations??? ( I am sure you made a GAL separtion in Exchange?)

    One step you need for preparation is Customized ABS, a good startline for that can be found here:
    http://www.confusedamused.com/notebook/injecting-contacts-to-the-ocs-address-book/

    A second task will be to create ethnical firewalls between your costumers if necessary. Is’nt it? I guess you have it for Exchange 2007? If you dont have it, your customers users can start chat or SPIM at each other… etc.

    Additionally I recommend to deploy Microsoft Forefront (formerly know as Sybari Antigen) for Office Communications Server to prevent from virus, SPIM and to enforce a communication policy (e.g. against strong words in chats, like you might do for email) … It is very familar to Forefront for Exchange, or Sharepoint.

    I will keep my fingers crossed! :) A hosted OCS / Exchange enviroment can be a challenge.

    regards,
    Jan

    Reply
  42. Ronald says

    May 13, 2009 at 4:18 am

    Hi Guys,

    OK, we are getting close now =)

    At this point I have a shared Exchange environment and I want to match the SIP domains to the exchange SMTP domains (which is also the same as the user’s UPN). For each of these domains I have created internal DNS zones. Externally there are also DNS zones for these domains.
    So I have a user [email protected] (as well for emailaddress, UPN and hopefully als as SIP account)

    I have the shared infrastructure :
    Internally:
    AD DNS Zone : shared.local, used as SIP routing domain. All user accounts reside in this AD. customers are split per OU.
    Externally:
    A Record : sip.allservices.nl
    SRV record : _sipfederationtls._tcp.allservices.nl

    Per customer :
    Internally:
    Exchange accepted authorative domain : customer01.nl
    DNS zone : customer01.nl
    A record : sip.customer01.nl
    SRV record : _sipinternaltls._tcp.customer01.nl -> sip.customer01.nl

    Externally:
    DNS zone : customer01.nl
    A record : ??
    SRV record : This provider does not support SRV records

    How do I configure the external DNS part ? Internally it all works.

    Suppose a new provider supports SRV records for customer01.nl and we move, can I then point the external SRV record from customer01.nl to the sip.allservices.nl (which is another DNS zone obviously) ? In that case a regular certificate non-SAN is enough.

    Thanks for saving the money on the AV cert =) !!

    Grtz,

    Ronald

    Reply
  43. Elan Shudnow says

    May 12, 2009 at 11:38 am

    Ya good catch. Don’t waste money on an A/V Cert. You just need one for the A/V Authentication. What I typically do there is request a separate individual certificate from an internal CA for A/V Authentication. In our internal environment, I did the following:
    1. Access Edge Certificate (Entrust)
    2. Web Conferencing Edge Certificate (Entrust)
    3. A/V Authentication Certificate (Internal CA)
    4. Internal Certificate (Internal CA)

    #3 and #4 are separate certificates.

    Reply
  44. Jan Boguslawski says

    May 12, 2009 at 11:25 am

    Hi again, here is what Microsofts OCS R2 Documentation is telling. I think this clarifies some things:

    Regards, Jan

    Certificate Requirements for the External Interface of Edge Servers
    ————————————————————————————
    Each Edge Server requires two certificates on the external interface—one for the Access Edge service, and one for the Web Conferencing Edge service. (The A/V Edge service does not require a certificate.) Each of these certificates must have a subject name that matches the external FQDN of that edge service on that server.

    For external certificates, public certificates are required for public IM connectivity, and to enable anonymous users to be invited to Web conferencing meetings. Public certificates also provide enhancements to federation relationships. Additionally, if you want to support public IM connectivity with AOL, AOL requires a certificate configured for both client and server authorization.

    A/V Authentication Certificate
    ————————————-
    An additional certificate is required for audio/video (A/V) authentication. The private key of the A/V authentication certificate is used to generate authentication credentials.

    This can be an internal certificate, but as a security precaution, you should not use the same certificate for A/V authentication that you use for any of the Edge Server services.

    The same A/V authentication certificate must be installed on each Edge Server if multiple servers are deployed in a load-balanced array. This means that the certificate must be from the same issuer and use the same private key.

    Reply
  45. Jan Boguslawski says

    May 12, 2009 at 11:21 am

    Hi Ronald, Hi Elan,

    I guess you dont need to buy a commercial certificate like av.allservices.nl for your Edge AV Server. This certificate is afaik only used to create a so called pseudo TLS tunnel. It will not be verfied by external connecting clients. Let save the money :) You can simply request this one from you internal CA. You dont need to add any SAN’s.

    Only your external Access and Web Conferencing Certificates need to public commercial. Please correct me if I am wrong.

    Best regards,
    Jan

    Reply
  46. Elan Shudnow says

    May 12, 2009 at 10:49 am

    I’d add a sipfederationtls for each sip domain. I talked with a Microsoft guy several months ago and he said PIC vendors do check for the SRV but don’t really use it yet if they ever will at all. The problem with PIC is that they ONLY look at the SN/CN of a certificate and not SAN names. Because of this, when you sign up for PIC, you’ll basically associate all your SIP domains with a single FQDN which will be the SN/CN of your Access Edge Certificate. This way PIC vendors know to route all SIP domains through a single FQDN.

    Also, I’d make sure that your 1st SAN name matches the CN/SN. For example:
    SN: sip.allservices.nl
    SAN: sip.allservices.nl with SANs sip.customers01.nl, sip.customer02.n
    SAN: sip.customers01.nl
    SAN: sip.customer02.nl
    Etc…..

    Reply
  47. Ronald says

    May 12, 2009 at 10:39 am

    Hi Elan,

    Finally, I can start ordering my certs. But it’s already a while ago since the installation of OCS.

    What do I exactly need for certificates for the Edge services ? I need one cert per edge service, that’s clear. So thought I purchase :
    regular certs : av.allservices.nl, webconf.allservices.nl
    SAN cert : sip.allservices.nl with SANs sip.customers01.nl, sip.customer02.nl, etc

    Then create SRV record _sipfederationtls._tcp.allservices.nl

    Add the A records sip.allservices.nl, sip.customers01.nl etc to the external DNS zones.

    Is this correct ? Do I need to create _sipfederationtls._tcp.customer01.nl as well if they want to use PIC or advanced federation ?

    BR,

    Ronald

    Reply
  48. Andy says

    April 27, 2009 at 11:42 am

    Fair point Juergen, I’ll try and get a new server with 4 nics and minimum spec to support this install.

    Thanks for your help.

    Reply
  49. Juergen says

    April 27, 2009 at 7:40 am

    Based on http://h18004.www1.hp.com/products/quickspecs/10902_div/10902_div.html this server is from the middle ages and won’t support x64 but no real time communication system at all.
    I think typewriters are faster.
    Regards,
    Juergen

    Reply
  50. Elan Shudnow says

    April 27, 2009 at 7:14 am

    The planning documentation as well as the planning tool will tell you the the hardware requirements for your ocs deployment.

    Reply
  51. Andy says

    April 27, 2009 at 4:26 am

    It would be installed on a HP DL380 G2? Not sure if that can cope with 64bit?

    Reply
  52. Juergen says

    April 27, 2009 at 4:02 am

    Hi Andy,
    R1 is 32 bit only, but missing a lot of features compared to R2. Also, 64 bit brings a lot in terms of permormance. If you want to go with R1 anyway, there is the Edge Deployment Guide: http://www.microsoft.com/downloads/details.aspx?familyid=ED45B74E-00C4-40D2-ABEE-216CE50F5AD2&displaylang=en
    In R1 it is not supportet to do NAT for the AV edge role, so the AV edge needs to be directly connected to the internet.
    Machines, that are not capable of 64 bit OS are likely to be quite old and therefore not suitable for a realtime media system like OCS anyway. Every AMD Athlon / Sempron x64 is capable of 64bit OS and they are 4 years old now! You might think about that.
    Regards,
    Juergen

    Reply
  53. Andy says

    April 27, 2009 at 3:55 am

    Juergen,

    Thanks for the quick reposnse, I’ve jusr realised that R2 can only run on 64 bit machine. Do you have any pointers to a similar guide for non R2 installs. We do not have any servers capable of running 64 bit windows.

    Also does the whole pool and edge server need to be R2 or can the backend be ocs 2007 and the edge 2007 R2?

    Thanks.

    Reply
  54. Juergen says

    April 25, 2009 at 6:47 am

    It is possible to run it with fewer IP addresses. I would definitely recommend one IP for each of these roles in your DMZ:
    – Access Edge
    – Web Conferencing Edge
    – AV Edge
    – Reverse Proxy (ISA listener)

    As you can use NAT for every role in R2, there might be the chance to take another public IP (e.g. the one from another web server) and reroute the required ports for one role to one IP in your perimeter network.
    Example:
    You have a web server for something else, listening on port 80 TCP.
    You have your NAT firewall configured to listen on port 80 TCP for the external IP 270.33.33.1. All web traffic is routed to the web server in the DMZ with the IP 10.1.1.1 on port 80 (port address translation table is used to do so).
    You can configure your firewall router to take all traffic from 270.33.33.1 on ports 5061 and 443 TCP to your consolidated edge server, where you configured IP 10.1.1.2 as your access edge interface IP also on these ports. In this case 270.33.33.1 is your public access edge IP address, where you would configure your DNS A record for access edge for (e.g. sip.contoso.com A 270.33.33.1).
    Hope this helps.
    Juergen

    Reply
  55. AndyC says

    April 25, 2009 at 3:38 am

    What a fantastic step by step guide. I have saved me hours of trawling through pages and pages.

    One question i have is, do you have to have separate ip’s/nics for all external facing services, or can i have a server with two physical nics one nic for internal connectivity and one for external connectivity.

    We have limited external public ips we can use.

    Thanks.

    Reply
  56. golfer_kuno says

    April 21, 2009 at 10:04 am

    hello, i setup our OCS 2007 and internally its working great. few weeks ago i started the edge server. i used notes from one of the knowledge base articles i saw on the net OCS_edgeserverdeploy.doc. my biggest issue is: i can get my external communicator client to talk ONLY when on the edge server i set the “Remote User Access Port” to 5061 but never get it to work when set to 443. i know its listening, i can see it when doing a netstat -an, both ports 5061 and 443 are showing up. here is my setup.

    communicator talking to OCS when:

    192.168.100.73 silver.semiconductor.com
    Federation port: 5061
    Remote User Access Port: 5061

    not talking to OCS when Remote User Access Port: 443.

    kindly let me know what am i doing wrong. thank you.

    Reply
  57. Paul says

    April 19, 2009 at 5:06 pm

    Elan, hopefully you can point me in the right direction. I have followed the instructions here. My confusion seems to be with the Edge servers. Internally all is well. External users can only connect if I point them to my Internal OCS Standard server. As I understand things, users should only be pointed to my Edge Server. ISA has the Internal OCS Standard server published per the instructions. My network setup is basically:

    OCS Standard Server: 192.168.15.x

    OCS Edge Server:

    Internal: 192.168.15.x
    Access Edge: 192.168.13.x
    A/V: 192.168.13.x
    WebConference: 192.168.13.x

    I have one external DNS record that points to the OCS Standard Server. (The ext. & int. names are the same)

    It seems even though I followed the instructions I am wondering if I have things installed on the Internal OCS Standard server that should be installed on the Edge Server.

    Reply
  58. Elan Shudnow says

    April 17, 2009 at 1:49 pm

    I have no plans to blog about CWA. If I spend any time blogging anything in my very busy schedule lately, it’d be on Exchange 2010 or OCS Voice, not CWA.

    Reply
  59. Marc says

    April 17, 2009 at 1:32 pm

    Elan, Can you cover OCWA a little? I have the virtual server installed, activated, and users are enabled however, when I try to log in I get this error “A problem occurred and the session was ended. Please sign in again. If the problem persists, contact your system administrator.(Error code: 0-0-18401-0-0)” I read something where this is a certificate problem with the virtual web access site and to disable the default web site, but I don’t get a certificate error from my web browser so I’m not sure that’s the problem. Also, there was advice to run a SIPstack trace, but I haven’t found how to do this to analyze this issue. Thanks for your help!

    Reply
  60. Elan Shudnow says

    April 17, 2009 at 11:09 am

    Lauren, I can’t say much since you haven’t given much. Look into your firewall, configuration on NICs, settings, etc… Make sure you follow the deploy guide correctly:
    http://technet.microsoft.com/en-us/library/dd441282(office.13).aspx

    You can also research using the OCSLogger and Snooper Tool. Netmon may also give you some insight.

    Reply
  61. Elan Shudnow says

    April 17, 2009 at 11:06 am

    Marc, all the port information is located in the OCS documentation.
    http://technet.microsoft.com/en-us/library/dd440724(office.13).aspx

    This section would most likely interest you:
    http://technet.microsoft.com/en-us/library/dd440724(office.13).aspx

    Reply
  62. Laurent says

    April 17, 2009 at 7:24 am

    Hi Elan, I got a souci. My edge’s configuration server has been validated but A/V doesn’t work for remote users. A/V work perfectely in the internal network.

    Thanks

    Reply
  63. Marc says

    April 16, 2009 at 3:35 pm

    Hmm, stopping the www publishing service allowed me to start the edge services that would not start. Then after a reboot, everything started just fine. Can you lead me to some information on listening port configuration for the web access virtual servers? Thanks.

    Reply
  64. Marc says

    April 15, 2009 at 4:11 pm

    Ok, I reinstalled and everything was successful except now 2 of the 4 services won’t start on my edge server. All the certs got assigned correctly it looks like. For some reason only the AV services started but not the other 2. Any ideas?

    Reply
  65. Marc says

    April 15, 2009 at 1:58 pm

    Thanks, I figured that one out. I’m still getting that error so I must not be assigning the certs correctly as I go through the Wizard. Although when I finish the configuration it only fails on the last check A/V Edge Server external FQDN saying “Cannot find object or property”. None of the services are starting either…

    Reply
  66. Elan Shudnow says

    April 15, 2009 at 1:35 pm

    If you go into the properties of your OCS Server in the admin tools, you should be able to manually force the OCS Server to use a specific certificate.

    Reply
  67. Marc says

    April 14, 2009 at 4:48 pm

    I appear to be stuck on the Edge server install. I tried to delete a cert that wasn’t correct and now I can’t get back to request another one. Each time I go to Configure Edge Server Wizard it gives me an error “Unable to read the certificate information, or the certificate is no longer available”. Duh, I removed it in IIS so now Configure Certificates is grayed out. How do I get around this?

    Reply
  68. Marc says

    April 13, 2009 at 4:33 pm

    I have an Edge server with 2 NICs. I was going to just add 3 IPs to the external and then assign roles to each IP, but it looks like the certs aren’t taking for each IP without it being on an individual NIC. How do I get around this?

    Also, it looks like no web sites have been installed in IIS on the Edge server. Perhaps this is because it routes requests to the front end server? Just wanted to make sure I’m not missing anything.

    Thanks,

    Reply
  69. Elan Shudnow says

    April 13, 2009 at 2:39 pm

    You should name the domain whatever is in external DNS. It doesn’t really matter what the domain is and doesn’t really have to match an AD domain or your SIP domain.

    Reply
  70. Mike says

    April 8, 2009 at 1:44 pm

    Elan, Thanks for putting this all together. I have one question that I hope you can answer. Say my AD domain is mike.corp and email is mike.com. When setting up the “External Web farm FQDN” section in part 2 I believe, do I set the name of the ISA server (isa.mike.com), or can I name it web.mike.com? I can’t tell if it really matters and the documentation isn’t really clear. Thanks again!

    Reply
  71. Elan Shudnow says

    April 3, 2009 at 2:43 pm

    Not sure if they fallback as there’s no documentation that talks about the federation SRV falling back as the SIPTLS one does for automatic logon. I’ve wondered the same but have always just put the SRV records in there.

    Reply
  72. Ronald says

    March 31, 2009 at 6:38 am

    Hi Elan,

    Thanks, I will let you know when I got the certs. Budget is a little tight but have good hope to have them soon.

    For federation to work, do you really need SRV records registered on the external DNS ? Or is there a fallback mechanism to A records ? My DNS provider supports DNS SRV records.

    BR,
    Ronald

    Reply
  73. Elan Shudnow says

    March 30, 2009 at 9:42 am

    Rodger, on the Edge, the internal NIC for the Access Edge will be contacted by the Front End using the VIP DNS Name. For the FE contacted the Web Conferencing Edge Internal NICs, it will contact the Internal NICs directly bypassing the VIP DNS Name.

    Reply
  74. Elan Shudnow says

    March 30, 2009 at 9:39 am

    The Access Edge does the Federation. I’d think of things for you to try, but get your certificates in proper working order before anything. You need a dedicated certificate for each role to be in a supported configuration.

    Reply
  75. Ronald says

    March 28, 2009 at 12:25 pm

    NB : In the Edge config I see at the internal interfac settings “User Authentication Certificate Information”. Why is this ? And why is this different from the TLS settings just above this one ?

    Thanks !

    BR,
    Ronald

    Reply
  76. Ronald says

    March 28, 2009 at 12:15 pm

    NB : The certificate on the Edge servers are all the same wild card cert, and I get warnings when I try to configure them. I could add them tough. I have not yet purchased dedicated certs for the Edge services.

    Could this be the problem ? Which service is responsible for the federation/public IM connectivity ? What is the outgoing IP address ?

    Grtz

    Reply
  77. Ronald says

    March 28, 2009 at 12:02 pm

    Hi Elan,

    Sorry for bothering again.

    I tried to get IM working, but now in my OCS clients I get the message “Limited External Calling”. With ISA logging I see that there is some traffic between the Edge server and the Front End server, I see only initiated and closed, which surprises me. I verified with telnet the following sessions :

    – From FrontEnd server to Internal Edge : 5061 = ok(Access), 5062 = ok(AV), 8057=ok(webconf). The certificate bound to the services contains the FQDN of the edge server.
    – From Edge to Front End : 5061 = ok(SIP), 5062=ok, 5063=ok,5064=ok.

    For the telnet sessions connects I use the FQDN that is noted in the OCS configuration, so from Edge to Front End I use the pool FQDN (which is also listed on the certificate).

    I didnt enable or configure enterprise voice.

    I see no errors in eventlog, the only error I see is :
    The process IMMcuSvc(2344) failed to send health notifications to the MCU factory at https://ocs-pool01.shared.local:444/LiveServer/MCUFactory/.
    Failure occurrences: 5, since 28-3-2009 16:41:30.

    Any ideas where to start looking ?

    BR,

    Ronald

    Reply
  78. Bill says

    March 28, 2009 at 1:41 am

    This has really hepled me out-thanks! Quick question: I had set up a standalone Standard Server and it was working fine. I had added A records of sip.domain.biz pointing to my FE server. Now that I have added an Edge server, do I need to change the A record to point to the internal interface on the Edge server? My external DNS is domain.net-The reason I ask is because I am getting certificate errors on the client because the expected server name is sipexternal.domain.net.

    Thanks!

    Reply
  79. Rodger says

    March 26, 2009 at 4:48 pm

    Thank you for the awesome article! Really helps this all make logical sense! I have one question thus far though. I have my front end, monitoring, and archiving servers all set up. Now I am working on my edge servers. Of course load balanced which is where I am finding many of my problems with the deployment to be at. I am a bit confused as to how to set up the VIP’s for the load balancing of the edge servers. I know I need av.domain.com; webconf.domain.com; accessedge.domain.com but the internal NICS do I create a server pool for those as well. such as IntOcsEdge.domain.com? When I go to configure the edge servers I think I will need the internal IP of that individual edge server and not the VIP of the load balancer but then think for the FQDN I will need the load balances FQDN such as IntOCSEdge.domain.com

    Thank you so much for your help! Greatly appreciated!

    Reply
  80. Nick says

    March 24, 2009 at 10:47 am

    This works OCS RTM, not for OCS R2.
    The ony way to do that I just found is deploy all services, use LCSCMD to deactivate un-needed services.

    Reply
  81. Elan Shudnow says

    March 23, 2009 at 9:41 am

    If you only want the Access Edge, when you go to deploy your Edge, only put the checkmark in the Access Edge and don’t select Web Conferencing or Audio/Video.

    Reply
  82. Nick says

    March 22, 2009 at 12:02 pm

    Hi:

    What if you i want to setup Edge with for PIC only. how do I disable (deactivate) AV and WebConf? the wizard does not give this option?

    thanks
    Nick

    Reply
  83. Elan Shudnow says

    March 12, 2009 at 10:28 am

    Digicert does and I know Entrust does with the Advantage and UC Certs. Not sure of others. I typically use Digicert and/or Entrust for all my certs since they’re supported for OCS (Digicert/Entrust/Comodo).

    As for inactivity, not sure.

    Reply
  84. Ronald says

    March 12, 2009 at 10:21 am

    Hi Elan,

    One final, do you know a company that does free re-issuing when you need an update of a domain name to a SAN cert ? I tried GlobalSign and GeoTrust but no can do.

    Do you have any idea ? Or two to be neutral =)

    BR,

    Ronald

    Reply
  85. Ronald says

    March 12, 2009 at 4:27 am

    Hi Elan,

    Many many thanks ! Think I got the whole picture now.

    BTW, do you know if or where you can set the inactivity time out for the CWA Service ?

    BR,

    Ronald

    Reply
  86. Elan Shudnow says

    March 11, 2009 at 4:44 pm

    Ronald, when the communicator client or Live Meeting client try to connect, they see the SRV record, do automatic logon, and if they’re talking to a FE, they’ll use the internal services. If they talk to an Access Edge, they’ll be referred to the AV/Webconf Edge Services. That’s how they hit those FQDNs.

    And yes about the public IP on ISA. ExternalWebFarmFQDN is for ISA to proxy to the InternalWebFarmFQDN that is on the Web Components Server which will be your Front End Server in a consolidated configuration.

    Reply
  87. Ronald says

    March 11, 2009 at 4:40 pm

    Hi Josha,

    I had the same as well, but this was because the default file type is set to .cer. Should have been .p7b or something in this case… And make sure you have the intermediate cert for commodo in your intermediate store.

    Grtz.

    Reply
  88. Elan Shudnow says

    March 11, 2009 at 9:05 am

    Joshua, I had that problem as well. You need to make sure the certificate chain (Root and Intermediate Certificates) are imported properly prior to importing your certificate. Do that and it will then work properly.

    Reply
  89. Joshua says

    March 11, 2009 at 7:10 am

    On the Edge Server every time I try and import a requested certificate, I get “the file is not a valid pkcs #7 response file’. The lastest file I tried to import was from Comodo. I got this when I requested from my enterprise CA as well.

    Reply
  90. Ronald says

    March 11, 2009 at 5:10 am

    Hi Elan,

    I understand that av and webconf are for the public part. But which clients make use of these records ? In which part or process are these records consulted ?

    Got the point about the web components role. This role is also public facing right ? So an external public IP is needed on the ISA side (additional to the Edge services NAT’ed IPs).

    BR,

    Ronald

    Reply
  91. Elan Shudnow says

    March 10, 2009 at 3:39 pm

    Webconf and av are for public facing edge communication.

    I’m publishing Front End because the External Web Farm FQDN reverse proxies to the Front End Web Components Role which would be the Internal Web Farm FQDN.

    Reply
  92. Ronald says

    March 10, 2009 at 2:55 pm

    Hi Elan,

    In part 4 you publish 192.168.1.163 which is your Front End server …. ? Maybe I misunderstood.

    I have one (last ?) question. Why is webconf.externaldomain01.com and av.externaldomain01.com registered externally and not internally ? Is it for legacy client support ? Are these URLs presented to the external client with the Edge Access service ?

    Thanks in advance !

    BR,

    Ronald

    I keep you posted on my Mediation progress, now first a week holiday

    Reply
  93. Elan Shudnow says

    March 9, 2009 at 9:54 am

    You don’t need a Public IP for Front End. That’s what Edges are for.

    Windows NLB is not supported. You need a Hardware Load Balancer. At the MVP Summit, a few of us including myself made it quite clear we want Windows NLB support. It shouldn’t be too d ifficult adding in a Load Balancer afterwards. But that brings an entire new challenge in itself.

    Good luck on the Mediation stuff. It’s not difficult to implement if you understand how the normalization works and the architecture.

    Reply
  94. Ronald says

    March 9, 2009 at 9:43 am

    Hi Elan,

    Made my day !

    So when using A records externally and SRV records internally, having SAN certs with the sip domains in it, one cert per Edge Service, OCS is fully transparent being outside or inside ?

    Cool ! But OCS costed my 5 public IPs !! 3 x Edge Service, 1 x Front End, 1 x CWA.

    All servers are now single. Is it difficult to add a load balancer for some services afterwards ? And is somehow NLB supported ? Didn’t see any options for that yet.

    Now on for the Meditation Server.

    BR,

    Ronald

    Reply
  95. Elan Shudnow says

    March 9, 2009 at 9:01 am

    Well, if you do not have SRV records, Communicator will still fallback to using A records. Check out Jeff Schertz blog post here which describes the fallback process:
    http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=14

    And yes, you can also configure Communicator manually.

    As for your certificate question:
    Access Edge – sip.domain1.com

    For each sip domain, you’ll need SRV records if you want to point to the sip.domain1.com. If you don’t support SRV records, you can still use SAN certificates, but you’ll need a “dedicated” SAN certificate for your AccessEdge so it can have multiple names such as sip.domain.com, sip.domain1.com, sip.domain2.com, etc… That way each A record for fallback will be on the certificate.

    And if you use Federation/PIC, you can still tell them that for all of your sip domains, use the SN/CN of your certificate (sip.domain1.com) for communication as Federation allows you to use one FQDN for multiple sip domains. In fact, PIC and LCS Federation requires you to use the CN of your certificate.

    Another thing to note is that SAN certificates are supported on your Edge. You just need to have a dedicated cert per NIC. That’s a bit different than saying SAN certificates aren’t supported.

    Reply
  96. Ronald says

    March 9, 2009 at 8:04 am

    Hi Elan,

    Thanks !

    I still do not understand the external part. I think my current ISP does not support SRV records. Do I still need the sip.domain01.com, sip.domain02.com etc. registered in DNS ? Does it make any sense ? Or can you configure the communicator client (if used externally) manually to point to a generic entry point like sip.alldomains.com ?

    Suppose I change to an ISP that supports SRV records. MS states you need one cert per Edge service. You cannot use SAN certificates. I can bind only one cert to an Edge service. So I can bind typically only sip.domain01.com to one Edge service. How do I setup an Edge service if also domain02.com should use the service ? Can I only overcome these issues if I create a dedicated Edge server per domainxx.com ? Hopefully there is a cheaper solution … ?

    BR,

    Ronald

    Got the CWA service and the internal stuff up and running.

    Reply
  97. Elan Shudnow says

    March 8, 2009 at 10:12 pm

    No problem.

    For the Edge Server, you’ll just use NAT Rules so a Public IP gets NAT’d to the Private IP. This is otherwise known as Static NAT. Again, ISA is only used to reverse the External Web Conferencing FQDN which has nothing to do with the Edge Server.

    If you have multiple dns zones, then in each of those DNS zones, you just have the automatic logon/federation srv records point to the Access Edge FQDN.

    Reply
  98. Ronald says

    March 8, 2009 at 7:13 am

    Hi Elan,

    Thanks for all your information !

    Still some questions. You state that you do not publish the Edge with ISA. Basically I planned to use a simple NAT rule for the edge services, not with a publishing wizard or something. I guess that works ?

    If I have mutliple external domains like domain01.com and domain02.com, can I point all records like sip.domain01.com and sip.domain02.com to sip.allresources.com ? allresources.com contains the edge services and the front end published stuff.

    Internally it’s simpler, because I can rely on SAN certs, so I can use one cert with multiple names having each sip.domainxx.com in there (we have primary zones internally). What about the external part ? Or should I deploy one Edge server and one public IP space for each domainxx.com ?

    BR,

    Ronald

    Reply
  99. Elan Shudnow says

    March 5, 2009 at 6:04 pm

    You have to enable federation and enable PIC. In Global Settings on your Front End, set the Federation route to your internal NIC on your Edge. On your Edge, enable PIC on one of the tabs (pretty sure the tab name is PIC but not 100% sure). Then just enable the settings to allow for Federation on your Edge. This is all if you’re not using Directors which I doubt you are.

    Reply
  100. rakesh says

    March 5, 2009 at 4:35 pm

    how can i enable im cummunication with yahoo or msn. where to configure all these things

    Reply
  101. Elan Shudnow says

    March 4, 2009 at 9:14 am

    I show the screen what FQDNs I use for my Edge Server in this article already. Web Conferencing Edge doesn’t have an internal FQDN and an external FQDN. You’re probably thinking about Web Farm FQDN which is different and is where ISA comes into the mix.

    The internal web farm fqdn should be the name of your standard pool, the enterprise consolidated pool, or the expanded set of web component servers. The external web farm fqdn is the ISA FQDN you want to proxy to your internal web farm FQDN.

    When you set up an Edge with Web Conferencing, it talks to the next hop server which will provide the Edge to Internal Server Web Conferencing connection. If a user is part of a different pool, that next hop pool will proxy the traffic to the correct pool. Or if you have a director, the director will instead proxy the traffic. Or if you have multiple locations, you can have the web conferencing edge in multiple locations and the access edge will see you have a web conferencing edge local to your site and redirect your web conferencing traffic to your local web conferencing edge server.

    As for your sip.exchange.shudnow.net question. Internally, I need to allow users to log on to exchange.shudnow.net since that’s the SIP domain. Because of that, I had to create an internal zone. When you configure the pool, you specify both your AD domain (for OCS Routing) and your external namespace SIP domain which users will use for logon. When you configure the certificate, OCS will see you have both SIP domains and configure the certificate with a sip.exchange.shudnow.net. So you want to create the exchange.shudnow.net zone (if it doesn’t already exist), create the SRV record there, and point it to sip.exchange.shudnow.net since that’s the format the certificate wizard uses (sip.namespace.tld).

    So for my access edge, I always use sip.namespace.tld. You can use accessedge.exchange.shudnow.net if you really want. And because it’s the access edge fqdn, I need to use the external namespace here as well. And because of that, it happens to be sip.exchange.shudnow.net

    Reply
  102. Marcin says

    March 4, 2009 at 8:25 am

    Another question, about Web Conferencing Edge Servers tab in web conferencing properties of ocs server. Internal server is webconf[…] as i presume, and what about external?

    Reply
  103. Marcin says

    March 4, 2009 at 7:36 am

    And can you post your configuration of ocspool -> global properties -> edge servers tab? I do not know, which fqdn’s i shuld use there.

    Reply
  104. Marcin says

    March 4, 2009 at 7:33 am

    Hi.
    Can you explain to me, why in part 4 you bind in dns .163 to sip.exchange.shutdown.net and in this part, you’re binding sip.exchange.shutdown.net to .183 – your access edge server. There is nothing wrong with it?

    Reply
  105. Elan Shudnow says

    March 3, 2009 at 11:21 am

    You don’t use ISA 2006 to publish an Edge Server. You use ISA 2006 to publish the Front End Services that you specified as the External Web Farm FQDN. Check out part 4 of this article series in which I talk about this:
    https://www.shudnow.io/2009/01/18/office-communications-server-2007-r2-enterprise-deployment-part-4/

    Also, SAN certificates on your Edge Server are not supported. To be in a supported configuration, you are required to have a dedicated certificate for each FQDN. While I have set up an Edge Server with a single SAN certificate and it worked just fine, it’s still not supported. Also, depending on the certificate vendor and what certificate you are obtaining from them, you can get free re-issues certificates.

    Reply
  106. Ronald says

    March 3, 2009 at 6:57 am

    Hi guys,

    I have an internal AD with ad.local. I host various email domains, domain01.com, domain02.com etc. The SIP domains are the same as the email domains. Internally I have created DNS zones for domain01.com, domain02.com and so on. ad.local is not a SIP domain, but used for routing.

    I have an edge server with private CA certificates. I have SANs on the certs, so the certs are good for either ocs-server.ad.local and also sip.domain01.com;sip.domain02.com etc.

    If I use ISA 2006 to publish the edge server to the outside, what should I configure on the certs for the public web listener ? And what should I configure as public DNS (my current provider does not have SRV record support). I do not want to use SANs on the certs on the public side, because a new domain would require an update of the cert to include the new domain name (which is not for free I guess).

    Anybody has an idea ?

    BR,

    Ronald

    Reply
  107. Elan Shudnow says

    February 25, 2009 at 6:46 pm

    So the A/V Authentication certificate matches the A/V FQDN but the A/V Authentication is used for internal communications only and no public facing certificate is required for users accessing A/V from the internet. Still though, the A/V Authentication matches the A/V FQDN.

    Check out the internal DNS requirements for OCS R2 Edge Servers:
    http://technet.microsoft.com/en-us/library/dd425138(office.13).aspx

    You only really need an A record that matches the FQDN of the Server due to MTLS requirements. MTLS requires a certificate that matches the FQDN of the Servername for MTLS to succeed.

    And as I mentioned above, if you’re doing NAT for A/V, you’ll need the A record in internal DNS that contains the publicly routed IP that the A/V uses for the NAT. That isn’t documented but is a requirement for it to work.

    Reply
  108. Kamil says

    February 25, 2009 at 2:40 pm

    192.168.1.180 :)

    Reply
  109. Kamil says

    February 25, 2009 at 2:39 pm

    Sorry, imeant for internal DNS you have mapping 92.168.1.180 for av.exchange shudnow.net…

    BR
    Kamil

    Reply
  110. Kamil says

    February 25, 2009 at 2:38 pm

    Hi Elan,

    You have used the same FQDN for A/V edge external interface and for internal A/V authentication certificate. Do you split DNS for that purpose?

    On external DNS you have mapping 192.168.1.181 for av.exchange shudnow.net and on internal 192.168.1.181 for av.exchange shudnow.net ?

    Is that correct? Doesn’t it make any problems? Or maybe there should be different FQDN for AV edge and AV Authentication service?

    BR
    Kamil

    Reply
  111. DanhCong says

    February 25, 2009 at 12:21 am

    Hi Jan!
    Thanks for your help. I did it after following your way. Now so happy.

    Best regard!
    DanhCong

    Reply
  112. Elan Shudnow says

    February 24, 2009 at 5:16 pm

    Yep, I do know that. Just didn’t go into detail so thanks for doing that. One other thing to note which is not documented that if you do decide to NAT the AV Edge IP that you need to create an internal HOST/A record for the Public NAT’d IP. So for example, if you are NAT’ing 30.30.30.20 to your AV Edge IP which has a FQDN of av.domain.com, then in internal DNS you have to create an A record in internal DNS for av.domain.com with an IP of 30.30.30.20. One of my coworker’s ran into this and had to call PSS in which they finally figured out after 5 Escalation Engineers that this was required but wasn’t documented. This was a few weeks ago and may already have been updated in the current documentation.

    Reply
  113. Jan Boguslawski says

    February 24, 2009 at 3:39 pm

    Hi DanhCong,

    please note: you should not NAT your Edge Server on both sides. NAT is only allowed on the external A/V Edge IP. (@Elan I guess you know this) I just wanted to add this Detail. So natted internal IP on Edge want work – for Media. Background: it breaks the TURN/ICE mechanism that helps the clients over NAT.

    In the compmgmt.msc Services and Applications you will find the OCS Edge Management SnapIn and Edge properties. On the Edge Interfaces TAB you will find the A/V Edge interface Management. Click configure and it shows you a deactivated checkbox: External IP address is translated by NAT. You will not find any similar NAT option in the server. In the “OCS Edge discussion ” with R1 I often used this map, to demonstrate the challenges with Edge.

    http://forum.pbxnsip.com/index.php?act=attach&type=post&id=164

    The biggest improvements in R2 Edge are:

    External IP of A/V edge can be natted, as long as it one consolitated Edge!
    Not neccessary to open 10000 ports on the external firewall to media acces to A/V 443 TCP and 3478 UDP required :)

    Best regards
    Jan

    Reply
  114. Elan Shudnow says

    February 24, 2009 at 6:55 am

    Yes, you can use NAT with AV. Read Part1: https://www.shudnow.io/2009/01/05/office-communications-server-2007-r2-enterprise-deployment-part-1/

    Reply
  115. DanhCong says

    February 24, 2009 at 4:20 am

    Is it possible public A/V edge server that network relationship is NAT

    Reply
  116. Jan Sverre says

    February 11, 2009 at 6:10 am

    Found my answer in part1 :-)

    Reply
  117. Jan Sverre says

    February 11, 2009 at 2:47 am

    Great article, but one question: Isn’t it possible to have just two cards in the edge server, and instead have multiple IP’s on the external card? Or is it a requirement to use one physical interface per external IP?

    Reply
  118. Elan Shudnow says

    February 10, 2009 at 6:42 pm

    You only need av.domain.com DNS on external DNS. For internal DNS for the Edge, you only need the internal FQDN of the internal interface. If not using load balancing, this would be the FQDN of the server. If using load balancing, this would be the FQDN of the load balancer.

    You can see DNS requirements here:
    http://technet.microsoft.com/en-us/library/bb870404.aspx

    Reply
  119. Juergen says

    February 10, 2009 at 4:05 pm

    Hi Elan,
    good article. I think it is missing one important thing: The DNS entries on the internal DNS. For my understanding this is not only the cons. edge fqdn, but also the internal name for av edge authentication.
    Please correct me if I’m wrong.
    Regards,
    Juergen

    Reply
  120. Elan Shudnow says

    February 9, 2009 at 6:50 am

    No, just configure the Edge Settings on your Pool to point to the existing Edge and then configure your existing Edge to allow your Front End/Pool to communicate with it. Your Edge will communicate with the Next-Hop Server and then that Pool will proxy the communication. For outbound traffic from the Pool to Internet, the new pool will communicate with the Edge Directly.

    Reply
  121. Marc says

    February 9, 2009 at 6:17 am

    Hi, thx for the article…
    I got a question.
    We have a OCS 2007 pool with an edge server (2007).
    Is it possible to connect this Edge Server to a new OCS 2007 R2 pool environment? Or do I also have to install a new OCS Edge Server?

    Reply
  122. Elan Shudnow says

    February 8, 2009 at 10:00 pm

    You said the certificate for ISA is ISA2K6.tailspintoys.com. When you installed OCS, did you specify this FQDN for your External Web Farm FQDN? You’ll want to have this External Web Farm FQDN and proxy it to the Pool FQDN. Because of this, you’ll want to ensure that the root certificate for your internal CA is present on the ISA Box. Make sure that you install the root certificate directly into the Trusted Root Store in the computer settings (not sure). I’ve seen cases where importing the certificate in the wrong location and moving it to the correct location breaks the certificate trust. Make sure you import it directly into the correct certificate store.

    Reply
  123. HOC says

    February 8, 2009 at 7:11 pm

    Hi,

    Thank you for the very helpful article.

    I am setting up a lab to simulate external user access via OCS consolidated edge. I have created all certificates using Win 2003 CA.

    I am able to successfully simulate external Communicator access for IM. When I go into Live Meeting, I am able to do all the LM functions, except uploading a file, and AV.

    When I upload a powerpoint presentation, the internal user is able to see the content, but the external user gets the error:

    “Unable to load content because of configuration settings in the conference center”

    I suspect that this has something to do with the reverse proxy, and I try to do some test to isolate it by trying to access the following URL:

    https:///abs/ext

    https:///conf/ext/Tshhot.html

    I am not able access the sites. I am able to do so however, using the internal FE FQDN.

    When I look into the ISA Alerts, I have the following error:

    “SSL Connection Failure with the Published Server:

    ISA could not establish a connection with the published server 10.0.0.2 (this is the FE server) on port 443 because the name on the SSL server certificate used by the published server does not match the internal name of the Web Server sip.tailspintoys.com, as sepcified in the publishing rule..”

    My setup details are below. Appreciate guidance on what I may have missed to make the Upload File feature to work:

    Machine 1:

    Active Directory ,Internal DNS and Internal CA (ADEX.tailspintoys.com)

    IP: 10.0.0.1

    Machine 2:

    Front End Server Standard Edition (OCS2K7.tailspintoys.com)

    IP: 10.0.0.1

    Certificates Installed:

    1. Root Certificate

    2. FE certificate SN: ocs2k7.tailspintoys.com , SAN: sip.tailspintoys.com

    3. reverse proxy certificate SN:isa2K6.tailspintoys.com

    Machine 3:

    Consolidated Edge Server, external DNS

    Internal IP: 10.0.0.4 (OCS2K7Edge.tailspintoys.com)

    Access Edge IP: 192.168.1.5 (ExternalAccessEdge.tailspintoys.com)

    AV Edge IP: 192.168.1.6 (ExternalAVEdge.tailspintoys.com)

    Web Conf Edge IP: 192.168.1.7 (ExternalWebConfEdge.tailspintoys.com)

    Certificates Installed:

    1. root certificate

    2. FE certificate SN:OCS2K7.Tailspintoys.com

    3. Access Edge certificate: SN: externalaccessedge.tailspintoys.com

    4. AV Edge certificate: SN: externalavedge.tailspintoys.com

    5. Web Conf Edge certificate: SN: externalwebconfedge.tailspintoys.com

    Machine 4: Reverse Proxy

    Internal IP: 10.0.0.17

    External IP: 192.168.1.17

    Certificates Installed:

    1. FE Certificate : SN: OCS2K7.tailspintoys.com SAN:sip.tailspintoys.com

    2. Reverse Proxy Certificate: SN: ISA2K6.tailspintoys.com

    3. Root Certificate

    Firewall Policies:

    Web Site Publishing Rule (To publish FE content, through port 443)

    Default ISA Rule (Deny All traffic)

    Reply
  124. henock says

    February 4, 2009 at 6:55 am

    Thanks for clarifying

    Reply
  125. Elan Shudnow says

    February 4, 2009 at 6:50 am

    The Edge just needs to be able to resolve the next hop pool. However you do that on the Pool with DNS configuration is up to you (DNS settings on Internal NIC, or DNS Settings only on External NIC with Hosts File, etc…)./

    Reply
  126. henock says

    February 4, 2009 at 3:56 am

    hi elan,

    thanks, is there any srv dns requirement i need to add on the “internal” dns for the egde servers for Next Hop.

    Thanks again for your time

    Reply
  127. Elan Shudnow says

    February 3, 2009 at 10:18 pm

    So internally you are correct. For external dns, you’d create a _sip._tls.domain.com that points to the FQDN of your Access Edge. So if your access edge is sip.domain.com then you’d have your _sip._tls.domain.com pointing to sip.domain.com over port 443.

    Reply
  128. henock says

    February 3, 2009 at 5:37 pm

    hello Elan

    can youy please clarify some confusion i have regarding srv records please. My users are SIP enabled for domain.com, I’ve created OCSPool A Record, and then created the SRV record to point to OCSpool.domain.com.
    Ex: _sipinternaltls Service Setting (SRV) [0][0][5061] pool01.domain.com. MOC and live meeting are working like a treat with auto configuration.

    now My question is do i still need to create another srv record for sipinternaltls pointing to sip.domain.com
    Ex: _sipinternaltls Service Setting (SRV) [0][0][5061] sip.domain.com when i deploy the edge servers.

    thanks

    Reply
  129. Abdul Aziz says

    January 23, 2009 at 8:49 am

    Yes thats what I meant. Thanks for clarifying!!

    Reply
  130. Elan Shudnow says

    January 23, 2009 at 7:19 am

    Abdul, those first 3 FQDNs don’t all point to the Access Edge. The Edge will have 3 IPs that are public facing. The Access Edge DNS will go to the Access Edge IP. The Web Conferencing FQDN will point to the Web Conferencing IP. The A/V FQDN will poin tto the A/V IP. But if what you meant to say is that the first 3 FQDNs point to the Edge Server, then yes, that’s correct.

    Reply
  131. Abdul Aziz says

    January 23, 2009 at 7:04 am

    Thank you for explaining in detail. To reiterate my understanding, the following URLs should point directly to the Access Edge behind a router:

    Access Edge – sip.domain.com
    Web Conferencing – webconf.domain.com
    A/V – av.domain.com

    while we use ISA just to publish ExtWebFarm.domain.com which is the OCS FE pool, is that correct?

    Thanks again for your time!

    Reply
  132. Jan Boguslawski says

    January 23, 2009 at 7:01 am

    Thanks for the hint. I did this at two Edge Servers, one was ok, one not :) After comparing the installed programs I saw, that I simply forgot the OCS R2 Administrative Tools one the second.

    Sometimes it is good to have a second pair of eyes. Thanks again, of course also for your great articles!

    Best regards,
    Jan

    Reply
  133. Elan Shudnow says

    January 23, 2009 at 6:45 am

    Yes, I did install it on Windows 2008 x64.

    Start > Run > compmgmt.msc

    Reply
  134. Jan Boguslawski says

    January 23, 2009 at 6:00 am

    Hello Elan,

    did you installed OCS R2 Edge Server on a W2K8 x64 Server? I did, but now I cant find the Administration Console. In R1 it was hidden in Computer Management / Services and Applications. But in W2k8 x64 Server it is vanished. The only way to administer atm. is rerun the setup. But I dont like this.

    Any hint would be appreciated :)

    Best regards,

    Jan

    Reply
  135. Elan Shudnow says

    January 22, 2009 at 7:59 am

    ISA is only for reverse proxying just a few things. When you go through the installation, it’ll ask you for your External Web Farm FQDN. This is what ISA is for, the External Web Farm FQDN.

    The names your Edge Server is publishing, the Access Edge FQDN, the Web Conferencing FQDN, and the A/V Conferencing are different names.

    ISA – ExtWebFarm.domain.com
    Access Edge – sip.domain.com
    Web Conferencing – webconf.domain.com
    A/V – av.domain.com

    So users using IM outside of the corporate firewall will go through the Access Edge which will then talk to the next hop and that next hop will authenticate the user. Once they are authenticated, they will be logged on and then behind the scenes, a connection will be made to ISA to download Address Book or if they need to expand a distribution group, a connection through ISA will be made. If they utilize Web Conferencing and upload a file, a connection will be made through ISA for that.

    Reply
  136. Abdul Aziz says

    January 22, 2009 at 6:05 am

    Hello Elan
    I want to confirm one thing- should the Edge server be published to the internet or the OCS Front End pool using ISA Server? Reading the documentation, it seems that the Edge server cannot authenticate users by itself.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

  • GitHub
  • LinkedIn
  • RSS
  • YouTube

More to See

Azure AD User Settings

Pre-creating Azure AD App for Azure Migrate

January 24, 2023 By Elan Shudnow

Azure Runbooks Connecting to Exchange Online and Microsoft Graph

July 22, 2022 By Elan Shudnow

Using Python 3.8.0 Azure Runbooks with Python Packages

July 11, 2022 By Elan Shudnow

Preserving UNC Path after Azure Files Migration using DFS-N

April 10, 2022 By Elan Shudnow

Tags

ACR Always Encrypted Ansible Automation Availability Sets Availability Zones Azure Azure Active Directory Azure Application Gateway Azure Files Azure Firewall Azure Key Vault Azure Load Balancer Azure Migrate Azure Monitor Azure Web App CDN Cluster DevOps DFS Docker DPM Event Grid Exchange Exchange 2010 Exchange Online Function App ISA iSCSI Log Analytics Logic App Lync Microsoft Graph OCS Office Personal PowerShell Proximity Placement Groups Runbook SCOM Storage Accounts Symantec Virtual Machines Windows Server 2008 Windows Server 2008 R2

Footer

About Me

Microsoft Cloud Solution Architect focused on Azure IaaS, PaaS, DevOps, Ansible, Terraform, ARM and PowerShell.

Previously a 6x Microsoft MVP in Exchange Server and Lync Server.

My hobbies include watching sports (Baseball, Football and Hockey) as well as Aviation.

Recent

  • GRS Storage and BCDR Considerations
  • Pre-creating Azure AD App for Azure Migrate
  • Azure Runbooks Connecting to Exchange Online and Microsoft Graph
  • Using Python 3.8.0 Azure Runbooks with Python Packages
  • Preserving UNC Path after Azure Files Migration using DFS-N

Search

Tags

ACR Always Encrypted Ansible Automation Availability Sets Availability Zones Azure Azure Active Directory Azure Application Gateway Azure Files Azure Firewall Azure Key Vault Azure Load Balancer Azure Migrate Azure Monitor Azure Web App CDN Cluster DevOps DFS Docker DPM Event Grid Exchange Exchange 2010 Exchange Online Function App ISA iSCSI Log Analytics Logic App Lync Microsoft Graph OCS Office Personal PowerShell Proximity Placement Groups Runbook SCOM Storage Accounts Symantec Virtual Machines Windows Server 2008 Windows Server 2008 R2

Copyright © 2025 · Magazine Pro on Genesis Framework · WordPress · Log in