Category: Lync 2010


Regex Tools

These are some tools that could get you started with regex. They also include testers for your regex

RegExr Desktop

Free RegEx Tool for MacOSX, Windows, and Linux

RegExr Desktop is a tool for learning, editing, and testing regular expressions

http://gskinner.com/RegExr/desktop/

 

For Testing your regexes

http://regexpal.com/

http://regexhero.net/tester/

Advertisements

The OCS & Lync Sign-In Troubleshooter helps diagnose Microsoft Office Communicator and Lync client sign-in issues.

image

Can be found here

http://www.insideocs.com/Tools/MOCLogin.htm or from my BOX

Most companies don’t keep a unified E.164 Structure for users numbers in Active Directory, This offcourse causes lync not to display the numbers for users like below

Hany Nasr George (Available) hany_george@idc.it

Now there is a way to fix that, all you need to do is create a file called

Company_Phone_Number_Normalization_Rules.txt

and place it in your file store defined in your topology under AB folder in the 1-WebServices-1 Folder , so it should look like this

\\FileStoreServer\LyncShare\1-WebServices-1\ABFiles

Now after you create the file, you should fill it with the normalization rules as below

norm

After doing this, you will see as below

image

ICE Warning Messages

At some point of time you will troubleshoot this strange issue with AV, that’s normal.

But to help understand where your problem is there is one Key Word that I normally search for and that is “ICEWarn” , now after that word there should be a code, and below is a codes list that would really help you have better understanding of whats going on

 

ICE Protocol Warning Flags

Description

Actions for the Administrator

0x0

There were no failures or the ICE protocol was not used.

None.

0x1

TURN server is unreachable.

This flag is not expected. Administrator need to ensure that the right ports (443/3478—by default) are open on the firewall or the TURN server is running. This may result in an ICE protocol failure.

0x2

An attempt to allocate a UDP port on the TURN server failed.

This flag may be expected if the client is behind a UDP blocking firewall. This may result in an ICE protocol failure.

0x4

An attempt to send UDP on the TURN server failed.

This flag may be expected if the client is behind a UDP blocking firewall. This may result in an ICE protocol failure.

0x8

An attempt to allocate a TCP port on the TURN server failed.

This flag isn’t expected. The administrator needs to check the firewall policy, and ensure that Audio/Video Edge service is reachable. If the client is behind an HTTP proxy, the administrator needs to ensure that the proxy isn’t failing the TLS attempt. This failure may result in an ICE protocol failure.

0x10

An attempt to send TCP on the TURN server failed.

This flag isn’t expected. The administrator needs to check the firewall policy, and ensure that Audio/Video Edge service is reachable. If the remote client is behind an HTTP proxy, the admin needs to ensure that the proxy isn’t failing the TLS attempt. This failure may result in an ICE protocol failure.

0x20

Local connectivity failed. (local UDP for audio/video and local TCP for application sharing and file transfer).

This flag can occur if the direct connection between clients isn’t possible due to NAT/firewalls. This may result in an ICE protocol failure.

0x40

UDP NAT connectivity failed.

This flag can occur if the direct connection between clients isn’t possible due to NAT/firewalls. This may result in an ICE protocol failure.

0x80

UDP TURN server connectivity failed.

This flag can occur if one of the clients is behind a UDP blocking firewall/HTTP proxy. This may result in an ICE protocol failure.

0x100

TCP NAT connectivity failed.

This flag is expected. If local-to-local connectivity succeeded, the TCP NAT connectivity check may not have been tried. Or there is no direct TCP connection possible. TCP NAT connectivity failing may result in an ICE protocol failure.

0x200

TCP TURN server connectivity failed.

This flag is expected. If local-to-local connectivity succeeded, the TCP TURN connectivity check may not have been tried. Or one side didn’t have TURN server allocation. If connectivity checks were successful for the rest of the call, ignore this ICE protocol warning. Otherwise, investigate why the TCP path was not possible. TCP TURN server connectivity failing may result in an ICE protocol failure.

0x400

Message integrity failed in connectivity check request.

This flag isn’t expected. If the admin sees this flag, it indicates some security attack. This may result in an ICE protocol failure.

0x1000

A policy server was configured.

This flag is expected if there is a bandwidth policy configured on the call link. If there is a call failure with this flag, increase the allocated bandwidth on the failed link. This flag isn’t indicating any ICE protocol failure, simply that there was a bandwidth policy applied to this call.

