RSS Subscription 168 Posts and 2,769 Comments

Office Communications Server 2007 R2 Enterprise Deployment – Part 5

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

151 Responses to “Office Communications Server 2007 R2 Enterprise Deployment – Part 5”

  1. on 11 Jun 2009 at 9:47 amOzgur

    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 ?

  2. on 11 Jun 2009 at 3:35 pmElan Shudnow

    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.

  3. on 15 Jun 2009 at 7:08 amAkhilesh

    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. :-)

  4. on 15 Jun 2009 at 4:16 pmElan Shudnow

    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.

  5. on 25 Jun 2009 at 9:45 amTrung T

    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.

  6. on 25 Jun 2009 at 10:05 amElan Shudnow

    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.

  7. on 25 Jun 2009 at 10:08 amTrung T

    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

  8. on 26 Jun 2009 at 11:01 amJohn Bales

    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?

  9. on 26 Jun 2009 at 11:12 amJürgen

    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

  10. on 26 Jun 2009 at 12:03 pmJohn Bales

    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.

  11. on 26 Jun 2009 at 12:42 pmJohn Bales

    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.

  12. on 26 Jun 2009 at 12:45 pmJürgen

    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.

  13. on 26 Jun 2009 at 1:01 pmJohn Bales

    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?

  14. on 26 Jun 2009 at 1:08 pmJürgen

    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

  15. on 26 Jun 2009 at 2:17 pmJohn Bales

    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.

  16. on 20 Jul 2009 at 10:39 amTrung T.

    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

  17. on 22 Jul 2009 at 11:42 amElan Shudnow

    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?

  18. on 24 Jul 2009 at 1:24 pmSean

    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!

  19. on 24 Jul 2009 at 1:29 pmSean

    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?

  20. on 24 Jul 2009 at 1:34 pmJohn Bales

    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.

  21. on 25 Jul 2009 at 1:56 amSean

    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.

  22. on 31 Aug 2009 at 8:39 amsuperjoe

    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 ?

  23. on 31 Aug 2009 at 1:34 pmElan Shudnow

    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.

  24. on 31 Aug 2009 at 3:42 pmsuperjoe

    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…

  25. on 31 Aug 2009 at 3:51 pmElan Shudnow

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

  26. on 14 Sep 2009 at 9:15 pmTasos

    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)?

  27. on 14 Sep 2009 at 10:00 pmElan Shudnow

    From a Microsoft supported standpoint, no.

  28. on 14 Sep 2009 at 10:07 pmTasos

    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?

  29. on 14 Sep 2009 at 11:44 pmElan Shudnow

    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.

  30. on 16 Sep 2009 at 4:02 amTobias

    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

  31. on 18 Oct 2009 at 1:22 amJosh Lynch

    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).

  32. on 18 Oct 2009 at 1:23 amJosh lynch

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

  33. on 18 Oct 2009 at 1:24 amJosh Lynch

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

  34. on 18 Oct 2009 at 2:50 amJosh Lynch

    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

  35. on 21 Oct 2009 at 6:40 pmElan Shudnow

    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.

  36. on 09 Dec 2009 at 3:58 pmgolfer kuno

    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.

  37. on 09 Dec 2009 at 5:34 pmElan Shudnow

    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.

  38. on 21 Dec 2009 at 9:31 pmgolfer kuno

    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

  39. on 22 Dec 2009 at 1:06 amElan Shudnow

    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.

  40. on 22 Dec 2009 at 3:35 pmgolfer kuno

    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.

  41. on 22 Dec 2009 at 4:01 pmgolfer kuno

    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.

  42. […] http://www.shudnow.net/2009/01/20/office-communications-server-2007-r2-enterprise-deployment-part-5/ Categories: OCS 2007 R2 Tags: Comments (0) Trackbacks (0) Leave a comment Trackback […]

  43. on 15 Dec 2009 at 8:19 amAndrea

    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!

  44. on 15 Dec 2009 at 8:42 pmElan Shudnow

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

  45. on 25 Jan 2010 at 5:12 pmMike

    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

  46. on 22 Mar 2010 at 10:24 pmmarc

    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.

  47. on 25 Aug 2010 at 1:50 amSaneesh

    Hi Elan,

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

    Thanks
    Saneesh

  48. on 16 May 2011 at 5:27 amFrancois

    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

  49. on 18 Jan 2012 at 4:19 amLuke

    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).

  50. on 18 Jan 2012 at 4:20 amluke

    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.

  51. on 18 Jan 2012 at 4:22 amluke

    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

Trackback this post | Feed on Comments to this post

Leave a Reply