birthdaysilikon.blogg.se - Lync for mac override photo

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).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. This method is slower than the Lync database discovery (it can scan a 254 host range in ~60 seconds or less. The tool will then "ping" the phones to see if they are at each IP in the range. So in version 1.02 a secondary "IP Range discovery" method has been added to discover phones on LAN segments. However, sometimes the Lync database did not have the data in it for every registered phone.

In previous versions the phone manager would discover the IP address of VVX phones from the Lync Server database. Support added for secondary device discovery method.Edit the $script:WebPort = "80" to whatever port your VVXs are using.

Added port variable for connecting to VVX via web browser when non standard port is used in the VVX configuration.

Text layout within the information text box has been changed to make it easier to read.

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. 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. 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. This issue is a caused by the database entry for SipCallId containing junk information instead of the devices IP address.

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.

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… 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.

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”. A simple example of this might be with a VVX phone, when you get a report from a user that their phone is “broken”. 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.