No announcement yet.
  • Filter
  • Time
  • Show
Clear All
new posts

  • Azure

    Has anyone been able to run Director in Azure?

  • #2
    If you pay for the level of service that allows hosting with a static ip you could likely do it. It wouldn't be as easy as it sounds but dealing with public to private networking is never as easy as its presented to be.
    Lance Paddock
    BTX | Business Telephone eXchange
    1(800) 289-0299


    • #3
      I'd suggest against it myself. Going to a cloud server brings in a whole other level of possible problems that are not normally an issue for an on premise setup.
      Last edited by Lance; 06-22-2018, 03:43 PM.
      Lance Paddock
      BTX | Business Telephone eXchange
      1(800) 289-0299


      • #4
        I know this is an old post, but as I'm trying this too, I thought I'd update for anyone else.
        We have on on-prem Mitel connect system, with 2 sites. We backup and replicate between those two sites.
        Main site has a HQ VM, and other side has a DVS VM. Both have several shoregear switches.
        We have an edge gateway so remote staff can use Softphone.

        We also backup to Azure, as part of our DR plans.

        In most DR scenarios, we'd just fail over to our other site, have to do some re-ip'ing, and be mostly set for Mitel.
        However in the event all our virtual infrastructure is unavailable due to something like ransomware, we would need to fail over to Azure.

        I'm currently testing what is, and is not, possible.

        So far I've been able to restore the HQ server to Azure, but ran into a couple of issues.
        1-IP address. We picked our HQ IP many years ago, long before we even thought of Azure. Azure reserves the first 4 IP's of a subnet for internal use, and it just so happened we had our HQ set to one of those 4 reserved IP's. So we had to change the HQ IP. I followed a guide online which involved updating it in a couple places in mysql, registry, and an ini file. After that I could login to director.
        2-You have no control over the mac address of the NIC in Azure, and you can't change the primary NIC's MAC within windows, or you lose communications with the server (fixes itself on reboot but back to the Azure assigned mac). This means Mitel director goes into lockdown because the mac is different. I think I've got around this by adding a 2nd virtual nic, but not assigning it any IP (I disabled ipv4/6 in windows). I then changed it's mac address in windows to the one Shoretel expects, and director is no longer complaining about mac address mismatch.

        So now I can login to director. I can also login to connect client on a device in the network (another azure vm).

        Next, I wanted to get EGW working.
        When this VM restored (we use Veeam), it only had 1 nic, needed two. I added the 2nd nic to it and assigned it to the correct vlan, assigned 3 separate public IP's.
        The internal network NIC was also set to use an IP in those reserved ranges, so I had to fix that via the serial console. I found the IP address assigned in Azure didn't affect the nic's settings on this linux vm. Once the IP was updated and I rebooted the appliance, I was able to login to the web interface. I updated the EGW IP and Mac address in HQ, then rebooted HQ. It showed EGW online after that.

        Now I can login to connect client remotely as well. However, as when I tried from internally, I get an error registering softphone.
        I suspect this is because there are no shoregear appliances available for the HQ to talk to. I may do some testing to see once I setup a VPN, if I can get the Azure appliance to talk to our appliances in either site. I'd likely need to do some re-ip'ing though, because we'd have the same IP subnets on both sides. This will have to wait until I can do a full DR test with some scheduled downtime.
        Even if I can't get that working, we'd like to be able to at least get calls flowing into Mitel where we can then forward them off cell phones or something at a minimum. As our phone lines are all PRI currently, my plan would be to have our provider forward our numbers to phone numbers we control at something like, and have SIP trunks, via an asterisk PBX in Azure, to handle calls from there.

        So my questions, if anyone can answer, are:
        -Do you agree the softphone likely can't register because lack of shoregear appliances, and related assigned resources?
        -If so, any workaround other than getting a shoregear appliance to talk to the Azure HQ? Like a virtual appliance?


        • #5
          Your assumption is correct. Softphone, like any other IP phone, needs an IP Phone resource on a switch. The easiest way would be a vPhone switch VM in Azure. It may be declared as a spare switch, so that it only kicks in if no other switch is available at this site. But remember that you will need vPhone licenses to keep it active for more than 45 days.


          • #6
            Thanks, yes our Mitel reseller let me know about that last week and I've deployed one. It immediately started registering phones on our production side as I didn't know to mark it as spare. I just lowered it's max clients to 0 which fixed the license issue too.
            So I've deployed that into Azure too now (along with a trunk appliance) and am now working on trying to get it all working. So far, still getting softphone registration timed out, though the mitel client itself logs in just fine.
            I likely have some firewall work to do in Azure.


            • #7
              Another update, the issue with softphone not registering was not firewall related, just having tcp/upd 443 allow in rules in azure worked fine. The issue was I had to go into admin, telephones, options, and set the virtual phone switch as the ip phone config switch.
              After I did that, I was able to register and call into internal resources like voicemail, auto attendants, etc.
              Next, onto connecting to an Asterisk VM to be my proxy to a VoIP provider.


              • #8
                And as a final update, this all worked fine.
                We connected to via a FreePBX VM. We were able to place and receive calls.
                Obviously in a real scenario, we'd need to get some licenses before the grace period ran out, or have our on-prem equipment working again.
                But happy to know this is an option for us in a disaster.