Lync Edge Testing Suite (Part 2) – Lync DNS Tester and IP Route Editor Tools

I am dedicating this post to the saying “measure twice, cut once”, as this saying is most apt when describing what you should do before deploying your Edge server. In addition to this, I will be bringing you, not one, but two new Powershell tools to help with your Lync Edge server deployments! In this post we are going to cover two areas of Lync Edge Server deployment. The first is Domain Name records and the second is IP Networking.

For Part 1 of the Lync Edge Suite series go here.

Lync DNS Naming

Domain Name records in Lync can be rather confusing, as over the various incarnations of Lync there have been many different clients and server functions that have required a variety of special DNS records to function. Here are two very useful Technet links for a detailed explanation of how internal and external DNS records work with Lync 2013:

• Lync internal DNS records example Technet
• Edge Server DNS records on Technet

In summary, there are many different records that have been added for various clients and features for Lync to function. So you should always check that all of your DNS records are configured in production. I've made a Powershell tool that may be useful in checking these records are configured.

Lync DNS Tester Tool

 Features

• Make DNS requests to the server of your choice. The DNS server setting will specify the DNS server to make the request to. This means you can test your internal records on your internal DNS server, and your external records on a public DNS server.
• Auto-fill common Lync DNS record names with the “Fill All” button. Tick the “Internal” or “External” checkboxes to select the records you would like to fill. You can even edit the variables at the start of the script to match your standard naming convention.
• IPv6 support for Fill All. Tick the IPv6 box to fill with Quad-A records.
• Can add your own A, AAAA, CNAME and SRV records.
• Save yourself from getting RSI from typing all these nslookup commands manually!

Download Version 1.00(Lync DNS Tester Tool):

External Records

Lync's external DNS records all resolve to either the Edge server(s) or the External Reverse Proxy server for web service connections. The table below shows the records that the Lync DNS Tester Tool will auto fill when the “Fill All” button is pressed and the "External" check box is ticked:

Record Purpose	DNS Name	Host	Fixed / Variable
External Access name	sip.<domain name>	Access Edge IP	Variable (Topology Builder)
External Audio/Video name	av.<domain name>	AV Edge IP	Variable (Topology Builder)
External Web Conferencing name	webconf.<domain name>	Web Conf Edge IP	Variable (Topology Builder)
External Web Services name / Reverse Proxy	lyncwebext.<domain name>	Reverse Proxy	Variable (Topology Builder)
Dial-in simple name / Reverse Proxy	dialin.<domain name>	Reverse Proxy	Variable (Topology Builder)
Meet simple name / Reverse Proxy	meet.<domain name>	Reverse Proxy	Variable (Topology Builder)
External Web Apps Server / Reverse Proxy	waswebext.<domain name>	Reverse Proxy	Variable (Web Apps Server)
Lync discover record for Mobile and Windows 8 App Store client. Technet	lyncdiscover.<domain name>	Reverse Proxy	Fixed
External SIP record. (not a mandatory record, however, it’s in the client lookup list)	sipexternal.<domain name>	Access Edge IP	Fixed
External SRV record for SIP connection	_sip._tls.<domain name>	Access Edge Port 443	Fixed
External Federation SRV record for Open Federation	_sipfederationtls._tcp.<domain name>	Access Edge Port 5061	Fixed
External XMPP Federation SRV record	_xmpp-server._tcp.<domain name>	Access Edge Port 5269	Fixed

For the DNS names in the table that are marked as Variable, there are variables at the start of the script that can be edited to match the configuration of your environment, for example:

# External DNS Name Variables - Edit these to whatever you are using for your Lync environment

$sip = "sip"                  # External Access Edge

$av = "av"                    # External AV Edge

$webconf = "webconf"          # External Web Conf

$lyncwebext = "lyncwebext"    # Lync External Web Services / Reverse Proxy

$dialin = "dialin"            # dialin conferencing name

$meet = "meet"                # meet conferencing name

$waswebext = "waswebext"      # Web Apps server external name

Internal Records

If you tick the “Internal” check box and click the “Fill All” button, the following records will be added to the list box:

Record Purpose	DNS Name	Host	Fixed / Variable
Dial-in simple record internal	dialin.<domain name>	Lync Front End Server or Web Load Balancer	Variable (Topology Builder)
Meeting simple record internal	meet.<domain name>	Lync Front End Server or Web Load Balancer	Variable (Topology Builder)
Lync web services external record. Required for internal Mobile clients. Technet	lyncwebext.<domain name>	External Reverse Proxy	Variable (Topology Builder)
Office Web Apps farm internal name	wasweb.<domain name>	Office Web Apps Server	Variable (Web Apps Server)
Admin console simple name	admin.<domain name>	Front End Server or Web Load Balancer	Variable (Topology Builder)
SIP record. Required for Lync Phone Edition, or automatic logon of clients without DNS SRV records, and for strict domain matching. Not required in all cases.	sip.<domain name>	Lync Front End Server(s)	Fixed
Internal SIP record. (not a mandatory record, however, it’s in the client lookup list)	sipinternal.<domain name>	Lync Front End Server(s)	Fixed
Lync Discover Internal - Mobile and Windows 8 App Store client. Technet	lyncdiscoverinternal.<domain name>	Front End Server or Web Load Balancer	Fixed
SIP internal SRV record	_sipinternaltls._tcp.<domain name>	Front End Server(s) Port 5061	Fixed

