CM SID CM SID wpetilli (TechnicalUser) (OP) 29 Jun 17 11:52 I'm migrating over a physical CM duplex 6.3 to virtual. Do I need to have a new/separate SID or re use? If new is needed what's the process to obtain that? RE: CM SID kyle555 (TechnicalUser) 29 Jun 17 13:07 Usually it's SID 1 nowadays. Pre-6 each PBX had a unique SID. You'd set it in the webpage server role page. If you upgraded a pre-6 system to 6, your xml license file might retain the previous SID of the system you upgraded entitlements from, so you might need to set it in the CM webpage too. RE: CM SID wpetilli (TechnicalUser) (OP) 30 Jun 17 02:57 So it sounds as if the SID is only relevant between the CM and LSP's it's associated, unless it's specified in the LF. I backed up the translations and restored the .xln file onto a spare CM (off network), via console. I modified the 'cha sys ips' field to disable IPSI control. The idea was to be able to restore these translations on my new VE duplex. I did a save trans and didn't realize the backup methods didn't provide an option other than scp/ftp/sftp. I thought I'd be able to backup locally.. guess not. In any event I did the 'save trans' and went to /etc/opt/defty and saw xln1 and xln2, but they were listed under the root ID to which I don't have the creds. Tried every combo I can think of. Is there any other way to peel this file off this box so I can restore to the new system? RE: CM SID kyle555 (TechnicalUser) 30 Jun 17 13:28 As it relates to ESS's and LSPs, yes, they all have their own MID, but the same SID. Pre-6, each LSP would get it's own license file and it would be like s1234m2.lic to say SID 1234, MID 2 and you'd need to match those in your server role pages. You still need to match them today as far as SID/MID is concerned, but they don't need a license anymore. That's why you'll usually see in your main license VALUE MAX SURVIVABLE STATIONS be something like 63 (max ESS) + 250 (max lsps) = 313*the total number of stations you have. You can backup locally. just use scp with CM's own IP and folder /var/home/ftp/pub :) * and remember, OS backup is IP stuff, Security is account stuff, XLN is call processing database stuff. Don't spin up a new vm on the same subnet as production and restore the OS backup. Bad IP conflicty things will happen. RE: CM SID wpetilli (TechnicalUser) (OP) 30 Jun 17 13:37 I think I tried that.. will try again. am I going to have the proper permissions to pull the file off the box? RE: CM SID kyle555 (TechnicalUser) 30 Jun 17 14:00 /var/home/ftp/pub is pretty open, and if admin was the account for the SCP backup, then admin's permissions are the one's used. Done it many times. RE: CM SID wpetilli (TechnicalUser) (OP) 30 Jun 17 16:31 That worked.. sweet to test an ESS failover the 'get forced' command is all that's needed? I ran it, saw the IPSI go in service to the ESS, but the phones are fluxed and won't register over. well a handful did, but they're not reachable. I let it sit for over 10 minutes and still they're in a wacky state. I failed back to the main for now. I have the backup server in the network region so that's not the issue. RE: CM SID kyle555 (TechnicalUser) 30 Jun 17 16:56 That'll force all IPSIs to the ESS There's a command to force failure of network regions too But if you got G450s to procr, that'll never totally fail it. I'd say disable ip-interface procr to knock the H323/H248 stuff out and get force ips all on the ESS, that ought'a fail'er good. RE: CM SID wpetilli (TechnicalUser) (OP) 30 Jun 17 18:33 hmmm.. maybe they were in a flux because the PE address was still reachable. One of the phones that were flaked said 'resources unavailable' when a call was tried. I have the ESS survivable processor set to intervening region 250. NR 250 has direct WAN to all other NR's. I didn't see your message about disabling the mains, PROCR for h.323 regs until late.