0x2000

Connectivity check requested failed because of a memory problem or other reasons that prevented sending packets.

This flag is unexpected and may indicate that a computer is over capacity This may result in an ICE protocol failure.

0x4000

TURN server credentials have expired or are unknown.

This flag is unexpected and may indicate that Audio/Video Edge service authorization service is down. This may result in an ICE protocol failure.

0x8000

Bandwidth policy restriction has removed some candidates.

If there is an ICE protocol failure with this flag set, this indicates that the policy server topology is misconfigured. In this configuration the policy was configured to route over another connection, but the other connection failed. (Possibility of internal NATs in the org). This flag may result in an ICE protocol failure.

0x10000

Bandwidth policy restriction decreases the bandwidth.

This flag indicates that the bandwidth being used on this call isn’t optimal quality (may be using a narrow-band codec or may not be capable of HD video). This flag does not indicate any ICE protocol failure.

0x20000

Bandwidth policy keep-alive failed.

This is unexpected. The call continues but the bandwidth used by this call may not be reported properly to the Bandwidth Policy Core Service. This can occur because the policy server or the TURN server have failed. This flag does not indicate any ICE protocol failure.

0x40000

Bandwidth policy allocation failure.

This flag is indicating that the policy server rejected the client to use a media path through two Audio/Video Edge services (relay to relay). This may result in an ICE protocol failure.

0x80000

No TURN server configured.

This flag is indicating that there was no TURN server configured or there is a Domain Name System (DNS) resolution failure, resulting in a communication issue between the client and the TURN server. This may result in a protocol ICE failure.

0x100000

Multiple TURN servers configured.

This flag is expected. This is indicating that there were multiple TURN servers configured (due to DNS load balancing). This flag does not indicate any ICE protocol failure.

0x200000

Port range exhausted.

This is indicating that the administrator manually configured ports on the client or the media server. A/V needs a minimum of 20 ports per call to start the call. Application sharing/file transfer needs a minimum of 3 ports. The port range being exhausted may result in an ICE protocol failure.

0x400000

Received alternate server

.

This is indicating that the TURN server is overloaded or preventing new connections. This may result in an ICE protocol failure if the alternate server isn’t running

0x800000

Pseudo-TLS failure.

This is indicating that the HTTP proxy is performing deep Secure Sockets Layer (SSL) inspection and failing the connection with the TURN server. This is not supported by Microsoft and may result in an ICE protocol failure.

0x1000000

HTTP proxy configured.

This is indicating that the HTTP proxy is configured This flag does not indicate any ICE protocol failure.

0x2000000

HTTP proxy authentication failed.

This is indicating that the HTTP proxy failed the authentication. This isn’t expected and indicates that the HTTP proxy didn’t recognize the user’s credentials or authentication mode. This may result in an ICE protocol failure.

0x4000000

TCP-TCP connectivity checks failed over the TURN Server.

This is indicating that TURN TCP-TCP connectivity check was tried and it failed. The failure indicates that port 443 was not opened on the firewall. If one of the TURN servers was 2007 A/V Edge Server. The administrator needs to open ports from 50,000 through 59,999 TCP to all external Audio/Video Edge services in the environment. This flag isn’t expected and may result in an ICE protocol failure.

0x80000000

Use candidate checks failed.

This is indicating that after receiving some packets the client didn’t receive the rest of the packets. This may happen on a client because of a third Winsock layered service providers (LSPs). These LSPs should be removed. This flag isn’t expected and may result in an ICE protocol failure.

In many times you face an issue with your Lync either in voice or video or anything else. Normally lync would throw a SIP code with a header.

Below is an RFC which explains those codes in details incase you ever run into something new or expand your existing knowledge

http://tools.ietf.org/html/rfc3261#section-21

The Microsoft Lync 2010 Adoption and Training Kit provides a one-stop shop for resources for IT pros, project managers, help desk agents, and trainers. The kit provides:

  • A workbook that provides step-by-step guidance for each phase of the rollout and adoption process
  • Adoption and training resources, such as primers, email templates, and templates for a custom Lync 2010 intranet site to help organizations successfully roll out Lync
  • Modular, reusable, rebrandable, and in most cases, customizable user education and training materials, including frequently asked questions, Quick Start guides, how-to videos, Work Smart guides, and training videos
  • Buzzworthy applications such as IM an Expert and learning tools such as the Lync How-to that you can use to generate user excitement and drive the adoption of Lync