For the DNS names in the Internal table that are marked as Variable, there are variables at the start of the script that can be edited to match the configuration of your environment, for example:

# Internal DNS Name Variables - Edit these to whatever you are using for your Lync environment

$wasweb = "wasweb"            # Internal Web Apps Server

$admin = "admin"              # Lync administrator web access

Note: The dialin, meet, and waswebext records will be the same for both Internal and External records. The settings for these names are made in the External settings. For a non-split brain DNS scenario you will either need to deploy Pin Point records, or an internal zone for the external domain name.

In addition to the tables above, you must also remember to check that your Lync Edge server(s) hostname/pool name has been added manually to the internal DNS server. These records are not automatically populated in DNS because Edge servers are not a domain joined machines, and will not automatically get added through Active Directory DNS integration. This is also the case with Lync Front End Pool names, so if you have added a new Front End pool to your topology you should always check that the DNS records have been added to the Internal DNS server manually.

Edge Server Networking

Edge server networking is also an important part of an Edge server deployment. An Edge server is a multi-network interface machine, which means that it needs to make decisions on which interface it will route packets out of when making connections to other machines. In nearly all cases (unless you only have limited external subnets connecting to your Edge) you will make your external Edge interface the owner of the default gateway address (0.0.0.0) and you’ll individually specify your internal subnets using static routes.

Example:

Below is a simple example of an Edge environment with an Internal and External interface:

Network	Net Mask	Next Hop	Interface
0.0.0.0 (Default Route)	0.0.0.0	210.10.10.17	210.10.10.18
192.168.5.0	255.255.255.0	192.168.1.1	192.168.1.2
192.168.6.0	255.255.255.0	192.168.1.1	192.168.1.2
192.168.7.0	255.255.255.0	192.168.1.1	192.168.1.2

For the Default route, you simply edit the Default Gateway within the External Interface within the Adapter settings in the Windows Control Panel, for example:

To set the other static routes within the server you usually use Command Line tools. However, rather than having to remember the syntax in the rare occasions that you have to do this, I decided to make a GUI tool to make this process a little easier.

IP Route Editor Tool

 Features

• List all routes on server.
• Add persistent routes.
• Delete persistent routes.
• Routes are colour coded in order of importance. (Grey = Localhost, Black = Broadcast, Green = Static Routes)
• Routes can be added with or without specifying Interface value. If the Interface value is not set then the server will automatically associate the route to the interface that is on the same subnet as the Next Hop IP Address.

Simply enter the Network, Net Mask, Next Hop, and Interface (note that it's not necessary to enter the Interface if you'd prefer not to, as the machine can figure this out based on the Next Hop address), and press the Add button. Hopefully this one will be pretty straight forward for you to use!

Update (5/9/2014)

1.01 Update:

• Updated to now run on Powershell 2.0
• Script is now signed

1.02 Update (Additional user input validation added):

• Updated the Regex check on the IP Address fields to better police against people accidentally putting bitmasks (ie. /23) after IP Addresses. This previously would result an incorrect route table entry because the route command would do strange things with this input.
• In previous versions the network IP Address was not policed to check that it was the actual network address based on the mask supplied (ie. not a host address). The result was the (non-network) host IP being input into the Route command and it not showing up in the Current Route Table. The network mask setting is now ANDed with the subnet mask to ensure that a real network address is being input.
• In previous versions the Next Hop address was not policed to check that it was on a locally connected network. The result was that the Route command would accept the input even though it was incorrect and add it to the route list. This bad route once entered was also not displayed in the Current Route Table. In this version the Next Hop IP address supplied by the user is first checked to see that it is on a directly connected network before the command Route ADD command is run. An error will also be displayed if the Next Hop is not on a locally connected network.
• Made the form resizeable.

Download Version 1.02 (IP Route Editor Tool):

The Wrap Up

Well, there you go, two more tools for your Lync Edge deployment kit bag. I hope you enjoy them, and get some use out of them. Like always, if you find any bugs or issues with the tools, please report them back to me and if I can reproduce them I will fix them.

Read more →

Lync Edge Testing Suite (Part 1) – Lync Edge Port Tester Tool

Okay, let's start 2014 with a bang, and turn this thing up to 11. This is the first post in a series that I will be doing about Lync Edge servers. More specifically, this series will be about some tools that I have written to help you with pre-deployment testing and troubleshooting issues with your Edge Server deployments.

