UnifySquare Logo


Nav Accent Bar
From technical articles to tid-bits of important news and information, stay up to date on the latest UC happenings. Unify Square Blog
Helping you deploy the world's leading platform for Unified Communications.
 

If you are using a hardware load balancer, it will perform periodic health checks for Lync to make sure it is distributing the load evenly to all servers that are functional. Because of the checks, you may end up with a large number of protocol errors in your FE logs showing a connection error with the VIP IP from the load balancer or one of its SNAT addresses. Here is an example of the error:

Source: LS Protocol Stack
Event ID: 14502
Level: Error
A significant number of connection failures have occurred with remote server IP 10.255.106.202. There have been 120 failures in the last 180 minutes. There have been a total of 291 failures.
The specific failure types and their counts are identified below.
Instance count   - Failure Type
291                 0x80072746(WSAECONNRESET)

This can be due to credential issues, DNS, firewalls or proxies. The specific failure types above should identify the problem.

Notice in the error, the IP of my VIP is listed (10.255.106.202).

Although these are expected, if you have not specified a Hardware Load Balancing (HLB) monitoring port, they certainly cause an awful lot of unwanted noise in the logs. 

To combat the issue, enable an HLB port on your FE servers (or any other pool you are using HLB on) and configure the health checks for the load balancer to use that port instead of the port used for TLS traffic. For more information on this blog, go here.

By Kevin Peters 


November 2, 2011 18:27 by BlogAccess Permalink | Comments (2) | Comment RSS RSS Button Image


While working with a client, we ran into two front-end servers and an edge server that would not replicate. The CMS was hosted in another country with plenty of firewalls in between, which definitely complicated the issue.  However, the root cause wasn’t a network issue or firewall.

We started by tackling the front-end servers. Two out of four front-end servers in a pool were showing out of date in the topology.  From the server hosting the CMS I verified I could ping each front-end server by name and to my surprise I could also telnet to them on port 445. 

Now that we knew the path used to connect was valid and the server was listening for the connection, I started a packet capture using NetMon, and ran the invoke-csmanagementstorereplication CMDlet to kick off replication. I captured data for 30 seconds and applied a Display Filter so I could look at the SMB traffic first.

There was “Access Denied” all over the logs. I tried to view the properties of the RTCReplicaRoot folder (by default this folder is on the root of the drive Lync is installed on), but didn’t have permission. Although this would seem like an error, it is actually expected behavior and it is best not to modify permissions to this directory. I discussed the build process with the client and determined a security script meant to tighten NTFS permissions had inadvertently broken CMS replication for those two servers. Instead of trying to fix the NTFS issue and risking other problems, we removed the boxes from the topology, re-installed the OS, and added them back as Lync servers after a clean rebuild without the security script. For more information on this blog, go here

By Kevin Peters


September 18, 2011 22:33 by BlogAccess Permalink | Comments (8) | Comment RSS RSS Button Image


Today, Unify2 released BusyOnBusy 2.0 (Lync version). You can contact emeasales@unifysquare.com to procure the trial or full version of BusyOnBusy 2.0. 

 

What is BusyOnBusy?

BusyOnBusy 2.0 is a Microsoft Lync Server 2010 based solution that enables administrators to configure (enable/disable) Lync users for secondary call suppression. If a ‘BusyOnBusy enabled’ user, who is busy in an existing/active Lync call, receives another (secondary) call from a Lync user or a PSTN caller, the BusyOnBusy server application responds to the secondary caller with a well-known busy signal.   Morever, users within a Lync pool can be individually configured (or batch configured) for BusyOnBusy, to either allow or block secondary calls. 


What’s included in BusyOnBusy 2.0?
The BusyOnBusy msi provides an easy click-through installation. BusyOnBusy comprises of the following components:  

-          BusyOnBusy.exe: A command Line Administration Utility to configure and administer Lync users for BusyOnBusy

        -          BusyOnBusy server application: A Lync Server Application that intercepts calls, and either allows  or blocks calls for Lync users, based on a user’s BusyOnBusy configuration settings

-          Batch configure users script: A PowerShell script that can be used to “batch configure” users for BusyOnBusy

-          BusyOnBusy Global settings configuration file: A configuration file that can be used to set the global BusyOnBusy policy for the Lync Pool

-          BusyOnBusy 2.0 User Guide: Documentation on installing/uninstalling BusyOnBusy and details & examples, on administering and using BusyOnBusy

 

Contacts   

For more information regarding BusyOnBusy sales and/or customer support, you can contact us at:   

Sales: EMEA: emeasales@unifysquare.com / US: sales@unifysquare.com  / APAC: asiapacsales@unifysquare.com 

Customer Support: emeasupport@unifysquare.com



Privacy  |  Contact  |  Terms of Use  |  www.unifysquare.com | Copyright © 2009 Unify2  -  All rights reserved.
Microsoft and the Microsoft Logos are trademarks of Microsoft, Inc. Unify2 is a trademark of Unify Square, Inc.