System Manager Migration 1

[trilogy8]

Hi all- I have a current SMGR managing 4 Session Managers and some other SIP entities. This was an inherited system with a bunch of stale data.

I spun up a new SMGR 7.x and don't want to migrate all the data. I want to manually start adding from scratch. To start I want to peel one of the Session Managers off the current SMGR and I'm just looking for the best way to do that.

1.I was planning to create the SIP entity on the new SMGR
2.remove the session manager entry from the current SMGR host file
3. remove the current SMGR entry from the SM host file
4. add the session manager to the new SMGR host file
5. add the new SMGR to the Session manager host file
6. run initTM

Also, should I delete all entity links on the current SMGR or any other reference to it?

Thanks for your help

 

[kyle555]

Hard to say.
Sure, add it to the new SMGRs hosts file and SMnetsetup on the old SM - that'll be all you need to get it up hosts-wise. Just depends on releases, what you were doing with it, certificates, etc.

it'll offer up a TLS cert signed to the same fqdn but from your new system manager as the CA. any entities or sip sets that trusted the old SMGR CA who signed the sm cert before would need the new SMGR CA cert.

If you had entities between all your SMs and you moved SM4, and only SM1 hit your SBC for example, you'd need to have routing in the new cluster to point to SM1 rather than rely on what happened on it's own when they were all together. Stuff like that - covering all your bases on your use case.

 

[trilogy8]

The plan was to move this 1 SM over and a lab CM. Once I get things where I want them I'd move the rest of the SM's all at once, since production things are tied to them. The SM I want to move isn't the primary connection point for anything. it has entity links to the other 3 SM's, but I thought I can just delete or disable those.

 

[kyle555]

so long as you thought everything through and have backups and backout plans, you should be OK

 

[jimbojimbo]

Make sure you migrate the licenses via PLDS since System Manager 7 will require you to have the Session Manager licenses installed.

 

[kyle555]

And I just played with 7.1 that came out this month and SMGR on its own as well as VMWare Utility Services not on AVP need a license. SMGR works like it always did, but does harass for a license. I'd presume it's a easy penny item order, but yeah... it wants a license now.

 

[trilogy8]

I know SM 7.x requires a license, but didn't think that with SMGR itself. My smgr is 7.x but the SM is 6.3.x. The smgr is barking about an auto file but that's it.

 

[trilogy8]

@Kyle - Just to be clear your stating if there are endpoints, trunks to other systems and other applications directly tied to this Session Manager that the new SMGR will offer a different certificate those other connection points would not have and then fail? If that doesn't apply to this specific SM, I should be able to move this w/o issue? Is it better to just delete the entity links one by one that this SM is assigned? There are entity links this SM has to the other SM's and CM's, but it is not a primary to any of them.

 

[dialtonebone]

@kyle555 - Did you find a way to edit the /etc/hosts file in SMGR7.1? It appears we no longer get root and need to start using DNS.

 

[trilogy8]

I'm able to get to root from mine and to the host file

 

[kyle555]

I did notice it was fighting me for root access. Nothing a CentOS live CD doesn't fix

But yes, DNS is vitally important. It isn't just for mapping host names to IPs anymore! It can be a means of validating that a server named "potato.com" at 1.2.3.4 with a certificate with "subjectaltDN" has "potato.com" and "IP=1.2.3.4" actually DNS looksup to 1.2.3.4!

Nifty though, 7.1 46xx lets you actually populate a hosts file in the phones...
SET FQDN_IP_MAP “sm1.avaya.com=135.20.230.199....

 

[trilogy8]

I've taken the crawl before walk phrase to new heights. I've removed any reference to this 1 particular Session Manager, disabled all entity links associated and denied new service to it since yesterday and I haven't broken anything. I have since deleted all the entity links it was associated with and all I believe is left is the SIP entity itself. My plan is to totally delete this tomorrow and then establish trust to the new SMGR tomorrow. Sound safe?

 

[jimbojimbo]

Security has become a major headache and Avaya documentation simply sucks.

Most clients now will do hostname validation (DNS) so the certificate must have a Subject or SAN to match. Additionally clients like Equinox want the SIP domain so add another SAN. While your at it try figuring out how to get the SIP URI for the ASBCE certificate.