For Part 2 of the Lync Edge Suite series go here.

Lync Edge Deployment

Deploying an Edge server within an organisation can often be quite challenging. The process involves topics like public certificates, private and public DNS records, routing, firewall configuration, DMZs, firewalls, NATing, etc… This often means that several people, or even several teams of people, will need to be involved in the process. As a general rule, the more people involved in a process, the more opportunities there are for things to go wrong. This is especially the case when only a small error like typing “_sip._tcp”, instead of “_sip._tls” can mean the difference between things working, and things not working.

When deploying an Edge server it is very important that you check that all the pieces of the puzzle are correctly in place before starting the installation. Otherwise, you will be “Nexting” your way through the deployment wizard towards a nightmare-hell-ride of live production troubleshooting. So it’s always advisable to test that everything is configured correctly on your network before even thinking about opening the topology wizard.

The area that we are going to focus on in this post is the testing of a DMZ’s firewall configuration. Microsoft has done a very good job of documenting the firewall requirements when deploying Lync Edge servers. The Technet pages here go in to quite a bit of detail about the different topologies and their port requirements. The Lync workloads poster is also a good place to look for more information. So, after reading all this information and configuring your firewall, how do you actually test that it is working? HINT: keep reading…

  Lync Edge Port Tester Tool

     Features:

• One tool for testing both ends of the connection. Run the Lync Edge Port Tester on your Edge server and on an internal and external network machine.
• Test both UDP and TCP ports are open in both directions.
• Select a profile from the list (Edge Outside, Edge Inside, Front End, Client Outside, Client Inside) to check all the relevant ports for that connection type.
• Open all the required firewall ports temporarily with the press of a button.
• Can be used to test connections to a live Edge (or Front End) server. If you run the tool on a live edge server it will automatically learn which ports are currently in use and only allow you to Listen on unused ports.
• Can be used on a Consolidated Edge configuration or on an Edge running with a single external IP address (ie. all 443 services running on different ports). The Single External IP check box allows for this configuration.
• Tool Tips to provide you with contextual help.
• All in one interface. (Over 100 interface objects! Yep, that was a lot of typing...)

Download Version 1.00 here:

 The Interface:

1. These drop-down text boxes need to be populated with the IP Addresses used on the inside and outside of the Edge server. The drop down menu for each of these gets populated with IP addresses that exist on the machine. So if you are running the tool on the edge server you can fill these in with the drop down menu selections. If you are running the tool on a machine that isn't the Edge you will have to type these IP addresses in yourself.
2. These profiles will set the port check boxes to the appropriate settings for testing each scenario. For example, if you are running the tool on the Edge server to test the outside ports, you will select “Edge Outside”.
3. This is the IP Address of the machine running the “Front End”, “Client Outside” or "Client Inside" profiles, that you are testing your connections to. If you are running the tool on one of these machines you can use the drop down box to select the IP. Or if you are running it on the Edge you will need to type the IP address into the field.
4. These are the ports/interfaces that you would like the tool to listen on. When you select the appropriate profile, the necessary ports will be automatically selected here. If you would like to test specific ports you can set these check boxes yourself. The naming convention used for these check boxes are <Port number to listen on><Interface to listen on>. The interface naming convention is, AC (Access Edge IP), AV (Audio Video Edge), CON (Conferencing Edge), and IN (Internal Interface of the Edge). The labels on the listening ports will change colour depending on which ports may already be used on the machine. If the machine already has a service listening on the port the label will turn a gray colour (and the check box will be disabled), so you will not be able to open a listener on these ports. The label will turn red if a port is being used by an existing service AND the port is used by the selected profile (this is informational, to allow you to know that you should be able to test connection to this port). 
5. These are the settings for making outbound connections from the tool. The naming convention for these check boxes are the same as above <Port number to connect to><Interface to connect to>. You should always be able to make outbound connections on these ports, so these port labels don't change colours like the listening port column.
6. These are Misc Options. “Clear All Boxes” will clear all the Check Boxes to allow you to make your own settings. “Close Listeners” allows you to close all the listeners that have been spawned in different Powershell windows. “Open and Close Firewall” button allows you to automatically open all the required ports within Windows Firewall to use the tool. This is necessary in order to be able to accept inbound connections to listening ports. When you first use the tool on a machine you should open the ports, and when you are finished testing you should press the Close Firewall button to remove the Windows firewall settings.
7. This is a window that will log information about what the tool is doing.

The 50000 Range

The 50000AV range is special because it can use TCP and UDP for the entire range of ports between 50000 and 59999. It's also special because, although the Edge will listen on a random selection of these ports, the ports themselves will only accept connections when media has been formally set up by client SIP signalling. This is a security measure that was implemented to reduce the attack surface of the external Edge AV interface.

