You are currently browsing the tag archive for the ‘Lync’ tag.

Had been running a hectic project for the past 3 months and is now drawing close to the final stage to bid good bye. And part of the final stage, I’d to run some test cases on Lync Web App (aka Online Meeting) where the each user would be connecting within the Organization network and the other would be using a portable Internet dongle.

After the sending an Calendar Invite via Outlook to my another account, upon clicking on the invite link, my Internet Explorer shows 404 File or Directory Not Found. OK, another 1 of my favorite error code thrown by the web services. So, time to roll-out some sheelves and troubleshooting here I come!

First of all, I’d to test whether the web services is running fine within internally, this is something that I’d held on whenever running any test cases within Lync – MAKE SURE internal works, before even talking about external. So, by clicking the invite from the internal network, everything seems to be working fine, Lync Web App launched perfectly and all functions are working as expected. So now, here comes the tricky part, as I’m having a Director Role installed in the environment, almost all traffic hits the Director Role from the DMZ segment: Access Edge and the Reverse Proxy.

So before drilling into the details, these are the configurations that I’d in my environment:

===================================================================================

Public Certificates

  • Type: Unified Communications Certificates (1 CN with Multiple SAN)
  • FQDNs: sip.domain.com; meet.domain.com;dialin.domain.com and webconf.domain.com

Lync Server Topology Layout

FE Pool (192.168.1.2) <—> Director (192.168.1.1) <—> Access Edge & Reverse Proxy <—> Firewall <—> Internet

===================================================================================

I’d to rule out Access Edge being the culprit here as clicking on an Online Meeting invite basically comes from the Web Services part, which is the Front-End pool, proxied through the Director Role from the Reverse Proxy (oh, I almost forgot, the RP is a Forefront TMG 2010). So to isolate this matter, let’s try to manually typing in the URL from the IE’s address URL, but this time, I’ll tried accessing the Address Book Service virtual path (ABS) https://meet.domain.com/abs outcome a 404 File or Directory not found as well.

So I’d figure likely it could be a Publishing Rule issue as the RP is unable to locate the virtual directory that has been directed. So let’s take a look at my publishing policy for Lync Web Services:

1. Confirm the redirected port, when publishing Lync Web Services, the ports must be redirected to port 8080 for HTTP traffic and 4443 for HTTPS traffic

2. Next, is to confirm the publishing paths

3. Run the Test Rule

 

 

OK, the rule looks fine, but wait a minute! Basically what happen here is TMG validates across the certificate that has been assigned for this reverse publishing against the CN and also checks whether the Machine is online (using pathping) and returns the results as Pass. But wait a minute…sip.domain.com, that doesn’t sound right – there shouldn’t be any traffic with this FQDN that is coming into the RP, only meet.domain.com & dialin.domain.com. The sip.domain.com only travels to the Access Edge.

So to prove the theory, I’d make some changes on the publishing rule by switching the Address to meet.domain.com

 

 

 

 

 

 

 

 

 

 

 

 

And ran the Test Rule function

 

 

 

 

This time, the TMG shows me an error that the https://meet.domain.com:4443 has an error to it because it doesn’t match the certificate chain name. Although TMG supports SAN publishing but it strangely, the Test Rule doesn’t validate SAN names, hope that the TMG Product Team could fix this in the upcoming releases.

Test drive! Vroooom……….and Walla! The Lync Web App was able to be launched after the change.

Lesson learned:

  1. Make sure that the URL address entered is according to the published name
  2. Mapped the URL to the correct IP address
  3. If you’re using UCC certificates, make sure the SSL listener has all of the FQDNs in the CN and SANs
  4. Running the test against TMG Rule maybe a good practice, but with UCC in the picture, you may want to opt to use the OCS Remote Analyzer Tool
Advertisements

Last year, I’d run a small workshop, demostrating the capability to the public on the capability on Enterprise Voice for Lync Server 2010.

Download the full presentation slide (PDF) from here

Happy New Year to all of my visitors

For the benefit for all my blog visitors, if you’re running a Lync lab environment and needed to test out audio output & input (recording), only Windows 7 Enterprise & Ultimate editions supportd these 2 functions when RDP into the Virtual Machine (link)

By default, Audio Recording is disabled. To enable it, go into the registry of the VM: HKLM\System\CurrentControlSet\Terminal Server\WinStations\RDP-TCP\fDisableAudioCapture. Change the value from 1 to 0 and reboot the machine to take effect.

I’ve a couple of feedbacks about the start-up time after the Lync client is installed. So to optimized the Operating System performance, my colleague and I had came out with a custom ADM that can be applied to via the Active Directory Group Policy.

Download Link: Disable Lync Client Auto Sign-In

I’d been pretty busy lately and haven’t got much time to blog. With finally some quiet time, I’m gonna share a bit of my experience on a recent deployment on Lync where it involves a Parent-Child Active Directory layout.

After publishing the topology and running the installation wizard, when we (my colleague and I) was about to enable a couple of users for pilot testing, here we hit into an error at the Lync Control Panel:

 Active Directory operation failed on DC1.child.domain.com. Insufficient access rights to perform the operation to create or enable users

Crossed check the account that belongs to the following groups:

  • Domain Admin
  • CSAdministrator

Well, everything looks fine, we were able to communicate with the Domain Controllers without any issues and querying to the Active Directory schema looks OK.

So we’re pretty sure that it has something got to do with the parent-child relationship where we’ve deployed the Lync services under the child domain and there might be some permissions that couldn’t be pass down from the parent domain. As we undergo some research, we finally found the solution: by enabling Inheritence Permissions at the Active Directory User Objects.

To perform this, go into any writable Domain Controllers and activate the Advance Features:

  1. Locate the user that is to be enabled and open up its property dialog window
  2. Select the Security Tab
  3. Select Advance
  4. Enable the check box Include Inheritable Permissions from this object’s parent

Logged back into the Lync Control Panel and that’s it! The user is now enabled and ready to logged into Lync.

Special thanks to my Chee Wai and also Mark A King from the TechNet forum (http://social.technet.microsoft.com/Forums/en-US/ocsplanningdeployment/thread/c90a7df8-ac4c-4297-a5a8-aa589e1d163d/)

MVP Logo

Follow me @Twitter

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Advertisements
%d bloggers like this: