Server Edition expansion systems (security settings/users/certificates)

[john3voltas]

Hello there.
Since my latest odyssey with expired self-signed certificates, I started investing more time in trying to understand the security section of IPO systems and also the nature of the Server Edition expansions systems. Meaning, I've been trying to understand what exactly is shared between the primary server and the secondary and expansion systems.
As I understand, we can synchronize service users and system passwords, single sign-on (Avaya Cloud), APNS (Apple Push Notification) and APNP (Avaya Spaces). in the WebManagement :7070 address.
From what I could gather, the sync for service users and their passwords is just that. User/Password combo. There is no sync of their rights groups and permissions.
On the other hand, the certificates.
As far as I could tell, the Identity and CA certificates are not shared between the server and the expansion systems.
My doubts:
- isn't this a Frankenstein what Avaya made with the Integrated Management of Server Edition?
- are we supposed to synchronize rights groups and permissions by hand? Is that what you guys do?
- since the Certs are different, should a phone loose connection with the Primary server and choose the secondary server or an expansion server to register, how will it validate the identity certificate?
My head is hurting lol

 

[sizbut]

Automatically synchronizing User Rights would often be counter productive. Settings (mainly Short Codes and Button Programming) that are valid on one system are not necessarily valid on another. So yes, you have to do it manually.

"the Identity and CA certificates are not shared between the server and the expansion systems" - That would make no sense at all. The identity certificates of all servers have to link back to a common CA (the clue is that name 'Certificate Authority'). If using IP Office self-signed certificates, you have to pick which IP Office is the CA and use it to create identity certs for each of the IP Offices (yes, manually unless you want to explore SCEP for the automated issuing of certificates to servers on your network).

 

[john3voltas]

Shortcodes and Button programming does make some sense, at least to me.
And apparently it made some sense to Avaya too, because they created the "solution view", where you can add/edit most stuff that can be shared across systems.
But Security users and their rights is precisely one thing that made full sense to be shared across systems.

The way I see it, an Expansion system makes integral part of the Primary server. It's like in Aura having a gateway registered to a server. The media gateway provides hardware (PRI/BRI trunk ports, analog/digital extension ports, etc) to the server (software).
When I look at a Server Edition, that's what I see. But then we lack network-regions, network-codecsets and stuff like Security users not sharing the same settings across devices linked to the same SE instance.
It just doesn't make sense to me.

Also, I'm still puzzled on how IPO manages resiliency.
Are user/extensions supposed to be all created on the Primary? How does licensing work then? Let's say I have 100 phones. And that I created 100 users and extensions in the Primary server. If the Primary goes offline, will the phones try to register to the Expansion server? Even if the Expansion doesn't have any user/ext configured? Does the Expansion need any specific licensing in order for this to work? Because, resilience (if properly configured) should have made a backup of all user/ext to the Expansion. What is needed for this to work? I can't find this in the docs...

 

[sizbut]

Okay... I thought you meant user User Rights and not security User Rights. Sorry on that. But unless you have more than a dozen systems, I can't see the issue.

Resilience is covered, but so simple you may not have noticed. The license rights of the user and phones move with them when they failover. No extra licenses needed on the IP Office to which they failover. The IP Office to which users and extension might failover knowns that, so I assume that during normal operation there is some swapping of information just in case.

 

[john3voltas]

Oh...shut! Is that so? I mean I can create all my users on the server, add an expansion for analog extensions with a nice VCM card, and the extensions will move to the Expansion in case they loose connection with the Primary server? Sweat.
How about the SIP trunks? Do I need to set them up on both systems or do they work the same way as the extensions?
Thanks in advance.
Cheers

 

[derfloh]

SIP trunks have to be created on both systems. Be aware that failover to expansion systems only work if you have Select licensing. If not phones can only fail over to primary and secondary server.

 

[Travis Harper]

Also, the trunk licenses are split between them. If your capacity reqirements are 100 today on a single server and you add a secondary, your capacity per server is now 50.
Keep that in mind.

 

[derfloh]

You have to define how many licenses you want to consume on each server. So I would set primary to 75 and secondary to 25 channels - as long as the trunk on the primary server is the one primarily used for inbound and outbound.
This way you will have more available channels most of the time but will have channels available if primary is down. As the down state is hopefully only a short time in my opinion you can live with the lower call capacity at that time.

 

[john3voltas]

Be aware that failover to expansion systems only work if you have Select licensing. If not phones can only fail over to primary and secondary server.

Ouch. Didn't see that one coming...
Got it, Pri and Sec only. Expansion only if customer has Select.

Also, the trunk licenses are split between them. If your capacity reqirements are 100 today on a single server and you add a secondary, your capacity per server is now 50.
Keep that in mind.

Ouch, ouch, ouch.
Avaya could/should implement adequate licensing for trunk resilience.

 

[derfloh]

I'm with you. Having 100 SIP trunk channels licensed should mean to be able to have 100 trunk calls at once - regardless what system of the solution wants to consume that license.