The Lync Edge Port Tester tool will test the first port (50000) and the last port (59999) in this range. This is by design for two reasons, the first is that the Media Relay service on the Edge only listens on a random selection of these ports (run "netstat -a" to check this) and most of the time this random selection doesn't include port 50000 or 59999. This allows these ports to be happily opened by the tool the majority of the time. The second thing is that firewall rules are always set on a range of ports so if we test the first port in the range (50000) and the end port in the range (59999). Testing these two ports is usually enough to allow you to assume that the ports in between these values will also be allowed by same firewall rule (if not, then you have bigger problems with your firewall).

For Lync environments that don’t need to federate to partners with OCS, you only need to open outbound TCP 50000-59999 range, so failures of the inbound connections can usually be ignored (ie. unless OCS federation is required). By default, the "Edge Server Outside" profile (and "Client Outside" profile) will test the 50000 range in both directions for both TCP and UDP. You can simply untick the tests in the inbound direction if you do not want to run tests on these ports.

Note: The purpose of this post is not to teach you how Edge servers work. If you would like to know more about how Edge servers work, Bryan Nyce and Thomas Binder have some good Tech Ed videos about it.

Using the Tool

In order to be able to use the tool you will need to run two copies of the tool in different locations on your network. The diagram below shows how you would test the connections in the internal interface of your Internal Edge interface:

Diagram – Testing Internal Connections

In the diagram there is a copy of the tool running on a server on the internal network that will behave as the front end server (it may actually be the front end server, but doesn’t have to be). This copy of the tool needs to be configured as the “Front End” profile. On the Edge server the tool is also running and it will be configured as being the “Edge Inside” profile. Configure the IP addresses at the top of both tools to match the IP Addresses used on the edge server. Configure the Front End/Client IP address on both tools to be the Front End IP address. Example:

To test the ports in both directions you now do the following:

To test connections from the Edge to the Front End (which as you can see in the diagram is just TCP Port 5061):

• Press the Listen button on the Front End side tool. The tool will spawn new Powershell windows for each listening port. Note, if you're running this on a live Front End server you will not be able to listen on port 5061 because it's already in use. However, there is a service on the machine already listening on the port, so when you test the connection from the other side the machine service should still respond to the socket connection.
• Press the Connect button on the Edge Server side. The Edge side tool will now send TCP (and UDP) connections to the tool at the other side as required and report the result. When the listening end receives the connections the spawned Powershell windows will disappear. The connecting side tool will give you feedback as to if the connections were successful or not.

Note: Make sure you have opened the firewall on the listening side of the connection using the "Open Firewall" button. Once you have finished using the tool you should always use the "Close Firewall" button to clean up and close the Windows firewall ports.

To test connections from the Front End to the Edge Server (which, as you can see in the diagram, is ALL the ports):

• Press the Listen button on the Edge Server side tool. The tool will spawn new Powershell windows for each listening port. Note, if this is a live Edge server you will not be able to listen on ports that are already in use. However, if there is a service on the machine already listening on a port, you will still be able to test the connection to this listening socket.
• Press the Connect button on the Front End Server side. The Front End tool will now send TCP and UDP connections to the tool at the other side as required. When the other end receives the connections the spawned Powershell windows will disappear.

Diagram – Testing External Connections

In the diagram there is a copy of the tool running on a server on the external network that will behave as an external Client/Federation Partner. This copy of the tool needs to be configured as the “External Client” profile. On the Edge server the tool is also running and it will be configured as being the “Edge Outside” profile. Configure the IP addresses at the top of both tools to match the IP Addresses used on the Edge server. Configure the Front End/Client IP address on both tools to be the IP address of the Outside Client machine. To test the ports in both directions you now do the following:

To test connections from the Outside Client to the Edge Server:

• Press the Listen button on the Edge Server side tool. The tool will spawn new Powershell windows for each listening port. Note, if this is a live Edge server you will not be able to listen on ports that are already in use. However, if there is a service on the machine already listening on a port, you will still be able to test the connection to this listening socket.
• Press the Connect button on the Outside Client side. The Outside Client tool will now send TCP and UDP connections to the tool at the other side as required. When the other end receives the connections the spawned Powershell windows will disappear.

To test connections from the Edge to the Outside Client:

Important Note: The outside machine will need to be directly on the internet in order for this to work. Most external connections to the internet are through Network Address Translating routers which will block unsolicited inbound connections. If you do not have a direct internet connection to test to you could configure port forwarding on the NAT router to allow each specific port into the outside client machine)

• Press the Listen button on the Outside Client side tool. The tool will spawn new Powershell windows for each listening port.
• Press the Connect button on the Edge Server side. The Edge side tool will now send TCP and UDP connections to the tool at the other side as required. When the other end receives the connections the spawned Powershell windows will disappear.

Tips, Tricks and FAQ

1. For a NATed Edge configuration you will need to set the Edge IP addresses on the tool running on the outside machine to be the Public IP Addresses for the Edge (ie. the external post NATed IP addresses). On the tool running on the Edge server you need to set the IP Addresses of the Edge server to the private addresses that are actually configured on the interfaces of the Edge server. If you don't do this then all the external tested connections will fail.
2. The ideal time to use the Lync Edge Port Tester is prior to installing the Edge software. This way you can be sure the network is right before installing the Edge server.
3. The Lync Edge Port Tester tool can actually be used to test connections to all TCP ports on a live Edge server. Also, it can be used to check UDP 3478 (STUN) on a live Lync Edge server, because it sends and accepts real STUN messages! However, the Edge does not respond to TCP and UDP for 50000 range of ports, as these only get opened when media has been negotiated. So you can only test the 50000 range between servers by using the Edge Port Tester at both ends of the connection (see the section about the 50000 range earlier in the post).

The Wrap Up

    Tell me what you think about your sit-u-a-tion,

    Complication – aggravation,

    Is getting to you,

        - The immortal words of Steven Tyler of Aerosmith in their 1993 hit song “Living on the Edge”

Hopefully, this new tool will help you to avoid lyrics such as these in any Lync Edge Server related songs that you may write in the future. If you find any bugs or issues with the tool, please report them back to me and if I can reproduce them I will fix them. Part 1 over-and-out. I will be back with Part 2 in this series shortly!

Read more →

Lync Polycom VVX Manager Tool

UPDATE: There is now a new 2.0 version of the Polycom VVX Manager Tool available. See the blog post here for more details.

I’ve recently been doing a lot of work with deployment and management of Polycom VVX phones on Lync. Like always, I’ve found that when rolling out hundreds of any device, there are certain challenges that arise. One of the main challenges is: how do you centrally administer hundreds of devices that are distributed around a large geography, remotely? The short answer to this usually turns out to be: with great difficulty!

One of the first rules of a good centralised management solution is how much information you can get out of a system without having to ask the end user over the phone to tell you something about what they are seeing. A simple example of this might be with a VVX phone, when you get a report from a user that their phone is “broken”. In most cases this is about the level of detail you can expect from an end user, because to them the fact that the system voice policy is blocking them from dialling out is the same as their phone having caught fire and exploding while they were out at lunch… The fact is, they can’t make a call, so the phone is “broken”. As IT professionals though, we know there are a great many nuances as to why the phone may not be working for the end user. So we start stepping through the troubleshooting process… Is the phone plugged in? Is the phone configuration FTP server available? Did it receive the adequate information from DHCP to prompt for PIN sign in? Does the user even have a PIN assigned for them to actually sign in? Is the phone registered with the system? Does the user have the rights to dial the number they were dialling? etc…

So you probably get the picture. There’s a tonne of questions that need to be answered, and the last thing you want to do to answer them is ring the user on their mobile (because their desk phone is "broken") and ask them if they see a little green tick or a little red cross next to the phone icon on the upper left hand side of the screen… followed by a thousand other questions about the smouldering piece of burnt up plastic on their desk.  

So I figured I would try and put together a tool that might make answering these questions a little bit easier:

Lync Polycom VVX Manager

Last Updated ( 1/7/2014 )

1.01 Enhancements:

• In the 1.00 release there can be cases where there is a VVX registered to the system but the tool reports them as having NO VVX in the ListView. This issue is a caused by the database entry for SipCallId containing junk information instead of the devices IP address. The processing has been changed in 1.01 so now when a VVX is registered it will always show up as YES in the listView. If there was no IP address in the database for the device then the IP will show as "IP NOT IN LYNC DATABASE" within the tool. A work around for this is to manually reboot the VVX, when it re-registers to the system the database field usually gets updated to contain the IP address again.
• Text layout within the information text box has been changed to make it easier to read.
• Added port variable for connecting to VVX via web browser when non standard port is used in the VVX configuration. Edit the $script:WebPort = "80" to whatever port your VVXs are using.

1.02 Enhancements:

• Support added for secondary device discovery method. In previous versions the phone manager would discover the IP address of VVX phones from the Lync Server database. However, sometimes the Lync database did not have the data in it for every registered phone. So in version 1.02 a secondary "IP Range discovery" method has been added to discover phones on LAN segments. Simply type an IP Range (format: "192.168.0.1-192.168.0.20" OR "192.168.0.0/24" OR add multiple with comma separation "192.168.0.0/24,192.168.1.0/24") into the listbox and press the "Discover from IP Range" button. The tool will then "ping" the phones to see if they are at each IP in the range. This method is slower than the Lync database discovery (it can scan a 254 host range in ~60 seconds or less. Note: scanning directly connected subnets is slow because of ARP wait time), so you should only use it if you reciving "IP NOT IN LYNC DATABASE" for the IP Address of users with the default Lync Database discovery method.
•  Added a new variable for https connections to the VVX web interface (as this will be the default in VVX 5.1 for the web interface when enabled). Change the variable $script:useHTTPS to be $true if you would like all web interface connections to use https instead of http. This will also require that you change the $script:WebPort variable to be "443" as well (or whatever port you set in the configuration file for https).
• Export VVX phone deployment information. This outputs a CSV file that contains all the Users, IPs, Firmware Version, Serial Numbers, Lync Server, and MAC Address (if available) for all logged in phones. If you select the "More" checkbox you will also get the additional Lync settings for the phone (this is slower).

1.03 Enhancements:

• Added the ability to send text messages to Polycom VVX phones. An example of this would be to send a message to warn before a system upgrade or a reboot. Messages are displayed on the screen for 30 seconds.

Version 1.03 Text Messaging Settings:

The Polycom VVX phones require special settings in order to receive messages from the Lync Polycom VVX Manager tool. The settings below will need to be added to your configuration files:

<apps.push apps.push.alertSound="1" apps.push.messageType="5" apps.push.serverRootURL="push" apps.push.password="vvxmanager" apps.push.username="vvxmanager"></apps.push>

• apps.push.messageType: This sets the level of messages that will be displayed for the phone. The VVX Manager always sets the messages as “critical” so they will always be received. The setting “5” means that all levels of messages will be displayed by the phone.
• apps.push.serverRootURL: This setting needs to be set to "push". This is used as part of the URI for sending messages to the VVX.
• apps.push.username: The phones use digest authentication for push connections. The username sent by the tool by default is “vvxmanager”.
• apps.push.password: The phones use digest authentication for push connections. The password sent by the tool by default is “vvxmanager”.
• apps.push.alertSound: Play a sound when the message is displayed. This is the standard Polycom sound that you heard when a phone reboots. This can help the user to see the message, as it will only be displayed for 30 seconds.

Within the Powershell script you can change the Username and Password used for authentication to something else if you desire. Settings are here:

#Edit these settings if you would like to you customer username and password for messaging.

$script:pushUsername = "vvxmanager"

$script:pushPassword = "vvxmanager"

Example Message:

System Outage

1.04 Enhancements:

• Had a report of some issues with case sensitivity with SIP URI's. Removed case sensitivity to correct the issue. (Thanks to Benoit Machiavello for reporting this issue)
• (Request) Added ability to filter users list to only show users with VVX phones.

1.05 Enhancements:

• Added the ability to import previously exported CSV files containing user/device information. This can save time scanning IP ranges for devices by only checking (ie. pinging each device to check who is logged in) the IP addresses from the CSV file. If you have a "known good" export (eg. an export that you may have been taken minutes earlier) you can directly import the settings without rescanning each device for changes. Importing without rescan can be a little risky if you're working with an older export, due to IP addresses and user logins of each VVX's possibly changing over time. So it is recommended that you use the rescan option to refresh all the user data within the VVX Phone Manager Tool's database.
• If a VVX handset that is signed out is discovered, it will be added to the user list under the name “VVXNot@LoggedIn_<index number>”. This allows you to use the tool to access these devices even though they are not logged into Lync. This method only works with the IP Scanning method of discovery, it does not work when discovering from the Lync database.
• Corrected an issue with the display of users that are logged into multiple phones. The tool will display multiple entries in the user list when user are logged into more than one phone.
• The tool in previous versions would automatically load the user list and try to discover user information from the Lync database. This could waste time when first opening the tool for users that only wanted to use the IP Discovery method. To save time in these circumstances, from version 1.05, the tool will not automatically try to connect to the Lync server database when first opens. On first boot you can update the user list by clicking the "Discover From Lync Database" or enter an IP range and click the "Discover From IP Range(s)" button.
• Added information in this post about using the VVX Phone Manager Tool with Version 5.1 VVX firmware. Read this section before updating your production firmware!

Download Version 1.05 here:

IMPORTANT UPDATE: Polycom VVX 5.1 Software Update Changes

Read this section before updating your production firmware!

Version 5.1 of Polycom VVX firmware has some increased security enhancements. This will affect your ability to connect to the web interface of VVX devices when you are running them in an out-of-the-box configuration. However, you can still have access to the web interface of the VVX phones by editing some configuration settings on the devices (usually done via a configuration FTP server).

The following web server settings have been enhanced in version 5.1 VVX firmware:

Web Config Mode	httpd.cfg.enabled	httpd.cfg.secureTunnelEnabled	httpd.cfg.secureTunnelRequired
Disabled	0	0	0
HTTP Only	1	0	0
HTTPS Only	1	1	1
HTTP/HTTPS	1	1	0

Example settings:

HTTP Web access only:

<!-- HTTP Admin Settings -->

<httpd httpd.enabled="1" httpd.cfg.enabled="1" httpd.cfg.port="80" httpd.cfg.secureTunnelEnabled="0" />

HTTPS Web access only:

<!-- HTTPS Admin Settings -->