This can be found here

http://lync.microsoft.com/Adoption-and-Training-Kit/Pages/default.aspx 

When it comes to Microsoft Lync 2010 user education and training, the strategy and resources that offer the best return on investment vary depending on the user profile and the Microsoft Lync Server 2010 workload or Lync 2010 product

and that is here

http://lync.microsoft.com/Adoption-and-Training-Kit/training/Pages/default.aspx

 

You Can use the below to manually create the Certificate request to be used in a HW or SW Reverse proxy

 

Open Certificate MMC

Expand Personal > Certificates

Right – Click Certificates then All Tasks then Advanced Operations Then Create Custom Request

Select Next

clip_image001

Select Proceed without enrollment policy

clip_image002

Select No template legacy Key

clip_image003

Select Properties

Enter a friendly name

clip_image004

On the Subject tab enter the Common Name and Alternative names

clip_image005

On the extensions tab under Key Usage choose Digital Signature and Key encipherment

clip_image006

Under extended key usage choose Server Authentication and Client Authentication

clip_image007

Under the private key tab under key options choose key size and select 2048 and select private key exportable

clip_image008

Under Key type choose Exchange and ensure that the key size above is set to 2048

clip_image009

Select OK, Choose path to save and provide the CSR to a Public CA and then import into the Personal store.

Lync/OCS Logger Options

 

A full list of the options and uses can be found here

http://technet.microsoft.com/en-us/library/bb936621(office.12).aspx

Lync Audio/Video Not Working

I have been trouble shooting an interesting issue with a client where If an External User tries to make an audio call to an internal user, the call would not be established due to network issues.

So the first thing that comes in mind are FW ports.Normally you need to double check the TCP/UDP 50,000-59,999 Range as well as the UDP 3478. Well after looking into it the ports were open and Edge was listening on them too.

Now the issue was only with the media, the signaling was fine, So when the External User calls the internal one, the called would get a notification, but when he accepts the call it disconnects.

The General idea of connection is that during the SIP negotiation and Especially the SESSION IN PROGRESS part in the SIPSTACK log, both clients would be offered the possible means of communications in the VIA field, So if you look closely You find the means to be BOTH Clients directly to each other or through an assigned ports on the edge.

Now running a SIPSTACK log on the Front End is saw the following error

ms-client-diagnostics: 23; reason=”Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote”;CallerMediaDebug=”audio:ICEWarn=0x80012b,

After checking all ports in all directions it was still not working. So I ran a trace on the Internal Interface of the Edge and saw the internal client connecting successfully to the Assigned Port that I got from Monitoring the SIPSTACK.

What was interesting is the External Interface. When I ran the trace on the External Interface I would see the Edge Denying the connection to the client on the specified port.

image

Now the Edge would behave this way if the client was not authenticating to it properly, So ahead to the UCCP Logs on the client side I went Smile which are located under %Username%\Tracing , But how would the client know where to authenticate ?

Easy when the client signs in, it receives the configuration. and we are specifically looking for the MRAS that we have configured and can be found in Lync Control Panel –> Topology –> Edge Server –> EdgeServer

image

Now you would ask me, how did the client know how to get there, Remember the SESSION IN PROGRESS Negotiation ?

Looking at the logs I searched for the FQDN I got from the External MRAS FQDN in the previous screen

image

Bingo, here is the issue. The client doesn’t know where is the AV.domain.com record. SO It means that the DNS record AV.domain.com is missing from Either their local DNS or the external one.

It was actually missing on both, So after creating this record both internally and externally to point to the NATed public IP address of the AV Edge. All Started working perfectly fine.

So in a nutshell,

If you are facing an issue with AV Not working externally check the following

1- PORTS (This is normally the issue)

2- DNS Records

3- Certificates and trusts

Hope this helps Smile

I don’t know if all of you have been getting this while outside

Untitled

But given that we are publishing through UAG and due to the statement in TechNet

When creating trunks and publishing applications, using non-standard ports is not supported; servers must listen on port 80 for HTTP and port 443 for HTTPS.

From here http://technet.microsoft.com/en-us/library/dd772157.aspx

The SP1 is designed to fix that. Due to the fact that Web services are published through port 4443

From Others I see that the Dialin and Meet publishes fine but Web Services like group expansion and Address book doesn’t work.

So SP1 your UAG and have this fixed Smile

SP1 can be found here

http://www.microsoft.com/download/en/details.aspx?id=27604