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 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.
- Install Files for Edge Server
- Activate Edge Server
- Configure Edge Server
- Configure Certificates for Edge Server
- Start Services
- 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.
luke says
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
luke says
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.
Luke says
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).
Francois says
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
Saneesh says
Hi Elan,
Can you please tell me the features available with this setup.
Thanks
Saneesh
marc says
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.
Mike says
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
Andrea says
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!
Elan Shudnow says
Not sure if it's supported and I haven't tried it. I always just create the accounts on the Edge Server itself.
Elan Shudnow says
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.
golfer kuno says
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
Elan Shudnow says
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.
golfer kuno says
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.
golfer kuno says
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.
golfer kuno says
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.
Josh Lynch says
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…
Elan Shudnow says
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.
Josh Lynch says
Firewall is open, i can telnet to 443 on ocs.domain.com just fine. Why is it asking for 5061?
Josh Lynch says
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).
Josh lynch says
by "av.com" i mean "av.domain.com". Same goes for "livemeeting.com" meaning "livemeeting.domain.com"
thanks.
Tobias says
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
Tasos says
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?
Elan Shudnow says
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.
Tasos says
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)?
Elan Shudnow says
From a Microsoft supported standpoint, no.
superjoe says
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 ?
Elan Shudnow says
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.
superjoe says
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…
Elan Shudnow says
You and me both. There has been a lot of feedback to Microsoft about the need to consolidate services.
Sean says
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.
John Bales says
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.
Sean says
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?
Sean says
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!
Trung T. says
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
Elan Shudnow says
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?
John Bales says
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.
Jürgen says
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
John Bales says
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?
Jürgen says
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.
John Bales says
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.
John Bales says
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.
Jürgen says
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
John Bales says
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?
Trung T says
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
Trung T says
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.
Elan Shudnow says
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.
Elan Shudnow says
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.
Akhilesh says
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. :-)
Elan Shudnow says
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.
Ozgur says
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 ?
Andy C says
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
Elan Shudnow says
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.)
Andy C says
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.
Ronald says
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
Jan Boguslawski says
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
Ronald says
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
Elan Shudnow says
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.
Jan Boguslawski says
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.
Jan Boguslawski says
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
Elan Shudnow says
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…..
Ronald says
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
Andy says
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.
Juergen says
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
Elan Shudnow says
The planning documentation as well as the planning tool will tell you the the hardware requirements for your ocs deployment.
Andy says
It would be installed on a HP DL380 G2? Not sure if that can cope with 64bit?
Juergen says
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
Andy says
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.
Juergen says
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
AndyC says
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.
golfer_kuno says
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.
Paul says
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.
Elan Shudnow says
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.
Marc says
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!
Elan Shudnow says
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.
Elan Shudnow says
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
Laurent says
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
Marc says
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.
Marc says
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?
Marc says
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…
Elan Shudnow says
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.
Marc says
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?
Marc says
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,
Elan Shudnow says
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.
Mike says
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!
Elan Shudnow says
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.
Ronald says
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
Elan Shudnow says
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.
Elan Shudnow says
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.
Ronald says
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
Ronald says
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
Ronald says
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
Bill says
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!
Rodger says
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!
Nick says
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.
Elan Shudnow says
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.
Nick says
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
Elan Shudnow says
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.
Ronald says
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
Ronald says
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
Elan Shudnow says
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.
Ronald says
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.
Elan Shudnow says
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.
Joshua says
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.
Ronald says
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
Elan Shudnow says
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.
Ronald says
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
Elan Shudnow says
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.
Ronald says
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
Elan Shudnow says
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.
Ronald says
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.
Elan Shudnow says
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.
Ronald says
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
Elan Shudnow says
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.
rakesh says
how can i enable im cummunication with yahoo or msn. where to configure all these things
Elan Shudnow says
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
Marcin says
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?
Marcin says
And can you post your configuration of ocspool -> global properties -> edge servers tab? I do not know, which fqdn’s i shuld use there.
Marcin says
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?
Elan Shudnow says
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.
Ronald says
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
Elan Shudnow says
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.
Kamil says
192.168.1.180 :)
Kamil says
Sorry, imeant for internal DNS you have mapping 92.168.1.180 for av.exchange shudnow.net…
BR
Kamil
Kamil says
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
DanhCong says
Hi Jan!
Thanks for your help. I did it after following your way. Now so happy.
Best regard!
DanhCong
Elan Shudnow says
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.
Jan Boguslawski says
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
Elan Shudnow says
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/
DanhCong says
Is it possible public A/V edge server that network relationship is NAT
Jan Sverre says
Found my answer in part1 :-)
Jan Sverre says
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?
Elan Shudnow says
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
Juergen says
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
Elan Shudnow says
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.
Marc says
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?
Elan Shudnow says
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.
HOC says
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)
henock says
Thanks for clarifying
Elan Shudnow says
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…)./
henock says
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
Elan Shudnow says
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.
henock says
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
Abdul Aziz says
Yes thats what I meant. Thanks for clarifying!!
Elan Shudnow says
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.
Abdul Aziz says
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!
Jan Boguslawski says
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
Elan Shudnow says
Yes, I did install it on Windows 2008 x64.
Start > Run > compmgmt.msc
Jan Boguslawski says
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
Elan Shudnow says
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.
Abdul Aziz says
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.