<httpd httpd.enabled="1" httpd.cfg.enabled="1" httpd.cfg.secureTunnelPort="443" httpd.cfg.secureTunnelEnabled="1" httpd.cfg.secureTunnelRequired="1" />

Both HTTP and HTTPS web access: 

<!—HTTP and HTTPS Admin Settings -->

<httpd httpd.enabled="1" httpd.cfg.enabled="1" httpd.cfg.port="80" httpd.cfg.secureTunnelEnabled="1" httpd.cfg.secureTunnelPort="443" httpd.cfg.secureTunnelRequired="0" />

Note: If you would like to make the Web Admin harder for people to find you can change the port number to something different from the default 80 or 443 settings. Then in the VVX Phone manager you can change the $script:WebPort variable to whatever value you have chosen. If you want to use HTTPS from the tool, set the $script:useHTTPS setting to $true.

In addition to this you need to change the default password on the devices as to avoid errors/warnings popping up on the phone display and web interface (“Default admin password is in use, please contact your administrator”). These can be set here:

<!-- Passwords and Security -->

<device device.auth.localAdminPassword="12345" device.auth.localUserPassword="12345" />

Note: Make these passwords whatever you want them to be, however, they must be different than the default of 456 in order to avoid the warning message being displayed on the phone screen.

After you have changed these settings the web login and phone screen login passwords will be changed. So if your support staff have been trained to enter the default “456” password, don’t forget to tell them that it’s changed.

Features of Lync VVX Phone Manager

1. Find out information about VVX handsets connected to a Lync system (IP Address, the Lync server that the handset is registered to, user policies, PIN status).

2. Remotely reboot VVX handsets using the ‘Reboot’ button. Reboot a selection of handsets by selecting (hold shift/ctrl) multiple users in the list, then press the ‘Reboot’ button. Or reboot all the VVX handsets on a Lync system with the “Reboot All” button.

3.Set the PIN for a user - either a random PIN (if the PIN field is left blank), or specify a PIN number by filling in the field. This can also be done on multiple selected users.

4. Lock and unlock the PIN for a selected user with the ‘Lock PIN’ and ‘Unlock PIN’ buttons. This can also be done on multiple selected users.

5. Test your FTP Configuration server by simply entering the IP address of the FTP server and pressing the “Test FTP” button. The tool will attempt to connect to the FTP server and download information about key files associated with a Polycom configuration server deployment. These include the base configuration file (000000000000.cfg), configuration files in the CONFIG_FILES tag, any MAC address files associated directly with phones, and firmware files (*.sip.ld). The tool will give feedback as to the state of the FTP server.

6. Test PIN and device bootstrapping by entering a PIN number for the selected user and pressing the "Test PIN" button. The tool uses the Test-Bootstrap command in the background to imitate the process of a Lync Optimised Phone connecting to the system. Part of this process is that the Lync server generates a DHCP Inform request from the Lync server and sends it out to discover the Vendor Class Options (Option 43), and SIP server Option (Option 120) which it will then use the results of to generate a PIN authentication with the system. Below is an example of the DHCP message that the server sends out for this test:

This is awesome, but in some ways not a perfect test. It will depend on how you have set up your DHCP architecture throughout your sites as to the result of this process. You may either be using your Lync Server’s inbuilt DHCP server to respond to these INFORM messages, or you might be using a real DHCP server on your phone subnet to respond to these messages.

If you always receive the error “Did not receive any response for the DHCP discovery message.” when testing the PIN number, then it’s likely that there’s no DHCP server capable of responding to INFORM messages in the subnet that your Lync server is on. To get around this you can enable a special DCHP INFORM message responder in the Lync server.

The Lync Server DHCP server configuration lives under the registrar configuration. You can see the setting in Powershell by running this command:

PS > Get-CsRegistrarConfiguration

Identity                        : Global

MinEndpointExpiration           : 300

MaxEndpointExpiration           : 900

DefaultEndpointExpiration       : 600

MaxEndpointsPerUser             : 8

EnableDHCPServer                : True

PoolState                       : Active

BackupStoreUnavailableThreshold : 00:30:00

MaxUserCount                    : 7500

Note: This setting only answers DHCP inform requests with Vendor Class “MS-UC-Client”, and not basic Discover messages used for IP address configuration.

If this setting is set to True, the Lync server will respond to INFORM requests it sees broadcast on the subnet. So if you don’t have a DHCP server on you Lync server subnet (which you may not if your servers are deployed in a data centre) you may have to substitute for this by turning on the DHCP server in the Lync server.

If you do choose to implement this work-around, be sure to understand that the environment the Lync server is in may not be the same as the one the phone is deployed in. You will need to ensure that the phone is getting the correct information for its DHCP INFORM requests as well. So be sure to check your DHCP configuration for the subnets that the phones are deployed on (ie. 001 – UCIdentifier, 002 – URLSchme, 003 - WeServerFqdn, 004 - WebServerPort, 005 - CertProvRelPath, 120 - UCSipServer). If you want to know more about the DHCP options required for Lync phones, have a read of the in-depth Understanding DHCP Option 43 article by Jeff Schertz.

