Network failures and the Dell R620

So we recently installed a Dell R620 server with IP Office Server Edition 9.1. While troubleshooting an unrelated issue we came up with a big problem: The device could no longer be reached on the network! Well that's a huge problem since we have IP phones and all the bells and whistles on this server. Avaya support wasn't able to resolve the issue because...guess what? They couldn't get into it remotely...

So we replaced the server and I took a look once we had it back in the lab. It turns out that the devices had been renamed. ETH0 switched with ETH2 and ETH1 switched with ETH3. By plugging in to Port 3 (which should have been ETH2) and enabling the port (#ip link set up) I was able to get connectivity right away. But how could this have happened, and what can I do to make it work with the correct network port? It turns out there is an issue with the way CentOS uses UDEV to create network interfaces. So how do you fix it? Well it's not too hard. I was able to make it work exactly as it did before by looking at a few files and changing one.

In the root folder there are four interesting files. They are ifcfg-eth0, ifcfg-eth1, ifcfg-eth2, and ifcfg-eth3. These files each contain a single line of text with the MAC address of the server:


Trust these files. They are the gospel. I was also able to find the MAC address of eth0 (Port 1) printed on the circuit board inside the server. The four addresses should be sequential, but keep in mind that they are sequential in HEXADECIMAL. So...29 does not go to 30, 29 goes to 2a.

So you may wonder, now that we have these MAC addresses, what are we going to do with them?

That's easy. Use your favourite text editor (I personally like NANO) to edit the file /etc/udev/rules.d/70-persistent-net.rules. You'll see your interfaces and, I bet, incorrect MAC addresses. Or at least MAC addresses that are not associated with the correct device name. Simply change the MAC addresses to the correct address for each device and you're on your way.

For example, change:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:2a:72:dc:17:2a", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:2a:72:dc:17:28", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Security Certificates - 9.1

With the release of IP Office 9.1 there have been enhancements made to the way security is handled. When deploying an IP Office Server Edition or Select Server Edition for a customer it is best practice to have them provide a fully qualified domain name or a machine name to use for the security certificate. The IP Office can be configured with a valid host name and the certificate can be imported into the Trusted Root Certification Authority certificate store. When accessing the system by the proper host name with the certificate properly stored there will be no security warnings while accessing the page.

When defining the hostname for the IP Office you need to either enter the FQDN that will be used to access the system or the IP address that will be used to access the system. In the case of my example I used the IP address of as the host name. If you are using a fully qualified domain name (FQDN) or a server name (NetBIOS) you will want to make sure it resolves with your DNS server or you will see a certificate mismatch error.

To use a self-signed certificate we will select “Generate New”:

After you click Next you will see the following warning:

The certificate will now be generated. 

Once the certificate has been created it is available for download. For a Windows Certificate Store you need to download the DER-Encoded certificate:

Once you have downloaded the certificate click Apply. The process will take several minutes, after which you will be logged out of the system.  Be sure to add the certificate you downloaded to your Trusted Root Certification Authority. If you're working with a domain this can be pushed to client systems using a group policy, or it can be added to machines individually using the Microsoft Management Console.

IP Office Registry Hacks

It has come to my attention that Avaya often hides functionality in a registry entry. I'm going to keep a list here. As I learn more I will add them. Feel free to comment any that you have tucked away under your cap!

Maximum UMS Users (166 by default):
Under HKEY_LOCAL_MACHINE/SYSTEM/CurentControlSet/Services/MSExchangeIS/ParametersSystem, add a new key MaxObjsPerMapiSesion. Under the new key, create a new DWORD Value objtMesageView, and set the value to three times the required users. For example, to support 500 users, set the value to 1500.

SIP Line Template:
In IP Office 9.1 the option for SIP Line Templates was included out of the box. In 7.0 and up the option is still there, but it's hidden. There is a two-part step to enable this:
Navigate to File --> Preferences on the IP Office Manager and select the Visual Preferences tab. Check the Enable Template Options box.
Under HKEY_CURRENT_USER/Software/Avaya/IP400/Manager and add a DWORD value TemplateProvisioning and set its value to 1. Reboot the server hosting the IP Office Manager.
You can now generate a SIP Trunk template

No Caller ID Alarms on the IP Office

So the IP Office screams every time a call comes in with no caller ID received. Avaya finally decided to put in a workaround, and it's super quick and easy to implement!

The workaround is only available in 9.1 (and up, I suppose).

Go to the NoUser user and click on the Source Numbers tab.

Add the source number SUPPRESS_ALARM=1

Merge your changes and that's it! The NoCallerID Notification will be suppressed for System Monitor, System Status, Sys Log, SNMP Traps, and e-mail notifications.