Utility Server 7.0.1 and below will most likely have SHA-1 certificates. These are generated as part of the RFA Auth file so make sure you have the correct FQDN when generating the auth file. 7.1 is supposed to support third party certificates however I haven't had time to play with it yet.

Endpoints want certificates. I strongly suggest having SCEP setup on the network. When Avaya finally does support Mutual TLS you will want to make sure end users get a certificate (typically through Microsoft AD/CA Auto Enrollment.

Still need to validate if WebLM 7.1 has SHA-2. Has been SHA-1.

For most of my customers I recommend setting up SMGR as subordinate CA to Enterprise CA. Makes certificate publication easier and reduces complexity across products.

Might have strayed a little off topic here....

 

[trilogy8]

I was able to delete this SM and then sync it up successfully to the new SMGR. I now have the license error that was mentioned earlier. This was/is a Session Manager 6.3.18 and it didn't require licenses before. I was told Session Manager 7.x requires a license and that 6.x didn't. What am I supposed to do with this now? I purchased 1 new SM7.x and 1 upgrade from 6 - 7, so I have procured licenses for those. The others I was told I could leave on 6.3.18 and they can run fine on SMGR7.x, along side the new SM's. I'm going to be laughed at if I go ask for additional $.

 

[kyle555]

PLDS should have the entitlements for all the SMs you need. You may have activated the SM instances on your previous R6 SMGR and just need to rehost from the SMGR 6 host ID to the R7 SMGR license manager for instances you've got already. So, 1 R7 instance + 1 upgrade from R6 to R7 means 2 R7 SMs provided you had a R6 instance to begin with.

This is where ordering under the same FL#/customer # is important to match up "upgrade my widget entitlement" on 1 customer # to "1 widget at R6" ideally on the same customer # to be able to get 1 R7 SM instance.

That you could have installed 4 SMs at R6 without validating licenses (despite being supposed to have had them) with real entitlements for only 2 SMs means you perhaps used more than you bought in R6. Not enforcing the license restrictions doesn't entitle you to keep using what you perhaps hadn't been entitled to use in the first place.

Say having 2 SM entitlements in R6 and standing them up in data center 1 before building data center 2 as a clone to DC1 means you could likely have more than you're supposed to.

 

[jimbojimbo]

@kyle555 - Sorry but PLDS will not have the entitlements. These are Session Manager 7 licenses for existing SM6 systems. Since you already have existing Session Managers you would be entitled to a $0 Session Manager/Branch Session Manager 7 license for each one you have. Every SM/BSM on SMGR 7 requires a license no matter what version they are.

 

[kyle555]

I politely disagree! There were no SM6 licenses at one point, but later on there were. Despite them not being validated, I still have 271552 AVAYA AURATM SESSION MNGR R6 VE VAPPLIANCE SYS LICS, SR entitlements in PLDS. I can activate that entitlement on a WebLM. Be it on a SMGR7 to use SM6.3 on it or on a SMGR6.3 for it to never really count or care.

I think it's just SMGR7 that checks now for a SM license, regardless of SM version.

 

[trilogy8]

In my case we did purchase the SM's and didn't do any cloning etc.. Mine are still on the HP servers. There are currently no licenses applied to any of them. If I log into PLDS and search for assets/entitlements for SM you're saying I should see something there even though they were never activated or applied? Is there a specific one I'd need to activate and host for that new SMGR to be happy?

 

[kyle555]

If you have PLDS access for your stuff, then yes, I think you should have entitlements relative to what you purchased on your SAP order/LAC, whatever.
That said, as Avaya changes things and adds required entitlements, you might not have them had you ordered a long time ago. That should be a free item to order. Examples like AAM 6.2 didn't need an entitlement to do TLS. 6.3 did and it was a free item to order.

You sound like you need a sales or design engineer to look over everything!

 

[trilogy8]

When I log into PLDS there's a line item with has the Sold To# of this specific site SM. Would this be what I need to activate and apply? Only thing is this license shows as VE appliance and it's a physical server. Trying to avoid sales at every cost. As far as what we use SM for... it is only used for SIP trunks to CM, SIP connection to a voicemail system and Cisco VCS. We don't have any remote worker or carrier SIP trunks.

entitlement# 13032383
application: Session Manager
Product SM Virtualization Licenses
Product ID: 271552
Title: AVAYA AURATM SESSION MNGR R6 VE VAPPLIANCE SYS LICS, SR
version: any
type : license
Quantity 1 for any license type