7. Easily connect to the VVX web interface of any user on the system by clicking the “Web Config” Button.

 The Polycom VVX has a web interface which can be quite useful for troubleshooting issues with Lync. It includes a page dedicated to Lync specific settings (Diagnostics->Lync Status), that gives lots of good information:

As you can see in the picture above, there is some very useful information held in the Lync Status page.  So if you’re having some issues with a phone, just find the user in the Lync Polycom VVX Manager Tool and click the “Web Config” button. This will connect you directly to the user’s VVX web interface. You can also configure logging on the phone from the web configuration page, and view/download the logs directly from the browser as well.

Note: When Polycom phones are put into Lync mode, not all of the features in the web interface are relevant. This is because the web interface still has all the Standard SIP mode features (used for other platforms) still in it. So be careful not to assume that changing random settings will have the desired effect.

Prerequisites to use VVX Manager

In order for the “Reboot” and “Reboot All” buttons to actually reboot your phones, you will need to configure a special setting within the configuration files used by your phones. The reboot buttons in the tool use a specially crafted SIP NOTIFY message that tells the phone to re-download its configuration files from the configuration FTP server. This updates most settings in the phone, but not always all of them. To force the phone to do a full reboot, which ensures that all settings are applied you need to add the following settings in your phones configuration files:

<voIpProt voIpProt.SIP.specialEvent.checkSync.alwaysReboot="1" />

Note: If you already have phones deployed, you can add the setting to the configuration file, and press the reboot button on the tool once to make the phones re-download their files (which will also update this setting). From then on you will be able to do full reboots of the phone from the tool.

Another suggestion that may be of use: if you want to be able to remotely tell what the MAC address is of a phone (useful when building phone specific config files) from the VVX Phone Manager tool interface without having to open the web config, add the following setting:

<device sec.tagSerialNo="1">

   <prov device.prov.tagSerialNo="1"/>

</device>

This will result in the MAC address being included in the device string, eg: “VVX Version: PolycomVVX-VVX_500-UA/5.0.0.6874_0004f28038f9”. If you do this, the tool will also check the FTP server for individual MAC address files and tell you which phones have these when the “Test FTP” button is pressed.

Note: See 1.03 release information for Text Messaging requirements.

Allow Call Park Manager to Connect to Remote Pools

In order for the Lync VVX Phone Manager to learn about the phones connected to your deployment, it needs access to your RTCLOCAL databases for each Front End server pool. If you only have one Standard Edition server, then you can run the tool directly on this server and it will be able to access the RTCLOCAL database directly. However, if you have multiple pools, the VVX Phone Manager will try and connect to each pool to download all the registered endpoint data for each pool.

In order for the SQL connection to be made, inbound connections to the SQL Browser Service and RTCLOCAL database will need to be allowed through the Windows firewall. These rules are not created automatically during Lync Server Setup like most of the other rules are. So to open the ports, download the script below and run it on all of your front end servers (including SBA and SBS servers).

Run the script included in the VVX Manager Tool zip file (OpenSQLPortsForVVXManager1.00.ps1) on the server you want to open the SQL Browser and RTCLOCAL Dynamic TCP SQL ports on (ie. all Front End servers and SBAs/SBSs). If you would like to know more about how to manually do this configuration, there’s more information on my Call Pickup Group Manager Tool post.

Note: This is the same process as is used for the Lync 2013 Call Pickup Group Manager tool. So if you have already opened the ports to run that tool, you don’t have to do it again.

Getting Started with a Polycom VVX Deployment

This article was written under the assumption that you already have VVX phones deployed, and you are now looking to manage them. If you need some more help with the initial deployment part of the process, I can point you to some useful resources:

Jeff Schertz' post on the different ways to deploy Polycom phones here in his article entitled Provisioning Polycom SIP Phones. Greig Sheridan also has a nice post on Optimising the Polycom VVX for Lync that you might want to check out.

If you would like to know more about what is supported on Lync with VVX phones and setting up a FTP server to support Polycom Configuration files on Lync, go to the Polycom VVX support page and grab a copy of the lovingly entitled: “Deploying Polycom® UC Software for use with Microsoft® Lync™ Server”.

An important recommendation that I can give you is to always test your configuration files on a real phone before deploying them into the wild, because very subtle errors can cause things not to work as desired.

The Wrap Up

As always, feel free to give feedback regarding bugs and issues you find with the tool, I will endeavour to fix any issues that I can reproduce. Other than that, I hope that you get many hours of enjoyment out of this new tool, and that it saves you many additional hours in the process. As Humphrey Bogart says at the end of Casablanca “Louis, I think this is the beginning of a beautiful friendship.” Fade to black. Roll credits.

Read more →